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)

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?

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.

Basically, if an enemy agent is next to the courier holding the package, you lose.
If, however, the VIP is next to the courier holding the package, you win.

So technically, I have a game finished. It’s very unfun, very unpolished, and very uninteresting, but you can make moves and eventually lose or win.

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

Right now, it is very difficult to get past the agents because it’s only possible to move a single courier in the move phase, and passing the package isn’t very effective. Allowing multipler couriers to move at once during the move phase should help even the odds and make it easier to pass the package around.

Randomly generated Pedestrians should add some flavor to the game. In a busy plaza, it might be difficult for couriers and agents to move around freely. Plus, shoving the package to teammates gets more fun if you can leverage innocent pedestrians, although it opens up some difficulties in the code and design. What if you shove a package into a Pedestrian who shoves it to another Pedestrian who ends up in an empty space? Should the package only get passed if you can end up with a courier at the end of the shoving chain? I’ll try to keep it simple and go from there.

The UI is a little frustrating. If you can make a move or if you can shove, you MUST. Currently, I have no way to say “No, I like where my couriers are, and I don’t feel like shoving this turn.” While I can fix it by adding a “Done with turn phase” button, maybe the requirement is fine. Checkers, if played correctly, enforces a “you must jump if you can jump” rule, which makes it very strategic. I’ll leave it until the end.

Another frustrating thing is that there is no way to cancel a decision before you’ve decided. If you click on a courier, you can’t change your mind and pick a different one. It’s fine if you’re playing chess to require that touched pieces must be moved, but if you accidentally click on the entity during the shove phase right after moving it, it can be annoying to see that you have to make a shove move that you didn’t want to make. Unfortunately, I’ll also leave a fix for this annoyance until the end.

There are 10 hours left in the Jam. While I continue my work, you can watch this series of videos of someone playing The Legend of Zelda, only he decided to do so without taking “this”:

In the last few minutes of Submission Hour, I finally had Enemy Agents who moved towards the package holder. I need to make sure multiple couriers can move at once during the move phase. The agents currently have too much of an advantage if you can only move one courier at a time.

I had to deal with a few seg faults getting to this point, but they were relatively easy to solve compared to what I’ve written about for this LD.

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

And I have 24 hours to get all of it done and submit a Jam entry.

Actually, I now have enough to submit what could technically be called a game if I can code up the win and lose conditions. They’re easy and low-hanging fruit, so I’ll tackle those first thing in the morning. It’s too bad I don’t have one more hour, and it’s too bad it took so long to start working on the actual game play. My game could have been among the nearly 300 entries if I had less to do from scratch.

The good news is that next LD, I might be able to take this project and gut out just the Hot Potato-specific parts, and I’ll be able to build a simple, LD-ready project from the moment the theme is announced. This LD showed me that I am finally starting to get a collection of boiler-plate code that’s easy to migrate from one project to another without too much hacking.

For now, I’m getting some rest. Congratulations to everyone who submitted on time, and good luck to all of the other jammers!

In the final stretch, I can finally DO something in the game.

In the Move phase, I can select couriers and move them to open adjacent tiles.

In the Shove phase, I can select couriers and shove another courier, and if the shover has the package, it is passed off.

What’s left:
- moving the agents towards the package holder
- adding pedestrians
- moving pedestrians
- win condition check
- lose condition check

Can I get at least a good chunk of it done during Submission Hour? I hope so.

1.5 hours left.

struct Foo
{
std::vector<Bar> bars;
createBar(int x);
};

void Foo::createBar(int x)
{
Bar bar;
bars.push_back(bar);
someOtherThing[x].pointerToBar = &bars.back();
}

{
createBar(1);
createBar(2);
createBar(3);
}

[On that note, does anyone know a good C++ code renderer for WordPress? I apologize for the formatting.]

What’s happening in the code is that you call createBar() to create a series of bars. These bars get stored in a vector of Bars, which is fine.

someOtherThing is using that vector to store a collection of pointers to those Bars. Seems innocent enough.

In fact, if you later did something like:

someOtherThing[3].pointerToBar->someBarThing();

