Now that the voting’s over, I have some tips on how to make a good concept for the game that I learned from observation and feedback.

1.  Aim for completeness over detail

The games that I enjoyed the most are the ones that feel complete. By this I mean that your game feels like any other, but shorter. Definitely work hard to include audio, non-placeholder graphics, and whatever else your game needs. Think about it like you’re trying to sell your game: you can’t give out everything you have in mind, but you can demonstrate why each aspect of it is good.

2. Let the player lose

If your game is based on levels and you only have an hour to do them, you are probably going to need to cut down on your vision. A common mistake is to drop the latter half of the game, where the levels become more difficult. I am much more interested in the levels that will challenge me and that I will fail on than some hyper-detailed tutorial. Let the player struggle with the clever mechanics you had in mind. A great example of this is Increpare’s Puppy Shelter. Even if your game does not involve levels, the player is eventually going to get bored of constantly winning with ease.

3. Reward smart actions from the player

From the comments on my game, I found this lesson to be quite important: the actions that the player can perform must significantly and obviously affect their performance. It is incredibly rewarding, as a player, to, after trying your game for a few rounds (or whatever unit your game is measured in) to be getting better scores (or whatever unit success is measured in in your game). If your concept doesn’t do this, it needs to. Also, remember that just because you, the developer, can see the link between actions and responses doesn’t mean everyone else can.

4. Make the Connection to the Theme Obvious

While it’s entirely possible to go through the competition and just write some short blurb at the end that uses the theme in it once, much of the challenge in this competition is using the theme. The theme serves as a constraint that lets you explore ideas that you wouldn’t have otherwise done. You are likely to be more innovative if you set a goal of yourself to put the theme even in the game mechanic because it rules out what has been done before.

5. Ensure that the player can learn the game

This is another one of the problems that arise when you try something new for your game. Ideally, your game would be completely intuitively – people would just figure it out from clicking on stuff and pressing buttons on their keyboard and no instruction at all would be necessary. It’s unrealistic to think that every concept you think of fits that. If you need to explicitly state anything more than that your game is a platformer and that it uses WASD, you should include some sort in-game tutorial (textual doesn’t work very well. I’ve tried that twice; people need to see what is being talked about and to try it). If, for your game, players need to memorize a lot of keys to press or rules, you need to simplify your concept.

6. Be confident in your game

Please don’t belittle yourself in your description of the game. Try to make your game look good.

7. Have fun

Okay, this isn’t exactly related to the game concept, but it’s always good to remind people of the fact that their ultimate goal here is not to win, but to have fun and that all tips are there to be broken. This is a great opportunity to try out new concepts and to do cool things. You should let yourself do whatever you want. There’s no reason not to; regardless of what you do, this awesome community will give you awesome feedback on your awesome idea.

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…

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

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

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.

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!

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.
(more…)

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.

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…

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)

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.

Congratulations!

You are the proud new traffic controller of this doomed city! Why anyone would be so insane as to WANT that position beats me, but you got it, and there is a giant wave coming in from the East. The situation is quite bleak, and it is up to you to prevent as many deaths as possible. This city has a high-tech system that lets you control the evacuation in great detail. When you begin, you will be brought to a screen that looks like this:

On the bottom of this screen, you can see the number of cars that you’ve rescued, and the number of cars that are still alive, but have not yet been rescued. To the right side of the screen, you can see a blue sliver, which is the progress of the wave – it kills any car that it touches. It will grow bigger as time goes on. In the middle of the screen, there are a lot of red-ish blocks. These represent buildings. If you click on one, it will turn green, and start allowing cars to exit from it:

Each car will take the shortest legal route that it can find to the exit. Because of this, cars will often try to take the same route, and it will cause gridlock. Now, in my experience, gridlock and deadly waves do not mix will, so, to combat gridlock, you have another control: You can make streets 1-way only by clicking on them:

1-way roads are marked by the little carrots. Cars will always obey these unless you block off their only exit, in which case, they will act eratically. A good goal is to try to keep all of the exits to the city full of cars at all time. This image also has buildings that are gray – gray buildings have been fully evacuated, or, at least, cannot be evacuated further (that is, all of their occupants drowned because of your ineptitude).

After all the citizens are either dead or safe, you will be evaluated. The following criteria are evaluated:

1. How many people you rescued.
2. How many people you did not rescue.
3. How many people were killed before they escaped a building.
4. How many people were killed while trying to leave the city.
5. How many buildings were completely evacuated.

