Well, I submitted my game. I have to remember how to package my submission for next time though, since it took well over an hour for me to go from “Done” to “Done and shared”. So, tips to myself and others using SFML & Mac OSX:
1) sndfile.framework needs to be included.
2) Remember to add frameworks to the “Copy Frameworks” step.

Other than that, I’m very pleased with my game. At the start of this competition, I really did not have any good ideas – or at least, I didn’t really have any ideas that I really wanted to work on until about 40% of the way into the contest (although, I hadn’t had much time to work on it prior to that, so I only lost an hour or two of work time). I actually was planning to leave the competition entirely because my ideas were all basically remakes of some other game – that is, the theme was only present in the assets that I created, not in the game mechanic itself. Also, I got the game finished faster than I thought, since I only *meant* to do the Jam.

I’ll probably get a bit more into the process later, but for now, I’m quite tired.

Well, I have to say that compared to my last Ludum Dare, this experience was COMPLETELY different. The first difference that comes to mind is how I didn’t waste all of my time trying to create a physics/movement engine. That thing sucked up, probably, about 80% of my time and I certainly wouldn’t call it “complete” even now. Also, it was more laid back since I only got around 14 hours to work on the game, as opposed to the 24 – 30 that I had last time.

What Went Well:

• I, once again, was focused the entire time. I was so focussed, in fact, that I forgot to finish off a delicious beverage (although don’t worry – I drank it now).
• My game concept was simple enough to leave me a whole day to work on assets & the front end.
• Audio. It existed this time. I think it sounds pretty nice for, like, 30 seconds on a loop.
• I had lots of screenshots & some demos to share before the compo ended (although I don’t think I packaged the demos correctly, and the LD site was down)

What Didn’t Go So Well:

• Uploading. I wasn’t good at it. I gotta remember to include sndfile.framework & to add other frameworks to the “Copy Frameworks” step in Xcode. I actually lost $5 here because I bet my brother that I uploaded something correctly and it didn’t work.
• I didn’t test all the “pipelines” involved in my game; 1 hour before the contest ended, I realized that I didn’t know how to get audio into my game. I figured it out though.
• All my ideas at the start were basically the same; I was only considering ideas where you (singular) were trying to escape from something, which isn’t really thinking outside of the box. I was actually really displeased with all of my ideas, and wasn’t having much fun developing them until I thought of the evacuation idea.

Overall, I am once again pleased with the product that I produced, and think that it is a pretty big step above my last entry, and am looking forwards to December. I might keep working on my entry (after the ratings though; programmers = good playtesters) since I can think of a few ways to spice it up.

(If you are some sort of STRANGE ALIEN and have yet to play my game, it’s over here)

Tags: postmortem

Maybe this time we can break 600 games (although that might not be a good thing).

My goal this time is to make a game that DOESN’T crash randomly because that’s not a good thing. That’s in addition to, you know, everything else, but this whole technical thing gets in the way of that whole fun thing.

EDIT: I wonder if I could make a programming game. I mean, this seems like a rather apt community for such a game…

In descending order of quality, the ideas I have so far are:

Idea #1: The player’s goal is to keep several people alone, and to prevent them from contacting each other. The game would take place on a maze on a grid (although, if possible, the graphics would be smooth). New people would be introduced as the game goes on, and the player would be charged with keeping them separate for as long as possible. It would likely be a turn-based type of game where there are two stages. In one, the player places obstacles and stuff, in the other, the entities move. There would be penalties for killing people.

Idea #2: Something about splinter cells or something; trying to function without knowing anything about other members of same “team”.

Idea #3: A damsel in distress self-rescues.

Which is odd, this early on. I must be getting better at this whole rapid game creation thing. The name is “Dwarven Isolation”. It is about preventing dwarves from mining into each other, which is important since dwarven handshakes cause catastrophic explosions (but I’m sure a smart reader like you knew that). The dwarves, of course, are attracted to shiny objects, like gold or treasure, and are quite good at whacking stuff and making solid rock walls go away.

More seriously, here’s my entire design document.

Dwarven Isolation
The game starts out with a maze through rock and ore. Several dwarves enter, and begin walking around and mining stuff. The goal is to earn as much money as possible before two dwarves meet.

Capabilities of the Player
-The player can place treasure chests and valuable ore.
-The player can place hard rocks on the path.
-The player can place traps which kill or injure dwarves.
-The player cannot do anything in direct view of a dwarf.

Rules of the Dwarves
-If two dwarves see each other, they will run towards each other. Unless there is a trap already in place, this is certain doom.
-Dwarven line of sight extends infinitely in all directions.
-As dwarves mine, they become better at mining and do it faster.
-If a dwarf sees treasure, they will run towards it. This is not as strong as seeing another dwarf.
-If a dwarf finds a body, they will scream, alerting all in a radius. They will find the fastest way, including mining things. You’ll probably have to kill someone else if they find a body. Yeah, it won’t end well.

