I believe a better name than post mortem would be lessons learned, so let’s see my lessons learned from the  competition. I would love to read this before the compo, as I can’t make the time go backawards, let try at least to help other newbies.
1. create the menu navigation at the start of the competition
As I was fighting agains some physics problems during the development process most of the menu was left behind. Then I realized 30 minutes to the end that my menu would be an image =) and a play button…

The lesson on this would be, use time in the middle of the nightmares to do these brainless activities, because what can go wrong while build a menu ? =)

2. draw in the paper build and color in the computer
That helped alot, I save my day manipulate the lines with inkscape, but … in order to slice images I have a nightmare with inkscape, go with Gimp works as a breeze

3. dont split images, let the engine split for you
ahhhh I spend some hours cutting images lol !!, could use something like http://love2d.org/docs/love_graphics_draws_1.html to draw a subsprite of the image …

4. make physics work for you
Oh Well after the physics hit me in the head, I learned some details and was able to make it work in a decent way, special note for the boats that hang around over the sea, for that I created a sequence of x,y that is the path to the boats, and I try to follow the path, I believe if I make the water line as an object and change its group to only colide with the boat would be the best to move the boat around.

5. clean the tables in one place only.
Not sure why, buit when I was removing items from my objects list in teh collision handler the LOVE was just crashing … workaroiund that I found : flag to items to be removed and remove in the update() method and one by one from each table, this is call at the end of the update() for each cleanable table :

[code]— clean the tables
function cleanTable(table2Clean)

for n=1,table.getn(table2Clean),1 do
if table2Clean[n].dirty ~= nill then
table2Clean[n].poly:destroy()
table2Clean[n].body:destroy()
table.remove( table2Clean, n )
break
end
end
end
[/code]

and at the collision handler, I dont remove the pig from the list, just flag it
and I believe that this would be a nice way to animate the pig booom =)
by using a multistate, like alive/almost dead/dying/im outa here
would change the image section, or play an animation … and at the end remove from the list
that would be great …

[code]
function killThePig( id )

love.audio.play( audioCollision, 1 )
pigsKilled = pigsKilled +1

for n=1,table.getn(pigs),1 do
if pigs[n].poly:getData() == id then
pigs[n].dirty = true
break
end
end
end
[/code]

6. reusable files should be in a folder
I’m using for labels the .lua classes that I made called LOVEly-eyes, but I had this problem with the Text object that wasnt transparent … Oh well I went in the code changed the super class, Rectangle to handle this and the Text is transparent by default, cool, but but but … after that I just copied all the files from the LOVEly-eyes folder to my game folder … too bad because I copied a main.lua file together … If I wasnt using subversion would be a nightmare … now LOVELy-eyes are in a separated folder =)

7. use a version control system
I used subversion, saved me when I made an stupid folder copy … revert and just lost some minutes of work… bu remember keep on committing =)

8. put together a zip with everything
Better that just the .love file, create a package with the execs, the best would be create an installer.

9. level up level up !!!
people like rewards, so more than the score I should add level concept, just with faster attack of the pigs, or a different scenario with different speed .. hummmm that would be cool a .lua file for each level

10. collision has 2 sides … A and B
It took me some time to realize that A and B collision data, first they are the DATA from the polygon nothing else, just disconnected data, not a reference, not and pointer … hehehhe string data what makes very nice and unplugged from the code, and you have to test both sides, if wherever A colide on B and the oposite, this was my colision code

[code]function collision(a, b, c)

if string.starts(a, “pig”) and string.starts(b, “battery”) then
killThePig( a )
removeTheBattery( b )
elseif string.starts(b, “pig”) and string.starts(a, “battery”) then
killThePig( b )
removeTheBattery( a )
elseif a == DIODONTIDAE and string.starts(b, “food”) then
eatFood( b )
elseif b == DIODONTIDAE and string.starts(a, “food”) then
eatFood( a )
end

end

function string.starts(String,Start)
return string.sub(String,1,string.len(Start))==Start
end
[/code]

note that I used start() because I add the object id after the type, so I can grabb it from the list, something like “crap_2″, “crap_3″

11. scroll the view is possible Luke… use the force !
Ha ! not the force, at the end I solved the screen scrolling with a simple solution, calculated a shif from the main character and update this shift in the update() method and every single draw has this shift. So the camera is following the character, thats stays in the screen all the time, and to avoid the char to drop outside the world I add invisible walls on left and right side and check if the cameraX is in the possible range,

this in the start of the code

[code]
startCameraX = love.graphics.getWidth( ) / 2
startCameraY = 200

cameraX = -startCameraX
cameraXLimit = {}
cameraXLimit.start  = 0
cameraXLimit.finish = -2905
[/code]

