Well, the dust has settled, so it’s time to do the good ol post-mortem writeup for my game, One of a Kind.

I actually have quite a bit I want to say, so I’ll probably be splitting this into two separate posts.  This one will have the basic what went right and what went wrong and what I learned, etc., while the other one will be longer, more ranty, and more of me expaining my development process, how the game came about, and some comments on the levels, art, and music.

Anyhow, without further ado:

What went right

Choosing an easy-to-use framework.
Although actually deciding what to use was a whole separate issue (more on that in “what went wrong”), once I settled on using C# with SDL.net, coding went really smoothly for the most part.  I just really like coding in C# with Visual Studio…it’s fun, there’s nothing that bugs me about it, compile times are super-quick, it makes a lot of sense, and when I screw up and run into a crash, I can debug it in almost no time flat.  It’s just a really nice language to work with.  Granted, I haven’t worked with other things like Python, Flixel, Unity, etc etc much so I don’t know about the other things out there, but I acn say for sure that I’m super-thankful that I chose C# over C++ with SDL, which was another option I was considering.  I’m sure that I would have just run into some stupid thing that would take me a long time to debug, or I’d have to think really hard about how I want to structure my game engine and who takes ownership of the allocated entities and you can’t delete them yet because they still need to do things, blahblahblah.  It’s just simpler in C#.  One small caveat is that I hadn’t actually used SDL.net before this, but luckily it turned out to be really straightforward (90% of the time, at least), and despite the somewhat lacking documentation (compared to vanilla SDL, at least), I was able to do just fine.

Messy Coding.
Now, don’t get me wrong here…I am a programmer who really, really places code elegance above almost all else normally, but when it comes to Ludum Dare, that totally just goes out the window.  The trick is to know what you can make messy and what you should refrain from making messy.  Most things you can safely get away with making messy because you know you’re not going to have to look at that code again.  But things that you -will- have to work with again, shouldn’t be quite as messy.  In any case, I had a whole bunch of public static variables, and even worse, I just intersparsed a bunch of them throughout the class, probably right before the function that uses them.  So it looks kind of terrible, but it streamlined the process and I think I struck a very happy medium where I didn’t go overboard on messiness to the point where it caused any issues.

Mood and atmosphere.
When I saw the theme “Alone” I knew that it was more of an atmopheric theme, and didn’t really give you any game mechanics or anything right off the bat.  And I knew that making a 2D platformer would let me create the mood I was going for, so I did that.  After that, it didn’t take much brainstorming to come up with the core mechanic that would fit the theme.  In any case, even at that point I already kind of had a vision in my head of how the game would look, feel, and sound (this was probably heavily influenced by The Company of Myself).  And everything including the art, music, even the narration of the instructions, was informed by this mood/atmosphere goal.  In the end I think this is the area where my entry shines and it all came together really well.

Time Management.
It was a great feeling to be a couple hours away knowing that all that was left was basically just some more levels, packaging, and some finishing up.  I already had my concepts in, my gameplay in, and even the music and sound and art style was all in.  I had even already programmed the ending in–I just needed a way to trigger it.  So there wasn’t any real rush to finish any features when it was coming down to the wire.  I also found that it was nice to work on level art and such other things while you were stumped trying to come up with new puzzles or mechanics, so you wouldn’t waste time.

What went wrong

Distribution.
Oooh boy.  Yeah, getting this thing distributed was (is?) way more of a pain than I would have liked.  It’s not like my usual C++/SDL setup where I know exactly how to make things work on Windows, Linux, and OSX with the least amount of additional dependencies.  This is C# with Mono, which…well, is already just asking for trouble in the first place.  Even my windows build ended up requiring the .NET framework, so I had to recompile using Mono, and even after that I stupidly forgot to include a .dll file.  The Linux and OS/X battles were much tougher to wage, and even then only partial victories have been won.  I guess I can see why web entries are so popular.  Anyways, the bottom line is that even though I knew that C# with SDL.net would run in a development environment on all three platforms (I tested that as my bare minimum requirement for choosing the language), I hadn’t had any experience distributing using this framework, so that was a pain.  Of course, I could have figured it all out earlier, but…

Being unprepared.
…I didn’t because I came into things just totally unprepared.  My initial ideal plan was to do a warmup game the weekend before LD, use that to decide how good of a framework C# with SDL.net actually was, and figure out how to port it to Linux and OS/X.  If it didn’t work out well, I might even have tried to make a test game in pygame, as that was another one of my possible choices of framework.  Unfortunately, real life, christmas letters, finals, and everything else happened, so I was stuck not having had time to do any of these things beforehand.  I had -barely- done enough work to decide that C#/SDL.net/mono was a “potentially okay” way to go.  On the plus side, I had done some good reading and thinking about fixed timesteps and framerate stuff, so I didn’t waste any time during the actual compo thinking about that (I ended up using a fixed timestep, and not limiting frame rate…I don’t think SDL.net lets you use vsync).

Puzzle design.
This is the one that had me banging my head against the wall.  One bad thing about coming up with a new puzzle concept is that you have no idea how interesting or not interesting it is, and you have no idea what kind of puzzles are even possible, let alone how to design good challenging ones.  So I definitely spent long chunks of time just trying to think of puzzles that I could create using the base mechanic.  And I think this is the weak point of my entry too–although the puzzles aren’t bad, they aren’t -good- either.  I think my friend said it well when he said there were never any “aha!” moments; it was more just going through and deciding what to do next.  I liked the fact that I came up with the reflection concept, but unfortunately that was so late in that I couldn’t really flesh it out with more levels.

Overall, how did I do?  Fantastic.  I’m super-pleased with my end result, and really happy that I was able to actually make a 2d Puzzle Platformer with this kind of style.  It matched my vision almost perfectly, and is just really good at cohesively establishing a mood.  And I love how polished everything in my game is–it doesn’t look like it was just thrown hastily together with simple placeholder art.

What did I learn?  hmm…well I learned how C#/SDL.net/Mono tends to work…easy development, “possible” to run cross-platform but really more difficult than you probably want it to be.  Next time perhaps I’ll try a web game…

Diamond Hunter Download

Diamond Hunter is a 2D Snake Clone.

You must collect so many Diamonds you can.

Its my first game!

Please rate and comment