And, if possible, ACHIEVEMENTS! Gotta love achievements!

What’s done right now:
Line of sight stuff is done.
Half of pathfinding is done (which really isn’t significant; it’s just A*).

What needs to be done:
Everything not listed above.

So, I’ve got a sketch of the basic dwarf mechanics. They are very greedy. And, in fact, that part works perfectly! Those dwarves will run towards gold they can’t even see! That’s not really supposed to happen. It’s made worse by the fact that they might be able to see another dwarf through the walls, and explode.

Currently, what I have looks as follows. The red square is a dwarf, black squares cannot be mined, the dark gray squares are already mined. The brightest two squares to the left are unmined shinies. The sight of a dwarf is shown as the highlighted mined squares.

Well, seeing through the hardest material in game which can’t ever be mined is probably not a good thing. It sort of seems like it’s only taking the sight radius into account. The game mechanic just… doesn’t work without the sight algorithm working.

Other than that (which, thanks to the fact that my code is… “neat” is easily replaced. I just don’t have a replacement), things are going pretty well. I’ve got a pathfinding algorithm that works (it’s just A*), and I’ve got the dwarf movement code working (well… as long as the sight algorithm works).

What’s left for today:

• Fix the sight algorithm. It’s really important.
• Allow the player to place stuff.
• Make the stuff players place do bad things to the dwarves.
• Implement a money & score system.
• Make a help screen!

Well, I was hoping to finish the game engine itself by the end of tonight, but I’ve got like, 6 hours before that happens and, as far as I can tell, the game works perfectly, and never crashes. There’s still some balancing left to do, though. I’m really surprised at being in this situation because my code is incredibly ugly, uses a massive excess of pointers, and has plenty of one letter variable names. But it works, so I just need to not touch anything except the rendering code.

Here’s a screenshot from the game. You can see that I have been very focused on the game engine, and less focussed on graphic or interface. For example, there is a black button on a black button that you can’t see, but has a pretty important function. Also, the title is “SFML Window” which isn’t really the most creative title ever.

Then, the same scene a few seconds later. See if you can spot the dead dwarf. It’s in the cluster of red things at the bottom left.

So, I guess the todo list looks like this:

• Fix a rendering bug that makes a new dwarf spring up randomly whenever a dwarf dies.
• Add some visible particle whenever a dwarf dies.
• Give everything real graphics.
• Differentiate between valuable ore and not valuable ore.
• Label what each button does & what its cost is. Also, actually charge the player money for placing stuff.
• Step on a kill trap, and record the sound I make for use in the game.

Have I ever said that graphics were useless? Of course I have. I am, right now, redacting all of those statements because man does my game look more awesome with graphics. I’m incredibly happy with the game grid (everything that doesn’t have words), given that I’ve never done such small graphics before (10×10 pixels for each square), but it actually looks quite nice and effectively conveys the information. Let’s do a before and after. I recreated a similar situation to my first screenshots (but with less deadly traps because they cost money now…). Before is on top, after is on bottom, As you can see, there are no longer invisible buttons, the dwarves sort of look like dwarves, deadly traps look like spikes, sticky traps look like… green stuff. Also, you can determine the value of rocks (diamond = most valuable, then gold, then ruby, then copper) which lets you place traps smartly. Also, the title is now “Dwarven Isolation” instead of “SFML Window”

 Then, each a few seconds later also shows some graphics (No longer shall dead dwarves look a lot like living dwarves and also look like traps! Also, no more phantom dwarves). The new one would have the white countdown bar, but I wasn’t quick enough on the screenshot:

The dead dwarf looks surprisingly dead, considering I just took a living dwarf, and put red on its face everywhere. I’m really really pleased with the graphics overall, since, as you can see, they are a MASSIVE step up from what I had before! I’ve got a really good feeling about this Ludum Dare, and if you read my blog posts this time, they no longer give you the picture of “Making a game in 48 hours should be considered a form of torture.” So, we’re at the halfway mark right now, so 24 hours left for polishing, I guess.

TODO LIST:

• Sound effects!
• Music!
• 2 more secret traps!
• Making the interface look nice.
• Help screen!
• (Achievements!?)

I like people who like demos because they can tell me if these actually work!

Mac Version

Windows Version

