Outsider Design Journal By Someone Who Never Learned Best Practices In Any Relevant Discipline

This is a blog about a small (for now) game project I'm working on, that started as a way for me to learn how to use GM.

Since it's the first entry, we'll start by talking about some design goals

1. The design is simple at its core.
This is less a goal and more just a part of the genre I'm aiming for. Easiest way to describe this thing is that it's like Asteroids, the old Atari game. If we go beyond the prototype stage, there will be more to it than that, but the core will remain the same.

2. Player inputs will remain simple and intuitive.
I will definitely be adding mechanical complexity whenever it's fun. I love simulationist design, for lack of a better term. But that shouldn't require complex player input. Everything the player can do is mapped to a key, almost nothing should be contextual, and no HUD should be necessary (aside from occasional text for dialogue or notifications). Everything the player needs to know to play the game should fit in a single list of keybinds on the pause screen. Any knowledge beyond that is gained through experience, and so must be intuitive.

3. Only keyboard controls
Should be easy for this project. Mouse input isn't necessary. Any added menu screens will be navigated using obvious hotkeys. I want something immediately accessible to anyone with a laptop.

4. Whenever possible, everything should be able to interact with everything else.
Player-on-environment interaction is a given, but environment-on-environment almost always makes things more interesting. This is what makes the play space feel dynamic. Within reason, if two things should be able to physically affect each other, then they will.

5. I do not want to artificially limit the player's power in any way.
No cooldowns, no limits to how much the player can utilize any power they are given. 
My first prototype of this project had a heat mechanic which meant that firing or using an ability for too long could cause your ship to overheat and power down. This was actually pretty fun, and tense, because you had to manage every action pretty carefully, and think ahead about what risks you wanted to take. This time around, I've opted to go in the opposite direction. I'm not going to "balance" the player's power downward by fettering abilities in any way. You have a shield that makes you invincible that you can use for as long as you want. You can teleport as frequently as you can press the button. Same goes for weapons, for the most part. The goal is to not limit the player, then design everything else around it to still be challenging. My hope is that the end result will be gameplay with a very high skill ceiling, with a limit only determined by the player's reflexes. 

2, 3, and 4 constitute part of a general approach I would like to use on future projects, as well. 2 and 3 shouldn't be especially difficult because of number 1. 4 will be complicated, and will only get more difficult as I add content.

The screenshots really drive home how terrible the video quality is in this recording...

So last week, I started working on randomized 'level' geometry using these floating blocks. I wanted them to connect to each other to form larger shapes. Initial attempts to make that work the way I wanted were a total mess. They would end up chasing each other around the screen, and weren't connecting properly anyway. In the end, I went with something simpler, and just leaned into the overlapping that I was initially trying to prevent. There's a bit of a trade-off, because the large clusters of them look better, but altering the code to make loose formations results in more maze-like patterns. I wanted them to look like miniature stations collected together, and I was listening to the Akira soundtrack the whole time, so naturally I envisioned a floating neon city. So this is my current, programmer-art, version of that. There is still way too much repetition, but even this amount of sprite work took most of the week. Animating a bunch of lights at 30 FPS is tedious. I knew that I shouldn't be working on minute aesthetic details this early on, but I just really wanted to see what this would look like. In the process, I think I went a bit crazy on the details. Also tried adding some random scaling to the objects to increase variety, but that seems to result in a lot of tearing, which makes the whole sprite look like it's flickering.

Currently, the blocks search for another block to attach to whenever their timer goes off. If another one is in range, it will change direction to move toward it, and stop whenever it's close enough. Pretty simple, and works more or less how I want it to. In terms of design, the main outstanding issue with this is that it creates collision problems which may be more of an issue later on. Because a block has a specific direction that it has to move in, it can't be stopped by bouncing off anything else (without needing to add complex pathfinding code). Anything that hits it will either be deflected or obliterated. In fact, if another object is unlucky enough to be in the block's direct path, it has a tendency to get stuck, draining its HP every step. For small objects, this isn't a huge deal, they can just be destroyed in the process. But if, for instance, I want to have large asteroids or any other solid shape that isn't destructible, we're going to run into some serious issues.

An alternate method would mostly eliminate this problem by simply cutting out the blocks' ability to move toward each other. Instead, they simply stop if they ever overlap, but don't actively seek out a connection. This means I could still have bounce code for them without having to worry about what direction they're moving. Of course, it has a huge effect on the sorts of patterns that are generated: we're more likely to get small groups of blocks that are more spread out, rather than congregating in one or two areas. And connections are just generally less likely to happen. 

 So far this week, I've mostly been torturing myself with sprite work, and trying to add more variety to the asteroids. Instead of two sizes, we now have four, and each one can create instances of the size below it when destroyed. The two larger sizes definitely needed explosion sprites to look right. In my previous prototype, I used a single generic effect for this and scaled it when necessary. For some reason, this time I decided to hand make a separate sprite for each object. It looks nice, but takes way too long. Fortunately, even with only three types of the largest rock size, things already feel much more varied.

 So here we have 3 frames of animation out of 15 for a single sprite. That's 1/4 of a second of animation. At that pace, it looks pretty smooth, but the details are almost imperceptible, given both the speed and the size of the sprite on screen. I can really see why most games either use a more pixellated style, or fewer animation frames. I definitely want to use a lower resolution for my next project, as it's much easier to make things look smooth. I'm sure a real animator could finish this stuff much faster, but it takes me a while. Let's not even talk about the little blinking sign on one of the station sprites, which ended up taking 127 frames of animation, and an entire day to finish.

I toyed with the idea of trying to use a single size object for all asteroids that was randomly scaled, and then tying its stats to its size through the code. But once again, scaling the sprites seems to result in a lot of weird flickering and tearing, so it's back to just making everything by hand. This is partially an issue created by the wire-frame aesthetic that I'm running with, because it results in a lot of isolated lines that are only a single pixel wide, and can't rely on blending into the colors around them.

Also debating whether there is going to be any background music. Originally, I was thinking of not having any in favor of just regular sfx and ambience. But listening to a lot of soundtracks while working has me reconsidering. So the other day, I looked up some traditional Japanese folk music from the 1800s - public domain - and started stretching and distressing it to see what it would sound like. It needs some new instrumentation to really fit in.

There are a lot of directions I could take with the soundscape. Right now, I'm learning toward mostly electronic ambience, with some reverb-heavy live jazz in the background. A good excuse to break out my tenor. If this project ever gets finished, it's going to be about a self-serving drifter caught in the midst of a class struggle, and the soundtrack for a stereotypical neo-noir sort of writes itself.

Also recently added my cat to the game, just because.

He is indestructible, and can pretty easily kill anything else just by running over it. Right now, he will follow you around, and sometimes chase down enemies if he feels like it. Later on, he will have more of a mind of his own, sometimes flying off to unknown places, or doing whatever else I can think of for him to do. Like breathing fire.

Another issue that I've run into, which is now obvious, is relying too much on flashing colors to achieve the look I want. It looks nice in-game, but it does not screenshot well, and is even hard to record video of, because of changes to the framerate. It's not on my list of things to address, but something to keep in mind for future projects.