Since you all enjoyed having the chance to rate some really nice hidden gems in my last posting I thought I would dig up a couple of diamonds in the rough for you as well… ones that have really unpolished graphics, or were first-time LD entries, or even better by people who have *never* made a game before, but still show real potential even despite their flaws.  Since I don’t have a lot of time before work though, I’ll leave you with just this one :

Alone?! – by SamuraiOfHoly

The graphics and sound obviously leave a lot to be desired, but on the entry page you’ll see that this is SamuraiOfHoly’s first attempt at making a game ever.  Bearing this in mind, I think you’ll agree that this is a valiant first effort!

Tonight, after I rate more games, I may have a few more of these to share.  In the meantime, give some love to the new blood coming into the game world!

I worked by accident on a soccer powered beat’em all.

You can play it here !

Please play it before reading this because it spoil a part of the game

A/ Genesis

First I want to say that the “Alone” theme was very difficult to handle. It’s hard to imagine new features for a game without adding new peoples, or monsters. Each time I could imagine fun stuff to add  it was always a step back on the “Alone” theme.

Initially I decided to work on a peg solitaire version. I was thinking that adding ninjas, a lot of bonus and special fx could make it interesting, but… the core game was still very boring on the first prototype.

So I tried to find the game stereotypes were Loneliness would be a real paradox. When Soccer came to my mind, I said it out loud and we had a good laugh ( I was working with deepnight, valandre, cardus and 01101101 ) It seemed like a good start.

I designed the soccer stadium and the bases of the soccer ball and players. I had to work on a false soccer player AI, good enough to make the trick for 10 seconds… They are not very good at it ! Always pushing the balls behind the goal or leaving the field..

The goal was to make everybody vanish after 10 of play to leave the player… alone. So I could fulfil the Theme.

But I was still failing to make it a game without adding monsters or peoples. I was thinking about opened drain covers or nails, that player should dodge… But it was not very exciting gameplay. I didn’t want to loose too much time, so I started to draw background of the city outside while thinking to the problem.

I finally bring myself to break player’s loneliness with sweet bouncy blobs, so he had something to burst with his soccer ball. Well I dont regret it, shooting ball at blob’s face was fun enough to make the core gameplay.

Here’s the timelapse 

B/ What went Right

- No Generation ! I did it ! All the backgrounds are 100% handcrafted ! No random flowers on the side of the road, no random clouds flying in the sky ! Well I’m not sure that was the best choice, but it was very refreshing to work this way !

- The public of the stadium : With just 3 animation and 2x color sets I could render a crowded stadium. Fast and efficient !! ^_^

- Focus : I could work concentrated for almost 37h. I think that taking care of my sleep on the past week helped a lot.

- Intro / GameOver / Ending screen : I started to experiment them with my first LD and I’m now able to achieve this task in a very short time. That’s all thanks to the Lumdum Dare experience !!

- MathMusic  ! That’s the terrible music you can hear on the title screen, here’s the part :

C/ What went Wrong

- I spend to much time to find the main idea. I used to spend only few time on the past LD events ( 30 min – 1h ) so it was very disturbing to watch time pass and not being able to write any line of code. It may be good to take time to find a good idea but too much make me feel nervous, and I finally lost my self confidence.

- SFX : I was thinking that 1h would be enough ( thx to Bfxr ) but I finally spend 4-5h to import a lot of sounds with differents pitches ( 3x different foot step, 3x different bounce sound, 3x different public voices etc ). I was an uncreative and boring task. I don’t even know if the game was really needing it.

- English language. I spend huge time to google each of my sentences to check if their grammar was ok. And I only have 10-12 lines of tutorial & ending… My slowlness and lack of imagination dissuaded me to use my text system in the game ( “Hello blob ! How are you ?” )

- I was far too unsociable. On sunday I didn’t take time to speak ( not a single word ) with my friends who were working on their LD22 entries, I didn’ even took time to test their game even if we were working in the same room !

- Control : one of the control feature is very hard to explain : You can press spacebar one short time to attract ball to your position. I could not achieve to explain it to the player so they could use it

Play/Rate

Stray Whisker Here!

When the theme was announced I was lucky to get an idea pretty quickly. Since kittens had been another candidate I had already been thinking about games with cats and so I decided to create a game where a kitten was left alone to fend for itself until the player was able to find others. I started making the game with no idea of how it would actually play in the end. I just concentrated on making the game as fun as possible to just move around and be a cat. I didn’t consider any goals for the player, and even in the finished game I don’t really think there’s really a “goal”. There is an ending. I just wanted to make a game where you could play as a cat. And in essence, that’s what my game is about. It’s about pretending you’re a cat, jumping around like a cat and being a cat. If people find enjoyment in simply moving and interacting with the objects in the world, then I think that the game achieves this aim. In a way, it’s like being a little kid playing with a toy figure outside, except instead of a toy figure, you have a virtual one. You can “win” the game in a very very short amount of time, but I would expect (“hope”) that people would spend time exploring the world and jumping around.

If you haven’t played the game yet you can Play And Rate The Game Here: http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=3289

It would be good to play it first since the following may contain spoilers.

With these things in mind, here is my short post-mortem:

Things that went well

• Graphics and cat animations. I rarely do graphics for my games. I usually partner with someone else and I’m the code monkey. So I was pretty happy with the graphics I did in this game. I started out doing “rough sketches” for the cat and buildings, however I liked the style and so I kept them for the whole game. Many people have asked me what tablet I used to draw the sprites with, but I actually just used my normal mouse. I have a large mousepad so I was able to do large sweeps to get natural curvy lines such as in the trees. I felt that the animations were quite fluid and I’m happy with those.
• Visual ambiance. I wanted there to be a lot of “stuff” to play with in the game and I think there is a fair bit to do such as smashing pots, playing with the ball, wind particles, leaves, grass, water, butterfly, etc. I would have added more of this if I had time (rubbish, rats, more ‘junk’).
• The red ball. I am very happy with the movement of the red ball and I think it’s a lot of fun to play with. Some people do find it hard to move exactly where they want, which is understandable. I find it easier myself because I spent so long playing with it while developing the game. I would have probably tweaked the movement a little so that you didn’t have to throw it around so much to get it to go where you want it. One thing I really love about the red ball is that nobody ever says that you need the red ball. Yet almost all of the players I have seen play my game attempt to take the ball as far as they can to the end.
• The Cat AI. I’m pretty happy with the AI of the cats that you come across. They weren’t meant to follow you constantly, or be completely random, and I think they’ve got a good blend. The AI of the cats you encounter differs slightly (the blue one is a bit more ‘sporadic’) but they both switch between moving randomly, following you and following the ball. Some people found the other cats annoying when you’re trying to move the ball – but I think they’re fun. They want the ball just as much as you!
• The cat movement. I think it’s very fun to just run and jump around, with no particular goal in mind, and that was one of my aims for this game which I think I’ve achieved.
• Level Design. I designed a lot of the game in a way which hopefully also explains the player’s abilities. An example of this is when you encounter the red ball. There is a wall directly in front of it, indicating that the ball can indeed be thrown. I also was quite happy with the placement of certain “triggers” such as when the first cat starts following you. Having watched people play the game, they all seem to do the exact same thing. They stop when they see the blue cat… jump up and down for a bit, trying to get its attention, and when they finally give up and think that the cat won’t follow them, they walk off to the right and the cat jumps down. Similarly the interaction with the dog forces the player to jump over it to dodge it, and the lack of buildings makes it a true chase.
• Focused effort. I put a real good effort into this game and I think it really paid off. I really did spent most of the weekend on it apart from a couple of a parties at night. And I even went crazy and pulled an all nighter on the last day until 7AM in the morning!

