That was fun.
Really, it was.. the majority of coding this was pretty good – as I had structured things fairly well for the most part.. till I went mad and started putting chunks of code in whatever file I was in at the time! Damn you Lua for allowing me to use any global function in any file at any time!

There were, however.. a few head smashingly horrific issues that did cost the game.

The Foul-Ups
————-
After designing a somewhat large play area, I needed a means of loading it in.
As the Moons of Subterrane loader was fairly decent, I decided to base it on that. Oops.
Due to the nature of Ludum Dare, you tend to code things just to that project, and not really leaving them agnostic or open. Case in point being the Moons of Subterrane loader – it was designed quite specifically for flip-screen gameplay. Trying to tear apart that system to include scrolling was not going to happen – and although realising this from the outset and trying to modify it as I wrote it up, I didn’t modify it enough!
A few hours later, and much swearing, I tore the whole thing apart and just loaded in each floor as one gigantic file, each.
I’d have preferred splitting them into screens – or even rooms – as it meant I could’ve done some semi-procedural stuff with their placement, but alas, it was not to be.

Once I got something loaded and on-screen however, things did pick up and I implemented a fair amount of stuff.. then came the Camera to allow scrolling the map.

2D cameras are strange in that they don’t really exist more than a hack to begin with. A 3D camera has position, orientation, and look vectors just like any other object; a 2D camera is little more than a viewport translation. Or so my textbook says…
Stupidly, I had implemented this properly in about ten minutes, but forgot to move everything in the opposite direction to counter the viewport translation. Nyargh.
Another few hours later and I realised my idiot mistake, battered my head off the wall, and put in the counter translation and it all worked.

Of course, attempting my game idea – specially with the amount of content I planned – within 48 hours was always going to be tight, those two bugger ups didn’t help, neither did nursing some sort of cold, as I did end up sleeping a total of 14 hours over the two days. Ouch. That killed sound, music, most game play and any decent graphics… and threw my timeline in the bin.

The Successes
————-
There are a few bits I’m quite happy with.
The game itself works, which is somewhat surprising as I pretty much bypassed all of my internal engine, save for loading and blitting graphics!
The horribly cheesy and cheap starfield effect really does work wonders to break up the Menu screens a bit.. a total of five minutes work for that, while pondering over the loader system. The typewriter text effect was also done in five minutes, though while thinking about the camera stuff – proof that if you go and work on something else for a bit, you’ll get better results

Splitting the units up into separate Lua classes was a good idea too, it meant I could deal with them all individually. Granted most of them are copy/pasted movement/firing code amongst each other, but the skills bits were meant to be different at least.. They’re also a bit more self-contained object like.. which made them easier to deal with too.

The Crew Selection bit is possibly the most polished part.. it works fairly well, but suffers like everything in the game in that there’s no feedback: up/down changes whether you’re Alien or Human in multiplayer, if you didn’t know…which you wouldn’t have unless you messed with the buttons, or read the source!

The Murky Bits
————–
There’s a general lack of feedback with everything you do.
You don’t know how many action points anything costs ( hint: movement is 1, opening/closing doors is 2, firing is 2 ) and unless you’ve just started and haven’t explored most of the map yet, your only indiciation of a door opening is your Line of Sight updating!

Speaking of line of sight, it’s a bit too exact on the diagonal and orthangonals… there’s no real in-between as it’s horrendously hard coded just to look on the eight axes. This is obviously quite daft, and is due to one major muck-up. I had a working LoS very quickly when I first got map loading going… then when I realised I wouldn’t have time to do much AI, I started jerry-rigging multi-player hotseat support in.. though I did this a bit too quick as a lot of the systems weren’t quite finished yet. So, this broke most of the game – unit movement, actions, line of sight, detecting other entities on the map at all. I very nearly had to pull out completely because of this, but things started to fall back into place in the final twelve hours!

Conclusion
———-
So, I ended up twenty mins late with my submission ( though it seems my laptop’s time was slow and I finished 5 mins late anyway *cough* ) due to Ark deciding not to zip things properly. After several attempts, I finally gave in and zipped it by transferring everything across to another machine. Re-installing your O/S the day before LD starts is asking for trouble 😉