Now, the instructions. The game will start with 4 dwarves in the corners of the screen, moving about and mining stuff. Whenever they mine stuff, you get points and money. Your goal, of course, is to get a lot of points. That seems pretty easy, given that the dwarves will do it without intervention from you. The problem is that dwarves will explode if they touch each other, and that’d be terrible. Thus, it is your duty to keep that from happening. There is a white bar to the right of the screen. Whenever it runs out, you have the ability to spend money to place traps, lures, and to empty spaces. Dwarves can see things in a 8-block radius, unless they’re blocked by a wall. Anything they can see if highlighted in yellow. You cannot place traps or anything within the sight of or next to the sight of a dwarf. Dwarves scream when they find another dwarf’s body, and the scream attracts all other dwarves in a large radius, so it is unwise to murder a lot of dwarves (well, it will be when more dwarves spawn, so don’t do it)

(Note that these are what is going to be easy mode, although more dwarves will spawn over time in the final version; for more of a challenge, don’t place anything every other round)

Well, that’s all I’m gonna do tonight. I’ll probably think about how to make it more “fun”; I feel that this game could use some more hectic gameplay (you should lose really quickly if you’re not trying).

• Bugs didn’t happen. It was sort of magical. I never spent more than 10 minutes correcting any bug, and there’s no crashes I’ve discovered in the Mac version.
• I had adequate time to create assets. Most of Sunday, actually.
• My game concept is original.
• My timelapse was good!
• I did some serious bloggin’.

• The game concept isn’t quite as fun as I’d imagined. I still like it though.
• The code is by far the worst code I’ve ever written. Yes, worse than both previous Ludum Dares I’ve done.
• The music doesn’t last very long. A longer loop would be good.

I’m planning to do an experiment to determine some things about the effectiveness of putting one’s work into various places in a game, and I need the source code of a few games in order to do it. Specifically, I’m looking for games which can run on Windows (or in a browser) and are intuitive to play; it should take no more than 5 minutes for someone to enjoy the game. I will be making minor modifications to the code of the game, and major modifications to the assets in the game and distributing modified versions.

If you’re interested (or, at least, don’t object to my use of your game), please post a link to your game in the comments & any attribution you’d like if I do use your game.

(I will, of course, share the results of this experiment with the community, since they are probably interested)

I’m trying to do a study on what aspects make a game fun (and specifically how that works with the Ludum Dare), but I need to get a good sample size in order to do that. Since this community is likely interested in the results of this and also are the judges in the Ludum Dare, people here are ideal for this. I would very much appreciate it if you took 3 minutes of your time to follow the instructions on the following page:

EDIT: Thanks for all your data folks! I’ll see if I can make meaning of it…

EDIT 2: Didn’t get conclusions. Probably need more data and better experiment.

I’m pretty excited for this next LD, but I’ve decided to dump SFML. So, either I’m going to use SDL, make a text-only game, use an HTML5 canvas, use Unity or maybe use Java or Processing. I think I’m going to spend a lot of time looking at documentation this time around. I’m pretty sure that GIMP and Garage Band will be in my toolset though (if there’s audio & graphics). In any case, this will be my 4th Ludum Dare, and hopefully it will be as awesome as the last 3.

Well, this dare is getting pretty close, and I still have a heap of things that need to be done before the dare. Most of it isn’t dare related (for instance, writing a paper on standardized testing, then reading a textbook to prepare for the AP exams), but that’s not because I’m at all prepared for the dare. I lost the code for my command line timelapse, want to ditch SFML (and don’t have it installed), and am midway into another project that I’m passionate about (but it’d be a shame to not participate! I haven’t made a game since the last LD).

Also, on a practical note, does anyone have any recommendations for a good platform for me to use? I’m looking for something that is free, OOP, and can display images and music. Bonus points if it’s web-based.

In any case, all my unpreparedness can only make this Ludum Dare more interesting…

• A game based on the idea of 7 degrees of separation. Preferably something to do with killing everybody or cutting the social ties.
• Something with a very large number of very small planets.
• A game of engineering really small biospheres (or death stars… they’re sort of like planets) or life on some tiny piece of dust. Or perhaps something else regarding life (humans perhaps) in isolation.
• The internet. I don’t know how that’s a game, but it sure makes the world small. Are we allowed to write an essay in place of a game? No? Darn.
• Make the Earth less big. Blow it up.
• Survive the birth of a planet. Perhaps something of a platformer, although with no definite “up” direction and with asteroids and bigger planets constantly crashing into your planet (and perhaps your character…), making it larger. And, of couse, I’m not opposed to letting the planets blow up occasionally.

Also, I think I’ll be going with Processing. It’s nice and portable and doesn’t punish me for not knowing how to package my stuff or link with libraries.

I’ve decided on my idea. You play the role of Karl, the Cosmonaut. Your tiny home world (yeah, great connection to the theme, I know) has drifted into the wrong part of the neighborhood – the part of the neighborhood where asteroids and rogue planets. Your planet comes under assault from asteroids and other celestial objects coming in from all angles! Your goal? Don’t be crushed. You can walk around and jump. If your planet becomes too big from other stuff crashing into it, it blows up. There will probably be powerups and stuff if there’s time.