+ cameraX on each draw
[code]
love.graphics.draw(diodontidae.image,
diodontidae.theChar:getX() + cameraX,
diodontidae.theChar:getY())

—— draw the batteries
for n=1,table.getn(batteries),1 do
love.graphics.draw(
imageBattery,
batteries[n].body:getX() + cameraX,
batteries[n].body:getY(),
batteries[n].body:getAngle() )
end
[/code]
this on the update()

[code]    cameraX = startCameraX - diodontidae.theChar:getX()

– keep the camera in the boundaries
if cameraX > cameraXLimit.start then
cameraX = cameraXLimit.start
elseif cameraX < cameraXLimit.finish then
cameraX = cameraXLimit.finish
end
[/code]

Introduction

PET THAT KITTEN! was my second attempted Ludum Dare,  my first actual entry, and my first XNA game. Going into this I knew I was going to use this competition as a way to get my feet wet with XNA. Considering the added learning curve I aimed for a very tiny scope. I think I went with the idea that crossed most LD’ers minds, turn the wall into an enemy and have it chase the player.

Development Tools

I had worked with a bunch of C# in the past so putting everything together in XNA wasn’t a problem. I had done my art up in Flash CS3.  I had planned on using hobnox to generate my sound effects and music.

What Went Right

The scope I had planned out mostly revolved around the fact that I was tackling XNA for the first time. The scope had lots of features I could easily cut out while still leaving me with a “complete” game.  I had done a bit of VB.net and C# managed DirectX stuff in college, XNA turned out be extremely similar so only very few features got cut.

Despite the programmer art, I’m pretty pleased with the way the artwork turned out. It was more time consuming than I had liked, but I feel like it breathed a lot of life into an extremely simple concept. I also decided that however crappy the artwork looked at the start, it would make it into the final project, no placeholder art.

What Went Wrong

I was using this Ludum Dare to kick myself in the butt to get something done in XNA. Most of my perceived problems stemmed from this though. I realize the ideal entries are executeables and broswer based games, no one really likes having to install dependencies or go to too much trouble getting your game going. I’m sure the installer for the XNA framework turned at least a few people away.

On that note, I know I could have gottent his entry done in half the time, possibly with more features if I had just done it in Flash. A good chunk of my time was converting assets to spritesheets and then fixing up the spritesheets (you’ll notice in the wall animation that you can see bits of other sprites on some frames).

My time management for this competition wasn’t too bad, I think I spent too much time on getting some of the artwork done, the time would have been better spent with an in game help screen explaining the game objects and scoring system.  The confusion brought on by the scoring system (and a scoring bug) was a huge oversight on my part.

Conclusion

As an XNA project I’m pretty happy with PET THAT KITTEN!. It’s a complete mostly functional game, and I managed to plan my scope out pretty well for the time frame. However as a Ludum Dare entry it’s a little less than ideal as I know I would have been able to polish it(Sound effects!) quite a bit more in Flash and avoid installer issues.

This Ludum Dare was a great learning experience for me. Planning out a scope under such a tight deadline, learning XNA, and finding a couple of really nifty tools for mixing music and creating sound effects.

Outline of 48hrs as I recall it…

Day before compo…

Stayed up too late on Chatroom, just getting hyped about the competition - Should have slept more.

Got up at 4am to check theme - found that it was AWOD couldn’t think of anything and went to bed.

Got up again jotted down game concept in notebook (see below)

Went to work knocking together basic sprite object - I know I should have grabbed a pre-developed set of objects but at least I can refine and reuse these now!

Went for a very free form map, no tiles just objects relying completely on BlitzMax’s in built pixel perfrect collision detection.

In the first day I managed to get the basic game mechanics working block growing, turrets firing, player deploying turrets - it was now almost a game.

Went to sleep thinking about adding towns, people, animals, plants running from the AWOD… Dream on!

Day two

Added screen, levels, win/lose states, basic sound effects

Afternoon - time was running down fast added …

Powerups - providing a limited upgrade to turrets

Base something for the player to defend and powerups to appear next too

Last minute play testing

Quickly zipping and posting it near the deadline - Phew Final post

What went right…

I managed to create a game in 48 hours!

I avoided getting tied into the complexity of a tile based system, thankfully BlitzMax’s collision detection works well!

I kept the ‘artwork’ to the bare basic minimum - inspired by the BUPA adverts (Coloured circles as people)

I kept the design very simple as well.

My Keep It Simple Stupid - KISS approach worked!

What went wrong…

Wrote too much code to start with I need a basic prototyping framework for at least sprites, collision detection, screens, menu ect.

Then I could have spent more time designing filling out the game design further but staying flexible, this might have prevented the last minute addition of powerups and base leaving next to no time for game testing balancing.