Either way though, I think I did fairly well and did get a lot done.
Unfortunately, gameplay suffered from the cold, camera, loader and my Sunday panic. I think that given a few more hours, I could’ve gotten the skills in, and maybe some feedback as to what’s going on.
I need more practice to work faster, and sleep less 😉

This is something I’d like to continue, though!
And hopefully, I can feed some of the changes back into Little Quirks ( remember that? 😉 ) and get it done too.

While I did manage to submit something that’s playable, I think it could have been alot better with a few more hours. I had an idea of adding a time limit to make it more paced. Ofcourse it would be nice to have had collision detection working, but it became too big of a project to implement inside the two days

Still fun. I’m going to participate another time!

Here’s a slightly edited timelapse. I cut out the part where I got drunk

http://www.youtube.com/watch?v=X8buTL_uIWo

What a weekend! I’m still sad to have failed as I did, and I know I could have done better. Shame aside, though, I’ve learned some things.

First, the reason I don’t have a new demo up is simple, but embarrassing. I never updated the gameplay as I worked. Instead, I just built up crap in the background with nothing to show for it. If I uploaded what I have now, it’d just be a bigger file, I’m afraid.

But, here’s what I’ve learned:

Things I Did Well:

• Got an idea from a random blog post, and thus pulling an idea from an unusual place. More a creative lesson than anything, but worth mentioning.
• I dumped an early idea due to a lack of proper art skills. I think I’m learning where my limits are.

Things I Did Badly:

• I spent too much time on the background code. I wound up with a fox gliding around on the screen, but with lots of cruft in the background. Also, about 5mB of memory that would have been all the media for the game world, but instead just took up space.
• All of my images, once loaded, took up 5mB of memory. I can do better.
• I futzed with my cell-based world generator for too, long, as well. It might well have worked, but at the rate it went it might as well have not. I never actually tested the output, just the time it took.

The heart of my problem was diving into the background and staying there. I never made new things playable, so I didn’t have any game whatsoever.

On a happy note, I did get to do research on pathfinding and random world creation. I’m going to take that into the roguelike I’ve been working on.

I’ll be back in the upcoming Mini-LD! Just you wait!

—Mr.Dude

After deciding that I was going to enter the Ludum Dare #16, despiste the almost completly lack of time I`d have to work on the weekend, I was able to finish my entry, somehow. Of course, it didn`t turned out like I wanted it to be, most because of the lack of time, but also because I hadn`t really a definite set goal until the last hours.

Deciding to go with javascript was a lifesaver. At first I wanted to write my game with Python and PyGame, but I`d end up spending too much time on rendering and UI implementation, and with javascript that was already hard-coded into the browser for me, so all that`d be left was to write the game logic. Of course, javascript has its issues, like you`re not guaranted fully compatibility between browsers (even with the standard ones, something may behave oddly), and that`s what made me cut that M$ IEerie from the list of supported browser before I even started writing a line of code.

More about it after the cut :3 (It’s rather long, but has a concept art to make for it :D)

—the concept—

You’re trapped within the labyrinth of consciousness, blocked out by the silly wishes of peace of mind. You’re the Truth, fighting with all you’ve got to bring some light into a world that decided to go on living the “Ignorance is a bliss” saying.But what to do? Is there anyone who wants to know the truth when you can live “better” with a sweet lie? Maybe, or maybe you have to force your way out, bringing those painful memories that are hidden in the deepest of a broken heart to daylight.

Is it cruel? Maybe, but not more than knowingly turning your face away from what you have done. What lies beyond those fragments of memory, lingering in the dark maze of consciousness? More importantly, will you have the courage to face the unknown or will you choose the large path, living on, in eternal oblivion…?

As you see, I think with stories. At first, I was going for a Turn-Based Strategy game with some dungeon crawling, however, since I couldn’t spend too much time working on a fully fledged procedural dungeon building algorithm, I went with the easier maze generation. Yeah, I could’ve just ported the algorithm I’ve written for Underground Tower, but it’s not really done, and there’s lots of issues there I hadn’t the time to address yet.

