http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=7456

This was my first Ludum Dare and I must say that I enjoyed every moment of it. I rarely see my projects through to the end so having a time limit and some competition was very useful for motivation.

What went right?

• Time. I had plenty of time to work on this game, an empty house and no plans for the weekend meant that I could dedicate every moment I was awake/not eating to working on the game.
• Pre-planning. I planned every aspect of the game on paper and planned out exactly what order I was make everything in before I wrote a single line of code. Not a single feature in the final version wasn’t planned on paper first, a lot of features from my original plans were removed though.
• Knowledge. Every feature in my game had been made at some point or another, in some form or another, by me. The problem was trying to remember how I made them and then put them all together into a game that actually works.
• Notch. That man’s livestream had some great music. Plus, the rhythmic tapping of his keyboard was great motivation to keep typing.
• Gameplay. The idea was that my game would be hard. I wanted people to feel under pressure while they were trying to disarm the bombs, I thought that the time-limit, lack of a reset button and having to start the game from the beginning if they failed was a good way of achieving this. Plus, if no one can finish the game, no one can complain that it’s too short.

What went wrong?

• Gameplay. Apparently players don’t like to be infuriated by high difficulty levels and over-the-top punishments for making just one mistake, who knew?
• Over-estimation of my programming speed. A lot of stuff from the original plans were never in the final game, this is purely because I didn’t realize just how long it takes me to code even the most basic of features.
• Lockpicking. As a result of not having the foresight to realize how long these features would take to add, lockpicking wasn’t started until a few hours before the deadline. This resulted in lockpicking turning from the Tetris style puzzle that it was originally supposed to be and becoming a “Bash the buttons as fast as you can” minigame with awful graphics. It also meant that the option to place a previously disarmed bomb in the lock to explode it open, had to be cut completely.

Conclusion:
Overall, I’ve learned that difficulty is not a good substitute for longevity and that believing my programming skills to be god-like is never a good idea, especially before I attempt to make something against the clock and something that other people will play.

This was my first Ludum Dare and I have to say it was a lot of fun. Looking back I can think of a dozen ways I could have done better, but I don’t think I would have ever seen those until I tried. Lets look back on the weekend about what went right, what went wrong, the game that came out of it, and what I feel I should do next time.

My Game:  http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=8475

The Game

After the theme was revealed. I was taken a little bit. I had read over the list of possible themes and had really no thought in my mind that it would be alone. So I had to think. Above all, I wanted to really work off of the theme in a real way. I thought that would help to make the game unique and feel part of this specific Ludum Dare and not just a generic game built in a haste for a contest. I decided on caves, on flashlights, and on dim lighting. After looking at the submissions it looks like about 100 other people had those same ideas. These were things that made you feel alone. I decided that I wanted the game to be about exploration, about rewarding curiosity and trying to achieve and end goal of just making it home. A solitary experience, but one that would (hopefully) be fun.

The Good

I finished the game! Just barely, but I did finish it. So what went right?

• Setting the mood. Even with a limited tileset (and talent) I was able to pull of  consistent atmosphere through the art.
• Navigation. Leveraging the Flixel Framework the platforming of the game works well enough to be considered fun.
• @Notch’s livestream. It may seem weird, but keeping his livestream open while I worked on my own game was a constant encouragement to keep working. Plus he cranked some pretty good tunes.

The Bad

This is it? The game was finished, but can I really call it a game? So, what went wrong?

• To many features. I had to cut so many features at the end, that the game feels incomplete.
• Not familiar with tools. I had never used Pixen or Dame before this event and I spent hours struggling against them to just get my tilemap working. If I was to do it over again, I’d do much better for this fact alone.
• Forgetting about the importance of Sound. Perhaps @Notch’s livestream is to blame, but I didn’t even think about adding music/sound until there was only 90 minutes left in the contest. I tried desperately, but had to cut them to finish the game in time. Then I sat and played my submitted game in silence and wept (silently) over what I had (not) done.
• Not knowing my frameworks documentation. Confession: I haven’t made a game in 3 years. Its been that long since Ive used Flixel or programmed in AS3. It was a world of hurt trying to relearn all of that in the course of 48 hours. It came back to me, but I spent way to much time reading forum posts and searching google for options and ideals. I feel the challenge in game design should be programming the conception in your head, not strugglingly against code libraries and syntax errors.
• Sick girlfriends do not, for a good game weekend, make. My poor wonderful girlfriend came down with a horrible sinus infection on Friday. Which caused my remaining time and attention to be torn between Ludum Dare and preparing Chicken Soup and the usual rounds of Man Nursery.
• Hitting the ground running. I knew this was basically a code sprint and I laughed at those attempting their premature code optimization. Sadly, my approach was just as wrong. I through coding standards to the win as I raced valiantly towards my goal. I had a working prototype up in only an hour! To bad all that code was scrapped and the residual bits came back to haunt me in the final hours of the game.

Tips for next time