Motivation wandered during day two, it was a playable prototype and therefore in theory a game, thankfully I managed to get moving again and ‘polish’ it up a bit, again a framework will make this a none issue.

I quickly realised that there was a performance issue with the block count, once you get over the 1000 mark the framerate really drops so I had to limit that.

I wanted a wrap around world where you can’t run away from the wall of doom, althought this should have been an easy thing to add I did not get around to adding it, possibly resting on my laurels a bit!

In Summary

I really enjoyed this although I wish I had setup a time laps screen capture, probably not a webcam feed ;o).

Well I must judge some more of the other amazing entries, Looking forward to the next competition already!

Regards

Merx

Sort of a postmortem for my game, Heart. I don’t know, I just wrote about the process and a few later thoughts. You can read it in my blog.

Also, the game is finally finished. Play the release version.

DoomCake was my first LD entry.  It was developed in Lua, using the LÖVE 2D engine.

In making this game, I learned a bit about Lua, and a lot about cake.  Read on to find out what a sugary zombie invasion might look like…

(more…)

If you did not play my game “The Final Solution”, you can get its win32 binaries and source code from my previous post.

This is my first LD.

I recently attended Global Game Jam [1], which was another 48-hour game competition held in 53 places around the world. We were 48 developers in Ankara divided into 13 teams/individuals, working like bees in our cubicles. My two friends joined separate groups and I started to make a game myself.

Having people around to test your game really changes the development process, as in the case of Itchy! in GGJ [2]. However, as LD is a solo competition, and I wanted to allocate my full attention to it, I did not see anyone during LD, and did not go outside except for getting food.

To mention a few lessons learned in LD;

(more…)

I came up with the idea of making a shooter based on drawing arrows after seeing a concept sketch for another arrow game by fellow LD participant Sparky. In the week before the contest, I entertained the idea and tried to think of ways to make it “themeable”. I came up with what I thought was a great idea for “Rain” - falling stars, that you would use as ammunition. When I saw the theme “Advancing Wall of Doom”, I decided to keep the mechanics from “Rain” and just work the actual theme into that. In retrospect, this might have been a mistake. Read why after the break.

(more…)

Standard Waiver, a short atmospheric first-person exploration game, was my first Ludum Dare entry. Here’s what went into it.

The foreground obelisk obscures the background one. It’s a mystery!

(more…)

Since it’s been a few days, I wanted to write up a postmortem on my LD48 #14 entry before I forgot too much.

Background

I didn’t think that any of the final themes were very good, or at least, anything I was in the mindset to tackle last weekend.  When the theme Advancing Wall of Doom was announced, I was sort of disappointed.  I hadn’t come up with any ideas for it, even though it was a front runner earlier in the week.  I think I sat down and watched some TV for about an hour and a half before I even started coding anything.  I flipped through the program guide for any ideas but nothing.

The idea can be literal, and I think most people created games with a wall in them.  Advancing Wall of Doom has been done in many games as an actual wall, so this wasn’t a bad design.  From the start I decided that I didn’t want to use an actual wall.  Figuratively, the AWoD is just something that you cannot stop from coming.  You just continue until you cannot continue anymore.  In lots of games, this wouldn’t be any fun, so if you can survive for a period of time, you win.  In a way, Tetris is an AWoD.  You can do what you can to keep the wall (i.e. the top of the well) as far away as possible, but eventually it gets closer (pieces fall faster) and you have less room to maneuver.

Mechanics

I knew that for this LD, I wanted to do something very, very simple.  I had two birthday parties and one playoff NHL game to attend to, so I didn’t have a full 48 hours.  I remembered an idea I had for a typing game, and decided that an AWoD would make a good way to push the user to type faster.

Gameplay is simple.  The wall moves from the left to the right as the phrases come from the right to the left.  If they meet, the game is over.  Since this is a typing game, a shredder played the part of the wall.  It starts off slow and as the user makes mistakes, the shredder picks up speed.  If the user can complete ten phrases without ending the game, they will get a short reprieve by setting the shredder back to the default advancing speed, but it will never ever stop.

Coding

I mapped out a couple objects that I would need and started getting them working.  First the phrases, then the AWoD disguised as a red box.  I progressed a bit at a time, getting the phrases to move, the wall to move, then for them to interact.  Input was probably the trickiest.  I used the KeyEvent VK codes, and they don’t tell you what character was input, only what key.  So it will tell you that the user hit ‘G’ but it doesn’t tell you if it’s a ‘G’ or ‘g’.  You have to check for the presence of the Shift key.  For the alphabet and numbers, it wasn’t a problem, but it got sticky for a couple of the symbol characters.  For some reason, the VK_QUOTE or apostrophe key and VK_BACK_QUOTE or backwards single quote were not actually showing up when I hit those keys.  After fussing with them for an hour, I ended up ‘hacking’ a solution together than just checked for the input I was getting from those keys.