It would work perfectly fine.

But if you did:

someOtherThing[1].pointerToBar->someBarThing();

You’d segfault. Why is the 1st Bar suddenly invalid?

The problem is that someOtherThing is getting pointers to Bars that exist in the vector at that time they are requested. The next time a Bar gets added to the vector, however, might require the vector to be resized, and so while the Bars in the vector are all there, they basically moved house, so the pointers you stored while creating them are no longer valid.

And that is why I took so long to figure out why my Courier selection code would crash on only some of the Couriers, and that is why I probably won’t get an entry submitted for Ludum Dare #20.

2 hours left to go. I’m going to get dinner.

In the meantime, here’s a screenshot showing the couriers on the left and the enemy agents on the right.

I now have the ability to select the courier you want to move once I moved the “store pointers” work into a batch operation. I thought not using pointers in the first place would save me headaches, but I guess I should have just new-ed up the Couriers in the first place. B-(

I have a background, plus the cobblestone play area that represents the plaza. I thought it would be simple to draw the package recipient on top, but for some reason, he disappeared.

After throwing in some debugging output and manually setting its position, I discovered just how weird this bug is.

If the VIP is standing to the left and up of a certain position, it gets drawn. To the right and down of that position, it was missing.

Wha-? I eventually saw that it was, indeed, getting rendered in the correct spot. It was just getting drawn under the cobblestone tiles in that area, so you couldn’t see it.

That’s bizarre. Now, my sprite rendering system does draw according to z-order. The basic way it works is that if Sprite A and Sprite B are to be drawn at the same (X, Y) position, but Sprite A has a Z-coordinate that is higher than Sprite B, then Sprite B gets drawn first so that Sprite A gets drawn on top. If the Z-coordinates are the same, then it checks the Y coordinate next, so sprites get rendered from the top of the screen first and the bottom of the screen last, which gives a nice overlapping effect.

But I didn’t set the z-order explicitly on any of these sprites. I verified that the default z-order for all sprites is 0. I find it odd that I can draw the VIP on top of the cobblestone for about a 10×8 area in the upper left but not in a 2×8 area at the bottom right.

So I set the z-order of the VIP to a high number, and it still wouldn’t get drawn on top. I set the z-order of the cobblestone tiles to a negative value, and suddenly it started to work correctly.

Now, normally I would look into this bug a lot more. The rendering system was designed so that sprites drawn from left to right and top to bottom would render overlapping correctly without the need for z-ordering to be set.

The only thing I can think is the problem is that I don’t actually draw the sprites until I collect all sprite-drawing orders and do them in a batch. So I can have a bunch of sprite-drawing requests, and they get sorted by the z-ordering rules I mentioned, and then the sprites get drawn. Actually, maybe that’s the problem. The background tile render requests are in the same batch as the VIP render request, and I have no control over how two sprites at the exact same position and z-order would get sorted before they are rendered. I’m not sure why the behavior is inconsistent depending on where the VIP is, but again, I’m not going to look into it now. I have a game to finish!

Here’s a screenshot of the VIP getting rendered on top of the plaza tiles correctly:

Yes, my programmer art will be very basic, which means it is quick to make.

After I got the basic rendering working, I had lunch. A number of people have told me that they are looking forward to my apparently famous peanut butter and pickle sandwich. I was actually planning on skipping it this LD since I thought people would be sick of seeing the same sandwich and food come up each time, but I can’t disappoint the fans!

So first we spread some peanut butter on the bread…uh, oh….

That’s not nearly enough. Where’s the peanut butter?

No peanut butter? I’m out of peanut butter?! Unpossible!

Every Ludum Dare, I go through a checklist. I make sure I have a working Audacity and sfxr in case I have enough time to implement sound. I double-check that my time lapse software still works. I ensure that I can start a new git project so I can get to work right away.

For this LD, I even made sure I had a new jug of orange juice, and I did have a new jar of pickles, but I forgot to check if I needed more peanut butter. B-(

But fear not! In the interest of variety, I have other nut butters! Walnut butter is too expensive to get regularly, but almond butter and cashew butter are delicious alternatives to peanut butter as well. Since pickle juice tends to make the sandwich a bit drippy, I opted to go with cashew butter, which has a stickier consistency than almond butter.

And there you have it: the cashew butter and pickle sandwich!

I sprinkled some cinnamon inside before applying the pickles, and it makes a compact, nutritious, delightful snack!

And now, on with the show!

A little less than 8 hours left. I’m not gonna lie. I’m getting slightly worried. My game might not have sound effects.

Or game play. But I’m definitely worried about the lack of sound. B-)

It also keeps track of each Entity running around. I keep Pedestrians, Couriers, and EnemyAgents in separate containers, and there is a single VIP (the goal) as well. All Entities have position, orientation, and a string that represents how to draw them.

Here’s how they differ:

Pedestrians also have a preferred turning direction. When they run into an occupied space, they try to turn in their preferred turning direction first. If that space is also occupied, then they try the other direction. If that space is also occupied, then they remain in their original orientation and stand still that turn. To illustrate, a Pedestrian with an affinity to turning left is facing to the right. In trying to move forward he finds that the tile is occupied by another Entity. So he tries to move up (turning left from his right-facing orientation) first before trying to move down.

Couriers can carry a package. There are plans to only allow one package in the game, so only one Courier will actually have the package at a time.

EnemyAgents have nothing special about them except that they cannot be shoved. If an Entity tries to shove into an EnemyAgent, the action won’t happen. Likewise if a chain of shoves results in an attempt to shove an EnemyAgent, the shoves won’t happen.

VIPs do not move, so they don’t have an orientation. They just stand in one place, waiting for the package to be delivered.

I’ve been wondering if I should have an explicit representation of the Package itself, but I’m getting sleepy and exhausted, so I figured it would be best not to make decisions like this until I’m awake enough to think them through.

Once I get these new objects rendering, I think the next task is to create some instances of Couriers and get them moving about the play area according to player input.

There are 21.5 hours left in the compo. I figure I’ll wake up with 13-14 hours left to go. Wee!

Still, there’s a lot of code powering that title screen now. I ended up borrowing more code from my other projects to get more boilerplate stuff in. I’m surprised how basic yet complex my boilerplate code is. Stuff like menu handling and basic input processing is a lot of code, and it sucks to rewrite it each time I participate in LD48.

In any case, I now have a high level state machine running the application. The main menu is one state, and clicking on “New Game” switches you to the in-game state. And since I have a way to get to it, the in-game state is where almost all of the work needs to be done next.

I need to implement:

• the plaza as the main playfield.
• the Very Important Person as the delivery target and end goal.
• the courier team.
• the pedestrians.
• the agents.
• victory and defeat conditions.
• and systems to run all of the above.

Essentially, The Entire Game.

If I would have had boilerplate code that was ready to go, I would have been working on this code from the start. Instead, I had to slog through getting each file to play nice with the relatively empty build.

Anyway, to prepare for the plaza, I’ve created a few tile images. I might end up using nothing but the “cobblestone”, but maybe I’ll get grass and dirt in for variety if I have time.

I took a dinner break and had some cheese pizza from a great place called Marino’s. They make the best sauce!

There’s a little over 24 hours left in the compo, and I don’t want a repeat of Advancing Walls of Doom. This game is getting made.

I’m going to need to eat some fruits and vegetables soon.

Anyway, last time I had a working build. My next goal is to get an SDL window to open and close. This part will either just work or I’ll find some weird complication here, too.

…

Ok, so I ended up copying a lot more files from other projects, but I finally managed to get to a point where I have something that might serve as a nice starting point for this and maybe future LDs.

For now, I have a splash screen.

The name of the project is tentative to change, but at least it has been born. Now to raise it into a healthy young game.

CMake, how I hate it when you don’t work.

I should have prepared for this compo by having a basic, buildable project ready to go.

In trying to create the barest project for LD20, I’ve copied the directory structure and CMake build scripts from my LD18 game, which still builds just fine by the way, and changed references from LD18 to LD20.

And for some reason, with a basic main function and a bare-bones Game class that does nothing, I get a build error.

I notice that for some reason, even though I tell it to build the files in my source/game directory, it seems to be ignoring it. It doesn’t ignore it in my LD18 project, though.

First, for posterity (and my sanity), the command to get debug output is “make VERBOSE=1″. I always forget it and have to do searches online to find it, and sometimes CMake searches aren’t easy to do. I need to keep these notes somewhere handy for the future.

Next, I saw that it wasn’t finding my project library. Basically, my game has a main.cpp, and it links to the library created by the game subdirectory. What’s nice about having the game built as a library is that I can also build a test binary if I was using unit tests by linking to that same game library instead of building the object files twice.

After looking at the CMakeLists.txt files and comparing them to the ones in my LD18 project multiple times, I finally saw the culprit:

TARGET_LINK_LIBRARIES (gbgames-ld20-bin gbgamesld20-lib ....

It should link to gbgames-ld20-lib. It was missing a frickin’ dash. Looking closely at the error message, I would have seen the missing dash there as well, but…GAH!

And this is how you lose about 40 minutes during a Ludum Dare compo. B-(

Luckily, I finally got the project building and running, so now I can get some lunch.

1 day, seven and a half hours left. Eat fast.

In this image, the hearts represent pedestrians walking across the plaza. They are oriented in the direction they are going, a nice characteristic of heart tokens as opposed to circles or stars.

The star represents the person you need to deliver the package to. The package is represented by the red gem, which is held by one of the three couriers represented by the Mans. The barrels represent the agents trying to stop the couriers.

Playing with the game in this way, I realized there were questions that needed answering:

• If two pedestrians try to walk into the same empty tile, what should happen?
• Should pedestrians always try to go to the opposite wall they start on, or should they just go forward until they are forced to turn?
• Should shoving be a second phase after moving your couriers, or should it be a result of moving into an occupied tile?
• Should couriers be faster than agents? Than pedestrians? Slower?
• Would randomness involved in the creation of pedestrians (where they spawn, what type they are, etc) be enough to prevent making the game mathematically solvable and therefore boring?

And finally, what is in that package that seems to be so important to the agents in the first place? B-)

I played around with various solutions, and I was able to get a feel for what made the game more complex/confusing versus what made it simple and straightforward, especially from the player’s perspective. Part of the game is being able to quickly read the status of the board and making moves with predictable results, so complicated shoving mechanics might not serve my goals. For example, if you shove an eastbound pedestrian north into a westbound pedestrian, should the westbound pedestrian get pushed east by the eastbound pedestrian? And if the westbound pedestrian is shoved into an southbound pedestrian, and if your couriers can be shoved back, it means that the end result is the eastbound pedestrian is in the same position it started from! The chain of shoves can get windy and interesting, but maybe it would be more straightforward and intuitive to force all shoves in one direction, so a chain is really just moving all pedestrians in a line.

There is one day, 9 hours left in the compo. I don’t think I need to solve all of these problems. I can always play with them as the game is developed. I have enough to start breaking ground on the code. Let’s get to work!

I started the day with a typical breakfast.

After my shower, I put on my custom Ludum Dare t-shirt.

I wore that shirt at the Ludum Dare Meetup at GDC 2011. And as I type this, it has been covered in white cat hair. Thanks, Diego. B-(

Throughout my morning, I’ve been thinking about game mechanics that wouldn’t require a full AI engine or physics or anything else complex. At first I was keen on getting rid of any entities besides the player’s avatar. After all, you’re alone, right?

But then I realized that I could make other entities follow simple rules. There doesn’t have to be decision-making or goal-driven actions or complex evaluations. Enemies or hazards can simply follow basic rules, so any decision-making is in the code when I write it.

And more and more, I’ve liked my Hot Potato idea that I mentioned last time. So here’s what I’ve come up with so far:

Your crack team of couriers have to delivery a very important package to a very important man who works for a very important organization. This man is standing in a busy plaza in the hopes of blending in with the crowd to avoid detection from secret agents who hope to intercept the package.

The plaza will be tile-based grid.
The play will be turn-based.
And hopefully the AI will be quite simple and dumb, yet effective. B-)

Some basic rules:

• Entities can move into adjacent tiles if they are free.
• Entities can also shove other entities into other tiles.
• A shoved entity pushed into an occupied tile will shove the other entity in the direction he/she is facing.
• Secret agents can’t be shoved.
• The very important package can be passed along to a teammate directly.
• Alternatively, if the package handler shoves a chain of people who end up shoving a teammate, the package can be passed through the chain.
• The very important man can only receive the package from the package handler directly. No chain can be used.
• If an agent gets the package instead, it’s game over.
• If the agents shove the package handler, it’s game over.

I think it can be an compelling game. My intent is to design the game so that if you try to deliver the package using only one courier, the agents will easily stop you, so you must rely on passing off the package to get it past the agents. The crowd may or may not grow/shrink in size as the game progresses. I don’t know how it will turn out, but I’ll have to do some paper prototyping to see if it has a chance of succeeding. BRB.

I’m not really sure about it. I was really hoping for “Traps”, but you play the hand you’re dealt.

I haven’t thought too much about the theme yet (I was busy play Jeopardy! for the Wii with friends when the compo started), but here are some first draft game concepts:

• Your Guardian Pet: Think Ico, only you’re the helpless one, and you have to leave your protective dog sometimes to find a way to get it into areas you need to go.
• Shove Off!: You’re among a crowd of prey (sheep?), and there are predators (wolves?) circling. You need to maneuver yourself into position to push, kick, or shove the other prey out of the crowd so the predators eat someone other than you. It’s more like “Take THIS!”
• Hot Potato: There is a very important item, and your team needs to deliver it, but there are agents trying to stop you. If a team member gets isolated while holding the item, you lose, so try to pass off the item to someone else before the agents can corner you.

One thing I want to try to do is avoid complexity, and while I’m more familiar with artificial intelligence, I’d rather not have to code up pathfinding or goal-driven agents. I’ll try to focus more on player-controlled mechanics and system interaction than on building a living, breathing world.

For now, I’m going to sleep on the problem, and in the morning, I’ll start prototyping some ideas. Good night, Ludum Dare!

I would like to say “Thank you!” to PoV for giving me a good way to hunker down and try to focus on the attempt. Before October, I was spending some time wondering how long I should work on the commercial version of Stop That Hero!, not wanting to take too long for fear of running out of savings, and not wanting to take too little time for fear of putting out an unsellable game. With PoV’s deadline, I had a good compromise.

PoV, thank you! I have a good start to my project, a better idea of how to manage it, and a greater awareness of my strengths and weaknesses as a game developer. I’ll be continuing, and I plan on finishing and selling this game before the end of the year.

So if you’re interested, here are the links to my dev posts. I’ll add links as the project develops.

An Inspiring Challenge, where I write about my acceptance of the October Challenge.

Stop That Hero! Post-Mortem, in which I discuss what went right, what went wrong, and what I learned in developing my LD18 submission. I also say that I intend to rewrite the game for the Challenge.

Stop That Hero! Development Challenges and Concerns, in which I discuss the major issues I want to address in this update of the game.

Designing Resource Usage in Stop That Hero!, in which I lay out the problems with the original game’s implementation of resources and analyze a number of different options to address those problems.

Agile Alert: Slow Project Progress, in which I express dismay at how slow my progress is and try to identify the major causes.

Balancing Current and Future Needs, in which I explained my insistence on using Test-Driven Development and elaborate on my concerns for over-engineering versus making just enough to satisfy the deadline.

Loading an Arbitrary Stop That Hero! Level, in which I briefly mention that the game can now load a sprite representing the world map and render it.

Stop That Hero! Sprite Rendering Questions, in which I describe some nifty world map to screen resolution position scaling to render sprites in a consistent way. Thanks go to FuzzYspo0N for helping me with the details!

State of the Art Game Objects, in which I describe my research on a component-based object system and give up on it after being overwhelmed by the immensity of what I was attempting in a short period of time.