• Plan then code. My work was never efficient until I took the time to get away from the computer and write out a game plan. It takes the indecision out of the process and helps keep you focused when coding.
• Make the game work first. I spent a long time working on individual features and making sure they worked. (some didn’t even make it into the game), but I neglected to make sure the game as a whole was working. Not until the final hours did I realize I didn’t have a cohesive mechanic for playing and, importantly, beating the game.
• Stick to coding conventions and organization. As tempting as it is to just let it all go away. Some of those conventions and organization techniques take no extra time to perform and will actually help.
• Know Thy Tools. I’ve already made a personal commitment to make a full game in the span of a week, the week before the next Ludum Dare, just to make sure the code, libraries, and tools are fresh in my mind.

Bonus: Where my Time went!

I use this great tool called RescueTime for keeping metrics of my average productivity per week. As an indie developer this is great. Well, I forgot that it would be keeping track of me this weekend and I for one am happy to see its results. Here they are.

Friday

• Development : 1h 50m
• Art: 10m
• Documentation / Reference: 1h 2m

Saturday

• Development : 5h 23m
• Art : 1h 40m
• Documentation / Reference : 2h 3m
• Level  Design : 43m

Sunday

• Development : 3h 44m
• Art : 1h 31m
• Level Design : 52m

In the end I spent too much time researching possible engines and didn’t get anything finished. A lot of time was wasted trying to figure out how to make Slick2d work in an applet. But really I didn’t have a game to applet…ize.

Game Name: Kitten Alone

Language: Java

Libraries: LWJGL, Slick2d, MarteEngine

Completion: 10%

I ran out of time leading up to the event to do the kind of self-education that would have made this possible. My current plan is to continue working on the game (and changing the title…) so next event I’ll have a better idea what I’m doing. And if for some reason my Java skills aren’t up to snuff by the next Jam, I may need to make the next entry in Basic. Or ActionScript 2.

Submission Page

Alone with... things!

What went badly:

• I didn’t have any basecode and started from scratch. Thus a considerable amount of time was “wasted” on animation, landscape tiling and collision detection coding.
• Any form of storytelling or player guidance fell victim to the time limit
• The LD started at 3am here in Germany. I only got 4 hours sleep prior to the start and got unconcentrated and tired rather quickly.

What went well:

• Coding went smooth like butter. I never really used XNA previously, but working with it is easy as long as you know the coding language well enough.
• I’m not much of an artist, but i’m happy with the art. Nothing fancy, but it works.
• Using bitmaps with 256 indexed colors for levels. You won’t need a level editor this way and adjustments can easily be made. XNA doesn’t support those, but the BMP format for color-indexed bitmaps is VERY easy to load directly from data.
• The game idea turned out to be interesting and fun. Combining a traditional gametype with some unconventional twist in gameplay seems like a good way to go.

Tips and learned lessons:

• Sleep and eat well before and during the competion. You won’t be very creative or focussed when tired.
• Use a coding language and tools you are very familiar with.
• Use base code for animations and stuff. If you don’t have any participate in the warmup to create some base code for such things.
• Priorize planned features and keep the unessential untouched until you are done with the essential ones.
• Look at the themes during theme voting and try to come up with ideas for as many as possible. It helps to bring your creativity up to pace, even if a theme gets voted for which you haven’t got an idea yet.
• A drawing tablet (even a cheap one) helps A LOT with making art, even if you aren’t much of an artist and not good at drawing on paper. Take time to configure it and its buttons well for a smooth workflow prior to the contest.

Timelapse:

There are many possible answers, even some impossible ones, but only one’s accurate.

I’m ridding myself of perfectionism.

Every time I start a project, I get stuck at worrying over every detail obsessively, to the point where the actual progress suffers. Ludum Dare with its strict time limit forces you to cut down on excess and only bring the meat to the table.

You can’t just wait for inspiration to strike out of nowhere. Inspiration comes when you’re actually doing and refining things. I was in a dead end in the night of day 1, but now I have a game I’m happy with. Perfectionism at its best is quality control for things you’ve already created, not a toll that blocks you from creating because “it won’t be good enough”. And LD always gets me in that sort of flow.

Also,

I told you it’s possible.

I feel like i’ve experienced the exact same scenario as my LD20 :

I started late, trying not to aim too high, but still wanting to add some fancy stuff like XP, ending up at -5 minutes without any thought on level designing.

What went right :

• I haven’t been stucked by any coding issue
• It’s not as ugly as i thought it would be
• I made a batman costume !

“A Tale of Seven Kittens”

What went right

1. Time Management
I made pretty much what I set out to make. I know how to manage my time and I know how quickly I work, so set my sights right on the limits of what I knew I could achieve in 48 hours. The game was completed about two hours before the deadline, which left me a bit of time for play-testing and tweaking the pace/balance of it.

In past projects my time has broken down like this: 40% graphics / 25% programming / 20% design & notebook / 10% testing / 5% sound. I think for LD22 the times I spent on graphics and programming were switched.

2. Choice of tools
I used what I was most familiar/skilled with. When deadlines are tight, one should aim to minimize risk by not introducing unknown variables.