Here’s some pictures that I drew!

Well, I’ve made a bit of progress on my engine. Supposedly, it should be able to handle as many planets in a cluster as I need (or a lot more than I need – I only intend to have around 10 before they all explode), and you can move around, and the camera follows you smoothly. I’ve disobeyed all of Newton’s laws already, but that’s okay because it’s easier, and the 3rd law would really screw up gameplay.

I’m actually really close to a working prototype, since the game logic is really simple if I’m willing to assume that everything’s basically a circle (See? I learned from last year! No more complex physics crap bogging me down!). Admittedly, in terms of screenshots, there’s not a lot to show. It just looks like 3 white circles…

This Ludum Dare is going so weirdly for me – I actually feel like I’m doing things right this time around. The game will be publishable to the web, I don’t need to create any levels or write any code to generate them, and the game will be nice and fast paced. The one thing that’s a little bothersome is that people have done basically my concept before (except not in space… I guess the change in gravity is original) and it’s questionably related to the theme.

Well, I got a working prototype and, as is usually the case, I’ve found that it’s not really what I want. The game depends on being exciting – there must be constant action. It needs to constantly put you in peril, and you need to constantly be able to escape. Unfortunately, I haven’t captured that. It just feels very easy at this point, even when I set every parameter to as high as they’ll reasonably go. Doing the math, it seems that around 60%, if not more, of the incoming asteroids are not a threat at all (and, in fact, serve to block more asteroids), which is a problem. I’m thinking that the randomness of it might not be working, or maybe it’s the uniformity of everything being an asteroid.

Possible solutions:

• Incentivize staying on the home planet somehow (and make it possible to do so). Or, have some other thing that, rather than saying, “DON’T be under the asteroid when it hits”, have something that forces or encourages the player to be somewhere specific. You could gain a bonus from mining an asteroid.
• Do exactly the opposite – destroy asteroids after the player steps on them
• Make the player control two characters simultaneously.
• Strategically send asteroids to be extra-problematic for the player.
• Add more obstacles. I mean, it is space, so adding lasers shouldn’t be a problem. Then you’d have to use asteroids for cover (and then the game could send all the asteroids from the useless direction) or something.

In any case, I suppose I’ll do a bit of graphics at this point as a bit of a break. Maybe the secret ingredient might be an absurd amount of particle effects and shaking the screen.

For the last 90 minutes or so, I’ve been getting nothing done because I can’t think of what to do, and everything seems either out of the scope of 48 hours, or not effective at correcting my problem. However, I thought of a nice, small change that will make my game better. Rather than trying to not get crushed, which is fairly easy, the player must stay within a circle in space. This is made challenging by the fact that nothing will stay stationary, and planets will keep getting destroyed by other planets hitting them. Sure, I may have made a slight departure from the theme, but oh well.

I still don’t have any good screenshots to show, though…

Yay! This whole sentence is a link to another page, listing Windows, Linux, and OS X versions of the software. There’s also an applet uploaded (and signed), but it doesn’t seem to work and it won’t give me error messages so… don’t use the applet, I guess. If anyone knows why this might be happening, I’d be glad to hear it. The game is pretty intuitive (I think), but if you want instructions:

Use the right and left arrows keys (or A and D) to move your character around. You can jump by pressing the up arrow, W, or space bar. If during your jump, you hit another planet, you will stay there. Planets are constantly being spawned and will collide with each other. Red warnings will appear on the edge of your screen when planets approach. The planets will become damaged and ultimately explode (except without the explosion because I’ve not added it). There is a white peg in the middle of a circle. The closer you are to it, the more points you earn. If you travel 3000 units away from it (as indicated by the yellow bar in the top right), you lose.

This is probably the last *really* productive thing I’ll get done tonight, at least on the game. What I have left for tomorrow is (this is the optimistic list. It is pretty much in order of priority, so we’ll see how far I get):

• Code to detect when your character is pinched between two planets and to terminate  you accordingly.
• Add stars to the background. This is actually a gameplay element, since otherwise you have no idea how quickly your moving.
• A title screen.
• More images for planets.
• An astronaut graphic and animations.
• Sound effects! The gentle thud of planets as they hit each other, the sound of a spaceman jumping, etc.. Yes, I am aware that sounds don’t travel in a vacuum. No, I don’t care.
• Music.
• Explosions for when things explode. Maybe some other particles
• Maybe multiple difficulties.
• Achievements.
• More types of obstacles in the arena.
• Witty instructions.
• A good explanation of how this exactly relates to the theme.
• Create an a priori physics engine instead of the a posteriori one I have now.
• Do schoolwork.