By the end of Friday, I had most of the idea done, it just needed something to make it a game.  One of the ways you can do that is add points.  So I came up with the idea that you would get a point per character and maybe some bonus for completing the phrase.  As I was beginning to code that, I figured stats on your successful streaks would be great, and then realized that you should get more points the better you are doing.  Instead of one point per character, you got your current successful typing streak.  So that works.

I started working on the graphics for the wall and settled on a box with teeth on one end.  I drew some teeth and photoshopped them onto the box. By the end of Saturday, I felt that I had a reasonably fun game that looked decent too.  Did I say Saturday night?  I meant Sunday morning at 5am.

Sunday, after four hours sleep, I fixd the two keystroke bugs and add some actual phrases for the user to type. Along with those phrases, I created the WordKeeper to keep track of them, and added a PopupText class to manage the popup text that shows up when you do good or bad, or complete the stage.

So I managed to complete most of what I wanted to do.  Of course, there is always polish that could be done, but because I had some things to do on Sunday, my time was limited.

What I Did Well

I think I did a great job at scaling down the game.  I didn’t need a lot of graphics.  In the past, I’ve spent a little time drawing some art and photoshopping it and while that may take a lot of time, I didn’t have to worry much at all for this compo.  I do miss the art style from my last compos though, so I’ll try to use them next time.

Input is usually one of the pain in the rear things for me.  I have to come up with a scheme that is intuitive, but I also have to take that input and figure out how to use it.  In the Roads compo, I had to learn how to use the mouse to steer a car on a road and make it seem legit based on the speed of the car.  I wasted a lot of time on that.

Sound effects.  Oh man.  Dr. Petter’s sfxr tool rocks for this one.  I think I spent less than five minutes generating sounds that I felt fit what I needed.  They’re simple and very Atari 2600-ish, but they offer great feedback while playing the game.  I tried his music program, but I lack talent in music and should probably try to learn it outside of a compo.

This was the fourth competition that I’m using the same general basecode.  I’m getting used to it and making changes here and there so I don’t have to waste hours trying to figure out how to do basic things for every compo.

What I Did Wrong

Surprisingly, not much this time around.  I had three things that were planned for the same weekend.  One birthday party each day, and a playoff hockey game Sunday night.  I knew that if I didn’t get the game mostly done by Saturday night, I wouldn’t have much time to complete it on Sunday, so that’s what I aimed for.  Sunday was mostly spent doing the last bit of features and polished a little bit of it.

I would have liked to have made the stat display actually look better with some kind of graphical overlay.  It’s really the only part of my game that I think looks boring.  Sure, the shredder could be better, but it’s ok the way it is.

Some of the phrases submitted with the final entry are really long.  They should have been split up into two or more.  It also might have been easier for the player if I put the entire phrase un-scrolling on the bottom of the window so they could look at that.  I think one of the voters already realized the maximum WPM you can get is around fifty since the phrases scroll is constant.  Another way to fix it would be to speed it up if your recent WPM is past a certain threshold and slow it down if it’s not.

What To Do Next Time

Next LD competition, I still want to scale down, even if I have more time that weekend.  With what I did in the time I had for AWoD, I could really make it great with another six or twelve hours.

I want to continue with my basecode and work to make it more robust of a base.  I see things that other people are doing and I know I’ll never be able to do them if I don’t build a better foundation and skip the mundane basic code.

Conclusion

I’m really happy with this compo.  This was my fifth competition, and the third where I actually submit a final version.  I’d like to continue as this is a great way to keep skills sharp and perhaps learn something along the way.  See you in August for LD48 #15!

Long post, more after the jump, but the headlines in summary:

• Learning from past mistakes
• Step #1: Add tile mapping
• Step #2: Add collision detection
• Step #3: Add physics
• Step #4: Evolve game concept
• Step #5: Iterate gameplay
• Step #6: Build-out and polish
• Step #7: PAAAANIC!
• Step #8: Deep sigh of relief… followed by panic

(more…)

Since I want to learn to write good blog posts, I would appreciate any feedback about which parts of the following post you found interesting. I tried to make it not dull. Hopefully you’ll learn a couple of new game design tricks or something. And if you’re not a programmer, just ignore any code, you won’t miss much.

The wiki mentioned that I should keep a log of some sort as I develop my game. I decided to write short entries in a txt file, then thought I would post it all when I was done. Now that my game is finished, I thought it would be a good idea to expand this short log into a full commentary-type thing of my Ludum Dare 14 experience. I will describe the development of DoomDrive in detail in the hopes that someone will find this interesting. Maybe this will make up for not doing a timelapse. Note: In this post, all times are EST and entries from the original log.txt file are italicized.

SF’s devlog