3. I saved my energy
I didn’t bother with the warmup, nor did I do any material preparation.

4. Sleep and Food
I worked from about 11am to 1am, taking a 15 minute break every couple of hours, and a longer break for meals. I had slightly less sleep than I normally do, but still comfortably enough.

I made a big pot of борщ (borscht) and baked some черный хлеб (black bread) before the competition started, and this kept me going all weekend. There’s nothing like a bowl of traditional Russian soup to prepare one for a day of hard work.

What went wrong:

1. 3D Models
I initially intended to make some chunky 3D models for the monsters, but I realised at the end of day one that I wasn’t going to have time to do that, so I opted for flat sprites the same as the collectable objects.

2. Procedural Generation
It works fine, but due to an oversight it wasn’t quite how I wanted it.

3. Room Levels
Some rooms are higher level than others, containing difficult monsters and higher level loot. I wanted some way of indicating what level a room was, either with text above the monsters heads, or text for each room. In the end I opted for room colours which go from cyan->green->yellow->red->blue as difficulty increases. This maybe isn’t as helpful as a number. Room colours were initial random.

4. Particle System
An optional component was a particle system. I didn’t consider this to be important, and as such thought I would add it at the end if I had spare time. I didn’t have that time.

Overall, I am satisfied with the game I’ve made, and I may spend some time improving it over the coming weeks.

Bye bye

Man-o-man my first entry in LD and it was one hell of a ride.
I did the most I could do in between the interruptions and think it came out pretty good.
Talking with friends gave me really cool idea’s for the game (exploding kittens).
I had a lot of fun creating the music, the graphics and recording the sound effects,
which I’ve never done all that much for a game before.

Check my platformer out over at My Entry

What went right
Creating the content, which I didn’t expect at all!
I didn’t know about music/SFX content generators but now I do thanks to a friend (Frib)
who has competed in LD before. I also expected a lot more stress
from LD, but it was more fun than stressful!
Also implementing a lot of ideas like bouncy balls and spikes went better than expected.

What went wrong
Physics and collision, it just works so borky (omg, I googled it, it’s a real word).
It has something to do with rounding integers from rectangles and I just made a really
dirty fix around it. I also wanted to make more levels but I had other things to do this
weekend and that really limited me from creating more content.

Lessons learned
Maybe use a physics engine, or some sort of small physics engine for tiled games
I could create before entering? Also, I learned that I’m half decent, well better than expected anyway, at creating music and sound effects!
It was really fun to do and I can see myself doing that again for other games.
I think the next game I’ll make for LD is gonna be a bit more basic though,
I don’t wanna waste so much time on physics anymore.

Conclusion
Ludum Dare is a real lot of fun and I should get my other
game developing friends involved into this fun competition.
Which I will, next Ludum Dare. We’ll probably enter a Jam
(and maybe a little game for the Compo? ).

Btw 3 a.m. as a deadline is the best.

I didn’t get any immediate ideas, so I began by making the basis for a platformer with the theme in mind. Then it sort of evolved as I came up with things I thought would be cool to add.

The tools I used:

• Flashdevelop (IDE)
• Flashpunk (Game library)
• Photoshop
• Audition (sound editing)
• Cubase (music)
• Chronolapse (timelapse recording)

I decided early on to make it atmospherical, and I put a lot of focus on the effects, sounds, music and animation.

What went wrong:

My computer kept crashing throughout the weekend, I think it crashed 8 times in total, which was really annoying. Fortunately I didn’t loose much work.

I waited far too long to implement basic things like getting hurt, dieing and winning, which meant I had to rush that in in the last couple of hours. The basic gameplay challenge when fighting the ravens is not that hard or fun, I should have worked more on that, as well as added more kinds of enemies, and perhaps a boss. It would also make the game more fun if I added some sort of progression, like new abilities.

The story is intentionally vauge, but only because I didn’t have time to flesh it out. It might add to the mystery and mood, I’m not sure. I would really have liked to have time to add a proper ending.

If you miss one of the spheres, you have to go back and find it. I wanted to have some sort of checkpoint, where to pass you would need to complete the part of the game behind you, but I didn’t get around to it. This also means you can win the game in different places, which is maybe cool, but…

What went right:

I think the strongest part of the game is the atmosphere. The rain and lightning effects really add to the mood. I’m also happy with the graphics, and especially the animation, considering I haven’t done that much before. The music is simple but effective, I didn’t go crazy despite listening to it for 10 hours straight.

The player physics feel pretty good, although the attacking part can use some more work. I’m proud of the healing mechanic although it isn’t used to such a big extent.

The camera doesn’t follow the player all the time, instead it snaps to 32×24 tile screens. This was an experiment, and I think it turned out ok. Because the screens are predetermined, you have more control over the scenes the player will see, and can tailor each scene to look as best it can. Of course, it’s also a limitation, and can be irritating for the player when navigating small passages for example.