Things that could have gone better

• Only one ending. I had originally designed the game for two endings, one with the girl and one with the kitten friends you have made. I was hoping that the player would have then been faced with an emotional decision to choose between the cat friends they had made and the girl, their owner. I wasn’t able to implement a second ending for a couple of reasons: I created the girl’s ending first, and after doing so I found it very difficult to work out where exactly to place the alternate ending. Should it have been when you walked into the kitten den? The problem with that is that then the secret (where you take the ball to the kitten den) would not have worked, as it would have triggered the alternate ending first. The second reason I didn’t put it in was of course, as always, I didn’t really have time to do it. In the end I compromised with one ending and one secret.
• Variety in the backgrounds. I had hoped to have every single object (primarily buildings/trees) uniquely drawn. I did pretty well with making the trees unique, but there were only 3 building types which I duplicated many times throughout the game. Again the reason for this was time, and a bit of effort. The buildings weren’t really that hard to draw but I had to complete other more important tasks.
• Music. There was no music or ambiance in the game. I spent some time (as you can see in my timelapse) mucking around with FL Studio to create some ambient music. I didn’t finish this and I didn’t use any music in the end as I felt that a bad track would actually detract from the overall game. There is one gorgeous track by FearOfDark that would have suited the game very well I think. However since this is LD we of course have to make everything from scratch. The track is here: https://8bc.org/music/FearofDark/Recovery+%28VRC6%29/ Try playing the game with this in the background!
• Sound. I did some sounds pretty well I think but there could have been more. In the end I had jump/land/pot break/pot hit/dog bark x 3/various meows (in retrospect that is a fair few effects )

If I had another chance I don’t think I would have done anything differently (process/time-wise). I would have changed the above problems in my game, but overall I am quite proud of what I made and I think it’s an entertaining little game for 48 hours.

I hope that this post will help others in developing their games next LD!

Please checkout my game if you haven’t already done so: http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=3289

More than 48 hours have passed since the weekend and I think I now have enough distance to my creation to write a post mortem about it. I will look at different aspects of the experience rather than do a general “What went right, what went wrong?” list. So here it goes:

Design Process

Initially I wasn’t very happy with the theme. “Alone” may seem to offer a very deep and “indie” setting for games, but in reality it limits the narrative possibilities. On the other hand, this is true for almost all suggested themes and may be a good thing (see “Lessons Learned”). Anyways, after my two past experiences with game jams, I tried to structure the design process a little. First, I simply wrote down the different meanings of “alone” as well as syno- and antonyms and tried to work from that. Next I compiled a table with “Theme”, “Conflict”, “Core Mechanics”, “Pro” and “Contra” with different ideas. “Theme” would set the general framework of the game, while “Conflict” captured what should drive you to play the game and “Core Mechanic” described in a few words what you should be doing while playing:

Theme

Deserted Island

Conflict

Survive and get rescued.

Core Mechanic

Gather stuff, build tools and shelter, make signs to be noticed. Preserve energy, stammina and sanity.

Pro

No need for AI. Wanted to it anyway. Fits theme well.

Contra

Needs graphics. Complex. No experience with these type of game.

The middle contra – “Complex” – should have set off some sort of alarm and it probably did, but I set it to snooze. My next favourite idea “The First(Last) Zombie” would have been a zombie sneaking game where you, the Zombie, would have to get past hordes of armed humans to feed on their young ones. I ditched it because the need for neat graphics, some sort of AI and the overuse of Zombies in general. In retrospect I probably should have sticked to it.

After that, I went to bed (around 4:30 am local time) to let the idea rest. I did not do any code or graphics or sound, which was a good idea.

Code

Overall, I am pretty satisfied with the code. Of course the quality could have been better, but it is amazingly clean for being yanked out in 48 hours. Counting the line of code using cloc reports 1393 lines of Lua or the equivalent of 5572 3rd gen code. That excludes blanks, comments, libraries I used and the code I deleted in the process. I also implemented a tile engine (with automatically computed tile transitions) which I had never done before. This turned out to be a good idea, since it helps speed up the design process a lot, and you can use tools already available for level design (I used the gimp). I will invest some time to learn more about tile engines in the future.

Graphics

Well, what can I say? Graphics are not really my strong point. Diagrams and technical stuff I can do just fine, but anything else is a disaster. Part of it stems from my lack of understanding my tools well enough. I will need to learn how to draw stuff and the proper usage of Gimp and Inkscape (or some other graphics program).

Audio

Audio turned out rather nicely. Though I have no idea how to do music, “Alone” begs for very minimal or even no music. Instead I focused on ambient sounds which I created using Audacity, my crappy laptop microphone and a little bit of bfxr. Making the sounds was a really fun experience, which I hope to repeat next time.

Other Aspects

Because an active mind needs a lot of energy, I tried to eat healthy this time. Cooking the food
also helped to take my mind off immediate problems and to see the big picture. This I will do again. Unfortunately I ran out of snacks pretty quickly. I greatly underestimated the need for this stuff. What I did and probably shouldn’t have was drinking a lot of coffee. It sure helped to focus and stay awake, but once the effects wore off, I felt even more exhausted than I would have without caffeine.

