|
Skulls of the Shogun is 17-Bit's first game as an independent developer, just launched on Xbox Live Arcade, Windows Phone, and Windows 8 (including the Surface tablet). When we left our jobs working at EA over three and a half years ago, we set out to revitalize one of our favorite genres, the turn-based strategy game (and specifically squad-based strategy games).
Skulls of the Shogun is set in the samurai afterlife -- dead samurai fight it out for all eternity in quirky, goofy, and eerie lands, with a nod to Japanese mythology mixed with a bit of modern humor. Players control only a handful of unit types, from the basic infantry, cavalry, and archer, to three different magical animal monks with upgradeable spells. The most important unit is your general, who is both the most powerful unit and the weakest, as the only requirement to win the game is to kill the enemy general.
Our goal was to take the gameplay we love, which is often thought of as being niche or only appealing to hardcore strategy fans, to more players. The challenge, of course, would be to not water down any of that strategy, but instead try to streamline it, teach to the player over time, get rid of a lot of off-putting genre conventions, and make it easier to jump into.
Given our experience working for large triple-A developers, we set out with a basic goal to build a vertical slice of the game, featuring a couple levels to test the ideal map size.
Over the course of the game's development -- and eventual broadening to include both Windows Phone and Windows 8 (desktop & tablet) versions -- we rigorously playtested and refined our design goals.
Arcade Speed
 Round 1! Fight!
Our first real design goal was to just take the genre and remove the cruft of menus that had accumulated in it over time. Selecting a character, then an action, then attack, then a weapon, then a target, etc., is fairly common user interface flow for this genre of squad tactics games. All of it feels cumbersome, and very little of it seems necessary.
As we playtested initially, though, this goal became crisper; we wanted to fuse the spirit of an arcade game into Skulls without sacrificing any strategy. After we had built our vertical slice of two levels (a small one and a large one, to gauge ideal map sizes), we imposed on ourselves a clear rule for any new mechanics -- no new mechanic could slow down gameplay. Defense was important, but even a defensive mechanic couldn't result in the bogging matches down by allowing players to "turtle."
We kept each round to only five moves per side, and limited resources to force a clear start, mid, and endgame. This kept the pace at a healthy clip and really allowed each player to stay informed of every change in the battlefield. Games tend to be more evenly matched, because even if one side has 15 players and the other has five, with five really well planned moves, you can still deal a ton of damage, particularly with mechanics like knockback and instant ledge death.
Ditching the Grid
In the name of speed, we ditched the grid-based system used throughout the genre. Direct control of units is just naturally so much more intuitive than the indirect control most strategy games offer you (selecting a unit, selecting another square to move to, then committing the action).
 An infantry at the edge of his movement radius.
Immediately the analog nature of the space opened up the possibilities of strategy. The gameplay was no longer about picking the perfect grid square, but about how you flank your enemy or fake them out, as it should be.
When people complain about too much complexity in strategy games, they usually point to these systems with many layers of rules. But that's not inherently something the human brain can't deal with -- if you go outside and play catch with your dog, both you and your dog are acting out complex physics equations in order to play. So the key in making strategy more accessible is to make it something the human brain has a lot easier time parsing.
By removing the grid, we made the strategy of army positioning more nuanced, and something players could more easily learn to intuit. There's a lot more room for finesse, and depth to how you maneuver your units, which people can pick up over time. As opposed to being presented with a ton of options or grid squares, each with their own set of data (advantages/disadvantages), these distinctions become easier to parse.
|
Can I just play it on windows platform straight up?
That's the basic idea of strategy, turn based tactics is what you achieved "I believe" (not having tried it). Accessibility of lukewarm tactical play, is pretty common.
But your artistic ideas are at least somewhat interesting, and the commercial appeal is present here. A bubblewrap popping game, great idea for a phone !
Will do, if I can get it for PC.
I consider both to be viable methods, but considering that being arcade-like was one of this game's design goals, going gridless was probably the right way to go. Though I haven't played it yet, so I can't tell whether it was implemented well or not.
Specifically, did you have any specific challenges that made you reconsider your choice of win8 as a platform?
Were there any libraries or dependencies that didn't exist you were expecting to be available?
Would you choose to develop the game for win8 if you had to do it again?
I ask because I'm on the verge of deciding which set of platforms the next big project will be on and I am considering including win8/RT.
As for the technical side, yeah, the lack of support of XNA certainly caught us by suprise. It was such a powerful library. It's cross platform nature made porting to the windows phone probably the easiest port I've ever seen or done. (Literally it was only a matter of days before it was playable at an ok framerate - it took a few more weeks to really optimize for it, but all told that's a small amount of work to take a console game to a phone). Since we use C#, it was also a little dissapointing DirectX API functions aren't directly exposed to that.
But thankfully we were able to port to Win8 using the open sources libraries SharpDX (a C# interop library to access DirectX) and MonoGame (an open source version of the XNA API). Now, this was before MonoGame had been ported to Windows 8, so it took us a few weeks. Not too bad, but now MonoGame has Windows 8 support in it already, so if you're using C#/XNA, you'll have a leg up porting to Win8 now.
We also had to spend a lot of time optimizing for the lower end graphical hardware on ARM tablets and the very-low end x86 tablets. On the phone we get aware with things like 16-bit color and half-resolution textures, which you can't notice as much with the small screen. And, like most high-def 2D games, we rely on many visual layers for effects like lighting, weather, etc. This can cause issues with graphics hardware that has very low fill rate. So we had to optimize for that scenario specifically for that kind of hardware.
But as for sales, since we just launch last week, we'll have to see. Hopefully we'll have more info for you in a post-mortem or future article.