I made the level as one big png-image in photoshop, where each pixel corresponds to one 10×10 pix tile. This made it really easy to edit, and because it was one single big image, I could quickly see how the whole world looked together. In order to see where each screen in the game was positioned, I just filled the image with helper rectangles. It worked suprisingly well.
Here is the final world image scaled up a bit (Warning: SPOILERS!): world.png

The auto-tiling was a thing I threw together in a hackish manner, but it worked really well too, and supports additional tilesets easily given an offset to the base tile (solid tile).

Summary:

I’m happy with the result. The graphics are simple but effective, the atmosphere is good, sound and music works, the gameplay could be better but is ok, and it’s a completed game! I focused on stuff I usually don’t, and think I learned a whole lot. You can try it out here: PLAY!

Here is the entry page, go rate it.
http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=2311

Bonus:

Some concept art I made while trying to come up with an idea.

Yay, like my fourth time competing in a Ludum Dare and I actually submitted something this time.  I had more plans I couldn’t act on, but at least I got something done this time.  So, what did I learn from all of this?

• Don’t change the base idea of your project the last day…
• Planning everything ahead of time to make things simpler on you later will not prevent you from cutting corners like crazy when the deadline looms and writing code you will not be proud of
• Kittens, while not the BEST theme, probably wasn’t the worst one either…
• There are no good free music generators that you can find for free easily.
• Converting a MIDI file (from Wolfram Tones) to an MP3 is much more difficult than it should be
• I am very very rusty at pixel art

Still, I am happy to have gotten something running and submitted, and do plan on adding the rest of the features I didn’t have time for and cleaning up the code so I am not ashamed of it anymore in the upcoming days after the deadline is up.  And hopefully by LD23 I will know what exactly what all I need to bring to the table.

Ugh. I reached a total brick wall (hehe) and couldn’t think of anything to do with the game. I realized that I would have to make a lot more gimmicks in order to keep the dungeon interesting, and I simply don’t have the time to implement all of that. So, I’m releasing it as-is.

I did, however, learn a lot from the competition this time around. jMonkeyEngine is a bit impractical for 2D games with very basic entity behavior, but it can be done, and it is otherwise fairly robust. I feel as though if I had the time, I could very easily create a full, 3D game on the engine. I also learned how to do physical collision using ray-casting, and for the most part, the implementation in the game works perfectly (except for a little exploit that I wonder if many people will find… it was very fun to play with in testing).

If I hadn’t decided to build the game for the purpose of learning jME as opposed to taking an easy route and using Swing or Slick (like Notch is doing), I probably would have made it far more complex and long.

Oh well. It was fun, and I’ll try to compete in the April competition if AP studies don’t get in the way.

Seeing as this is my first blog post I’ll include a preface about my first LD48 experience!:

I’ve been waiting to do a Ludum Dare event until I had 1) Spare time, and 2) Recent experience with a game programming language/library. The second point is important because I do programming entirely as a side hobby. I haven’t had much experience with the art in the past 4 years. I’ve taken swings at SDL, LWJGL, and Allegro before… but this time I had been learning to use Flixel.

Cut to the night of the competition–I was checking my email in bed on my netbook and decided to check on the LD website and HOLY LUDUM they’re having a competition right now! Man, this is cool stuff… what would I do for the “escape” theme if I were participating? Actually, what can I do? Well basing it on Flixel what if I made the main character an extension of the FlxTileMap class instead of the FlxSprite class? Hey this is an exciting idea… let’s actually do it! So I opened up FlashDevelop and started typing away in bed. I ended up coding the whole thing on a netbook. The graphics I did on my old old desktop simply because I wanted higher resolution and I already had Paint.net installed on it. It was crashing on me but… I frantically got my desktop stable again and pressed on. In the end I learned a lot more about Flixel and even came up with something good enough to submit! My only regret was not having enough time to squash bugs.

My game Globular Prisonbreak

So on with the blog entry thing. Results!

Here we go in reverse order:

Humor: No ratings at all? I must be super un-funny. I wasn’t really going for funny but the game itself is a bit corny. I expected a low rating for humor but got none at all. *shrug*

Community: I could probably benefit from posting once in awhile. I didn’t post before the competition because I didn’t register until a few hours into it. Plus there was no planning whatsoever. I didn’t make a post during the competition because I couldn’t figure out how to even navigate the LD website (and it was down mostly). I’d like to put a lot more effort into community stuff next time…

Fun: Well this was sort of expected. But I am surprised it got this low relative to my other scores. I knew it would be low because my game is confusing and buggy, and those make games very un-fun. On the other hand it’s fun in a innovative/schmup/puzzler sort of way. I guess my gameplay is also quite nitch and suffers from being something I want to make and not what others want to play. But I don’t think that’s not a bad thing.

Overall: Okay. Not much to say. Overall is sort of each individual’s weighted average. johnfn pointed out that Overall is closely linked to fun, so this score makes sense.

