Author: Gianfranco Berardi

So 48 hours came and went, and I have no game to submit. B-(

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.

My fiancé is fantastic.

1.5 hours left.

Here’s a little C++ quiz for you. What’s wrong with this code?

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 created a bunch of sprites, but they weren’t being drawn on the screen. I’ll fix that!

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-)

So I’ve been tackling the Plaza, which was originally planned to be a simple representation of the play area grid.

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!

The title screen doesn’t look very different from the splash screen:

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.

What’s faster than reheating leftovers?

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 love it when you just work.

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.

I used my trusty graph paper and my handy-dandy game design prototype toolbox to see if the game rules I came up with could be any fun.

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!