The player objective would be to collect memories and uncover the game’s story (which I still haven’t thought of besides that introduction up there). While exploring the maze of consciousness the player would gradually fade out by the sweet lies that lies at each one of the walls of the labyrinth, eating away any “silly” try to look at the “real” world. Therefore, collectable reasonings for staying alive would be found lying around the place.

The memories where when the story of the game would come, but I haven’t had the time to code this part. Not that it would be difficult to code the part of collecting memories (it was just a matter of inheriting the cCollectable class), but to arrange it to make a good story would.

It all could’ve work… if only I haven’t tomorrow’s trip planned.

Concept art for Lucy, the bestowal of light (?)

—the goodies—

That said, there were some good parts about this game. First, the wonders of javascript prototyping. I was afraid to don’t even finish my entry, but I was able to accomplish a fair amount of work without really having a gaming library (mine isn’t complete and it hasn’t much useful things for games right now). Kudos for the Prototype and Scriptaculous libraries for making my life easier too, working with pure javascript is not that fun, must I say, but these libraries make your life a heck easier.

I’ve also learned to write a procedural maze generator using Depth-First Search algorithm. It was quite fun, easy and quick to implement, actually, and it works neat. I think I couldn’t ask for more, could I?

Surprisingly, I had time to sketch a main menu background and a javascript motivational. I wanted to color the motivational, but I’m dog slow at this and don’t have a tablet. So… yeah, it’d take me ages D:

Last, but not least, I had quite fun participating. Even with all the swearing while I was shopping and looking at the clock, seeing I was wasting a precious, precious time. Well, I wish I spent more time chatting with peoples on IRC and so, I haven’t really talked on IRC, I guess.

—the baddies—

Well, now to the part that really matters: what went wrong.

• Lack of time (and this must come first, as I planned a game without the proper time to implement it)
• Light handling on the maze has a bug which won’t fade the illuminated cells if they can’t be reached by the player’s light radius.
• Didn’t had the time to implement things I wanted, like the story and the auto-explorers (whom could be cast to search for something)
• Points are meaningless when they don’t mean anything in game.
• No sounds and music whatsoever. I’d want to put a suspenseful music together with the story, and maybe some footsteps sound. But haven’t time for neither.
• Lack of gameplay and difficult progression, since I haven’t time to test any other than “Does it works? Fine, submission where?”
• Things takes so long to load, and there’s no preloader for images. Minifying the javascript and putting everything on a single source file would solve this, though.

—the conclusion—

While I have other projects to work with (RED -spider lily- and some libraries), I think I’ll work on this game first. Either because it’s simpler and shouldn’t take me too long to finish, and because working on it I can work on my Lily library at the same time. And I’m thinking about porting RED -spider lily- to web, instead of continue on Python. But that will depend on some design issues I still have to address.

Some feedback on the game would be really nice :3

The timelapse video of me working can be found here.  It’s only 22 of the 48 hours, since I turned my computer off at night and deleted the frames which where black due to my screen turning off from inactivity.

What went right:

• I had a lot of fun.
• I chose to not worry too much about graphics, theme, story, etc.
• Ran into no major time wasting bugs.

What went wrong:

• Scope of the game would have been better for a PyWeek.
• It would have been better to start with a library or codebase that handled much of the grunt work for me.  Instead of working on a game, I spent a lot of time writing code for gui, animation, tilemap, resource management, collision detection, etc.
• I didn’t have anything a player could control until 3 hour from the deadline.

I’m thinking of trying to bring this game to a completed state within the next few days.

I have a new wallpaper!

Keep doing square numbers, guys!

This was my second LD48.  I flip flopped with ideas the first night and settled on something rather generic that I hoped would be fun.

The idea was to make a space shooter set in a random starfield.  You start with a shuttle and explore the universe making money, checking out planets, and battling other ships.  Stations allow you to upgrade your ship and weapons.