Audio: It’s nice to get a score in audio since the last time I touched game audio at all was with Modplug back around 2001. I only included a Level Complete Jingle for my game. I tried to have various pitch sound effects for when blobs hit you but my attempts didn’t sound right and I was wasting time. I’ll take a swing at sfxr now that I know it exists (thanks community!). I’d like to try including music when I’m comfortable believing that I can make something that actually sounds like music.

Theme: I was hoping to do a liiitle better here. Simply because my game was about escaping a prison, and each level involved you escaping off the top of the screen. I even included the line “Escaped!” as a possible level-win message. Plus I used the word “Prisonbreak” (not a “real word”, this is intentional) in the title, which I thought was a little more creative than games that simply used “Escape” in their titles. But I’m not complaining here so much as nit picking.

Graphics: A pleasant surprise to score this high on graphics. I did throw out my first colorful floor tiles in preference of a simple brick pattern after my roommate complained that they looked like shit. I guess it paid off.

Coolness: Ah yeah! My game is so cool! Oh right, this is about how many games I played. I made a point to avoid the overly-popular games during the voting. I played a mix of what looked interesting and those straight from the rate games page. My favorites were:

Dystopian Future Underground City – j_peeba
Bunnies, Back Into Your Cage! – ratking
Planetary Mission – NMcCoy
Towering Inferno – tenpn
Snake Plissken: Surfin’ U.S.A. – vandriver

I pity the fool who can’t beat Dystopian Future Underground City and Snake Plissken: Surfin’ U.S.A.

Innovation: I’ve been disappointed at myself that I couldn’t polish my game more or weed out bugs before submitting it. I was thinking, “well, at least I might score okay in ‘innovation’”. Turns out I did pretty darn well, and I’m really happy about it! I think most of us wouldn’t work on a game at all if we didn’t think it was innovative in some way. Why make something if it already exists? This i’s especially important to me because I spend a lot more time thinking about game ideas than actually making them (I don’t program for a living). Plus this is the first time I’ve made something public. So I couldn’t be happier with this result. I even made the Top 25 Categories page!

Future Plans

While I think my game does have potential, I don’t have plans to develop it much further. I think it would have to be reworked from the ground up. I would up the tile size to 16×16 and try to make gameplay smoother. My original plan didn’t have movement locked into a grid, and I’d still like to try it without the grid (which would need other changes for balance). Balancing could already use some work to improve the strategy aspect… things like reducing the color count to 4 in the earlier levels or changing the floor tile algorithm for better color clumping. (Without clumping there is no point to the bullet-adopts-the-color-of-the-floor-tile mechanic.) Ultimately I think my time is better spent on a randomly-generated platformer I’ve been tinkering with for some time already. I might start another separate short-term project or just wait until the next LD48. But until my “fun” rating becomes decent, I think I have to focus my time on real life concerns.

In the interest of full disclosure, I’ll state up front that the main reason for this post is because someone told me I couldn’t get trophies if I hadn’t written a blog post. I have no idea if we’re too late for any awarding, but what the hell.

I haven’t really felt the need to talk about my game, EscapeOut, because it wasn’t a particularly interesting process. Relying on a 20-min show-off video by Photon Storm about how to make a brick breaker in 20mins, I stumbled my way through Flixel and came up with something that put a little spin on the core concept. The theme of LD21 was Escape, so how else does one apply that to a brick breaker? Easy: something on the screen has got to try to get the hell out of dodge. From there it was a simple leap in logic to the eventual core mechanic. I won’t say what that is because I don’t like to spoil the game. In fact, I really liked setting friends down in front of EscapeOut with no instructions to see if they can figure it out. The game has no instructions for a very intentional reason.

Judging by the comments on EscapeOut, forcing players to discover the game’s mechanic paid off. I’ve been a very bad LD participant: haven’t blogged, haven’t played many of the entries, haven’t used the IRC channel except for a couple technical questions. Mostly this has been due to time; I only managed to spend half of the 48 hour timeframe coding, due to oversleeping and family obligations. So, I was quite surprised to log on today and see the comments and ratings left for EscapeOut. A few people really seemed to like it, more than I ever could have imagined. Even more shocking, the game was rated #54 in humour. Seriously, a game with no instructions, no words other than “YOU HAVE DIED” and “YOU ESCAPED”, no characters, no narrative, and even no sound effects or music, ranked within the top 10% of humourous games in the entire Ludum Dare 21!

I guess this really goes to show that an intriguing mechanic can turn a relatively bland experience into an interesting one, even if only for a few minutes.

[My name is Carlos Leituga and I’m an intern Junior Game Designer / Implementer in a Portuguese company, where I’ve been working on a Hidden Object Adventure for a year now. I was invited by friends to help develop a game for the 21st Ludum Dare event. We are the Make A Game team.]

It was around 11pm when I left my house with a 1 hour trip ahead until I met the yet to be named Make A Game team. Having memorized half of the list of possible themes, I spent the little I could of brain waves keeping my car on the road, and tried to think of quick game mechanics suited for a 72 hour game development.

