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:
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:
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 woke up this morning, and unfortunately my dreams didn’t help me come up with a cool game concept.
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:
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.
So the theme for Ludum Dare 20 is “It’s Dangerous To Go Alone! Take this!”
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:
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!