Dev Blog 005: Testing Space Clunker

Gameplay is an obtuse word.

I use the term gameplay a lot, holding it up as the most important aspect of a game, but it's rarely defined.  That's largely because it's a very different thing depending on which game you're looking at, and thus its hard to capture with a single definition.  Even after holding it on a pedestal for so long, I feel ill-equipped to define it, as I tend to operate far more on instinct than studied definitions.  I'll try though...

Good Gameplay: the combination of smooth controls, reliable response, and intuitive goals that make an experience continuously fun to play.

That's an okay definition I suppose.  It doesn't effectively grab variations of exploration gameplay, social gameplay, open-world gameplay, etc., but it does tap into the most common things being referenced when someone says the gameplay isn't working.

It's perhaps a bit easier to spot from the other side.  Some common symptoms of bad gameplay:

  • There is a delay between you trying to take an action and it succeeding.
  • There is a lack of effective feedback on success vs. failure of an action.
  • The character keeps accidentally doing things you don't want them to.
  • The actions you take are frequently similar, with little to influence varied strategy.
  • There is a lack of ability to impact results through choices you make.
  • The goals are difficult to identify, or your control over them is inconsistent.

Some projects stumble into bad gameplay simply because they spend most of their time focused on the larger picture of the game, building wide systems or creating content without spending enough time thinking about the moment-to-moment feel first.  If you go too far down that road, it becomes very difficult to go back and focus on the gameplay afterwards, because the implications on changing the rest of the game can be monumental.

Some projects stumble into bad gameplay because they heavily prioritize realism or convincing animations early in their process, which interestingly enough can fight heavily against smooth gameplay.  Pressing a button on a controller or keyboard takes a fraction of a second, so a 1-2 second animation standing between that button push and a sword swing hitting your enemy can actually be really damaging to an action experience.  Locking the player in animations they can't break or escape from can be even worse, because that both fails at responsiveness and at expectations of what a real person would be able to do at the same time.  You can try to embrace this, as with Dark Souls, but without a lot of attention it often ends up clunky and horrible.

So my simple advice for landing good gameplay is this:

  • Focus on moment-to-moment gameplay first, before building the rest of the game.
  • Think about what elements are critical to proving the gameplay.  1 environment?  2 enemies?  3 player abilities?  Don't get lost in building more than you need until you're sure about your gameplay.
  • Stay with this focus until you've found something that's fun to play in a vacuum.  No deep story, no pretty art, no dependence on rewards to motivate.  The core every-moment experience should be fun without all of those things.  Get experimental if you have to to find this.  It could reshape your whole game when you do.
  • All actions should be immediate and responsive.  Code efficiency and client-server delay are serious issues to address early in this territory.
  • The player should feel in control at all times.  Break physics rules and animations as necessary.
  • Little things matter.  Pay attention to feel.  You may be able to write off small dissatisfaction in content, but you should take it very seriously in core gameplay.

Some experienced developers will disagree with me on some of these points, but I stand by them.  There are other ways to achieve good gameplay, but they're often fraught with peril.

Okay, let's get back to working through Step 4. 

  1. Decide on the goals of my project as a whole.
  2. Brainstorm more ideas than I need.
  3. Create a list of questions I will use to test the strength of my ideas.
  4. Use those questions to filter my ideas down to a top 3.
  5. Research similar games to see what I'm up against, and what to avoid.
  6. Choose the single idea I'm going to dedicate myself to.
  7. Build a prototype of a section of core gameplay.
  8. If solid, start the project.  If not, fall back to one of the other ideas.

The first idea I tested is was a concept idea, focused on a general story and character, with only a vague idea of what the gameplay would be like.

This is an idea focused heavily on gameplay mechanics and systems, with specific ideas in mind for how it would be satisfying to play.  As a contrast the previous idea, what it lacks is that effective 'skin' to make it relatable and interesting to someone just hearing about it.  So I'm expecting the test to highlight very different things for this one.