I was the last of the team to arrive; I met some new faces and joined in on the ready up ritual. There were still 3 hours until the official LD #21 theme to be revealed, so we started throwing ideas around, writing them down on our white boards and linking them to similar themes.

 Look busy guys…

The awaited hour finally came, and the Escape theme was victorious. We quickly (and sleepily) gathered around one whiteboard and started discussing our previous ideas, along with new ones. Among them, the Survival Tetris game was highly praised. For some dumb reason, I went to my computer and searched if someone already had done such a thing. It existed, and in two quite different forms. In one you only controlled a stick figure, and in the other you controlled both pieces and a round character. We were bummed out.

(more…)

Post mortem for Towering Inferno, also cross-posted from my dev tumblr:

Things that went right:

• The Pomodoro technique kept me focued for the first day. It breaks work down into 25 minute chunks, with 5 minutes of break inbetween. In my todo list I kept track of how many pomodoros I had spent on each task, so I could see when I was getting sidetracked. For instance I could have spent more time on the procedural level generation mechanics, but could see the pomodoros adding up, so decided to move on.
• Git and github. I haven’t used Git in anger before and quite like the workflow, but by hosting for free on github I could quickly push updates to a friend who would playtest them for me. This was two or three keypresses in bash, but if I had to package and email off builds it would have taken much longer.
• Playtesting. The game was essentially finished by 5pm, but I spent a lot of time balancing and playtesting the game, along with a friend mentioned above. He helped me fix many bugs and gave input on the difficulty and balance of the game. It’s inifinitely better because of his input. Thanks Steve!
• Libtcod. This was the first roguelike engine I tried. I had others lined up, but this fitted the bill perfectly. It did not require much code to hook up, and handled all the annoying bits of game development: graphics, input, etc. Its BSP library was very useful for the procedural generation of levels, and even provided a good random number generator.

Things that went wrong:

• Difficulty. The procedural generation is very basic, which makes some levels much harder or impossible compared to others. The only sop to this is that fire is not allowed to start in the exit room or the room connected to it. This removes some of the frustrations but it’s still there. I needed more time to come up with a scheme that generates fire in challenging but not frustrating places.
• Choosing an engine. I was originally going to use Unity, and had spent a few days prior to the event learning the ins and outs. However on the morning I decided on a roguelike game, which by its 2D nature is not very well suited to Unity. It took me more than the first morning to investigate, choose and then learn a dedicated roguelike engine. Libtcod was very good as I mentioned above, but I could have got a lot more done if I had got up to speed before the weekend.
• Presentation. Everything about the game is functional – the color of the fire, the ascii art representing the tools, etc. It is not that attractive to look at. In particular it’s not easy to create enticing screenshots, which may hurt the click-through rate on the ludum dare site.

After having improved the level generator a lot, I think it’s the right time to write a post mortem of my game.

What went right:

• Game idea: At first I was disappointed with the theme, because I had some nice ideas for self-replication and genetics. But with the morning shower there came several interesting ideas. First idea was some sort of swarm attracting rescue game (still self-replication minded), second was a rpg in which you try to escape your chosen role (e.g. only get xp for things you are bad at) and the third idea was the actual one. I chose the later because it was the easiest to implement.
• Tools: After warming up with python and pygame in the Mini-LD shortly before LD21 I felt very secure with the programming. Gimp, bfxr and Musagi also worked great.
• Time management: Almost all the time I felt just a little bit ahead of my schedule which really is a great feeling (should once happen in my everyday job)

What went wrong:

• Final improvements: I head some plans to further improve the game: better soundtrack, improved graphics, more player control over level generation. I even had the time, but as my wife and child came back home on Sunday my time for game development suddenly vanished (that’s not as bad as it sounds )
• Windows executable: Meh, stupid py2exe. Just didn’t want to automtically bind the sound libraries. Actually that’s just a small issue, cause it wasn’t necessary to have this executable at Sunday night, but I was so eager to release it in time.
• Randomized levels: I made a rather late decision to do randomized levels instead of pre-designed with raising difficulty. I am quite happy that I chose the randomized approach but my algorithm was to stupid to have real control over the difficulty (explanation here). I fixed it for now, which I want to illustrate with two screenshots.

Developer's "see all" mode: On the left the old generator on insane. Number of cages and cacti walls are quite random. On the right the improved version. Fixed number of cages and walls with random distribution.

Will there be a post-compo version? Definitely, there already is (not yet online) and I am planning to do further improvements based on the feedback so far. Ideas include:

• Different play modes (e.g. visible cages with other constraints than now)
• Kind of  dungeon crawler with inventory and classes
• Integrate the dungeon crawler to a bigger scale exploration game (to prevent stupid descend dungeon levels)

Final words: If you haven’t already:

Go Play

This was my first Ludum Dare and it totally rocked.  I am a great fan of creativity under a deadline events.  I’ve participated in NaNoWriMo (Novel Writing), 24 Hour Comic, and NaNoRenMo (Visual Novels).

The Good:

Remembering to keep things simple.  The original story I came up with was much more complicated and involved things like timers and explosives.  I broke it down to the simplest elements.