The first real language I learned was C++, I started learning it at age 11 when my older brother gave me a book about it. I didn’t know anything about compilers then so I couldn’t even write a program until much later, but I absorbed the information with great interest anyway. I love C++ for its speed and the amount of control it gives me over my code. When choosing graphics and sound libraries to start learning I did a few comparisons and settled on OpenGL with GLFW helper tools, and OpenAL. I haven’t had too much trouble with these (though my OpenAL knowledge is limited) and they’re what I know best so they’re what I used to make DoomDrive.

Saturday morning (18apr09)

2:40 - Forgot about LD for the past couple days, remembered it just now.
The contest began at 23:00 on Friday, so it was 3:40 in. I had decided to start developing a game (unrelated to any contests) a week before. It was to be my very first serious game (a space shooter, heavily inspired by the rather obscure Hell Fighter). I’d done enough half-projects experimenting with the aspects of game design - code structure, physics, graphics, art, sound, game theory, etc - that I knew I had a good grip on making games… I just hadn’t done it yet (other than a GameMaker game I made at 14, and of course Tetris). My problem was I never felt like doing anything. (more…)

A good week-end that was. I am pretty satisfied with what I came up with.
Here comes a (rather long) reflexion about the process of creation.

(more…)

Right, now that I’ve taken steps to correct the control irritations in Only Forward (see below for the updated version) this seems like a good time to write up a postmortem for the competition.

What I aimed for:

LD13 was my first Ludum Dare competition, and whilst I’ve previously dabbled in coding with tight time limits it’s the first games competition I’ve entered into, so it was all pretty new to me.

My goal from the start was to try and make a game that was essentially complete/polished etc.  I was less worried about managing something technically impressive, or dramatically original, I just wanted to *finish* something in the time.  This ended up shaping the majority of the game, I picked the concept I did because it required minimal simulation, the graphical style because I wouldn’t need to make too much etc. etc.

What went well:

I’m really happy with the direction I took, and particularly my choice to bite off as little as possible.  I ended up being able to get the core gameplay, graphics etc. down very quickly, and that left me with a lot of time to polish and polish.  Were it just a prototype (say what I had at the end of day one) I’m not convinced it’d have been very good, but I’m pretty happy with the fleshed out version.

Following (not quite to the letter, but not far off) the Survival Guide paid off to, it’s a very good set of advice.  I think even the time I spent blogging/on irc/or cooking all ended up helping me keep sufficiently distanced to be able keep polishing and improving something despite being so close to it for such a short length of time.

What went badly:

The controls!  I was a little bit worried about them from the very start, and with all the time I spent polishing the rest of the game I could have easily taken the hour or two I’d have needed to do something less frustrating.  I think the problem was that by the time I had the free time to deal with such things I was so familar with the controls I’d put in earlier on that they just felt natural to me.  I should perhaps have got more feedback during development (and listened more to that I did get).

The other issue was that I couldn’t really see a simple solution and I didn’t want to spend time faffingiaround on something that might not have even worked.  The solution now seems very trivial with the benifit of hindsight, you just allow directions to be pre-selected before the junctions.  It’s the only thing I’m *really* unhappy with in the game, and as such I spent a little time fixing it.  The updated version can be downloaded from http://jwhiting.nfshost.com/coding/onlyforwardfixed.zip it is perhaps worth mentioning that the only thing I’ve changed is the controls, and also that if you’re still judging entries do play the genuine entry instead. The updated version for the unlikely event that anyone wants to play a better version after they’ve made their mind up.

Conclusion:

Wow, that was a bit more epic than I was expecting, congratulations if you’ve just struggled through all of it!

Overall I really enjoyed the competition, I’m definitely looking forward to the next one (fingers crossed I’ll be able to enter it).  It was all a lot of fun, and some extremely impressive stuff was done (just not by ’safe option’ me).  I’m quite looking forward (only forward, har har..) to seeing the results tomorrow too, I never thought I’d care about that side at all, but it’s kind of exciting nonetheless.

Badass Frog postmortem - the ‘meh’ factor

After my LD #11 ‘Minimalist’ entry was voted “most innovative” game, I’ve been trying to pride myself as “that guy that makes innovative games”. So I thought long and hard about the theme for LD #13, “Roads”, trying to come up with something innovative. But the creative juices just weren’t flowing, and it didn’t happen (I’d also just bought Shaun White Snowboarding: Road Trip for Wii, which was taking time away from ‘designing time’). After 12 hours, with no good ideas for a game I was actually enthused about making, I decided to make a simple Frogger clone - at least this way I could hone my Processing skills, and learn the ins-and-outs of Mobile Processing.

Some thoughts about developing for mobile devices

Turns out there is a whole “other world” of mobile development that I just hadn’t really thought all that hard about. (more…)