Lessons Learned

The first and foremost lesson I took from this experience is that I need to impose limits. Limits not only on the game design (i.e. make it simple), but also on the inputs and graphics. A LD game should be playable using Gameboy controls, which means two buttons plus 4 movement directions at top. Better just one button and two directions to move. This will have two effects: First, the game needs no real explanation/tutorial, and secondly, the game mechanics have to be chosen accordingly. Graphics wise I will probably use a 16 or less color palette next time. Other lessens learned: Less caffeine; Tile engines are useful; and Sound design is great fun.

See you next time.

I made a video of SOLILOQUY, especially for Linux users which can’t use the Unity3D webplayer plugin.

I’ve wanted to do Ludum Dare for a long time, but for one reason or another kept missing it.

This time I decided I wouldn’t miss it, no matter what happened, I would be doing LD22!

And then my brother’s wedding happened to fall on the first day of Ludum Dare.  And added aspect of complication was that I was the best man and celebrant of the wedding.
Initially I thought I couldn’t do it, I wanted to be quite ambitious with Ludum Dare and create something very polished.  But I’d most likely lose most of the weekend to the wedding and planning it.

So it inevitable I’d have to make a minimalistic, simple, procedurally generated game .

Play the game

Rate the game

Intro to First Cell

‘Alone’ is a difficult theme…

because game design is based around interaction with other entities.  It limits the possibilities of your game when you are meant to be alone.
But I also firmly believe that external limitations bring focus and help the creative process.
I was at the wedding when a friend emailed me which theme was announced.  And I had a good 12 hours before I’d be home coding.  But the entire time I couldn’t think of an idea I could complete in 24-36 hours.
But I had a game mechanic floating around in my head for a while that I had never coded, so I thought I’ll work on that idea, and if I can’t get it to work with the theme, so be it, at least I would be productive.

The mechanic:

The columns on the left are before collision, the columns on the right are after collision

The concept behind the mechanic was a system whereby shapes would morph into new shapes based on the number of corners on each shape.
In the diagram you can see that if a square hits a triangle, they simple swap, same goes for a square and a pentagon.  This is because there is only a difference of 1 in the corner count.
At the bottom of the diagram you can see that a square colliding with an octagon will result in both shapes becoming pentagons.

In essence the shapes lose or gain the difference between there corners when they collide.

But I did not know what the game was going to be, a 2d shooter? a puzzle game? an evolutionary art piece?

A similar diagram but in the case of the triangle collisions.

Workspace:

My workspace during the LD22 Compo

A great workspace, I came to visit my parents in the Blue Mountains for the wedding so I set up my computer //Atlas, on their dining table.

You can see the garden as you code, it’s much nicer than Sydney.

Something I ate while doing the compo.

Notes:

When the reception was over I got home and started coding straight away, probably about Midnight.  I decided I’d get shape generation working first and assumed I’d figure out how to turn it into a game as I went a long.

Here is my notepad file which I used to brainstorm as I coded:

-----------------------------------------------------

acceleration increase when collide
friction over time
interaction keeps the system going!
ENTROPY > lonely?

Initially nothing moves, but you bump into it, and it brings the world to life!

mist, and prisms!

darkness, you emit light!

when you accidentally bump into an object, it slightly illuminates and begins to move, but will
slow down over time unless it collides with something else.

this sets of a chain reation, lighting up everything!

sounds to represent this change!

the shapes change when they collide.
You need to be a certain shape to fit through certain parts of the world

NO lighting - too hard

just use shades of flat colour.

Lighting actually easier than expected.

1.Wake up your friends
3.Become a goal shape
4.Avoid
5.
6.Eventually create a fish creature out of composite shapes.
7.Cell replication?

-----------------------------------------------------

So the fish creature didn’t happen and I had a few problem with collision along the way.
I really could have benefited from setting up a simple simple engine beforehand to save me from figuring out simple issues.  Next time I’ll know and maybe try out Flashpunk or Flixel or lwjgl.

Alone – Aha Moment!

There was a moment where I realised how to make this game that was fairly interesting I literally stood up and did a dance.  It was a great feeling.

Timelapse

can be found here.

Gameplay Video

can be found here.
What worked, what didn’t, lessons learned.

What worked:

I like the aesthetic, I like the game mechanic, I feel the game is really fun.  It is just kind of arthouse and obscures how easy it actually is to play.

I accidentally made the game quite in depth.  Because there is a system behind the game there is possibilities to master that system, and also for emergent gameplay to arise.

Blending modes in AS3 are great.  The red glow has this brilliant effect of creating silhouettes of shapes around you, it’s almost like a sonar.  It dissipates over distance.

I really like the sudden flashes of light at the beginning of each round, combined with the thunder.  The sounds in general work very well, and even though most people didn’t understand how to play(my fault), they all seemed to enjoy the mood of the game.

I showed a few friends, and after explaining to them how it worked they contacted me later saying they have been playing it since and really like it, and that they actually find it quite addictive because it has no precise ending(muahaha!).

Blending Modes in AS3 are really powerful.

What didn’t work:

It is a dark game, it is also not a recognizable genre, it is abstract.  So that means I had to fight for the players commitment.

To see around you all you have to do is move.  The trouble is the timid uncertain players will probably not move.  It is a game where you have to remember where each shape is and navigate there quickly before the shapes change.  But that isn’t communicated, that is only observed after playing a while. If you sit there, everything will go dark and your opportunity to hit the once shape you need will escape.

I don’t like the fact that it isn’t accesible.  A few hours after the submission time I added some in game help and made the glow colour red to help differentiate the player from the other shapes.

But really the nature of the game is that it is abstract, and it is hard to have pure aesthetics and also accessibility.

Lessons learned:

Play testing is actually important?
Submit now, test later?  It doesn’t work.  If you are lucky you will get 10 reviews from users, I had 3 within the first few hours of submission.  Their feedback was great, it helped me make the game a lot better.  But they were judging the game  based on that snapshot.  Probably best to test on people that aren’t going to affect your score.  It’s good to get a friend to ask their friends what they think, they will be more brutal when they aren’t saying things to your face.

In game help is actually important!
Sure have a blurb, on your website, but a lot of people prefer to download the binaries.  People also often skip reading the help, because we always think we will understand things immediately.
Have in-game help and make it unavoidable.  I made my help context sensitive, so if the player was going well, I wouldn’t give them hints.  But I think you can take that a lot further.

