Today was a rainy Saturday – which, once I had some caffeine to overcome the gloom, was a perfect opportunity to spend a number of hours working on Impulsing.

I started out in the morning looking back at the 2D version, as I had completed a number of levels there, some with components I don’t have yet in 3D. I decided that in order to get those levels up and running in 3D, I need only a couple more major components. So I decided to work on one of those today.

I came up with a simple design for it, visually, and got it up and worked out in Blender. It changed a bit as I worked on it. Sometimes you gain inspiration as go along. Also, what looks good in Blender – where you can pan, zoom and rotate – sometimes doesn’t end up looking good in Godot once you look at it in 2.5D at a fixed angle. You lose some of the visual cues that tell you what it is. Here is the new component, “Soojin”. (Code names abound on this blog.)

I got far enough as to get a new component created and integrated into the palette, along with a bare bones underlying node that doesn’t do what I want yet but gives me a place to “make it happen”.

Tomorrow, it will be “TDD time” to get the functionality in place. I thought it might be straightforward enough that I was tempted to just implement it. But then I realized that the behavior was more complex than I first believed. I need to think about what I really want it to do before I try to code it.

Despite having been a software developer for a long time, I have found game programming to be different in very striking ways. You would think it’s all just programming, but it becomes so much more. It might be because I’m actually designing the game as well, but I think it’s also more than that.

If you’re writing, for example, a paint program, as long as people can get done what they want to do in the software, it doesn’t really matter how you do it. You can even have a completely ugly but functional application. The important thing is the ability for people to use it as a tool.

When writing a game, though, you’re actually creating an experience. Just a bare-bones, ugly, functional game would work, but it wouldn’t do well. That’s not what people want from games generally. You need to not only consider what people will do but also how they do it and what they see and what they hear and how do they know what is going on and – most critically – does everything behave in a reasonable way?

My understanding of the elements of my own game has evolved over time and continues to do so. The more you dive into the details, the more you see. And what you have created – if you care about what the player experience is – constrains what you can create, because as you work out the rules and behaviors, the next set of rules and behaviors has to fit in with what you have created so far. You can’t just hack things on. You have to keep refining what you’re doing to avoid ending up with an unholy mess.

Sometimes, the design experience is revelatory. I didn’t know even all of what I have created in the game so far when I started this. The game itself presented issues that became design decisions as I solved them. Sometimes that was the most exciting part, when you come up with that answer to a problem and it’s not just a hack but something that emerged from what you’ve been working on in a natural way. Part of the work of design is seeing what the game is telling you and forcing you to face.

What’s interesting about that (and possibly sad) is that when the design decisions are so natural, nobody but you may ever realize what it took to arrive at them.

Day 3, over and out.