Space Clunker.  Seeking fortune as a novice space pilot, slowly accumulate mix-and-match ship parts that help you brave the dangers of space.
  1. Can I pitch this idea to someone in 2 sentences and get them excited?
    • Mmm, not yet.  On the surface, it reads as a pretty unoriginal idea, as it is mostly trying to wrap a weak justification around specific gameplay.
    • Given time, I could come up figure out an interesting story concept that has some emotional connection related to the gameplay, and put on the surface to help make the idea pitchable.  I have some general worries that spaceships, asteroids, and aliens are hard to make appealing to the masses, even among gamers.  The emphasis might need to be on other aspects of the game.
    • I could get a bit risky and try to pitch the idea based on gameplay.  There might be a describable version of it that actually stands out, but past experience tells me that's rarely the case.
    • Knowing that this idea is hard to pitch, I might also consider an alternate approach of submitting it to indie competitions or something similar, to try to generate interest and word-of-mouth.  Perhaps a hard road, but if the game is strong enough, it may be a reasonable avenue.
  2. Do I know how I would hook people with a trailer for this?
    • Nope.  Strategy and custom-building gameplay tend to look pretty lackluster in trailers.  If you combat or discover portions end up visually appealing, I might focus on them.
    • I'm certain there would be a gripping trailer idea somewhere along the way, but I expect it to be a challenging portion of selling a game like this.
    • I'm willing to accept that I don't need to know the answer to this to be willing to make the game.  Just something to keep an eye out for.
  3. What other games are similar to this?  How do I stand out by comparison?
    • FTL.  This would stand apart through its extensive ship customization (parts, overall shape), a greater ability to express personalization in the process, and a greater variety of encounter mechanics.  The gameplay would actually feel very different in practice, though comparisons would inevitably be made based on the general theme and likely camera perspective.
    • Galaxy Truckers (Board Game).  Some of the inspiration for this comes from Galaxy Truckers.  The main advantage this game would have is that it would translate some of the key gamplay appeal from Truckers into an environment where the game itself could handle a lot of the more complicated mechanics, letting the player focus on the fun parts without the nasty learning curve and logistics.
  4. Do I know how to start building the core gameplay for this?
    • Make a simple representation of a ship with multiple parts/rooms.
    • Create basic concepts of functionality for those rooms like shields and weapons.
    • Create a couple hostile events to overcome.  Start with flying through an asteroid field (shooting them down, shielding impacts).
    • Start adding basic customization of placing rooms/parts in different locations with the goal of yielding different results for those pre-made encounters.
    • Expand encounter types and customization options, following the most compelling gameplay along the way.
    • Start stringing a meta structure together where encounters are initiated and you can progress through multiple in a chain.
    • Start hooking up the customization options as rewards for encounters.
    • Start randomizing the encounters and rewards.
    • At that point, most of the core gameplay should have made itself clear and it should be well on its way to being a fun game.
  5. Do I see potential to discover new gameplay as I go with this idea?
    • Absolutely.  There's a ton of potential in the customization, in the encounter types, in the long term campaigns.  It's easy to imagine integrating ship-boarding, or relevant planet-side portions of the game.  There are a ton of places to take it depending on what is fun and what is reasonable for scope.
  6. Is this idea bringing something unique to the table that other games haven't?
    • Yes.  The appeal definitely shares space with some existing games that I've had love for, but accomplishes it in a way that I haven't played elsewhere.
  7. Does this idea bring more value to the player than just passing entertainment?
    • Yes.
  8. Is this a game I'd need to maintain after shipping?  Can I do that?
    • It's a very expandable game, but it could also ship as a self-contained package that shouldn't require much additional maintenance.  Could go either way depending on success or lack thereof.
  9. What's the basic art style for this game?  Do I have what I need to accomplish that?
    • Perspective-wise, it could work with anything from a pretty basic 2D overhead art style that I could accomplish myself to an isometric 3D perspective with more detail.
    • I think a very final version of this game could be made with a very simple art-style, but I could also seek out an interested artist to bring it more visual appeal.
  10. Do I have the right people on my team to build this?
    • Potentially soloable.
    • The heavy system interplay and the procedural content strategies suggest that I might want to explore some more experienced engineering help if I want to have confidence in a non-lengthy development time-frame.
  11. Do I have the time to build this and remain financially stable?
    • Yes.
  12. What is the smallest possible version of this game that could be justifiably complete?
    • It's a game type that suggests heavy replayability, which demands effective procedural methods and content variety, preventing there from being an extremely small version of the game.
    • Past that, once a critical threshold of content and customization options are attained, everything from there is incredibly scalable without any painful impact on the project in the process.

I like this idea a lot.  It's hard for me to imagine how I'd pitch it or sell it in trailers, but those are challenges I'd be willing to take on.  Otherwise, it hits many of my gameplay ideals, and of all the ideas on my list, it's probably one of my best chances at a project I might be able to actually solo with minimal contracting of key art, etc.

I should probably look around at how other strategy games market themselves.  Maybe there are some good ideas out there.

I'm disliking going this detailed on the test.  It comes out a bit dry, and the realizations are pretty isolated.  Still, I'm posting it just in case some part of the thought process that I assume is straight-forward actually proves informative to someone.  I think if I went through all of this again, I'd definitely do it differently, but there's no need to idealize that until next go around.

I'm curious - have you ever seen a good trailer for a strategy game that interested you in a game you weren't already going to buy?  Is there an effective way to entice non-strategy-gamers into these types of games to give them a try?



[My thoughts and opinions are my own.  They are not those of Blizzard Entertainment, and they do not necessarily represent Blizzard design philosophies.]