Have a tutorial, or some kind of learning curve.
I really really wish I went down the route of levels designed to teach the mechanic and the concept.  I think of the first few stages of Osmos and how short that tutorial and how it so smoothly bleeds into the game.
I also think about Miyamoto saying to never blame the player if they don’t “get” your game.  It is always the game designers job to work around that, to communicate better.

Ludum Dare is more work than just the 48 hour jam.
    I am sure a lot of the veterans know this, but once you submit your game you should rate and review other peoples games.  You should probably have created a time lapse, a game play video.
You have a short period of time where you can make subtle bug fixes, so you are actually working a lot after the competition.  Uploading, testing and dealing with the consequences of doing a 48 game jam.

Assume nothing!
    I assumed that people would just assume (double assume!) that you used the arrow keys to move.  But when I tested some people tried to accelerate with space bar, some people used WASD, some people tried to use the mouse.
So I ended up adding a lot of alternate control schemes.

Uploading takes ages.
Especially  in Australia.  The site couldn’t handle the simultaneous uploads so we were given extra time.  Without that extra time I wouldn’t have made it in time.
I suggest upload your resources and other larger files early on, you will most likely only be changing source code.  Then you can upload a single zip file after the competition is over.  That way you cover all bases.

A lot of my favourite games…

are Ludum Dare games, and as a game development student I use them all the time as game design and code examples.  I tried to encourage friends and other students to participate and maybe they will next time.

I am actually honoured to have submitted a game alongside so many creative and talented people.

Shapes illuminated at the start of a round.

Thanks for reading the Post Mortem, I hope you play the game, and I wish you the best.

Cheers,

Canyon

Play the game

Rate the game

La instalación fue fácil, sólo apareció en el CD-ROM y hacer clic en el icono de instalación. Después de abrir el paquete de software lo primero que debe hacer es asignar mi tarjeta Digi 001 como la tarjeta de sonido de audio para ser utilizados por Traktor. Artículo recomendado por Traktor

I really have to say, I had a great time participating in this Ludum Dare, and first of all, I want to say I’m gonna do it again! LD is such an awesome experience!

I was surprised I did not have much problems during the development. I couldn’t code on saturday, but that was not a problem after all.

This game btw

What went wrong:
- Sound. I planned to make a music and add some sfxr’ed effects, but when I was done with coding, it was already monday here in germany, and I had to write a test this day. All in all I got 3 hours of sleep, and did not feel great that day. But I don’t regret anything. ^^ Anyway, sound is something, I would have liked to include. In the post-compo version, I added it.

What went right:
- Planning: I used 6 hours of saturday to write everything on paper. This of course gave me the opportunity to develop with a full concept of how the game should be, which resulted in enhanced coding speed!
- Discipline: I got up at 7 am in the morning, and coded nearly straigt until midnight. But I drunk way to less, just one and a half pot of tea for the entire day!
- Gameplay: The gameplay developed amazingly nice. I did plan how to make the game, how it would be was unknown, in my opinion, the gameplay is quite nice.

I had a todo-list, which gave me motivation, each time I completed a point.

P.S.: Many thanks to Notch for bringing me here with his timelapse videos! (Metagun!!! Breaking the Tower!!!! Bunny Press!!!)

Just like manual PvZ

So I had a lot of issues with the recording… first time I’ve done this sort of thing and all :S

Ended up losing a bunch of the data. Very annoying but ah well.

Check it out anyway! The best bits were the ones that I lost …of course

video link

my entry

until next time!

Here’s the actual game page.

What went well?

1. Preparation

I spend the two weeks leading up to LD22 learning how to make simple models in Blender. I’ve never had much more than a passing knowledge of Maya or Max ( I could operate them, but not build anything ). Despite making games professionally for 10 years there had always been an air of mystery about how artists actually realised things in these packages. Turns out there is no mystery at all. It’s really straightforward, that’s not to say I’m a good artist now . Anyway, having that experience meant, I knew what I could build and how to build it. So there was very little learning in the 48hrs, I could just get on with it.

2. Knowing the engine

I wrote a significant chunk of the PlayCanvas Engine, so I know it pretty well inside out. Not only that, but the engine is written in javascript, so I could step into it and debug from game-code into engine-code with no added steps. It’s incredibly helpful not to be using a ‘black box’ engine, you can always see exactly what is going on.

3. Tools

I’m very big on tooling for game development, and I think it’s critical to have great tools. The PlayCanvas tools did well despite being early in development. Having simple features like Undo/Redo is such a time-saver.

4. Rapid deployment

I could deploy my game in a couple of seconds and have it ready-to-play by anyone. If there had been an extended packing and publishing stage for me to complete I probably wouldn’t have got it out by the deadline.

What didn’t go well?

1. Physics and Collision Detection

Collision detection and physics is hard, not only is it hard to comprehend, but it takes long time to debug and get stable and working. Trying to do 3D collision detection and dynamics in a 48 game jam isn’t very sensible. Still I got it mostly working. I had to remove some bits where you could jump gaps with the ball because the physics wasn’t stable enough. Next time I’ll either do something without complicated physics, or hope that there is an existing stable implementation. If you’re interested I used verlet integration.

2. Tools

Tools are so important that when they have issues, it can really slow you up. Some features of the tools were slow, and it cost me a lot of time to make small changes when it should have been quick. But on the plus side, I now have a big list of bugs to fix.

3. Audio

No time, no skills, no audio. I really wanted to go out and record some grinding stone noises to add some flavour to the movement, but I just never had the time.

4. Timelapse

I wanted to record a timelapse, I did the first day, and them somehow failed to start recording on the second day, dammit!

Conclusion

This was my first Ludum Dare, though I followed the last one with interest. It was a fantastic experience, I’ll certainly be doing it again, and next time I’ll be even better. Sitting in on the irc channel was also really fun. This is a great community of people sharing, helping and really pushing forward games development.

Also this was the first real test of our HTML5 engine PlayCanvas, and I think it did pretty well. If you’re interested in trying it out I’d love to help you, drop me a mail dave@playcanvas.com.

Good

