Category: Game Design

The player can control the tank, including firing bullets. I’ve also added boulders.

They are randomly placed in the environment, and when the player passes them, they are removed from the game. If there are no boulders left, more are generated.

Collision between the player and a boulder is deadly, as demonstrated by the randomly controlled tank in this video:

I had some difficulty with handling bullet collisions with the boulders. Right now, they shoot right through them. I want them to disappear. Boulders are not affected by bullets. I have plans for boulders interacting with enemies and explosives, though. If an enemy hits a boulder, I think it would make for an interesting mechanic if the boulder starts to move towards the player. Explosives should be the only thing that destroys boulders.

My current plan:
– get the player’s character in the game
– make it controllable
– add obstacles (most likely boulders)
– make collisions between the player and obstacles deadly
– make collisions between bullets and boulders result in bullets disappearing
– add an enemy
– create a wave of enemies
– create a way to modify the wave of enemies so each enemy evolves in some way

One thing I was hoping to use was my component system, but so far I’ve represented bullets and boulders as positions, along with constants representing their collision radius. It’s working well enough.

Once I get bullets working right (I’ll need that collision detection working for the enemies anyway), I can finally start working on the first enemy so I can get around to doing some evolving.

So while the pasta was ok, apparently I was still hungry.

As for the game, I realized that my code that wraps libSDL and allows the rest of the code to be easily unit tested has a problem. It only knows if a key is currently being pressed or is currently released. It has no easy way to tell if the key has just been pressed or released.


case SDL_KEYDOWN:
{
m_keyboardState.setKeyDown(event.key.keysym.sym);
}
break;
case SDL_KEYUP:
{
m_keyboardState.setKeyUp(event.key.keysym.sym);
}
break;


Typically you would check SDL_KEYDOWN/SDL_KEYUP events in the event pump, and if those events occurred, you could handle them directly. Since I wanted my code to be unit tested, I created a HardwareLayer that wraps all of this functionality, and I used a KeyboardState class (that’s m_keyboardState) to track key status. Then, in my game, I can check the keyboard state for individual keys to see if anything is being pressed.

What this means in practice is that SDL is already creating an event for a key press/release, but then I ignore the existence of the event, tracking only the status. If I want to know if a key has been pressed this update, I essentially have to write code to track the state of the key and do a few if statements to know if I’ve already processed it or not.

But why do that when SDL has already done the work for me?

So I’m modifying my keyboard state to track not only the status of a key, but to also track the fact that it has been pressed or released this update. Then my game can check for this list of events, do whatever it needs, and at the end of the update, the keyboard state will clear out the list.

And this is why LD is fun.

My back started to hurt, so I tried resting. I even retired to the bedroom, but I brought a notebook and pen with me.

Pro-tip: pens stop working if you are writing on a notebook you’re holding out above you as you lie in bed.

Anyway, I realized that it was getting late, so I had a quick dinner of leftover mostaccioli:

I have a couple of pages of notes, and I’m aware that I could easily take this “simple” game and evolve it into a monster.

But those notes are details. I’m sticking with my plan, and I still need to make the tank controllable by the player before doing anything else.

The first lunch of the compo:

That’s a peanut butter, banana, and raisin sandwich. It also has some cinnamon sprinkled inside. And some carrots and broccoli on the side.

As for the project, here’s what I’m planning:

– get the player’s character in the game
– make it controllable
– add obstacles (most likely boulders)
– make collisions between the player and obstacles deadly
– add an enemy
– create a wave of enemies
– create a way to modify the wave of enemies so each enemy evolves in some way

That last bit hopefully doesn’t become too ambitious. There’s a lot that could be decided here. For instance, maybe the attributes of every enemy that makes it past the player or causes the player damage more heavily inspire the evolution of later waves.

But besides that, I should probably figure out exactly the kinds of things that can be evolved. Here’s where I worry about how limited the evolutionary changes can be. There’s only so much procedural work I can leverage. There’s still the decisions I have to make for what that procedural