What went wrong..

I never came up with a design doc, which would have helped me budget my time, and realize which features to work on first.  At the end of the first 24 hours I realized I needed to limit the amount of objects in game by setting up a spacial hash.  It took all morning sunday to do that, and if I had done that from the beginning I could have saved a lot of time.

Lack of content:  I designed the game to make it easy to add new ships, weapons, and planet variations. Despite that, I only made 3 ships and 2 guns.

Cutting of features:  Some features would have been easy to add and made gameplay more interesting:

• Fuel: Having to buy or find fuel would have made money and exploration more pertinent.
• Shield and ship statistics upgrade:  Would have not taken to much time to add.  Especially random ship upgrades from visiting planets.
• AI teams:  I had planned to have 2 ai factions, and pirates who attacked any weaker vessels.
• Displayed statistics.  It would have been nice to see the health of enemies/asteroids when you target them.  I also thought about giving enemies random names.

What went right

Not spending too much time on the graphics.  I consider myself more of an artist than a coder, limiting my art making time was hard but necessary in the end.

Guerrilla coding.  My goal was to pound out features, as quickly and ugly as possible.  Making this game was like surfing a massive tsunami of bad code, but since I was working non stop, I could actually remember what I was doing.

Rethinking the player controls:  Originally you used the keyboard to rotate your ship.  Adding mouse control for the rotation and turret aiming makes for a pleasant user experience, and gives you a needed advantage over the enemies.

Sticking to my guns:  I got majorly overwhelmed by the amount of features that needed to be in place to make my idea playable.  I refused to give up, and in the end came up with an actual game with more features than I had originally planned.

Music:  I only spent a half hour playing music, but I came up with a very appropriate song for the game.  It’s short, spacey, and really sets the mood.

What I Learned

Well I think it’s time I branched out from using Blender as my realtime engine.  I love having my dev. environment be the same as my 3D modeling/sculpting/animating/texture painting tools, but I was discouraged with how my game is published (the .exe wasn’t displaying the font correctly and I ended up distributing the blend with a windows version of Blender)

I think I’m going to start working with Unity free engine.  People here give it good reviews and it seems to import art assets from Blender very quickly.

I just made last edits on my submission – turned out that platform compatabillity between windows and linux with python wasn’t 100%. Had to make events and graphics to run in the same thread. On top of that py2exe didn’t like opengl, so here i am without a .exe file.. :/ still i hope(,hope,hope) that all of you guys have have a python interpreter with  pygame and pyopengl installed(fat chance!).

Anyway, it was an awesome weekend with plenty of coding, drawing, recording soundtracks, drinking [beer, wine, whiskey,cola,coffee],  crap food, sugar overloads, transfat clogs in my throat,  caffeine overdose,  and so on.. I will be dreaming about pythoncode the next few days.. Good gaming and rating to you all 😉

Or a timelapse video of Echolon development. You know, same difference.

The first minute of this video shows me working on the first game I did which was jettisoned on early Sunday for a new game that eventually became Echolon for Ludum Dare.

The LD entry page for Echolon: http://www.ludumdare.com/compo/ludum-dare-16/?action=rate&uid=781

This was my first LD, and I had a great time! : ) Thanks to everyone organizing this, being in #ludumdare, and just working hard to churn out awesome games. THANK YOU!

There’s definitely something to be said for reflecting on the good and the bad, though. Let’s start with…

The Bad:

1. It took forever to come up with a platformer engine in pygame. I didn’t really have one till 2 pm on Saturday, and I spent forever wrestling with collision detection and never actually got it to work correctly. In the future, I would love to start with an engine that is much closer to my finished product that straight-up pygame.
2. I started with this lofty idea for a story, and viewed the game as a storytelling medium, relying on level-design and storytelling to make the game fun. Whoops, I have NO experience with either of those things and couldn’t really pull it off. Also the story stank.
3. As a result, my game is a very generic platformer, short, and… not actually very fun at all. Next time, I plan to think about gameplay first, and what ‘innovative’ things I can do in that department, and story, atmosphere, etc. second.
4. Again on the story front, I actually totally changed the story and concept to be less pretentious sometime really late Sunday night, which is part of the reason the story seems like an afterthough. :/ It was.
5. My plan was to finish on Saturday night and work on homework on Sunday, but that didn’t happen.