• My zombie! I’m really proud of my ugly zombie. Yes, I spent a lot of time on it and it isn’t good art by any standard but I don’t care. It was worth it to see it “alive” in my game
• I only realized that after I was done but I kind of made the game I wanted to do for December 2010′s LD. Except then I had found myself making an alien instead of the zombie I had planned to do and then gave up before I had gameplay anyway. So it’s like I tied up a loose end.
• The jam. If not for the jam I wouldn’t have been able to finish my game and the LD would have just ended in bitter disappointment for me.
• My trusty ZBrush was awesome: sculpting/painting the zombie was the most fun part of this LD, Blender was also great for animating it.

Gray Area

• Making the low-poly retopology took more time than I thought. I tried TopoGun which I had just bought a few days before the compo and never used.  That added a few hours of work but then TopoGun worked really well for generating the color and normal map from the sculpt.

Bad

• I missed the compo deadline and had to do the jam
• I was generally not very fast. Lack of concentration maybe? Everything seemed to take just longer than it usually would.
• I spent the same amount of time on the environment than on the zombie and yet it really doesn’t show.  I just wasted time noodling with bits cut from my original hallway model and just made a mess and had to restart again. It was a time sink for no reason.
• Simplistic gameplay. I wanted to make the game more about stealth.
• I still suck at using Modo. It’s a great software I have no doubt of that and I mostly knew how to use it. But somehow I still find myself struggling against it every step. I don’t know how to explain what it is exactly. It’s weird and it’s probably just that I lack the practice to have the right instincts but it’s really annoying when trying to speed model and everything reacts in a slightly unexpected way and I keep having to undo and try again. I’ve got to spend more time using it.
• Still no time for particles effects. I put them on my priority list for this LD and still neglected them.

Time use

• Code: 11.2h (includes setting things up in Unity)

• Model: 9.3h
• Texture: 4.7h
• Animation: 3.5h
• Sound: 2.4h
• Level building: 7.6h (half of it wasted on a discarded version)
• Sleep: 24h
• Doing other things: 3.4h
• Misc: 5.5h (probably 50% actual work the rest being posting WIPs, chatting on the IRC channel, etc)

• Total spent on zombie (including sounds, code, etc):  15.5h
• Total spent on the environment/level (incl. medkit props and ambient soundtrack): 15.4h

I had time to add the alternate ending and the credits, I did a few minor corrections/tweaks and I quickly made a real page to house the game

Also I would like to thank everyone who played the game!
We’re receiving a lot of positive feedback, that’s really appreciated, so yeah, thanks guys!

Here you go, enhanced version:

Click here to play my game: Paper Town!

Developers often do a “Post-Mortem” after completing a project, exploring the things that went right and wrong. This helps them keep track of what they’ve learned and also help other people who are going to try the same thing.

What went right

The Story

“Alone” is really a mood theme, rather than a mechanics one, and that had me a bit stumped at first. All the neat “physics” and “sim” ideas I had in my head needed to be thrown out.  The gameplay was to be a slave to the story, which is pretty much the inverse of how I usually think.

Right from the beginning, I had toyed with the idea that the protagonist is not literally alone — just that he feels alone.  Paper Town takes that the next level and places the player in the mind of someone who is psychologically damaged and is living in a world where he perceives himself to be alone and can’t recognize the presence of people around him who are trying to help.

I believe it’s an idea that can resonate with a lot of people. You may feel lonely, but at the same time you pull away from other people and avoid talking to strangers.  This explores the extreme outcome of that:  The character will in one line of dialog lament the fact that everyone has left him, but in another line of dialog scream “LEAVE ME ALONE” to the nebulous entities that sometimes appear.

It’s through the development of the story via note pickups that the character finally gets a chance to recognize that his solitary universe is self-inflicted and that he can break out of it through a true desire to be with other people.

Unity 3d

For a lot of people, the spirit of Ludum Dare is to build everything from scratch — or as much as is possible without implementing your own programming language and basic library of functions.  However, I very much wanted to build a complete game and starting with a fully functional gaming engine went a long way towards ensuring that.  Being able to drop in primitives and start programming behaviour 5 minutes after deciding on an outline for my game was incredible.  Not having to worry about how to load images and sound, nor do physics, was likewise amazing.  Also, having access to some great pathfinding middleware was also exceptionally helpful, though it brought its own problems (see below).

On the other hand, since my challenge wouldn’t be about the base engine, it means that I had to make certain that my execution of the theme was top notch.  I wanted to tell a complete story, and I wanted to make sure that there was a way to win and to lose the game.  I think it takes about 10 minutes to win.

I didn’t have the time or the ability to do any 3d modelling, but I did as much as I could using pure primitives (cubes, planes, spheres, and capsules).  I’m also pretty keen on my moody lighting effects.

Time Management

While there are certainly things I would have liked to have gotten done if I had more time, I actually didn’t feel very rushed during the 48 hours, and I think a lot of it had to do with having a solid time plan right from the beginning.

The theme announcement and start of the competition was at 9:00 PM my time on a Friday, so that evening was all about coming up with the idea for the gameplay and story, and to setup the initial environment in Unity (terrain, character, a simple building, and the ability for the player to click/pathfind around the obstacle).

Saturday was planned to be “gameplay” day. I generally didn’t worry about the actual looks/art.  The game just had to be playable, and by the end of the day all the major gameplay features were present:

• Randomly generated city, including 4 types of buildings, streets with intersections, lightposts with actual lights
• Enemies that would spawn, patrol around, and chase the player if they saw him — dealing damage if they got close.
• Pickups for the player, which would be stored in inventory
• The ability to create a “paper doll” with the right items. A “paper doll” is a turret that shoot bullets at enemies.

Sunday was planned to be “story development”.  I know it may seem weird to play on having 50% of your time to do all the “real” features and 50% of the time to do “fluff” and polish, but in practice the big features don’t take that much time. They’re often far more straightforward and easier to understand. It’s the fine-tuning that can be really time-consuming, but it’s also the thing that truly sells your product in the end.

I think my final story is a bit cliche and maudlin, but still works to really sell the theme.  This time allocation meant that I was also comfortable spending time making sounds and intro/end screens, which I think are an important part of the “complete” package but often get overlooked in the face of adding more gameplay features.

Things I did on the final day:

• Redid city generation (it was crap and the road/fence were very crap)
• A dialog system, allowing the story to be told during gameplay (and also to explain gameplay mechanics as they come up)
• Added a new pickup type: Notes. These are used for the victory condition and also trigger lots of dialog.
• Changed player to WSAD/Mouse movement
• Fiddled with the pathfinding multiple times
• Rebalanced the enemies and pickups multiple times
• Added a day/night cycle, which looks good and controls enemy spawning
• Intro screen!
• Win and loss screens!
• Sound effects!
• Music!