I made my own event system. OK.  This is not that great an achievement, but I am happy with how well it worked.

The Bad:

End Graphics (The Lack of) I ran out of steam with the artwork and didn’t make any. The game didn’t feel complete without them.

Awkward interface.  Adding the mini map helped a bit, but it was hard to place yourself in the location.

Passage of Time not Apparent. Many people didn’t notice that the raccoon was slower than the cat.

What I learned:

You are much tougher on your game than other people are.  There is no need to point out all your mistakes to the people playing your game.

Play my game!

Susan

What Went Right or The Awesome Things

The schedule I laid out for myself worked very well. Before starting I decided to set very general time slots for when I would work on what. These were split into two segments: first 24 hours and (you guessed it) second 24 hours. Knowing that gameplay and mechanics are the glue that hold most games together (there is the rare game where this is not the case) I decided I would reserve the first 24 hours to having a completely playable, beginning to end prototype of my design minus art, music, story and sound (those 4 things were to be worked on in the last 24 hours. The question needs to be asked, if I thought gameplay was so important, why did I set so little time aside for it? The answer is because it was my first Ludum Dare. I didn’t know how much time it would take me to upload everything, how much time it would take me to randomly scribble on my computer until I  got something that could maybe somehow pass off as art, nor how many takes I would need to record on my cello to get serviceable sound. So yes, my schedule wasn’t perfect, I did end up with some free time on the last day, but the point is that my game was complete. It wasn’t a great game, but it did what it set out to do perfectly, be a simple story based puzzler.

The music was something I was surprisingly capable of doing well. I had the idea set in my mind from the very beginning that I would do all of the sound for the game on my cello, because I thought it would sound cool, and because I thought it would save time and allow me to focus more on the other aspects of my game. The thing was, I hadn’t played my cello for a good 2 and a half years, having given it up partway through my eleventh grade of highschool. Luckily my 7-8 years of training flooded back to me and I did a job that I’m proud of, even though I couldn’t get the looping to work perfectly.

The sound efects were something I struggled a lot with at first, after recording all of the music I decided to test sound effects by randomly playing them over the looping music tracks. This sounded absolutely HORRIBLE, like stab-myself-in-the-ear-with-my-cello-bow bad. At first I thought it was because the sound effects were note-based as was the music, and the dissonance was causing it to sound terrible. So I decided to try an experiment, I went online and watched a bunch of videos of classic games known for having great music (Super Mario Bros., Legend of Zelda and Sonic the Hedgehog are the three most recognizable ones I watched) and found that there sound effects weren’t much different from mine in that they were off-key, out of time and just generally clashing very much with the music. But they sounded good. But then I turned off the monitor and re-watched (listened?) the videos. And they sounded terrible. So, I concluded, that when  you know that a sound effect is coming, when you know what it will sound like and what causes it, the brain is capable of filtering it onto a different track then the music, making them separate entities. Basically, you are capable of listening to the tune uninterrupted in your head, even though what is really coming out of the speakers is a cacophony of unspeakable ugliness. So I kept my sound effect as they were.

The mechanics and gameplay worked well, and in my opinion, were fun to use. I don’t really have much to say about this, as the best way to find out about them is to play the game yourself

Obligatory picture placed here to keep reader attention.

What Went Wrong or The Things That Sucked

The level design was hindered by the coding. This was my biggest failing and the one that could have most easily been avoided. Before the competition I was set on the theme of Self-Replication and a Legend of Zelda-like game where your character only lived for thirty seconds and then respawned, leaving the world as it was when he died, needing you to go back over and over again to set up the world to be conquered in thirty seconds or less (or whatever amount of time). When the theme of Escape was announced I was thoroughly unprepared. I had, gone through the list of themes and made ideas for each of them, but the theme of Escape was one of the few (along with Espionage, Castles and others) that didn’t have any idea to its name. So I tried to adapt my Self-Replication idea to the Escape theme and started coding a whatever you would call a Legend of Zelda style game. By the time I wizened up and decided to go with my final idea, so much base code was written that I wouldn’t have time to rewrite that I was severely limited in mechanics I could add to my puzzler. The “engine” I had created did not allow for dynamic npc objects, something that could have been implemented into my level design had I had more foresight.

The art sucked, and it sucked bad. I am not an artist, I have tried to teach myself, to practice and to improve. However, I have not (though I’m not giving up (: ). I knew my art would be bad coming in, but I thought with enough time I could slowly make something that looked good. Unfortunately, I wasn’t able to, I ended up drawing base shaped and using all kind of effects on them so that they looked like they were well drawn (but in an abstract style). Luckily, however, I came to the realization that I would have to except defeat very early, allowing me to at least make the concession of only including two-frame animations, in order to lower the work required.

As beautiful as the the stars at night.

The typo. I wrote wan’t instead of want. That is all.

Last... typo... you... will... be... destroyed.

In the end, I found this Ludum Dare to be a great experience that came out of the blue (noticed it mentioned on the Minecraft site when I was downloading the game) and was a fun learning experience that I got to share with 599 other people. I’d like to thank all of the organizers of the Ludum Dare for offering this experience to people. See you next time!

This is kind of a port-mortem of EscApe (there’s another game with same name, it’s not about that one ) but I’m going to focus certain design choices I did in the 3 hours I created it.

Massive spoilers below, so if you intend to play my EscApe, go do it now!

“Your game is just a crummy monkey in a badly drawn cage”, you say? Perhaps, but there’s still more to it than meets they eye. Continue reading!

I’ve found two other games that are exactly the same as EscApe, except that they look and play quite differently. There’s The Power of Escape by BurnZeZ and BATHOS by johanp. I’ll use them to point out some differences in game design, which might sound like I’m trying to bash the other games, but that’s not my intention. Read it as constructive criticism.

The basic concept [of all 3] is of course to present the player with a room, which is impossible to escape using methods normally available in computer games. Not until the player starts thinking outside the box (or tries to quit the game, as we’ll see later), and takes what’s printed on her keyboard literally, she will escape the challenge. If executed correctly, this puzzle actually takes place in your room, rather on the computer screen.

Now, what did I try to do with this? My goal was to give as many hints as possible, without actually revealing the solution. I wanted the player after figuring it out to think “omg, why didn’t I think of that from the beginning?”.

Starting at the title, there’s a big green hint all over the screen. But I tried to draw your focus away from it, by making the game about an ape. You see, the title only says “escape” with “ape” highlighted.. or does it? To put even more emphasis on this I added the text “Can you help the ape escape?”. There’s actually one more thing, which I didn’t think of until later, that APE is written in a slightly stronger color than ESC, but I think the difference could have been even bigger.

Still at the title menu, at the bottom it just says ENTER (the compo version had more text, but I thought it was distracting so I changed it). This is also a hint, actually. You see, I don’t give any exact instructions on how to play the game – I will return to why shortly – you have to figure it out yourself. As I mentioned the solution is to read the Esc-key literally, and for this to work, all keys have to work in the same way. You enter the game by pressing the enter key. Simple enough.

Lack of instructions, yes? The reason is of course, that only thing worse than giving no instructions at all, would be to give partial or faulty instructions (without telling the player that they are faulty). So either you tell players what all keys do, which would spoil the puzzle, or you say nothing at all.

(BATHOS – not made by me)

As you can see BATHOS looks nothing like my game, it has much better graphics (and sound) and I thought it was incredibly funny as well. But the other Johan seems to have done the opposite in just about every choice I’ve described so far. In fact, it even seems like he knowingly tries to lead players in the wrong direction  By giving instructions, there’s nothing in the game – or deducted from experience of playing 100s of other computer games earlier – saying that there’s another unmentioned key that is crucial to winning. Further, if Z means “jump” and X means “pickup”, then Q might as well mean “escape”? IMHO it’s a little like playing Super Mario Bros and having to figure out that you have to press the reset button on your console to press to find the princess. Though BATHOS has a lot more comments and ratings than EscApe, so maybe this is what people wants

Back to our poor, caged simian. My idea here was to print out the key you pressed in clear text, so you would get the connection between its literal meaning and what goes on on screen. Initially I was going to make it more passive, so that pressing left would only make the monkey look left for example, but I ran out of time sooner than expected. People ought to figure out soon enough that moving around in the cage won’t help you, so I’m not sure it made any difference. Hopefully after coming to that conclusion, all the previously mentioned hints have trained the player enough to start pressing other keys to see if anything happens.

Due to this lack of time, there is a crucial part of the game missing; There should be more keys with functions in the game to lead the player from using the direction keys to thinking “aha! I need to press Esc to escape”. Not only would this help bridge the logical gap, but also add a little bit more fun to the game. These were some I thought of:

• Space – Launches the cage into space or something. Maybe the monkey just thinks about space. However, it is a very important key, as it’s likely one of the first ones the player tries pressing (partially because of its size and location and partially because of its use in other games).
• Shift – The ape shifts its weight around.
• Home – Text: “You can’t go home”
• Enter – Text: “You’re already inside”
• Dash (well, it’s technically a minus sign, but they look similar enough) – Quick sprint in either direction.
• End – Popup saying “Are you sure you want to end the game?” with possible quit.
• Backspace – Printed as “Back (from) space” and returns to the jungle. Maybe too far fetched.

So why am I ranting about all this? Because gradually training the player to adapt to your game’s rules and mechanics is how you write modern games. No game designer ships their game with a printed manual these days, and if they do, nobody is going to read it Another central concept of modern game design is to make player feel like they’re doing exactly what they want to, while they’re doing exactly what you want them to. This makes the player feel incredibly awesome and is a lot more rewarding that simply following a heavily scripted story. Ok, so EscApe isn’t Half-Life 2 (Valve are good at this), but maybe it’s a little bit more to it than you initially thought?

I wonder what would happen if the next LD theme was “space”…