The Good:

1. I FINISHED! I’m extremely proud of myself for this. I usually have a short attention span and trouble finishing stuff, but I did this time. : )
2. This was the third game I worked on, and the first individually – for that, I feel very happy with what I came up with.
3. I was about to give up Saturday afternoon due to my problems implementing a platformer – but DIDN’T. I just threw out the bits of collision detection which weren’t working, which turns out I must not have needed that badly, because the game mechanics work alright without them.
4. The graphics are very atmospheric and cute and actually didn’t take too long to come up with. : ) I’m very happy to have struck a happy “simple, but effective” medium here.
5. I made music! I know nothing about music, and had never made any before, and granted I mostly just jiggled knobs in audiotool, but I feel very proud of myself for attempting and making something that fits the atmosphere even vaguely.
6. A few hours before the competition ended, I got a great idea to actually make the gameplay unique and fun! There’s no way I could have done it in 48 hours having started where I started, but I plan to work on it over winter break.
7. I got sleep, I showered, I didn’t totally wear myself out. I’m especially happy I just slept in as late as I wanted on Sunday, since that was much-needed rest for Finals week.

Conclusions

I had a great time at this LD, and I’ll continue working on my game, and hopefully participate in future mini-LDs and full LDs. : D Thank you everyone!

Well I think its safe to say I have totally mucked up my game. After getting some sleep and finishing my maths exams today I played through the game. I was horrified at the number of mistakes and errors there were. I also realised that I spelled the name of the game wrong when I submitted it. But I’ve learned some new things so that’s the good thing.

One question though. After you have submitted your entry are you allowed to fix errors and stuff in it? I don’t really want to fix anything (what’s done is done). I’m just stupidly curious.

P.S Maybe I’ll get the worst game award.

Tags: 0423, chip, epic, fail

Hi there, I’m wondering if I can change the preloader code to fix a bug. I promise not to touch the gameplay. Can I?

Nobody must move a finger but me (as I host the flash at my site)…

Thanks!

First, I’ve now posted OSX and linux/source code versions on my entry’s page.  I noticed some serious slowdown when testing on my macmini – this is because it uses very large textures (1024 x 768), and there isn’t really anything I could have done (not within the 48hr time limit anyway, it would have been too fiddly and time-consuming).  Fairly recent (/non bargain-basement) graphics cards shouldn’t have a problem, but I apologise if you find the game getting slower and slower the more moves you make.

Second, here’s my timelapses:

Coding etc.

Audio

There’s two because I did the audio on a different computer, and I’m too lazy to edit them together properly.  Read on for my post mortem.

This actually went surprisingly well, especially considering I spent the best part of 7 hours on Saturday afternoon at work.  It was definitely the most enjoyable Ludum Dare I’ve done so far.

What worked:

• Setting my alarm for 2:15 am to see what the theme was.  It may have been a fluke, or it may have been that my head was in a different place having just woken up from deep sleep, but literally within 5 minutes of seeing the theme I knew what I was going to do, and within 5 minutes of that I had the entire game fleshed out in my head (I don’t think I changed anything between then and the finish – I’m pretty sure I even came up with ‘Maggott’s Restorative Ship’s Biscuits at this point).  Another 5 minutes and I was back to sleep.  The whole thing was pretty much perfect.
• The map and background paper.    I did the map in black acrylic ink on cartridge paper, and I think it turned out really well.  The compass is a bit wonky, and I maybe should have drawn those lines you see on old maps to go with it, but that’s just nitpicking.  I was a bit worried about the background paper being too light and not stained enough, but a little fiddling with Paint Shop Pro fixed that.  I’m really pleased with how the whole thing turned out, especially when the coloured segments get drawn on the map as the game progresses.
• Research.  Getting to research old maps and food adverts on google was fun.  I think I did a fairly good job of getting that old-fashioned (Victorian?) look for the game.