So, throughout this entire dare, I’ve been having to deal with my program randomly segfaulting and crashing due to reasons that were unknown to me, and somehow related to the std::list class. To fix this, I rewrote the class, and it runs perfectly now (or, so I think. It’ll probably crash when I go back to test more). Also, I’ve got my title page and credits page done, and am making good progress towards finishing!

Here’s a screen of the title screen, for your enjoyment (and it gives the name of the game!):

So, I managed to get my game logic finished last night, and now since the site is back up, here’s a demo (without so much

milo.grotonma.net/uploads/LD21.zip

It contains no instructions, so I’ll give a brief rundown:
1) Each weird redish-thing is a building. If you click on it, cars spew out. Red Building = Not evacuating, Green Building = Evacuating, Gray Building = Empty.
2) Cars always take the shortest path to the exit (which is any road leaving the left side of the screen). This usually causes gridlock.
3) There is a deadly wave bearing down on the cars. Evacuate the buildings before it’s too late (or don’t; it’s your choice).
4) Clicking on roads makes them into 1-way roads. Cars will obey these UNLESS there is no path to the exit.

Okay. That’s where I am now. Also, that’s an entire game. That means that tomorrow is left for assets, tweaking, and making menus and stuff. Which is AWESOME because, last time I did the Ludum Dare, I was working on the game logic until up to the deadline! Also, my timelapse is working this time! Things are really going up my way this time.

Of course, I have to say that if I had been a fool like last time and tried writing a fairly elaborate physics engine, I would be failing again (Read: All the blog posts I wrote last time about HOW ANNOYING that code was. Debugging it took up, probably, 90% of the entire time I was working on that). Also, every system in this game is discrete, so I didn’t waste time on difficult math (I love doing that math though). I think that, even though I only intended to do the Jam this time around, I’ll be able to make the competition, which is pretty sweet (although, I don’t have any windows computers nearby, so they’ll have to compile for themselves; shouldn’t be too hard though, since its only dependency is SFML).

I’m quite pleased with this game, especially considering that the theme completely caught me off guard (what were you thinking, people who voted for “Escape”?) and that I didn’t really have any good ideas (~first 16 seconds of my timelapse = creating a game below my quality standards) until about 8 hours ago. I’ll have to think about whether I want to keep working on this game after the dare (it needs more spicing up though).

Well, I haven’t had much time to work on my project today (which is why I’m trying for the Jam), but that might be a good thing because I have thoroughly convinced myself that my old idea was not actually worth working on and that it didn’t actually integrate the theme into the game mechanic. Thus, I have come up with a new, better idea (and one that might actually get done in time)!

The idea is basically that you are some sort of city official that is trying to evacuate a city. The player would be able to mark streets as 1-way

So, my idea has been something based around escaping the army. So there will be lots of shooting. Also, there needs to be maps too, so here’s a picture of some procedurally generated terrain that I have started on. It’s supposed to be nice an’ simple. I’ll probably have several types of terrain in the future, but this will by my “urban” environment (without, you know, the buildings and snipers).

In any case, here’s an image to give the illusion of progress (these are basically the final graphics, except without the… uhh… parallax background, sepia tone, buildings, character, etc.)

(Also, I’m unusually tired tonight. Hopefully I will be able to stay up to, at least, when I usually go to bed tomorrow…)

EDIT: I decided that this idea was terrible, and needed to die. So this is unrelated to my final product.

My ideas so far (direct from the recesses of my mind):
1. Some sort of racing game with something chasing you that you have to escape
2. Escape from the wild. Some sort of RPG-ish thing.
3. Escape from the army. Maybe like a platformer. Could have interesting mechanics in both having to fight off the enemy (or not? ally the enemy?) and avoid detection by your nation.
4. Use sepia-tone graphics somehow…
5. Mash the escape button. Not sure how this turns into a game…
6. Something where you don’t know what you’re escaping from, and the goal is to find out.
7. Escape the internet/technology. Something about destroying infrastructure related to the internet (because let’s be honest, how else would you escape it?).
8. Escape stress/time pressure. ???
9. Something where “Escape” doesn’t come first in the sentence…
10. Escape daily life. Something about getting away from routines. Could be set in some sort of dictatorship that enforces routines.

I’m in. I probably won’t make it in time for the contest (since vacationing with my family is a full time job), but I’ll try to get it in for the Jam.

Tools (assuming that I make a 2D game, which is probable considering that meshes are time consuming; if I do make a 3D game, it’ll be in Unity):
IDE: Xcode
Library: SFML
Graphics: GIMP
Audio: cfxr, Garage Band

(And hopefully, unlike last time, I will not screw up my timelapse)