I wrote a quick postmortem for Anathema RL. Read it here, on the game’s stunning iWeb-made page.

I too was waiting until after seeing the final results before I would post my post-mortem.

First I’d like to say well done to everyone who took part and completed a game within the time limit, and thank you to everyone for giving me honest reviews. I had great fun taking part and learned an awful lot about game development during and after the contest.

(post mortem continues after the break) (more…)

Post mortem, thoughts on things, etc. This post is mostly just going to be me rambling about my game, and this particular Ludum Dare. Basically, I didn’t really like the theme. Sure, it’s not a bad theme, really, but I couldn’t think of anything original to do. My ideas pretty much went from “Climb the Tower” to “Tower Defense” to “Build a Tower”, and back. Honestly, both styles of games would be pretty cliche, and I didn’t really want to do that. I figured there’d be plenty of other games with these basic rules, and I was right. That said, there were plenty of awesome and inventive games made too, and games that took these ideas and turned them on their head. Congratulations to everyone who submitted a fully fleshed out game, and good job to those who worked all weekend. I am not one of those people. (Rest of this, plus solution to level 3 after the more.. link

(more…)

My 2nd Ludum Dare didn’t go as well as my first. While I managed to get Tower Defender submitted, it can’t be called a game so much as a tech demo.

What Went Right:

• Simple game mechanics still work.

  Like my LD#11 Minimalist entry, I wanted to use simple mouse-movement-only controls. I feel that mousing over your units to make them attack made sense, and while I only had archers available in the end, it seemed to work. It’s too bad there wasn’t more of a game built around the mechanic, but I intend to flesh it out after LD.

• I had an office door I could close.

  My cats are incredibly reliable. If I am doing anything that looks like productivity, they will insist on sitting on my lap, resting on my arms, and otherwise preventing me from working. Being able to close the door on them helped keep me focused on game development. Towards the end I got lax about keeping the door closed, but the cats left me to work for the most part.

• Using Test-Driven Development

  Test-Driven Development, or TDD, is great for designing your code. Also, since code changes often, you can feel confident that your changes won’t break functionality since your tests will tell you if they did break. More than once, I was surprised that a seemingly innocuous change resulted in failing tests, so I was able to keep the game working at all times. I know that I wouldn’t have caught one specific crash problem right away, and it might have resulted in a non-working game for hours, preventing me from submitting anything. Since I found those problems sooner, even in code that wasn’t directly being tested, I felt that using TDD was the right thing to do.

What Went Wrong:

• Learning Test-Driven Development while using it.

  I know quite a few people would disagree with the use of TDD during Ludum Dare, but I think what burned me was my inexperience with implementing it. I spent too much time trying to figure out how to apply it to rewriting code that I already had written. My first bunch of tests were helpful, but all I ended up with at the end was a slightly smaller Game class with a separate Timer class, and it seemed that if I applied TDD to the entire project I would barely have an SDL window by the end. While my normal projects might benefit from test-driven design, my LD game needed to get finished in 48 hours, so I had to alternate between writing tests first and skipping tests. I’m sure once I get some TDD experience, I’ll be much faster and know when it is in appropriate to write tests. For LD#12, it was a learning experience.

• I still didn’t have a good handle on SDL

  Last LD, I noted that I hadn’t practiced using SDL much, and right before LD#12 started, I realized that I still hadn’t done so. I never had to render animated sprites in SDL before, and I skipped it in favor of static images moving around, but not before spending precious time learning what I would need to do it. Again, there was too much wrestling with technology instead of game development, and this time it prevented me from finishing my game.

• Working long hours really does screw with your productivity

  It’s common in the programming world to find people working Twelves, especially in the game development industry. Crunch times are intuitive. If a project needs to get done in a week, and there are two weeks of work to be done, then have everyone work longer each day. Well, it is common knowledge, even if that knowledge isn’t applied, that working longer hours doesn’t translate into greater productivity.

  I experienced these issues firsthand with the 2nd day of LD#12. I realized I had worked about 12 hours straight by the end, and I was making sillier and sillier mistakes. Sometimes my tests would save me, but since I didn’t write tests for a good portion of my code, I had to figure out what I did wrong most of the time. Bugs were finding their ways into my code a lot easier, and debugging was painful. When I did LD#11, I got plenty of sleep and took frequent breaks, and ended up with a finished game. I wonder if I could have done LD#12 better if I took a few more decent breaks during that 12 hour stretch.

• I didn’t get game play until the very last minute.

  I knew that getting game play up as quickly as possible was important, especially in a timed competition, and yet I believe I struggled so much with the technology that the game didn’t start to form until I had minutes left to package it up and submit it. I think if I had used a few more hours in a productive way, I could have made something enjoyable.

What I Learned:

• I still have a lot to learn.

  It’s weird when you feel confident going into a competition like this and then hit a wall due to your own lack of knowledge. I was depending on TDD, SDL, and common game programming concepts such as OnMouseOver, but I didn’t have much experience with them before this competition started. I like using LD as a learning experience, but next time I’ll focus on learning only one tech or tool for LD at a time.

• Test-Driven game development is awesome.

  Yes, the learning curve slowed my productivity down, but I already saw many benefits from using a test-first design for my coding. I could see that my code base was going to be much better for it, particularly in terms of my ability to make cross-platform games, but I had to stop applying it due to time constraints. I was already trying to incorporate TDD into my main development before LD, but now I see that it’s going to provide better benefits than I originally thought.

• I need to work on my pacing for LD.

  It seems most of my productive work happens during the 2nd half of Ludum Dare, and it makes me wonder what happened during the first 24 hours. I saw that more than a few people had working prototypes up and running within a matter of hours, and I want to make sure my future LD entries are in a playable state as early as possible, too.

Once again, 48 hours resulted in a bunch of code and experience I didn’t have before the weekend started. Even though my submission can’t really be called a game, it has potential, and I had a lot of fun working on it. The next LD is in December. A few months should give me time to develop my skill and technology base.

This was my first Ludumdare entry, and not knowing just what I could manage in 48 hours I decided to stick with a simple idea and tools and libraries I’m familiar with. The original game idea was to make the player hit all the walls in a 2d space with a trickier-than-usual to control ball, although this didn’t quite work with the Tower theme. Hence, I decided to turn the walls into a scoring mechanism, and to make a tower to ascend or descend instead.

(more…)

Here’s the postmortum I promised last week.  I haven’t read the comments on my entry yet and I wanted to get my thoughts down before I did.

THis LD48 was my third, if you don’t count the two that I intended to enter and never did.  My number one goal was to finish, and the number two goal was to do something fun.  I’m happy that I completed goal number one, but failed on goal number two.

Technically, I didn’t really even submit a game.  There is no real end condition or repeatable system that goes until you fail.  I never got a chance to actually implement the “monster at the gates” scenario, as I fought with a stupid bug at the end brought on by stupid changes on my stupid part.

What did I do wrong in the LD12?  I didn’t spend enough time on it.  I should have squeezed three or four more quality hours in.  My mother-in-law was visiting, and that led to the normal distractions as she visited with us and our newborn.  I probably could have completed something that resembled a game with a little more time, and I know that the time existed.  I just didn’t use it well.

I didn’t get any real animation done with the monsters or the dude.  It would have been nice, but time didn’t allow it.  I also used some sound, and while it wasn’t nearly to the level that I wanted it, I thought it was neat to hear the monsters gargle when they died and the arrow whisp away from the dude on the tower. 

I think my usage of the angle/power aiming mechanism was a bad idea.  I think I should have gone with the “point-and-click” method, which would have been easier for the user and fits better with the action oriented design.  The arrow was made up of separate graphics rotated to the closest 15 degree mark.  I could have implemented a rotation transformation, but that would have taken longer and probably been more CPU intensive.   

So what did I do right?

I met the theme of the Tower by simply having a tower in which the dude fired from.  I didn’t stop there, and created a middle floor from him to fire from and also made the doors at the bottom open and close.  The tower isn’t just a pretty graphic.  It’s functional and strategic.

The part I liked the most about my entry was the graphics.  Most of them were sketches from my initial game idea sheet.  I scanned it into the computer and photoshopped color into it and cut it into separate parts and images.  I think it gave my entry a unique style that I’d like to use again in a future competition.  I’m not a great artist, but I think if I don’t try to make everything perfect, it comes off better.  Reminds me a little of the original South Park or other ‘construction paper’ style.

Another thing that I really think I did well was keeping the coding distractions to a minimum.  By this, I mean that I didn’t get sidetracked coding something that wasn’t important ‘right now.’  In the past, I will start to code something that may come in handy later, but doesn’t really help me too much in completing more important foundation pieces.

So all in all, I think I did ok.  I can see that I learned some things from the last time around and I really look forward to taking the things I learned here for LD13 in December.  Same goals, but I will try to think through the game for a little while before coding to make sure that it is actually a game and hopefully fun. 

I would call my game Incoming Fodder both a minor success and a minor failure.

My goal for this competition was to create sound and music in the game, and of course it must be playable. So I made a lot of sound effect, some good some bad, mostly bad when things get crowded there are so many sfx playing it’s annoying. The music, or what you might call it (You can kill the music) was a complete failure. There was a MOD player lib for flash that I though would be awesome to use, took about an hour to get it to work.

Then I needed to create music. I suck at composing, I know it, doesn’t matter what tools I use, it’s just awful. I might have a tune in my head, trying to get the music to sound like that never ever happens. So I scribble down something trying to make it sound like music, copy paste. Crap, I better sing the tune next time.

I chose flash 9 as platform, that was good. Learned a few valuable things, like it’s not easy to pause things running with event listeners without preparing for that before you build your system. I had to skip pause, lost some time there.

Game play wasn’t as developed as I wanted. I really don’t know why I didn’t have time to improve here, I picked the idea of the game so I could spend more time on polish, but I guess I wasn’t interested enough in the idea to really devote to it. I need to be quicker in this area. I need to focus on that in the next LD.

Coding OOP is lovely, I had one moment of awesomeness this time. I’ve built a tower that can shoot arrows, then I built a castle to protect, after a while I realized that the castle also should shoot arrows, so I made castle inherit tower and voilà it shoots arrows! I did have to make it own 3 more towers to make it have 4 arrow shooters.

Graphics was the least of my priorities and it turned out ok, the defeat screen it the best of the whole game.

Timelapse. You may recognize the music

Preface

Since I’m only a few months into my game dev journey, I set a few concrete goals to ensure that I would finish with a game:

• Have gameplay decided on before bed on the night the theme was revealed
• Have gameplay/art 90% done by bed on Day 2
• Finish gameplay/art, do music, menus, polish, package, etc on the last day
• Also eat a lot of unhealthy food

The Bad

My Idea: My main concern was to make my game about owls. In the end, I accomplished this, but I should have thought it through more. After getting most of the gameplay implemented, I started to realize that the scope of my game was way too small considering the time I had as well as my ambition. I was sure that it was too late in the 48 to start over, and I lost motivation.

Motivation: (That was a pretty direct segway.) I didn’t really feel like finishing my game. I didn’t put much effort into it until night fell on Saturday (awesome). That’s when I made the game’s song, and finished gameplay for the most part.

Packaging: I provided three versions of my game: an exe made with py2exe, an app made with py2app, and a source version. I guess I need more practice with py2exe. It took me a while to get my game packaged, and I even had to change some code in the game to make it work. My py2app experience was great, but the .app ended up being over 20 megabytes large. That sucks, sorry guys.

The Good

Music: I am really happy with the way my simple song came out for my game. I had a whole other song ready, but it just didn’t fit the mood of my game. The completion of this song actually brought me out of my motivation problems in the second-half of the competition.

Code: It should be no suprise that I had no trouble implementing this game. There’s really nothing impressive about the way it works. Some aspects are even quite underwhelming, such as the collision perhaps. Overall, I got to spend some quality time with vim and python…what more could I ask for?

Motivators: This section is pretty self-explanatory.

I Had A Wonderful Time: LD12 was a blast, I learned a bit and had a great time. A success overall.

Looking Ahead

I have a lot of ideas on how I can improve for my next LD. I feel like I can make a bigger and better game. I also think I can improve the efficiency of my music recording and packaging processes.

Thanks Guys

Well, I’m back from spending last week in LA at the siggraph conference. Looking forward to playing all the entries.

Here’s a link to my timelapse video. Thanks to Daz for the ETL screencap program he posted, which I used to make this (plus ImageMagick to add timestamps).

A quick postmortem: I was using this compo as a chance to experiment with Ogre3D, so I didn’t expect to end up with something too polished, but i did hope it would be at least playable, which didnt quite happen.

What went right:

• Ogre particles — easy and they look great.
• Art assets. I tried to focus on the minimum that I would need, and they turned out pretty good.
• Learning Ogre. I learned a lot more this way than just reading docs would have taught me.
• Great theme. I had a lot of good ideas for this one (maybe too many).

What went wrong:

• Camera — I spent a lot of time messing with the camera. Afterwards, i realized I should have just went with a fixed close-to-overhead camera.
• Starting with ExampleApp was more trouble than it was worth. In the end, I wasted a bunch of time rearranging it.
• Too many ideas: The theme generated so many ideas for me, I kept changing my mind and adding things. I should have gone with a straight up tower defense.
• Too ambitious. Didn’t get first-playable until Sunday.

I posted a little list of tips on LD Survival, and ended up ignoring almost all of them.  That’s okay, I had a great time and got a bunch of experience with Ogre3D.

A technical note: I was using Ogre’s OpenGL mode during development, and noticed at the last minute that the D3D mode was much faster. So the readme encourages you to use the D3D mode. However, I didn’t realize until afterwards that it blows up after a few minutes, so if you get everything flying off the screen, switch back to OGL. I probably forgot to initialize something.

Okay. Well first two days i was mostly getting feedback and trying to restore my brain to usable state Yesterday started to implement all changes that i hope will make game more fun.

You can still access old version and sources trough links in my Final journal.

And here is new version:

(more…)