48 hours of game development has been condensed into a little over a minute and a half of video.

It looks as if a lot of the creating parts happened in small bursts of a few seconds, done around IRC and eating. B-)

It is done.

It doesn’t have nearly as much as I wanted. I had design notes for different enemies with different movement patterns, weapon types, power-ups evolutionary upgrades, and bosses.

What I do have is a basic enemy that gets more and more health and moves faster and faster in each wave. You have three lives. And each killed enemy gives you 10 points.

It has some basic sound effects.

And you can get the files here:

Windows .zip 5.2 MB
Linux tar.gz 4.7 MB
Source .zip 4.0 MB

And now, I will celebrate with a peanut butter covered chocolate chip cookie.

I managed to get a lot accomplished in a couple of hours.

- 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
- make collisions between bullets and enemies result in damaged enemies
- make collisions between player and enemies result in killed player
- create a wave of enemies
- create a way to modify the wave of enemies so each enemy evolves in some way

Right now, you can shoot enemies as they approach, and when they die, they become harmless and visibly destroyed. If you crash into an enemy that is still alive, you both die.

Enemies are mindless right now. They simply move forward in a straight line to the left. While I have a bunch of random enemies that looks like a wave, I don’t really have waves as a concept in the game. And with less than four hours left, I don’t think I’ll be adding lots of visibly different enemies and power-ups. We’ll see.

Oh, and my wife was nice enough to bring me something to snack on.

Got any gwapes?

I woke up with a sore back. I was lying down on the floor with my legs up on the ottoman since that’s supposed to help your muscles relax if you do it for about 30 minutes. Then I went back to bed, and I didn’t wake up for a few hours. Then it was time to go to church with my wife, and we had lunch:

That’s a Planet Veggie from Planet Sub. It has provolone, cheddar, fresh red peppers, artichoke hearts, sun-dried tomatoes, and a tangy olive spread. I washed it down with lemonade.

I wish I can say I’ve made progress, but sitting at the computer has been incredibly uncomfortable. But lying on the floor seemed to have helped, so I’ll be back at this project today.

A reminder of what I’m doing:
- 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

There’s a little over 6 hours left in the compo. I can do this.

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.

I now have a tank capable of moving up and down and firing bullets.

That footage is based on the random movement I programmed in. It’s not player-controlled yet, but at least I can leave it up to take a break and be sure that the timelapse is a lot more interesting.

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
- add an enemy
- create a wave of enemies
- create a way to modify the wave of enemies so each enemy evolves in some way

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!

I’m in. I haven’t decided if I am going to continue working in C++ with libSDL or if I will use Stencyl, but I’ll be participating in LD #24. It’s been too long.

I updated my final Ludum Dare #20 Jam entry to include a link to the Windows port of Hot Potato. Whew! Now I can get back to working on Stop That Hero!. B-)

Here’s a video of my desktop through almost 72 hours of development of Hot Potato compressed into less than 2.5 minutes:

It’s complete. I’m not satisfied with the balance or the feel, but Hot Potato is finished and submitted.

Oh. I should rebuild it on my Debian system since other people tend to have problems playing my game when I build a project on my Ubuntu system I might make a Windows port soon, but after 72 hours, I’m beat. I’ll update this post when I get those two things done.

Updated! I created the Windows port, and I rebuilt the game on my Debian system so that a wider variety of Linux-based systems should just work out of the box.

You can download it for:
- GNU/Linux (1.6MB tar.gz)
- Windows (3.12MB .zip)

Even without Pedestrians, I might have implemented one of the items on the list since I wanted to change the behavior of package passing.

Now when a package is being shoved down a chain, the last courier in the chain receives the package. Technically, the only entities that would break the chain are the VIP and the Enemy Agents, so it should work once Pedestrians are in. I won’t scratch it off my list, however, until I code up some Pedestrian entities and test it out.

I’m getting concerned that my game world is too big. As I playtest, I realize that I’ve never made it all the way across to the VIP before the agents intercept my couriers, and it’s kind of tedious to click click click to get there. If Pedestrians make it take even longer to get to the VIP, I might need to shrink the plaza to avoid player tedium and RSI.

What’s left:
- moving the agents towards the package holder
- win condition check
- lose condition check
- allow multiple couriers to move during move phase
- shove passes through chain of couriers to last courier instead of next one
- shoving package through pedestrians
- adding pedestrians
- moving pedestrians

5 hours left to go. Who wants to go for a stroll through the plaza?

Moving multiple couriers was a little tricky, but it was mainly because I didn’t realize what exactly I was supposed to be checking in my code.

I originally created a mapping of Courier pointers to bool values to represent whether a courier has been moved already.

std::map<Courier *, bool> m_couriersHaveMoved;

At the beginning of the Move phase, all of the values are set to false. When you select and move a Courier, its value is changed to true to indicate that it has already been moved. This way, during the Move phase, I can highlight only the active Couriers and prevent inactive Couriers from being clickable. As Couriers are moved, they become inactive and ineligible for later selection during this Move phase, and when it is time to move the Couriers again, they are reset to being active. Great!

The problem came when I tried to abuse those values to check if the move phase was completed.

It made sense at first. The Move phase is over when you have moved all of your Couriers. Checking if the Move phase is over was as simple as checking if any of the existing couriers had an associated false value in m_couriersHaveMoved.

Except there was a problem. If a courier COULD be moved but can’t due to the fact that all adjacent tiles are occupied, the Move phase would wait for you to click on a Courier, but none are selectable, so you wait forever, or at least until you pause the game and click “Return to Menu” to start over or quit in frustration.

So I tried to make sure that blocked couriers were considered finished with their move. Unfortunately, this had the side effect that if a courier is blocked at some point during the Move phase, it can’t be selected and moved later even if an adjacent tile opens up. Well, that’s unintuitive for the player!

Eventually I realized that I was trying to use the wrong solution to the problem. The actual problem I’m trying to solve is knowing when the Move phase is completed. The solution has nothing to do with whether or not all of the couriers have made their moves. The solution is to check whether or not there are any tiles adjacent to ACTIVE couriers that are empty.

So now I have the ability to move multiple Couriers in the same Move phase, and I solved the new application-hanging problems that cropped up involving the difference between an inactive Courier and an active Courier that just happens to be unable to move at this time.

What’s left:
- moving the agents towards the package holder
- win condition check
- lose condition check
- allow multiple couriers to move during move phase
- adding pedestrians
- moving pedestrians
- shoving package through pedestrians

Shoving is broken. It has been broken, but it wasn’t until I was able to use it more often that I can see what’s wrong.

Basically, shoving works fine if you shove a single Entity into the next empty square. There’s a potential bug when you shove entities into other entities. If an entity later down the chain can’t be shoved, it won’t be. But the entities earlier in the chain are still shoved, so it looks like one of the entities eats the other.

I need to do a complete chain check first before a shove is allowed. If the check says it is not possible, whether due to the existence of an unshoveable entity or the border of the game world, then no shove happens. If the check says it is possible, then the recursive shoving algorithm can go forward without a hitch.

Also, since shoving is how the package is passed off, I’d like the package to also shove through to the end of the chain if it is possible. Right now, it only passes to the first entity being shoved.

So with 7.5 hours left to go, I’m fixing shove mechanics before adding Pedestrians to make the game more interesting. After that, I suppose I would have time for sound effects and polish, but I hope to submit this game to the Jam long before the deadline so I can get back to actual work. Besides, it is Monday, and “Chuck” is on tonight.