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.

No fancy graphics today.

I spent the evening getting the “Owen” node hooked up to the higher-level “Owen” component. I decided to have this split from the beginning between the underlying graph nodes and the higher-level UI/game components. It has served me well so far, especially since a serialized Godot component is a huge mess. It’s amazing how much “stuff” it writes out.

Once I got the node hooked up and loading from the palette, I found some issues I had to fix, but it all went smoothly.

I have a Trello board with next steps. I need to add some more, as I know there is more than three things left to do. One will be to create some new levels with this component and make sure it serialized properly. I haven’t tried that yet. At least I have a plan for tomorrow. (Saturday! Yay!)

Hey, look! There was a graphic after all. That’s the editor component palette so far.

I decided to give the #devtober game jam on itch.io a try this year. It popped into my inbox, and it sounded like it might be a good experience. You can read more about it here: https://itch.io/jam/devtober-2020. Basically, you just work on your game each day of October and blog about it. Then in the end you write a post-mortem. I have been working on it almost every day anyway, but this makes me write about it, too, and maybe some people will read along.

This is day 1.

A month to go.

Given that this is the first real Impulsing posting, I probably should give a little information about it. I would love to post images, talk all about it, and get everyone excited (or bored) by what I’m doing. However, part of the game is figuring out what it all means, and talking about it too much could spoil that sense of discovery. So I need to be a bit guarded.

Impulsing is a puzzle game I have been creating off and on for over two years. Probably closer to three now. Part of that length of time is that I’ve been working only on it in my spare time. Another part of it is that I have been working on another project as well at the same time that has been taking priority. Another part is that I actually gave up on it for a while before a mental “eureka” moment happened, which provided a breakthrough to a tough design problem and got me back into it with real energy.

It went through a number of (crude horrible) prototypes in HTML and JavaScript before I began to cause my CPU usage to go through the roof. Time to get more real.

I dabbled in Unity for a while before my struggles to do simple things put me off it. I am now using Godot, and I’m much happier with it, though it too has quirks that drive me bonkers at times. (One example: I’m using resources to read and write levels, and there have been times where the game crashing has trashed the current level resource file. And the Godot editor/system seems to still have it open – if I restore it from git, it just overwrites it again whenever I do anything. I have to shut down the Godot editor before I can restore the file.) However, there is a lot I really like about Godot, like its nested scene/component model.

The game started off life in 2D, and I sent around a small prototype to some people I know. For various reasons, I decided to move to 3D.

One reason I did is that I’m “better” at making 3D art than 2D, even though I was using Inkscape to create SVGs. I enjoy using Blender, I can produce some nice (if simple) assets, and I want to get better at it. Also, the 2D game was top-down, and it was just too limiting to try to make things look good and interesting looking straight down. Now with 3D (really 2.5D), I can have more depth and make things easier to understand. And lots of interesting 3D assets to use, if desired.

Original 2D game:

Current 3D look:

Another reason I switched to 3D is just to experience using 3D. I don’t know if this game will ever amount to anything, so I’m really using it just to learn about a wide variety of things.

That’s a brief overview. That’s all I’ll say for now. What did I do today?

I’m working on a new component called “Owen”. All right, that’s not what it’s really called. That’s just its code name. I just made it up.

This is what it looks like, so far. It feels too bulky, but… get it working first. tweak later.

I have made a point of using TDD to drive at least the complex parts of the game, like the graph and nodes. I’m using GUT in Godot for my unit tests. Today was working test by test to drive the component’s code. As often happens with TDD, suddenly it was just working. And I had the tests as a testbed to show me it working, outside of the complexities of the game. Faster turn around. Faster development. A bit more code in the end, but probably less typing. And I know, at least for the test cases I have so far, it works.

Time to step back from the screen before heading off to bed.