Small Game Series (2/10) - Schmup

It's time to close the book on attempt two of ten in my small game series. Considering I didn't ship anything for this one, another deep dive is in order to analyze the failure.

I'll admit to stretching the truth here too. I technically started a game in between the first project and this one, and it failed to pan out so quickly that I cut it short far faster than the two official projects. The secret second project was a tiny strategy game, and I just couldn't figure out how to go from zero to game fast enough.

Even though I'm only counting two of these attempts against my goal of ten, they're all worth revisiting. Elaborating every issue would take too much time and space, so this is a sample of things I noticed.

Screenshot of the main gameplay in game two
Screenshot of main gameplay screen in game two.

1. Even on the little things, design before executing

This is more about programming in general, but it's a lesson to re-learn every so often.

A lot of things look really easy to go and do by intuition alone, and the temptation is always to sit down and immediately start programming. If it's something done to the point that it's like riding a bike again... fine. But every single time I remind myself to do some focused thinking first, even as little as 5 minutes, the benefits outweigh the downsides of ripping out code on pure momentum.

I did do this more than before during the most recent game. I'd also argue it still wasn't done enough and with the proper perspective to make it clear how one session connected to the end goal of finishing the game.

What can be changed for next time? It's always hard in practice to stay mindful, though there are a few things I want to emphasize:

The first is fairly common advice while the second isn't something I've heard stated with quite that phrasing. Keeping complexity down is always useful. What's difficult, I think, is to make it so you limit the total space of necessary decisions.

Since I follow the Handmade community quite a bit, the suggested practice is to make your solutions as specific to the problem as you can. My objective with the second point is to extend this practice to the design space of the game (whereas the aforementioned practice is often targeted toward the code).

Which relates to the next issue...

2. A mechanic in isolation isn't worth calling a mechanic

In other words, don't tune a thing before putting it in context.

It was easy to get stuck fidgeting on the tiniest of things, and also as mechanics started to add up, and especially because it felt like I had to do it to make anything worthwhile. In reality, I could have made a couple bullet patterns for the enemy ships, heck even some "fancy" ones, and moved on to make getting the overall concept of a level in.

Instead I ended up spending most of the time (enjoyable time, which is why this one is so damning) building a little editor to visualize various bullet pattern parameters. The result was fine, but not valuable to getting something finished.

I justified this in the moment by thinking of myself as someone who needs to see the thing in action to better understand it. And this is true! In a game it's hard to judge without the interactivity. The problem is that it didn't operate in reference to anything else.

Screenshot of bullet pattern editor
Screenshot of bullet pattern editor in game two.

I also blame language used in game design for this as well because "mechanic" is used to describe absolutely any little thing that happens in a game. The trouble is that as players we typically perceive a unit of meaning as consisting of multiple interactive actions occurring. This is the same definition that ought to be used when talking about design, with some far less important word to talk about the truly atomic actions happening in the game world.

On the surface, this problem seems difficult to resolve. Some genres (e.g. physics-centered games) intuitively feel like nothing but little tweaks. Thinking on it though, there are a lot of discrete elements where it otherwise might feel like a continuous space.

Taking platformers as an example:

I could list a zillion other things, and many of these have a huge range they could eventually operate on. The point is that an imperfect version of all of these could be done in tandem with a design that uses them (either a level or a single trick or puzzle or whatever), and probably many of them before going back to make them feel perfect.

Again, it's a tough call because an untuned version of some of these could drastically change how the construction of other parts are built (such as the overall height of a level).

But that's also why trying to add more constraints as design is done, not less, is probably good.

3. Putting in the time is important, but so is using the right kind of time

I chose a 2-hour slot most evenings as my dedicated working time for projects.

When the evenings rolled around, I almost universally did not have the energy to work on anything beyond small bits of code where I 100% knew what I was going to do to implement them. This was true even though it's also the time I would be least bothered (kid asleep, spouse doing her own thing, and so on).

I thought I could make it work, except reality dictated that if anything else about the day was draining, it meant nothing left to get more creative or mentally engaged when it was finally project time. If you have a day job and a family like I do, it's tough to get around this.

At the same time, I do think it's possible to still get work done during these low energy times. It just requires picking the right things to put at the right times where your energy is best spent.

4. Some mechanics naturally take a while to figure out

After attempting a couple designs now, I don't know the point at which this holds, but clearly some things are harder to find the "fun" in or to discover the interesting parts of. The further you go from traditional tropes of a genre or try to break genre entirely, the more this likely holds true.

Even in staple genres this can be tough to deal with if a lot of scaffolding needs to be in place. Many genres have collision handling, and you don't need to be elaborate about it most of the time. Something like "destroy on colliding" are relatively simple to implement. Whereas others might have a huge set of things to do based on complicated physics, visual elements, or whatever else you might think of.

Again, this problem feels less obvious how to solve to me because I think a lot of rhetoric about game design these days comes from game-jam-length games where you're supposed to be able to "find the fun" almost immediately.

What that actually results in are games that come off "arcade-y", or one contributor was enough of an artist to pump out a huge amount of flash and style in a short period of time.

If I were attempting some kind of experimental game for example, I have a hard time seeing how you can find interesting gameplay in such short amounts of time while also worrying about something being shippable.

This might just be me though, and I haven't found a groove for how to think through design problems with this kind of clarity.

Debugging further

Talking out loud, while these look like big problems, they also seem to require something more like course corrections than heavy-handed solutions. The actually hard part is paying attention to the small changes at every micro-moment that they matter.

Avoiding getting stuck doing tweaky changes sounds obvious out loud, so how the question is how to maintain vigilance against it. Particularly when you look at smaller time scales and try to constrain how long you spend on some idea.

The best thing I can think of is to pay attention to the examples I gave earlier, which is to stop at discrete boundaries of things and let continuous parameter spaces feel crappy for a while until they matter (within reason... if you have the floatiest jumps of any platformer ever made for example, that of course changes the nature of the game design).

As for how to go about designing, there's a reality to grapple with where going further from cookie cutter elements of a genre might just demand a longer timeline to feel like the exploration panned out. For those of us with limited schedules, that kind of sucks, but it's at least an explicit problem that can be dealt with.

Perhaps related is a piece of advice from Ted Bendixson about having a goal and leaving when you accomplish it. I think this is quite useful for just about every kind of work you might do in a sitting because it forces the time to have a purpose other than to abstractly "make progress". And sometimes that goal can be to do a bit of creative ideation.

I used to resist this kind of thing with creativity-style sessions in particular because I thought it would clash with a certain kind of faux artsy mindset that creativity can't be planned and only every strikes when you least expect it.

Of course, what's foolish about that attitude is you can obviously carry a pencil and paper around with you to write something down if you need to. But for all the intentional working time where you need to get things done, you do have to learn to get your brain to think laterally when you ask it to.

Conclusion

So far, all of these forays were rather short.

Something I struggle with is exactly how much time to give to an idea in these initial projects. Tyler Gliel's article that originally inspired me to do this ten game series suggests a time limit of two weeks, but I suspect this assumes someone with more free time than with a family, standard day job, and children.

In Tyler's own words, he's been making games a long time and from a young age, and an early advance is always a big boost. Unfortunately, I'm getting older with various existing life commitments, and despite having loved games all my life and making some crappy ideas here and there, I never spent much time designing them.

I guess we'll see how these lessons and thoughts funnel into the next game.