Food and Drinks

Lots of good, satisfying food at my disposal.  No junk food, and nothing that would leave me with messy fingers. Also, everything could be prepared in just a few minutes, minimizing downtime.

Meal examples:

• Bacon and Eggs
• Avocado with Sriracha hot sauce (sooooo goood)
• Tuna salad
• Leftover ground beef/veggie casserole

Note that these are low-carb, high fat foods that fit into my Keto diet. If someone on a standard diet ate like this for 48 hours, they’d probably feel a bit foggy-headed, which wouldn’t be ideal for the competition.

Live Streaming

This was by far the single best choice I made with regards to Ludum Dare.  Having hundreds of people watching me all weekend kept me motivated and entertained and provided me with a veritable army of beta-testers!  I had to create all the game code and content myself, but having people provide immediate feedback was invaluable.

All the videos from the stream should be available on my Twitch.tv account, starting with this one.

Sound

Many Ludum Dare games don’t have any sound, or at best just include a few bloops and bleeps generated with a tool like BFXR – which was absolutely my plan too.  However, in practice I really wasn’t happy with these sounds. I felt like their arcadiness took away from the mood of the game, and I’d just about given up on the sound (which was already an Final Hour job)…but my stream viewers made a case for the importance of sound and music. And I’m happy they did!

So I went to Plan B for sound, which was simply to use my microphone. Sound effects for item pickups came from flipping pages in a book (Python & XML in a Nutshell), and music came from something I’ve never done before: Me playing an instrument in front of an audience.  I played a few bars of some badly off-tempo blues scale on my harmonica and then slowed down the recording (which also lowered the pitch). The result is a haunting soundtrack (with two songs) that – while far from good – is way better than no sound at all.

What went wrong

Pathfinding

One of the resources that was in my toolbox even before the theme was announced was the great A* Pathfinding middleware by Aron Granberg.  It’s a very simple drop-in solution that makes it pretty easy to add basic pathfinding to a project.  I like to use it by attaching an empty “pathfinding target” gameobject to my units and just moving that target around to make things happen.

Unfortunately, I ran into some limitations with the default way of using the middleware that caused to pretty serious problems and almost wrecked my whole idea.  I wanted a fairly large city for the player to explore, but the combination of a large area with the need for a fairly fine pathfinding grid (to be able to maneuver around furniture around buildings) meant that we were generating far too many nodes and Unity would crash.  After some fiddling, I was able to find a compromise between city size (3×3 blocks with 2×3 buildings each, for a total of 54 buildings) and grid resolution. At that point, things seemed to work pretty well until I started balancing the game.

It quickly became apparent that I needed quite a few enemies to appropriately populate my relatively large city space, but as I increased the number of units my pathfinding system started to lag.  Luckily it’s pretty intelligently designed, so the actual game performance was unhindered, but the pathfinding request queue was taking longer and longer to get through.  This wasn’t necessarily a problem for the AI, since it’s not the end of the world if it takes them half a second to change to a new path in response to stimulus (it just makes them a tad easier to juke).

For the player’s mouse-controls, however, it was a big problem.

Mouse Controls

One of the first things I added to the game was a click-to-move functionality.  Reasons for this were varied, but a big part of it was a drive for simplicity. I wanted a game that was utterly intuitive for anyone to play.

My initial approach was to do a raycast from the screen to the ground when the mouse was clicked, which worked great. Unfortunately, Unity doesn’t provide a simple way to eat mouseclicks when the player hits the GUI, so interacting with it meant the player was moving unintentionally.

The second approach was to have the ground react to OnMouseClick events, which worked just as well but wouldn’t be triggered when the user was clicking on the UI. Unfortunately, it also does not trigger if the user is clicking on another model, including my road segments and building floors, so I had to ensure that my “HandleMouseClick” behaviour existed on all relevant objects, including pickups.  This worked okay.  Until I ran into my pathfinding issues.

During the day, everything was pretty good (minus a little funniness due to the pathfinding grid resolution), but at night when enemies showed up, there was a noticeable delay when clicking due to the pathfinding queue being pretty full.

In the end, I gave up on mouse controls and switched to WASD/Arrow controls, leaving the player feeling very responsive.

Raycasting/Line-of-sight

I’d decided pretty early on to make the building outer walls quite low, that way the player could easily click on the ground inside and also not worry about the player being hidden behind a wall (due to my fixed camera angle). This lead to me having to fiddle a bit with my line-of-sight tests with enemies, because they shouldn’t see the player through a wall.  I had to make sure that my raycast was low enough to be blocked by the short walls, but high enough to not get screwed up by the lip around the road or the strange mesh deformity on the player’s capsule model.  It ended up being kind of fiddly.

It would have been nice to put an invisible wall around the buildings and have them block enemy LOS rays, but between the UI, the “shade” block inside the buildings, and the invisible walls I couldn’t figure out a way to allow mouse-click raycasts to get through while blocking enemy raycasts.

Of course, that was all moot by my switch to WASD/Arrow movement, but that change happened way too late in development to save me any trouble with the enemies.

Randomly generated content

This always SOUNDS so cool, but for a game like this I’m not sure it does anything for the gameplay, nor am I sure that it saved me any time.  Yes, placing individual buildings would have been a pain, but I spent so long having to tweak the system so that the buildings and roads all ended up in the correct location that I think it took longer than doing it manually would have.  And it’s still not perfect!  There’s slightly more space on one side of the blocks than on the other.

Even things like Pickup spawns were totally random at first, but sometimes pickups would land on top of objects and be inaccessible to the player.  Ultimately, I placed empty gameobjects to act as spawn points and that worked so much better (I also did this with enemies).

So if I *did* want randomized buildings, without having to worry about getting my placement math right, I should have manually positioned building placeholders and just have them be populated at program start.

Note that I had intended to make my city bigger (which is why I felt that random generation was the way to go), but I had to scale down my plans due to pathfinding contraints.  I do think my final city is a good size for the actual game.

Paper Dolls

The idea that the protagonist has devolved to making paper dolls in order to combat his loneliness came about very early and was meant to be a major part of the gameplay, adding in a “tower defense” component. However, this never came to be and as a result the act of creating the paper dolls and their use in gameplay is rather secondary.  It’s still better than not having them at all (and having the game just be about exploration and hiding), but I think more could have been done with them.

