GBGames

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.

Behold, win and lose conditions are in!

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”:

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.