[ Play Abigail's Descent | gameplay footage ]

My game’s a platformer where you descend around the outside of a cylindrical pseudo-3-D tower. It’s nothing groundbreaking (I’ve seen the tower mechanic in at least 2 other games) but I still felt like I put enough into it that it wasn’t completely derivative.

I don’t usually have trouble coming up with an idea that I like. I started on the tower mechanic 21 minutes into the competition, and I had the rest of the gameplay in mind within a couple of hours.

I think I made the right choices about which features to cut and which to keep. Some highlights:

• I’m really happy with the 2.5-D tower. This obviously was not trivial to implement, and it turned out pretty well. I wish I could have made the platforms look better, but nobody has complained yet.
• I like the grayscale characters. It reminds me of Paper Mario. Feedback has been mixed.
• I really like the clouds. Nobody’s commented on them, but I think they do a great job adding to the 3-D effect and they only took 20 minutes to add.
• The dialogue/story is good, but I wish I could have spent more time on it. The knight was originally only going to be in one level, and I had other characters planned.
• I think I got the challenge level just about right. I followed my rule of thumb of making it 1 to 2 levels easier than it seems like it should be. Some players still thought it required pixel-perfect jumps, though in reality every horizontal jump has at least a 14 pixel margin of error.
• People don’t like jumping games, I know. I really like to have as simple of mechanics as possible and make the most out of them. I think if your character can jump, you should have some challenging jumps. I hope that the frequent checkpoints helped minimize the frustration.
• The sound and music are fine. I may some day be able to make my audio rather than just using whatever comes out of sfxr and Autotracker-C. But until that day, I’m grateful for these amazing tools.

I had a great time this LD, and I was pretty happy with how the game turned out! It’s already gotten twice as many ratings as my last LD game did during the whole competition, so I certainly can’t complain about that. So far I’ve gotten very constructive feedback.

Thanks to everyone who took the time!

After finishing my game I noticed that I had plenty of spare hours left so I decided to add a scoreboard. Unfortunately that meant communicating with a web server, which to my knowledge meant I had to sign the thing.

Signing applets involves some console work, but most importantly it involves an annoying popup asking people to let the thing run. In my mind that’s nearly as bad as a installer and I didn’t want anything of the sort, besides I tried that on a previous project (which come to think of it was also a 48 hour game) and that resulted in people not playing it a all.

From some android work I’ve done I remembered I can call links to pages even if the app has no permissions(the browser handles the links), and I wasn’t too surprised when I found out that an unsigned applet can do the same.

Basically what I did was call

link(“http://example.com/scores.php?name=Andrew&score=asdfg”);

(processing function, no Idea if it’s the same in reglar java) where ‘asdfg’ was an encrypted version of the score.  This coupled with making each score unique prevented floods on the scoreboard.

The function spawns a popup window, and I’ve noticed that even if chrome blocks it, it still preloads the score page causing the score to go through. This may or may not be a security issue.

If anyone knows a better, or just different way to have an applet share its internal data I’d love to hear it.

VIEW GAME PAGE

Looks like people are still writing post-mortems a week later, so here’s mine!

Development:

I woke up last Saturday and checked the theme on twitter. I didn’t really expect the theme to be ‘escape’, but I had a think over breakfast and got a cool story idea, sort of inspired by an episode of an old TV show called Porridge. I started off with a dull blue wall tileset and made a prison cell in DAME.

Drawing tilesets in Graphics Gale.

Once the character graphics were done, I threw together a system which scans the DAME project file for game entities then places them on the map, since I didn’t have time to get to grips with the complex export system in DAME. Eventually I had little Rick running and jumping around in his cell, and I spent the rest of the day composing in SunVox and using Tweener to arrange the introduction text and events.

I didn’t actually start on the gameplay or levels until Sunday, when I decided to construct a small jungle full of spiders and spikes. It took most of the daytime to create the enemies, tiles, and music which left me with the evening to work out how to bring everything to a close. I stayed up right until the deadline designing the last area and finishing the game off, but I managed to squeeze in another tune, bringing me to a total of four songs!

Making the soundtrack in SunVox.

What Went Right:

• Considering this was my first time using DAME, creating the levels and making them work in Flixel was surprisingly painless.
• I’ve practised a lot with SunVox, so I can churn out decent music fast!
• I had a nice storyline idea and managed to keep it short without ruining it.
• I’ve been practising with Flixel and FlashDevelop for quite a long time. Even though I hadn’t released any Flixel games before this one, I was very comfortable with my choice of language and library.

• I missed a few details, for example there is no wall on the left side of the jungle, so you can fall off the screen and be stuck forever.
• Quite a lot of people heard strange hiccups in the music playback. I have no idea what’s causing this and I can’t hear them myself, but I added a standalone download which should hopefully fix any audio problems.
• I made a couple of bad design decisions, there are quite a lot of blind drops into enemies. I thought the levels were short enough not to need checkpoints, but it looks like I was wrong.

I’m really pleased with the amount I managed to get done in two days! If you’re interested, check out the entry itself here.

Oh, and if, like me, you don’t want to hand pick entries to vote on, I made a small bookmarklet for you:

javascript:var a=jQuery('table tbody tr td a');window.location=a[Math.round(Math.random()*a.length)].href;

Add this link to your bookmarks bar, then go to the view all entries page and run it, you will be taken to a random entry page. :] Happy rating!

Hi there, LDs over for a week and I got many people to say, that my glorious (ahem) piece of work isn’t beatable at all.

So, I beg to differ

http://www.youtube.com/watch?v=U-RNWmPBj00

Yes, you’re absolutely right, it’s hard as hell, there’s no introduction or tutorial at all and you’ve to have a lot of luck to get a starting position where your ship isn’t blast into pieces after a few seconds.

But it works.

Ok, I’ll try to learn this lesson once and for all (my LD 19 entry wasn’t nicely to play, too)

Someone playing Elastic Prison

Alright so here go my final thoughts.

Game Mechanic:

I’m pretty happy with how everything went. The first day I spent a lot of hours just brainstorming, trying to come up with a really cool and simple concept. I’m a big fan of generated content and simulations that give the player something interesting and new to play with. Something that encourages the player to experiment instead of just running through everything completely deterministic. And I came up with a concept that was just way too abstract, and I wasn’t able to fill the blanks with working/realistic ideas. So about 10 hours in I somewhat hit a wall and was feeling quite stressed out. So I remembered to keep it dead simple and came up with what turned into my final entry. Elastic Prison, a game where the player controls a ball that is attached to an elastic band that keeps pulling it back to the starting point. And for the player to free himself, he has to cling & swing himself from one floating hook/ball to the next to maybe reach something that will remove this rubber band.

First I focused on how the player controls this ball and how the elastic band attaches itself to these hooks. I had something running pretty quickly and felt satisfied with the controls. Then I started to focus on the actual level creation. I knew there needed to be some variation so I created different kinds of hooks. I also put a few minutes into improving the performance so I could just throw everything into one big level.  The next step was creating the level. I did so by making one challenge at a time for me. Every time I tried to make it different from the previous one, or even so that it builds on the skills that were acquired earlier. I tried to make later parts of the game really hard as I hear people are complaining a lot about games being to easy these days. So I could just barely play through these final stages that I created. Still it’s not impossible and after uploading my submission I recorded a 12 minute play through.

Tech:

Using LWJGL was a pretty straight forward decision but looking back it might have been smarter to choose libgdx because it’s LWJGL + more nice stuff (mp3 support). It’s been smooth sailing with LWJGL though. Currently I’m working on porting my game to libgdx to maybe have it run on android or as an applet.

Sound and Artwork:

Those were the things I was most confident about and surely enough I was really quick. Ableton and Photoshop did their job well. The sounds turned out a bit quiet though.

Feedback:

I have to say I was quite surprised with the feedback. Yes people liked the concept, art and sound but had a gripe with the controls, expecting them to behave differently and not really being able to figure out how to master them. And they were quite frustrated about how checkpoints work, as they won’t keep  you forever from going back to the beginning. Well I can see now how people expect the controls to work and it’s too bad that I didn’t hear that kind of feedback before I uploaded my final submission. While working on it I was told it is hard but fun, which is what I was going for. Now to the checkpoints. I guess the problem here lies completely in not communicating well enough how they work. The funny thing is that it is a really simple concept. Every hook behaves the same way. But some might hold you longer, depending on their size. You won’t end up at the beginning if you understand this concept and make sure to reattach yourself to these large hooks again when they stop glowing.

Once you get it it’s a challenging and interesting concept. And I thought it goes quite well with the theme. The player is trapped and tries to escape. Once he stops struggling he is in danger of being back where he has started.

Future:

I look forward to the next Ludum Dare. I’ll make sure to get more feedback while working on my game, and to keep it simple straight from the beginning. As for Elastic Prison, I’ll make it available as an Applet and maybe do some more with that concept sometime in the future.

My Entry

So, unfortunately, due to the numerous issues with the site over the weekend I fell out of the habit of posting anything to my log over the course of Sunday. Given that this was certainly not the case for last LD, I am going to try and make up with a huge post instead, with sprinklings of hastily drawn drawings of things.

[ Play Aphelion Incident Here! ]

What Went Well

Planning

Oh boy did I ever improve on planning from last time. In LD20 I planned basically nothing and made it up all as I went along, reasoning that I’d find better use for the time actually making things. This was a mistake.

The time I spent on planning was 2 hours total (not a solid block), and for every minute I spent planning I saved two having to come up with things later on. I can’t emphasise enough the advantages of planning, but it’s one of those things where it’s obvious if you already do it and seems a waste of time if you don’t.

I did spend a lot more time on planning things I eventually had to cut, but without those plans in place I would have never known what I could have cut. I had to excise things like multiple species of guards and individual chatter lines simply because I didn’t have the time, but as stated, if I had never planned to add them in the first place, I could have never decided to omit them knowing I had more important things to work on first.

As my scanned-in plans are far too big to post here, you can find them here if you’re interested.

Prioritising

Code first. Code first is the most important rule you can adhere to for a competition this intense. It felt disheartening seeing a bunch of other entries being so much further along in terms of graphics when I was stuck with boxes with arrows on them, but with perseverance I ended up with a game that was more complex below the surface than Throwbots was. However, Throwbots had a few easier gimmicky things, which spiced it up a little. This game was a little lacking in gimmicky things, but it ended up spiced a little by something else.

Making the Guards Relatable

This I managed to hit spot on. I went into this with the idea of making the guards you’d otherwise treat as faceless enemies in a video game less faceless. I added a profile of stuff for each of the 20 guards in the game (which ate more time than I could ever have predicted) but knew there was one thing more I could do.

Give them friends.

In retrospect, “is fond of” was a bad phrase to use when the friend of a guard was meant to be any sort of positive camaraderie with another guard, and it made it look like the entire station was filled with courting couples or something similar. What was more interesting was I added individual messages to each guard if they saw their friend possessed or killed, but due to the frequency of random chatter it almost never showed up. It all helped to make people a little more hesitant to start gunning the guards down.

In initial playtests before submission, people were asking if I could make it so that guards could move into other rooms so they could unite the pairs of guards. I figured I’d won at making the guards relatable at that point.

What Could Have Gone Better

Guard AI & Controls

The guards don’t really HAVE an AI. Considering the initials of the game are “AI”, this feels a little more of a lacking feature than it should be.

Having never tried any sort of decent AI implementation in a game before, I had no idea what I was getting myself into. The state machine was simple enough, as was setting up an array of reactions based on certain stimuli.

But the main problem was a lack of good platforming AI. Having detection of pits and walls to turn away from was pretty simple – just check the tilemap to see if there’s a pit or a wall the guard is about to step into, and if that’s the case make them turn around. But then came a problem of the guards climbing jumpable parts of the map. I limited the jump height to such an extent that they couldn’t overshoot the block they were jumping to. For some reason, I decided to make that the jump height for the player too.

The kicker is that I later added code for the case where a guard falls too far away from their patrol point and made them pick a new patrol point based on where they were, so there was no reason to be so defensive about keeping them near where they started. That was an honest mistake on my behalf.

The transitions don’t always make sense either, and guards have no persistence of memory. If they see the player and the player ducks behind a corner, that’s it. The player has ceased to exist for them. If I had pathfinding code in there, I’d probably have made them chase the player while they were within a sensible range, but I sure as hell was not writing my first platform pathfinding AI during a Ludum Dare.

All in all, a host of niggling issues that I would definitely like to resolve.

Guard Interactions

I’ve heard people coming back to me saying they memorised all the guard details in case they had to use them. With more time, there would have been social interaction puzzles, because while it’s fun to take over people’s actions why not also meddle in their affairs while you’re at it? Unfortunately, I couldn’t think of a streamlined way to do this, nor a way to get the relevant reactions and such done within 48 hours. A future version, perhaps!

The UI and Tutorials

Quite simply, there was no tutorial. I ran out of time to add one, and so tried to make up for it by sticking the controls in my entry text. Not only that, but I ran out of time for custom keybinding. For everyone not using a US/UK English keyboard, I am so, so sorry to force Z/X/C on you guys like so many other inconsiderate devs, but when it came to getting the game finished or implementing custom keybinding, I knew I had to focus on the former.

As for the UI, well, I didn’t get any of the graphical elements done so most of them ended up hidden. It’s a confusing mess at the moment, but believe me when I say it’d be more of a confusing mess with a bunch of squares that don’t do anything on it. Once I get the first post-compo release finished, you’ll hopefully see what it should have been.

Critical Bugs At Release

The first version of the compo release had a critical game-freezing bug if you managed to get shot while controlling a guard (a case I never encountered during my own all too brief testing), as well as a duplicated terminal and a missing terminal. The first was due to another instance of a variable being null when I didn’t expect it to be (easy to fix).

The second, though, was the worst damaging typo of the compo. Each terminal had a numerical ID. Terminal #16 ended up getting 10, so there were two terminal #10s and one terminal #16. Now, this might sound meaningless, except the doors are locked according to terminal IDs and whether they’ve been used or not. Terminal #10? That’s the terminal that unlocks the door to the teleporter room. If you were confused by the earlier comments on my entry about finishing far earlier than they expected, that’s why. Whoops. My bad. It’s fixed now, though.

What To Focus On Next Time

Sounds and Music

I managed to miss this out this time as well, much to my disappointment. I had such neat ideas, too. Oh well. Best to have an okay working game that looks passable instead of a broken game that looks terrible with annoying screechy sound effects, right?

Core Mechanics

Although the extraneous bits this time around may have elevated my entry from mediocre platformer to something with a bit more depth, I still think the control mechanics could have benefitted from a little more love.

Timelapse

I skipped it this time around due to lack of preparation. In future I am going to do my research to find out what programs to use and more importantly how to make my reams of coding look a little more interesting.

In Conclusion

I had an amazing though hectic weekend working on this thing and there is no doubt in my mind that I’ll be entering LD22. This time, I intend to work on a post-compo version of my game and perhaps even carry it into the October Challenge if it’s on this year. Regardless, I’ll see you guys at LD22. Keep being amazing.

(Let’s see if we can break 1k entries next time!)

This was my second Dare, and it was just as fun as the last one. I learn a lot from this process, and I am proud of being part of this incredible welcoming community.

The concept
The game is based on an idea I got a few months ago. I’ve wanted to try out this idea for a while, just to see if it would turn in to an enjoyable game. After seeing the end result of the voting rounds, I immediately thought that this would be a good opportunity to try to implement this game.

The premise of the game is simple: Wolfenstein converted into a turnbased puzzle game.

What went right

1. The engine
An engine like the one used in Wolfenstein is quite easy to implement using the technology that exists today. Back in the days you had to implement it all in software on hardware that merely were fast enough to draw graphics at that speed. I went for a really easy approach where I simply put a lot of textures cubes on the screen. This works fine as long as the maps arean’t big enough. Using this method, it was easy to implement a simple tilemap loader that put the cubes at the correct position in the world with the right texture.

2. Known library
Unlike my first Dare, I used a library I’ve used before. I used the same library as I used for my entry for Mini-LD #28, Three.js. This turned out well, as I could be productive from minute one.

3. Level editor
In the middle of the implementation process I figured out I needed some way to define the levels. I figured I did not have time to write something myself, so I checked out a few tilemap editors I already knew, but none of them would export to a javascript-compatible file out of the box. Some of the editors support writing custom exporters, but I didn’t feel like brushing up on my Lua experience. I therefore went for an easy middleway where I used Mappy to build the levels. I then exported them to text format, and copied part of the text over to a custom made fileformat using json. This solved my problem completely, and worked well for my use.

4. Browser standards
For this entry I used some of the latest HTML5 technologies. It’s suprising how well the standards are defined for both WebGL and HTML5 Audio. When I’ve implemented the engines using Chrome, and then tested it using Firefox, it seemed to work with almost no changes. The only change I had to do, was some error checking for loading audio for Firefox.

What went wrong

1. Postponing sound
Once again I postponed the sound and sound implementation to the last minute. Sound creation went fast as always with the mighty powerful BFXR. Earlier I’ve used a sound library that uses Flash for sound playback for maximum browser support. But I figures as I’m using WebGL, I could as well use HTML5 sound, even though it is not that well supported yet. I’m pretty sure that if your browser supports WebGL, it will also support HTML5 sound as well. Problem is, I’ve never used HTML5 audio, so I needed to learn it as well. Turned out that is wasn’t that hard, and within an hour I’ve made a very simple sound engine for my sound and music needs. Before the next Dare I should probably create a sound library that I can use instead of having to struggle with sound once again.

2. Lack of artistic skills
This is a general problem with my entries. I lack the artist gene, and is therefore not able to draw pretty pictures. This is shown in most my entries, where I try to minimize the damage done using as simple as possible drawing. This time I needed to draw a simple character, and it turned out ok, but I think I should stick to mechanical constructs ahead to avoid having to draw organic objects. The same goes for music. I found this really nice tool before the competition that I thought I should be able to use to make simple music with, DrumCircle. When I sat down with it, however, I could not create anything that sounded like music, even though I succeded using it a lot before the competition. I therefore ended up using elevator-music generated from Wolfram Tones.

3. Difficulty level
I really misjudged how hard it would be to play the game without a minimap. I intentionally did not include a minimap just to give the game a little more challenge. After reading comments and seeing friends play the game, it seems like a minimap is a must for this game. It is also har to judge how far you’ll step using a single arrow because of the lack of a visible grid. This was also caused in part by the lack of variation in the wall graphics.

4. Level design
I had no clear idea how I should design the levels, and how I should design their challenges. With that in mind, I ended up using scare-tactics as a gameplay element. The challenge of the game became the avoidance of the guards. I initially intended to add sophisticated shooting-mechanics into the mix, but it turned out that running away from guards was enough.

5. Rough introduction
There was no tutorial in this game. You was thrown right into the frying pan, causing all kind of confusion because the player had no idea on how to play it. This could be solved by having a more sandbox-like first level with some popups appearing when the player walks over given points. As it is now, the player is greeted with a wall of text at startup, and you cannot really play the game without knowing the bare basics given there.

6. Irritating UI
I implemented the UI using JQuery and JQuery UI. These libraries aren’t really made for games, and it shows in this game. I wanted a queue of commands for the pleyer to execute. This queue could become taller than the height of the screen. Instead of allowing full window scrolling I made a smaller area with a scrollbar. It was then possible to rearrange items in the queue by dragging each command up and down. The problem with this approach was that it was possible to scroll past the horizontal and vertical edges of the queue, which made it quite hard to predict what would happen if you dropped an item at times.

The future

If I get the time, I will try to improve on the game, and maybe even add a few features.

1. Minimap
I would like to add a small minimap for the players to easily orient themselves. I’m not sure if I should place enemy markers here. I should at least mark their position if they catch you in case the camera is not in the correct direction. I should probably change the camera angle in any case.

2. Level grid
A visible grid that gives an indication on far you will step if you add one more move action to the queue.

3. Less annoying interface
An execution queue that does not scroll at its own will. I will probably implement this using a canvas where I calculate the position of the individual queue elements myself as well as accepting the input.

4. Speed of execution
Buttons to control the speed of playback. Too often it feels like it takes an eternity to make the player avatar move.

5. Conveyor belts
This is a new gameplay element. I was thinking about adding conveyor belts that you could push crates onto. This would give the possibility to kill enemies by pushing them with the crates. This idea came from reading about the board game Robo Rally.

It’s been a good set of days with Ludum Dare, and aside from one incredibly annoying and potentially ruining issue it has been a great learning experience. It’s been a lot of fun and I hope to compete again in the future.

The Good:

Entire game got completed, without too many hits (except for the one mentioned above), it’s been a blast and in general I wouldn’t have anything bad to say with it. Programming was difficult at times, but it helped me push out more and further my little experience in that field a lot more.

The Bad:

 Work on the Music took a lot longer than previously desired, but more-so than that it seems the game is working out to be a bit hard for players. I wish I had placed the controls information inside the game, as this generally would clear up that holding X makes the character run a lot faster and in general makes for easier platforming. It -is- playable, but this is where the ugly comes in.

The Ugly:

This is where it gets really nasty. The original upload I made for the contest had everything working, everything, except -one- item, which is crucial to completion. The reason why this wasn’t in the original upload? On zipping the file I must have done something horribly wrong which wrote those rooms as completely blank. In my source outside of the zip everything was fine, but with the zip bundled and such, I didn’t notice this error till later. I reuploaded another zip with the correction made, but if this invalidates the entry then I’m willing to roll with that blow; I’d much rather a game that was complete and made in the spirit of the contest rather than try to rush something out just for the whole idea of “winning” something. Hopefully though, this shouldn’t cause any problems.

Summary:

Incredible learning experience through and through. I had originally intended to make an RPG with a basis engine beforehand but the time frame for that does not fit very well for a 48 Hour contest. I’d like to attempt it someday, but maybe for the Jam as opposed to the Compo. I really look forward to the next Ludum Dare and as usual check out the other entries submitted. There’s some amazing content up!

Till next time~

This has been my first LD. I've managed to complete a game and the whole
weekend was a nice experience. Here's what I've thought...

Before LD21

+ you can't possibly make interesting levels by hand in whatever little
time you have left after finishing the engine and art, therefore you need
to make a game that doesn't rely on levels
+ you can't make decent 3d games in 48 hours
+ you can't balance a game in 48 hours
+ libraries are for lazy programmers

After LD21

+ you can make interesting levels because developping with libraries saves
you lots of time or you could make a level generator
Astar
Hell fortress escape

+ you can make nice 3d games in 48 hours with the proper tools
Stratus
Under a watchful eye
Prelude of the Chambered

+ libraries are mandatory if you want something more complex than a tic-tac-toe like game
Gather 10 keys to escape

+ mining games are pretty damn popular
Lost in the shadows
Caved in
Tea powered escape!

+ 48 hour entries can provide an interesting atmosphere
Escape from the labytinth
AWOL

+ you can write a story-based game in 48 hours with superbe pixelated graphics
A tale about life, death and a loser

+ WordPress hates me

Hi guys,

I had this game done but didn’t have net for 6 days so I couldn’t get on. Someone  forgot to pay the bill. Anyways here is my late entry. Hope you like it.

The game is about escaping the fly swat and dodging the gun turrets with bullets to reach the finish line.

http://dl.dropbox.com/u/6138533/Smart%20Fly.rar

screenshots

http://tinypic.com/view.php?pic=6pmc7l&s=7
http://tinypic.com/view.php?pic=6f0bp0&s=7

If it shows a error make sure you get the latest directx 9 have fun

Hello again! Gosh you do smell nice this weekend. Is that new cologne/perfume/soap/deleteasapplicable?

Just the other day, in the post-LD glow, I asked for some of you to poke your games in my direction so I could play them while rocking slowly back and forth in this white cell… and you did! I love you!

I added a few of my own picks to the mix, and glued it all together… and here it is:

65 Games in 10(ish) Minutes

(or “The Slow Descent into Madness”)

MASSIVE thankyou’s to (in show order):

schonsta, TurboDindon, Jasper Stocker, nilstastic, quickfingers, johanp, Bloodyaugust, Hempuli, puffi, ratking, jonnopon3000, gokuhd, DecsterB, Kevin Wells, oatsbarley, Dark Acre Jack, icrisanto, theosk, angrygeometry, agersant, dray, Felipe Budinich, marudziik, johnfn, Tom 7, Rolpege, KevinWorkman, lectvs, ointment, degtyarev, Winterblood, ChevyRay, Jhelle, pekuja, pgil, Zed, tcstyle, SLiV, Doft, Sos, matthias_zarzecki, LegacyCrono, WiggleWorm513, platypus, joekinley, heck, PaulWagener, Gib, Notch, accidentalrebel, None, Folis, PaulSB, superflat, RichMakeGame, kevglass, redwater, Superyoshi, Surrealix, EricTheCoolDude, digital_sorceress, Lattyware, Andrew, TheGrieve, Nanolotl

…and everyone else who supports indie gaming. It’s important. Very important. I love you all. x

Mouse trap got “done”, many people have played. rated and commented it. So let’s get to it!

What went wrong:

Art:

I consider myself a programmer, and I really dislike doing art. But it had to be done. Besides disliking doing art, I am also way too perfectionist. Because I had a semi-working tile engine made, I used it.  So I’ve gone straight into doing the artsy stuff. But I ended up spending too much time on drawing a nice mouse.

The mouse:

I only realized that when I watched my project timelapse (see links at the bottom). And all that detail ended up unneeded. I was going for a zoom-able camera, so when a level started it would make a “dramatic” zoom out. To do that, I needed “high enough” resolution pictures and tilesets. No “great” zoom effect was done, so there was some good work wasted.

The mouse in all its glory.

Reinventing the wheel:

After doing the mouse, I’ve put it to test on the tile engine I had. And because I was bored of art, I ended up doing some code in the engine itself. I modified the way the tiles were stored in memory and  squashed some bugs. But the thing that I shouldn’t start doing, was implementing in a dumb, heavy, and ugly (both visually and technically) way the Fog of War. I tried to ease it up with some alpha blending, making the game running like a snail. Then an easier way, that would take 10 minutes of my time, come to my mind. Threw the old code away, wrote the new one. Even more wasted work.

There's always an easy way, that doesn't require too much coding. Also this is the fog of war image, that took a lot of code away (and made the game look better!)

Sweet but short:

Because I spend way too much time on the things above, I really didn’t gave enough time to level design. As another “artsy” thing, I don’t like doing it. I had a level designer in place for this engine, but changing the way tiles were in memory and the way levels got loaded, the level editor simply got broken. I even spent one hour or two to fix it, but then, I neglected it, and made the levels by hand (check out the levels’ source code in the links below.). The first one had to be ultra easy to ease on new players (I made the game so my mom could played it). The second had the traps, whose code and drawing were rushed. The labyrinth was made in the way of a “random walk”. While “walking randomly”, I made up a story in my head, that I kept writing, directly in the map tileset source code. After that I didn’t know what to do next, and I had only 2 hours left, and way too sleepy.

Level editing, like a boss... (or like a propeller head)

The typos:

“Freedoom[sic] and cheese”. Let’s just leave that in the way it is.

RTFR:*

Those were the bad parts during the compo. After my game was published into the wild for ratings and reviews,  a guy on IRC asked me  if the soundtrack I had used was made by me. I said no. It wasn’t mine. Then that guy pointed out that I couldn’t use content created outside the LD48. I panicked. I didn’t want to lose my entry, due to forgetting one simple rule. The fix: rename the music files on the server, effectively removing the music from the game (the music’s link is below).

No updates, no news:

Another thing that I forgot to do was to keep a nicely updated journal, to keep people posted on what was I making.

What went better than expected

The reviews:

Well, the reviews were all awesome. Better than expected really! There were people who felt that this game was an analogy for life… My initial reaction was to laugh at it… My breath was taken by those comments. Then I replayed the game, and tried to look it in their point of view… In fact, maybe they are right! That is probably a good analogy for life!

Code reusing:

It really sped up my development. It sure is much easier to write from a known codebase than from scratch.

Conclusions

People loved the game and I feel I put them in the mouse’s shoes. In my spare time, I’ll probably enhance it, with more levels, a deeper story and more kinds of traps. I would love to get doors and some animated enemies working on the game. Also a nicer intro screen and a great ending screen wouldn’t hurt…

Links

• Mouse Trap entry
• Timelapse
• aMaze (the engine that I reused)
• Levels’ source code
• Level 1
• Level 2
• Background music – Through Uncertainty

Glossary

*RTFR: Read the F…ine rules

Urth has a rather high difficulty, especially in the puzzles available in story mode. These require both planning and reflexes, and may seem impossible. What works on paper doesn’t necessarily work so well in the field, and I’ve learned that by repeatedly failing to finish my own levels. Of course some tweaking there and there helped, and feedback from the community helped identify the particularly tough levels which needed ironing out.

Without further delay I present one set of possible solutions to the puzzles:

VIEW LEVEL GUIDE

I don’t doubt that most players devised their own solutions, and if anybody would like to share theirs I’d love to see them.

VIEW GAME PAGE PAGE

Here’s my timelapse finally! I spliced the two days together.

Well while I wait for my timelapse to attempt to upload to Youtube for the 5th time, I might as well write a post-mortem for my game. Here’s a reminder of which one it was:

Awesome

So I pretty much managed to stick to my original plan this time. I chose the absolute simplest gameplay concept I could come up with, and avoided the temptation to try to make something fancy.

Avoiding falling stuff has to be the simplest action game imaginable; and in fact for a program I used to use called DIV Games Studio, it was the tutorial. A bit of a speed-up mechanic and some lava to escape from and I had my gameplay down. The code was messy, but never got to an unmanagable state.

I was then able to spend the second day working on the graphics, which I was pretty happy with in the end. I managed to submit a couple of hours before the deadline with Windows build complete, which is a first for me. It was nice to not have that sinking feeling about 5 hours before the deadline when you realise that you’re nowhere near to completing what you wanted to have done. And ever nicer to not be scurrying around trying to throw a build together with 10 minutes to go.

Pants

I still didn’t leave enough time to record some proper sounds and write some music like I’d hoped to. I ended up throwing together some sfxr noise, which is better than nothing, but does all start to sound the same after a while.

While the code went well, I found myself writing unnecessary bits of boilerplate code that I always seem to end up writing. Code that could and should really be abstracted into a library and reused.

In Closing

I think I took the right approach this time. No grandiose plans, no over-optimistic attempts at procedural generation, no attempts to invent new genres, and generally no biting off more than I could chew. I kept it simple and relaxed and while my entry isn’t going to win any prizes (there aren’t any anyway), the sense of accomplishment and closure was pretty satisfying.

Next time though, I’m going to be better prepared in terms of the libraries I use, and cut down some of the boilerplate to leave more time for gameplay code. Every extra minute I can save here and there gives me more chance to add polish, namely audio which always gets left until last and therefore neglected.

TL;DR: Happy but music next time

Finally I made a post mortem longplay.

I assume you read enough of those already so i made it a commentary to a longplay.

Edit: Its broken, gimme some time to fix, pinnacle videospin is CRAP. It removed all of the audio, didn’t doublecheck beforehand :/. Do you know any other free video editing tools for windows?

Edit2: Enjoy it as longplay, video spin won’t render the remaining audio no matter what i do.
I will re-edit and upload it when i found another tool

Enjoy

This is the second post I’m making about the game I made this LD – not been very active on the blog due to the website having its problems. I did tweet a lot, though.

I was very determined to do better than my previous entry this time – which I feel I have accomplished.

What went well:

• Really happy with my tile work. This went a lot better than I had hoped.
• The light/particle-stuff worked well.
• My sound-system worked well.
• Things were in general pretty smooth.
• I even made a title-screen that looked fairly decent

What didn’t go well:

• Level-design. I need to learn how this is done best. I believe that the first two rooms were decent – they did their purpose. However, the other rooms were garbage, and not clever at all.
• There’s no ambient light in the game – several people have complained about not being able to see the player.
• Giving too few instructions. I haven’t decided if this is a real problem or not — it is the kind of game where I want you to search around, and try different things. Some people didn’t bother, and some got genuinely stuck.
• Spriting. I gave up making nice sprites, and just left in the placeholder sprites temporary sprites I made in the beginning of the competition. I need sprite-practice.
• I took a shortcut on a couple of textures, and didn’t make them the power of two — that was silly, as some people got artifacts. (Hint; One of the textures is the title-screen)

Those who completed my game have been encouraging. I think I could create a larger game, based on this idea. It’s further down the road, though – since I have other plans.

Can I do better? Yes I can, just check out my performance on LD22.

Timelapse;

Screenshots;

This weekend I shall start polishing my compo entry, Viral. I’ve been closely watching the comments/suggestions on my entry page and my post-mortem and add in most of the suggested items from that list.

The List

• Moving from Flash CS4 to FlashDevelop IDE – As suggested in my post-mortem
• Massive code clean – Way under commented, over copy-pasted, too much last-minute-hacking-please-let-me-make-the-deadline
• Bug fixes from my known bugs list on the entry page
• Art pass – Make everything look less programmer-art and more spiffy
• Sound pass – The music works, but a two bar loop is just silly
• A win condition – Not entirely sure what this will end up being quite yet
• More levels – Possibly a random level generator
• One more ability for the player
• Balance pass – Make the abilities that don’t work well, work better

I think that is it. I estimate this will take more than a weekend to complete, unless I want to put myself under the strain of another compo again so soon.