What didn’t work:

• The AI.  The CPU players are useless and offer no challenge.  I should really have spent more time on them to make their actions less random, and I should have used A* to get them to move towards unexplored spaces.
• That’s it, as far as I know.  Maybe some comments will point other problems out, but I haven’t seen anything obvious yet.

What may or may not have worked:

• Not having the chance to play the game with other human beings yet, I’ve no idea whether it’s actually a good game.  I think it has the potential to lead to arguments and people storming away in a huff (the mark of all good multiplayer games), but really I don’t know.  The rule set is very simple, so maybe that’ll make it less fun to play, but until I can try it out properly I’ve no idea whether it works or not.

As a bonus for reading this far, here’s a picture of the stuff I scanned/wrote down during the competition:

Tags: timelapse

Okay so i just woke up after my long period of post-LD sleep and i discovered the the goal of my game (collecting the 4 heart pieces) is unacheivable because you cant move between rooms smothely and you get stuck in walls. i think i know how to fix it (i didnt have this problem before, and that is why i submitted it without checking) and just then i found this:

“After the deadline, we do allow bugfixes. You’re allowed to fix any bugs that stop a player from playing or finishing your game. Make your fixes and upload/edit your entry as appropriate.

New content however is outside the scope of what’s considered a bugfix. You’re welcome to and encouraged to make a “post compo” version of your game after the deadline. Feel free to edit your entry post and make a new posting on the blog to tell us about it.”

So please tell me, am i able to fix this and resubmit it now?

BenHem says …