To a certain extent, the weakness of the doll theme is a result of the time limitations with regards to creating more enemy types and behaviours and just general game balance.  I also think that the dolls are dependent on a certain amount of art development — I think they deserve a cutscene for their creation, to add real emotional depth.

Another contributing factor to not further developing the paper dolls idea was the conflict between static, unmoving, tower-defensive gameplay and the need to explore to find notes to advance the story (and win the game). Making the dolls secondary (and have very limited ammo) turned them into something that was just a tool to help you survive a bit longer and facilitate your exploration (and thus completion of the story).

Conclusion

I consider this project to have been a HUGE SUCCESS! I program all the time, but usually I’m making business-oriented web applications.  I have started many games, but I’ve never finished one before.  Paper Town may be rough, but it is a complete game and that makes me extremely happy.

Also, even if the game hadn’t worked out, we still had a stream that averaged 100 people for an entire weekend.  That’s amazing!

I absolutely hope that I can participate in the next Ludum Dare, but I also hope that I can find more time to make games in general.

It’s a little late but here is the post mortem to my competition entry The Lonely Island, which you can find here: http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=3428 .

The plan.

My plan was to make a bit of a survival simulator where you are stranded alone on an island and you have to slowly gather the resources you needed to make your escape. I wanted to have day/night cycles, mountain areas and loads of different items to find and craft. All this turned out to be a little too ambitious though and I ran out of time before I could add any of these things. In the end I had to quickly implement making a raft and escaping before the development time was up.

Day one

The first day went extremely well. I got the tile maps loading and rendering very quickly and made great progress on the GUI along with some of the more important mechanics. I’m not too familiar with AS3 and Flash Punk but most the things I tried to do either worked first time or worked shortly after trying to implement it. Bug’s didn’t take more than 5 – 10 minutes to fix and it started to look like I would be able to add either everything or most things I had planned on, but I was wrong.

Day two

In comparison to day one, day two was a nightmare. Nothing worked first time and major bugs took what seemed like forever to fix. It didn’t take long for me to see I either wasn’t going to finish on time or I wasn’t going to be able to add many features. I started off the day by getting the map scrolling with the players movement, and this caused a load of problems and broke most of my GUI and I had to spend at least half the day fixing everything. I learned a valuable lesson from this though, get scrolling maps in ASAP in the future. After I finished climbing over that humongous hurdle I didn’t have long left to implement the crafting system. After thinking for a while and the most easy and time efficient way to get crafting in I decided to go with a simple combining method for creating tools and the raft. By the time this was done I only had about 20 minutes to implement some simple sound effects and get my game submitted.

What went well

I have never really tried to make a GUI before so I’m pretty proud of the results, even if it is a little crude. This is also my first game from the top-down perspective, which was a nice change of pace making.

What  didn’t go well

Many things. The art, for instance wasn’t particularly good but then again my art never is, I just wish I had some more time to spend on it.
The scrolling maps, as I stated earlier, didn’t go well while implementing and ate up most my time but at least it got sorted out in the end.
My game also ended up being too easy and lacking in features as a result of various problems and the time constraint.

Most importantly, did I have fun?

Hell yeah I did. Making a game to a set theme in 48 hours is an amazing experience and I learn so much each time I enter. Ludum Dare also has an amazing community surrounding it which I am proud to be a part of.

Thanks to WineSkin, I now have a working bundle for osx users to run.  The downside is that it is 155MB, and >400MB when uncompressed, because it contains an entire install of Mono.  Which is really ridiculous.  BUT AT LEAST IT WORKS.  And you don’t even have to install anything!

Linux users, you can also run in Wine if you download the windows version and use “winetricks mono2.8″.  Otherwise, you’ll have to install all the mono + sdl packages and run it the usual way.  I’m assuming Linux 64-bit is still broken but I have no way of verifying this since I don’t have a 64-bit Linux VM/machine.

Main game submission post, again, is here:
http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=7285

Postmortem of “Lonely Island”, my first Ludum Dare entry.

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

The Good

I decided before the compo I would not make a game about killing things (having kids changes your thinking).  This helped me come up with something original (for me anyway).  Okay, so you kill the trees and you kill the fish when you cook it but hey, baby steps.

I took lots of breaks, got enough sleep, and ate healthy.  I think this made a big difference in my stress level.  I wasn’t even feeling that stressed when Sunday came and I still didn’t know what my game was going to be about.

I found an animation template that helped immensely.  My programmer graphics perhaps went from fugly to “charmingly ugly”.  I probably would have spend the whole two days just adjusting pixels to make the guy walk without it.

The Bad

I made the n00b mistake of committing my pre-competition thoughts to either Random Generation or Evolution themes, both having great possibilities.  I never thought Alone would win.  So when it did my mind went blank.  “How can I make an original game about being alone?  That’s like 90% of games already out there.”  I spent Saturday just making a generic game and hoping inspiration would hit me.  That might explain why you saw down trees by umm, punching them?

I waited until late the last night (GMT+1 here) to make most of my sounds.  My kids were sleeping in the next room and I was exhausted.  Not the ideal environment for trying to voice hilarious dialog.  Next time I will do this during the day and leave quiet night-time for coding and graphics.

Not enough playtesting. I got my wife to stop rolling her eyes long enough to try the game a couple of times so that helped.  Myself, I only played in easy mode (everything costs 1 log) to test all the features because building the boat over and over got tedious.  When your own game gets tedious to play after just a few times that should tell you something.  I missed the message because building the boat is still tedious.

Got too used to seeing my placeholder graphics for terrain.  The only piece of terrain that wasn’t created in the first 3 minutes of the compo is the freshwater, which is exactly one tile out of 300.  I should have looked at it with a more citical eye.  Spending just 20 minutes on terrain would have made the game look much better.

The Ugly

Not this time.  It was a thoroughly enjoyable experience.  Can’t wait for the next one!

Here you go: http://www.youtube.com/watch?v=30zRwUFP5Ww

Oh, and you can play the game here: http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=4431

Hi guys this was my first LD and it was awesome, i will be back for more!

Here is my time lapse video:

http://www.youtube.com/watch?v=EsAElyrM-bU

It also was my first time using AS3 and Flixel so i learn a lot. I will try to be more prepare for the next one.

If you want to check my game it is here:

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

Have fun rating games!!