For instance, enemy health can increase as new waves arrive. What about enemy armor? Should I include it, or is it just the equivalent of more health? Weapons could get stronger and faster, but what about allowing angles? Homing missiles? Spray guns vs lasers vs explosives?

If I decide to include explosives, then the radius could be one of the attributes that changes, but the decision to allow explosives in the first place means that the potential for evolutionary changes is limited by what I can implement on my own, and the procedural stuff is less interesting than merely tweaking some values.

But I’ll worry about it all once I get something playable.

So I finally have a scrolling background:

It’s that 1600×600 image from my previous post, seamlessly scrolling.

Next up: putting interesting things on it.

I went to take a shower, and in my haste to dry off and get back to work as quickly as possible, I hit my knee against the counter. Apparently not the first injury of this LD, and probably not the last.

Wanna see? Warning: I was naked when I took this picture.

It hurt a lot when it happened. It’s not bleeding profusely, but I see it is going to leave a bruise.

But it won’t stop me. I will carry on. I will develop a game.

But I worry how much of a mess I’ll be by the time this is all over. Between my hip/back tightness and this knee, what’s next? Lunch is in a few hours…

Anyway, before that shower, I created a background for my game.

Oh, that’s right. My idea: a simple side-scrolling shooter, where the enemies change movement, attacks, armor, and size as the waves start. Essentially, the evolution is in how those elements change in random ways. I’m also thinking that if you defeat an entire wave, you should get the chance to evolve as well.

So I’m not sure if I should go with organic characters or machines. A player-controlled tank means less animation, but then, why not just set the game in space? Whatever. This game is on the ground. A grassy ground.

OJ and a mixed cereal. One cereal has a lot of protein and fiber. The other has a lot of B6, B12, and iron.

My wife suggested the idea of “Evolving Doors”, which I think is brilliant because (1) it suggests a game play mechanic of choosing to go through doors to evolve and (2) it makes for an excellent play on words.

Before I went to bed, I started working on getting a skeleton project up and running.

I know. I know. It’s supposed to be one of my pre-compo checklist items: “Is your build environment working? I’m using CMake, and I should probably prepare an LD24 project beforehand so I’m not wasting time trying to get the build scripts to work when I could have a buildable project with a blank window from the start.”

Well, I didn’t. So I spent the first few hours getting a window up. Basically, I took existing scaffolding code (a basic Game class, Command/Event interfaces, stuff like that) and slapped it together as minimally as possible until it could build successfully and leave me with a window that shows a title screen and can exit properly.

The title is…evolving.

But the actual game design? Still only ideas right now.

I figured that a lot of people might try to make a Spore clone. I’ve seen quite a few screenshots with little primordial oozes as playable characters, and presumably you gain abilities, appendages, and interact with other units that might be more or less evolved than you. While I’m excited to play some of these games, I’m not sure Yet-Another-Variation would be interesting to work on.

I like the idea of an evolving landscape. A tile-based world that starts out with only one kind of tile with certain attributes, but as you explore it, you come across evolved tiles which might have new attributes or changes to existing ones that might impact movement, health, sight, sound, etc. And if I do it right, no two play sessions will be the same.

In terms of engineering, experimenting with neural networks might be fun. Maybe let the player pick a trait, and then have the system go through a few iterations to find out how healthy it is compared to others. On the other hand, that sounds like a lot of uncertainty and an unfinished compo entry.

Anyway, I’ll think about it some more over breakfast.

So, the theme was announced, and it’s Evolution.

Now, Evolution is the theme that was the Susan Lucci of Ludum Dare themes. It always made it to the final round of theme voting and always lost out.

Until today.

And somehow, I’m unprepared for it. Out of all of this LD’s themes, Evolution was the one I hadn’t given much thought to. And I even voted for it!

I’m a little worried about this compo. This morning, I woke up with pain in my hip and back. Walking is awkward, standing is difficult, and sitting seems to make it worse. I don’t know how much time I will be able to dedicate this weekend if I can’t be in front of the computer.

But I’m sure as the weekend evolvess (see what I did there?), things will come together. I’m going to spend the first few moments just thinking about potential design approaches.

Good luck, Ludum Dare participants!