Crash!
|./bashplore: line 83: {-2..2}+15+(15-2)*121: syntax error: operand expected (error token is “{-2..2}+15+(15-2)*121”)
./bashplore: line 96: [: ==: unary operator expected
./bashplore: line 27: {1..20}+{1..20}*20: syntax error: operand expected (error token is “{1..20}+{1..20}*20”)

Nooooooooooo, gona fix it after a film, thanks BenHem

BenHem, don’t understand how you get the error because when i get this kind of error it always say something like File_other_then_bashplore: line … Cannot easly find the bug but i’ll try to fix it, that’s a promise 8p

I just made a timelapse video, you can watch it here. I removed the parts where I was away or asleep. The music is from a concert I played on Friday (from Brahms’ 2nd symphony).

• http://www.youtube.com/watch?v=buC_zbkgDHU

Edit: programs I used: FlashDevelop, Tile Studio and my new pixel editor which is still work-in-progress.

First off: Wow. What a weekend. So many thoughts I want to share. So many emotions flooded out during the experience. Let’s see if I can try and compose this a bit.

LD Entry URL: http://www.ludumdare.com/compo/ludum-dare-16/?action=rate&uid=1277
Time Lapse Dev Log: via YouTube, via MobileMe

The Plan:

My high-level plan for the weekend was:

• Friday: Prove out key tech elements needed for the game concept.
• Saturday: Build the game. Make it playable from start to finish. Get to “content complete”.
• Sunday: Polish, Tune, add the nice-to-haves.

I’m glad to say I was more-or-less able to stick to this plan.

Friday – Concept Discovery:

The Ludum Dare theme was announced at 6:00 P.M. on my way home from work. “Exploration” was not the theme was I was planning for so I immediately panicked. I figured I’d try and explore a concept of “limited visibility in an environment”. There was a small problem with this… I hadn’t yet figured out masking in Flash.

Friday – Tech Prototyping:

Being able to mask areas of a layer was going to be key to my game concept so I spent a large portion of Friday night focused on prototyping technical implementations. Thankfully I was able to figure this out within a couple of hours and I had my first build showing a bitmap with a sprite masking it. I was able to addChildren to the sprite to get the dynamic effect I was looking for.

The rest of Friday night was spent shoehorning some of my tile engine code into my game concept. I called it a night at midnight.

Saturday – Fleshing out the Concept

It’s amazing how your dreams change when you are up to your eyeballs in a project. I was able to focus in on my game concept a bit better with a night’s sleep worth of brain parsing. I decided to scrap my idea of doing a platformer due to unnecessary risk. I focused in on the concept of a bat (easy to draw & animate) trying to find his way through a cave.

Saturday – Building the Content

I had to force myself to stop playing with my tech at noon on Saturday and start focusing on building game content. This is where I encountered my biggest stumbling block. My tile engine code was great at loading an overly verbose XML data file. But this XML file was not ideal for rapid prototyping. I ended up deciding that Excel would be an ideal level editor. So I rebuilt my tile engine to load a .csv file. While this was indeed a big stumbling block, it only took me an hour or two to resolve. And in the end, the time saved by being able to edit levels in Excel was well worth the investment.

Building the levels was very straightforward and it didn’t take long at all to build all 5 levels of the game. I focused on a learning arch that would guide the player through the experience. The game peaks in difficulty in level 4 then eases it’s way down to the end. By 7pm I had the game playable from start to finish. This was a huge accomplishment and really put my mind at ease. The rest of my time could be spent tuning, tweaking, and polishing.

Saturday Night – Audio

I spent about an hour in GarageBand putting together a straightforward audio track that would serve as the atmospheric backdrop music. Nothing special – but it certainly added something to the experience.  CFXR (a Mac port of SFXR) was the tool of choice for the sonar sound effect. Since I knew the player would hear this sound a lot, I made 3 variations of it that played at random. This partially minimized audio strain.

Saturday Night – Sleep

I called it a night at 1am quite confident in my progress. Trying to sleep was next to impossible. It appears that after 18 hours of straight game developing my mind and body started acting weird. My brain wouldn’t calm down as it continued to parse through a backlog of thoughts and ideas. My body felt like I was going through withdrawal. I was breathing weird, my heart was racing, everything hurt. It was a very very odd experience and it took 3 hours to get to sleep.

Sunday Morning – Book ends

Saturday night I came up with an idea for the game’s ending. I decided to invest a lot time Sunday morning building this out. I really really like how it turned out. A good chunk of time was also spent on the title screen which led to me changing the fonts throughout the game.

Sunday – Final tuning

Once of the last decisions I made was to remove the timer system from the main play-through of the game. I felt the timer took away from the feeling of solidarity and exploration. I wanted the player to explore with no pressure the first time through. I did however add the functionality so a second play-through (during the same game session) would trigger the timer and allow the player to race against a par time for each level.

I submitted the game at 3:00 P.M., very pleased with the final result.

Thoughts & Conclusion:

I’m very conservative in my development style. I’d rather focus on something small and polish it than stretch my time too thin. EchoExplorer was no exception to this rule. I cut many elements very early in development that I felt were not critical to the core gameplay. But even with this small core I attempted and succeeded with many new things this project:

• This was the first time I’ve made a game with “levels”
• I built a .csv parser so I could build levels in Excel. I’m so impressed with how well this worked.
• I got alpha masking working.
• I created a really cool ending sequence with dialog, timed sequences and camera panning.
• I made my most polished and awesomest game to date.

I wanted to create a small but polished experience. The game can be completed in as little as 2 minutes but there are lots of little things that I feel make this a richer game experience. I like the pacing. I like the graphics I was able to put together with my limited ability. I like the story and emotion the game delivers. I even think the difficulty and frustration is nicely tuned given the short length of the game.

What would I have done differently?:

I had a lot of time to be a bit riskier but I chose to err on the side of caution. Next time around I may loosen up a bit and try to bite off more. Though next time around I should also be able to progress faster from the tech-side. (I still spend a lot of time looking up Actionscript code as I write)

The bottom-line is there will be a next-time. This was my first “proper” LD. It will not be my last.

Well, my first Ludum Dare is finally over. The dust has settled and I finally have regained sanity from sleeping a combined ten hours over two nights. My game,  Lost? (spelled with punctuation to differentiate it from the popular television series of the same name), is pretty much a combination of Knytt Stories and Metroid (leaning significantly towards the Knytt Stories side). I’ve learned quite a lot about rapid development here, so I’ll outline it as the fallout has settled.

The Good

Let’s talk about what went right, first. While I barely planned out the game (I spent literally five minutes brainstorming the features and part of the game map), it turned out pretty well in the end. Pretty much all of the pieces fell into place in the last five hours pretty nice, and all of the bugs were ironed out within one hour of the competition ending. Every single goal of the game was met to some extent, so I now proclaim my first Ludum Dare a resounding success!

The Bad

Well, if someone says that their LD entry has gone without problems, they are lying. Developing a game in 48 hours from scratch is not something that is easy. One thing I would have liked to change is the ladder physics. I modeled them off of Mega Man 2, thinking it would be an good example as I have never actually implemented a ladder in a platform game before. Not only did it messy up my beautiful platform code by adding conditional statements everywhere, many people disliked the slow speed of moving up and down ladders, and not being able to jump up while climbing. I would have changed it during the last hour of the competition, but I was unsure how I could make climbing ladders easier but keep them as a challenging game mechanic.

Probably the biggest problem I had with the development was the music. Music is a very important element in the game, but I almost didn’t have it. First my tracker just failed to start up. I had to spend an hour trying to get it to work and trying to find alternatives, but I got it working eventually and made the music all on Sunday. The second problem with it is the tracker I used only saves in very outdated formats. So outdated, in fact, that the module files it saves are pretty much incompatible with modern computers, and the only format that works is Scream Tracker 3 files. Now, only one wrapper exists that can run the required DLLs to play the files, and the wrapper is really, I mean really annoying to work with. It is a pain to stop songs, see which songs are running, and much more. I had to jump through hoops to get it to work out, and I did some things I wouldn’t normally do. For example, when it all came down to the last hour and I had trouble getting the sound to stop after beating the game, I pretty much gave up, so whenever the game ends, the DLL is unloaded, the entire game restarts, and then the DLL is reloaded.

Lastly, I would have loved to have more time with areas and just simply planned the map out better. The game only has four areas when I originally planned to have at least five. The water area was removed as I didn’t have enough time to expand the already overcomplicated physics code to handle the changes in movement whilst submerged. Another unintended consequence of my lack of planning was that it was impossible to leave the fire area as the jump to the left of the save point was to large. So I added the lower exit, which increased the size of my game by a few screens. So I guess that was a good thing.

So, after my second LudumDare (the first being 14th, I forgot about LD for the 15th contest), I was rather disappointed. I made 2 entirely crappy games, one not even functional. I did manage to stick with my wheelchairs, but I really just made a platformer with spring platforms, and added some outline graphics to make the blocks look a little better, and little branches to hold the springs onto walls. But in all honesty, it was completely rushed (yes, I’m comparing this to a 48 hour timeframe) and played like crap. I couldn’t even be arsed to make the “PRESS ANY KEY” message blink in and out, or even use an outdated chiptune I made.

However, on the plus side, I participated, and I made ExciteMike’s wallpaper be square. I also learned I suck at making randomly generated mazes.

So, maybe next time I’ll think of a better idea. I can’t say I liked the theme. Don’t flame me on this, but I think most people just voted +1 because it wasn’t a bad theme, and it ended up winning (much in the same way that a tournament participator could be getting 3rd place every single round and still win).

This was my first Ludum Dare and my first game I programmed too.  My game was very simple but I wanted something I knew I could finish and finish I did.

What went right:

• The game got finished
• Fixed any major bugs

What went wrong:

• The goal of the game: it never really happened
• Bugs took a long time fix
• Ran out of muffins

What went into my belly:

• 6 muffins
• lots of soda
• Rigatoni with pasta sauce
• Angus burger
• bagel
• chow mein

What I learned:

• You can make a very simple game in 48 hours while knowing practically nothing about game programming
• What a SIGTRAP is
• How to use Code::Blocks and its debugger
• You can never have too many muffins
• Pasta sucks without parmesan cheese

Tags: postmortem