Day 3: Build the Gameplay

I spent this Sunday doing most of the stuff that was directly related to how the game plays.

First, let's begin with the less-juicy part. I started adding very basic text support to the game-sketch system itself, which serves as basis for everything I've been doing. As I explained before, the system intends to emulate part of the Processing 2.x API. For that, I also needed to basically remake part of my old font system I did for a C++ engine back in the day. For that, I also had another game in Common Lisp which I partially used as guide, however it did not have full ASCII support, and only supported numbers. I managed to implement that, but there is still a weird texture bug which I believe might be related to the way I'm uploading textures to the GPU or to the way I'm calculating texel coordinates. No matter the reason, I still have time to figure it out.

Of course, I couldn't just get stuck on that. I still needed to think about my game itself.

As you can see on the video above, today I managed to add a new type of weapon and started building a very basic (and still very ugly) heads-up display. The new weapon was a torpedo, which I already planned before; the torpedo itself uses the same projectile pool as the main weapon (the machinegun), however it also has a cooldown system. Oh, and of course, though I haven't demonstrated it, I also added a nice pause feature; for that, I had to fix a nasty bug on the single-keypress detection. A small tip: in Common Lisp, instead of trying to clone a list of pairs, represented as cons cells, with the copy-list form, use the copy-tree form instead, or else the copied list will just include the same cells of the first one: changing a cell in one will also change a cell on the other list, if you aren't careful about that. Heh, just when you thought you're not dealing with memory pointers, surprise, you actually are (and that's fine by me, a good game developer shouldn't be afraid to deal with memory pointers, in my not-so-humble opinion).

Tomorrow, I'll have less time to work on the game, if I'll even have any time; I'll probably only work on it at night, but I'll try my best to.

The next big challenge will probably be the whole level layout itself, which also includes obstacles/enemies; and that needs some careful approach due to the movement mechanic of the ship. The enemies and the obstacles should match whatever challenge resolution I'm trying to require from the player, and so their form must follow their function (thanks for that, Scott Rogers). I also like the deterministic scroller approach, but I also want the game to be dynamic; so it should probably be interesting to just script WHEN certain obstacles will appear, but not HOW they will appear (e.g. at a certain point, three enemies with the same movement pattern will appear, but they may appear anywhere on the screen, as long as it makes sense). Other lesser challenges are a main menu, and maybe a pause menu. I also need means to restart both the game and the level in runtime, probably from said pause menu, and that all shouldn't be hard to implement (as long as I get the text thing working).

I think I also need to edit a little this itch page too. I mean, I haven't even named the game yet. I was thinking about Moon Assault or even Orbit Defense Strikeforce, but these names might be lame (though I do like the last one, I'd probably use it if I were developing a game for a larger time).

Oh, and of course! Those useful links from the first post... I've added them to the game description now.

Well, that's it for today. See you again tomorrow.