A 2D game: the 1st and 4th dimensions!

Well then…

This was not my original idea, not at all. I wanted to do a mind based conversation driven thing. I had most of the core done, no graphics though, a debug text skeleton of a game. I couldn’t figure out a clear entertaining and unboring goal for it so I scraped it.

Then I went out to grab a late lunch. It was already over 12 hours down on the clock, and I was zoning out looking for ideas half the time. Several hours later as I was walking back through rain the idea hit me. A mind in a mind in a mind.. mindception!

Look! the room is shaped like a brain!

I figured I’d do something different this time and do all the art assets first. In case you remember my previous entries, I wanted to avoid cutting so many corners on the visuals. Only way to do that effectively was to get it nice and pixelly.

First I made the character, which looking back, I forgot to name or even assign a gender to. I guess that’s less relevant in the great scheme of things though.

They see me walkin'

They hatin

I’ve done this, and all other assets in ASEPrite, which is a perfect little tool for it. Needs some work on managing layers but otherwise I have no complaints.

After I got the assets done I began fiddling with the ‘engine’ of the game. I basically made up a sort of scripting language, and made the game interpret it. This is what the ‘empty coals into the heater’ script looks like:

kill crt
add thu 16 2 100 0 3 Frederik:_It_seems_that_while_you_were_turning_the_heater_on_Miguel_took_your_bed_away.
kill tr2
kill bed
add pot 12 0 40 0 1
add hed 15 0 50 0 0
add crw 11 2 100 -40 -1
add hl1 7 0 110 100 3 Miguel:_Your_bed_was_stupid,_but_I’m_hungry._Trade_you_the_pot_for_food.
add ge2 4 0 110 100 2 unlocksecond.txt -1
add fd 7 0 110 80 2 feedfish.txt fis
add sla 7 2 120 50 2 cut.txt swrd
sound coaldump2.ogg

Wasn’t complicated at all but took longer than expected. Making the level(s) took longer than expected as well, but only slightly. I intended to have a puzzle based on the warp mechanic and item drop mechanic, where the player would have to warp in certain spots and pick items up in a certain order to emerge carrying the right item in the right spot. I couldn’t get this right. It was frustrating to the player and unintuitive so I ended up dropping it alltogether. I did leave the steal-the-pot loophole instead and was positively beaming across the room when someone figured out they could do that.

I hate beds because I can't use blankets because I have NO ARMS!

I knew I could make sounds work, and how. I tried that after failing to get it right on my previous html5 entry. Problem was getting the sounds themselves. Well.. not really. My laptop came with a mic, and I had audacity installed. See where this is going? Most sound effects were done by mouth or various objects (like cereal) hitting the desk.

Maybe next time I’ll figure out how to loop music as well.

And that is that.

• I’ve figured out better/different ways to do things
• including scripting
• I’ve  figured out worse ways to do things
• I’ve made a game that some people can easily figure out
• and have fun with
• And some people have trouble with
• and find frustrating
• And some people get weirded out by
• I’ve ported it to android
• And now I’ve written a post-mortem

Overall, not bad.

You can give the game a play/rating by clicking on this lengthy verbose link which you are reading right now.

Hello there ! Even if it was a 6 hours only game jam for me, it was great and I learned some useful things doing it ! I wrote a post mortem on my blog, so if you like to read post mortem or want to know of “Where it begins” works with physic, just go there.

So now that Ludum Dare #23 has finished and the dust has settled, I guess its time to write a post about the post mortem and give some insight into my experiences with making a game in 48 hours…

Here is a diary of the major milestones of my 48 hours highlighting interesting points of my development:

Hour 1

I rushed head first into creating my voxel engine, I was pleased with the announcement of the ‘Tiny World’ theme, it seemed as if this theme was perfect for what I was creating… My mood was great!

Hours 2-6

Still driving ahead with the voxel engine, encountered a few problems with how the triangles and meshes are rendered, so had to go back and improve my rendering engine. Spent a good portion of these hours optimizing how triangles are pushed to the renderer and adding support and features for mesh rendering with display lists and vertex buffers.

Hours 7-9

Started playing around with different configurations for meshes/chunks/regions… came up with some interesting implementations of how a voxel world could look (sphere worlds, cube worlds, trees). I made sure to leave all configuration/ideas in the code so that I could easily come back to anything which worked.

Added support for cubes/voxels with different textures. Using a texture atlas to store the different textures. i.e. (grass, stone, wood, magma, etc) This would be important since I wanted to make a world that could be modified by using different cube types.

Towards the end of day 1

Hit a wall with regards to what my final outcome was going to be… I did have some original ideas relating to a flat, cubed world with tress and houses that you walk around and do stuff as a player, but nothing really inspired me in that respect without completely ripping off minecraft functionality (which I did NOT want to do).

So I went to sleep and hoped to come up with some neat ideas in the morning.

Day 2

I woke up with renewed vigor and some thoughts about a different direction that my game could take. I decided to make it more abstract and not have a player in the world or have any direct user control, instead focus on world destruction and voxel effects.

Day 2 general

The bulk of day 2 was taken up coding effects and voxel related gameplay. I created asteroids and a layering system for my planet, exploding blocks and effects of asteroids crashing into the planet. The vaporize and terraform effect was actually something which came about accidentally, but I liked how it looked so decided to keep it in and make a gameplay mechanic for it.

Hours 35-40

This period was pretty crucial for me, I was rushing and coding gameplay elements really fast, I had a feature idea and once I got it working I moved onto the next thing on my mind. Asteroids, world vaporize (terraform), exploding chunks of the world, world rebuilding. I needed to make a full game cycle so I decided to add a timer that would ultimately drive the gameplay (destroy the world within the time limit).

Hours 40-45

I had finished the gameplay that I wanted. Next came the hard part of making it usable and playable. Having a lot of functions that are bound to keyboard keys is no good when you want other people to play your game and enjoy it.
I started to code the game flow:

Start menu –> enter game –> game timer –> score screen –> restart.

Added basic HUD and menu. i.e “Press SPACE to start/restart” and a scoring system.
My plan for the scoring system was going to be more complex with multipliers and additions for which super moves you used, but I didn’t have the time to make this work, so stuck with a simple score and time multiple.

Hours 45-47

The HUD and user interface needed work, I added these features faily easily but they were basic and static. So I started working on timings and polishing the interface. Flashing “Press SPACE to start/restart”, score screen with accumulating score. Timings and delays on the game flow to add additional polish. For example when you destroy the world, the score screen doesnt instantly popup, it has a time delay, or when you press to restart the game, the game waits until the world is rebuilt before allowing player control and starting the time. etc. This polish and attention to the small details is what makes your game stand out and feel like a proper experience, rather than a load of features cobbled together.

Final hour

This last hour was mostly taken up with preparing a release package, zipping up the projects and source and testing to make sure a download of the source and executable would build and run, etc… Faily boring stuff but it does take time. I noticed a problem with absolute paths in my Visual Studio project, so had to rebuild a whole new project solution to fix this… luckily my project solution didnt contain too many header and cpp files.

I tested my package, uploaded it and then created an entry on the Ludum Dare website… then sat back and had a rest.

My entry can be seen here:
http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=11531

WHAT WENT RIGHT:

• Had great momentum from the start – I was able to put off the design and gameplay decisions till much later, since I had a lot to code from the start, having decided on a specific rendering engine.
• Used my own personal engine – Since I was using my own 3D/OpenGL engine, I knew exactly what I could do and how to do it.
• Voxels and cube art is great for programmers (and anyone who isn’t an artist) -   Art was always going to be a problem for me, but creating stuff in 3D mitigates that problem slightly and creating stuff purely with voxels actually looks great with NO art whatsoever (See minecraft )
• Got lucky with the theme – Seriously, I couldn’t have chosen a better theme for a voxel based game if I tried. if the theme had been something like ‘Evolution’ or ‘Discovery’ or some other abstract concept then I don’t think my game would have turned out half as good as it did!
• Got involved with the LD community – I really enjoyed looking at the other users entries on the LD website and also posting my own progress and hearing feedback and comments from the community. Nothing is more rewarding that seeing other people’s efforts and encouragements from the community.
• Self documentation – I think I did a pretty good job on documenting my progress, taking screenshots and uploading videos to youtube.  I even enjoy looking back myself now and seeing the progress that I made during the 48 hours.

WHAT WENT WRONG:

• Gameplay – I left most gameplay decisions until the 2nd day. After I was happy with my rendering and voxel engine I actually spent a good hour or so scratching my head as to what to do next.
• Focusing too much on the rendering/engine – I was torn between wanting to make a really optimized re-usable voxel engine, and adding in gameplay features. At one point I had to physically stop myself adding voxel engine features and rendering optimizations to force myself to think about gameplay and mechanics. I could have quite easily spent the whole 48 hours making a voxel engine…
• Trying to do too much – I had far too many ideas that I wanted to try out and not really having a clear design goal or making any gameplay decisions at the start meant that I was fragmented when I wanted to start making something that would be playable.
• Memory leak! - I found a major bug (memory leak) in my voxel particle renderer about 8 hours before the compo was due to end. I was leaking memory quite badly when creating and destroying particle effects that I HAD to fix. This took up about 2-3 hours of valuable time towards the end of the 48 hours.
• Basic user interaction - It is really hard polishing a user experience, so I ended up just putting a couple of buttons in for the special moves, not the most elegant way of coding gameplay features

Advice:

• Sleep! - Don’t even bothering thinking that you can work solid for 48 hours, it is just not possible. It’s counter productive to lose ANY sleep and even just trying to do one all nighter is going to be detrimental to your progress. Yes you are going to probably stay up later than usual and once you are in the zone its hard to leave things to go to sleep, but if you are staying up into the early hours of the morning and going to sleep before it gets light outside, I would say you are doing something wrong.
• Prototype FAST - 48 hours goes really fast, if you are spending a lot of time on a feature or idea that just doesn’t seem to be working, move onto something else. Don’t waste time flogging a dead horse.
• Know your tools/code/engine – Since you are going to be creating something SUPER fast and with no time to spare, you really need to know what you are using. It helps if you know exactly what your engine is doing, right down to the individual function calls and rendering details. You will spend far less time fixing bugs, debugging code and trying to figure out what is going wrong if you know your engine/code inside out.
• Make decisions before the competition starts - I think I can attribute a lot of my success to this point. Since I was prepared before the theme announcement and was ready to start programming the instant the 48 hours started, this helped me a *lot*. I could have took this EVEN further by making some gameplay decisions first as well as deciding on the style of my game.
• Make the theme work for you. – (This is related to the previous point) Already have an idea of the sort of game you are going to make and then just adapt it to suit the theme… It is no good having no idea about what you are going to make and just trying to come up with a game that perfectly suits the theme. You will waste valuable time thinking and designing when you could be coding!
• Polish what you have – Personally I think that a well polished, smaller scope game that does a few features really well, is much better than some attempt at a game that has lots of features but doesn’t implement any of them particularly well. LD is a time to create something small that shows off something cool in a neat little package, not create the next big blockbuster.

Final Thoughts:

Overall I had a blast making a game in 48 hours and taking part in my first Ludum Dare. I am pleased with my final outcome and even surprised myself with what I made. I now have a 3d voxel engine that I didnt have before I started the LD48 and don’t doubt that I will be using and improving it from now to create even better voxel games.

Thanks for all the support guys and see you next time.
AlwaysGeeky

(Yes, I realise I spelled Hollywood wrong, but I didn’t want to cheat and fix it after the deadline)

Link to my game (ratings and feedback appreciated!)

Background

I have a bit of experience in Flash and have released a few small games over the past few years. I took a hiatus for a while and picked it up again about six months ago very part-time. I’ve wanted to give Ludum Dare a try for ages, but honestly didn’t think I could actually finish anything in <48 hours. Since this was the 10th anniversary, I figured I’d block out this weekend and force myself to at least try.

I read a lot of post-mortems to try and learn from others, and made a few very very simple games in Flixel last weekend to familiarise myself with the library.

Tools

• IDE: FlashDevelop
• Library: Flixel
• Graphics: Paint.NET
• Sound: as3fxr

The finished product

Nineties Holywood Hacker has you hacking like in a cliched nineties Hollywood movie, i.e. with no resemblance to actual hacking in the real world. First, in the Pipeline-esque intro game you need to build a link between your computer and the target node. Then, you have to fly through the link cell-by-cell from the start to the exit in a top-down Smash TV style. Watch out for rogue security programs and collect coins to buy upgrades.

What went well

• Editing levels visually

I started off trying to make levels in a text editor and hard-coding them. This was fine for the very early testing, but as soon as I started on the actual game I gave FlxTilemap.imageToCSV a try and drew monochromatic tilemaps in Paint.NET. Making changes to a level became as simple as ALT-Tabbing to Paint, drawing a couple of black/white pixels and recompiling.

• Planning

At the start and whenever I came to a good stopping point, I spent 10-15 minutes updating a features, tasks and bugs list, estimating how long each might take and prioritising accordingly. Because of this, I implemented *nearly* all of my originally planned features and fixed all the major bugs with time to spare.

• Taking regular breaks

Sometimes I’m in the zone coding for hours and everything compiles first try. Other times I’m stuck for ages trying to fix a bug and it turns out to be something stupid like for(i = 0; i < numEnemies; j++). For the most part, I was pretty good at stepping away from my PC for five minutes every so often to reset my brain.

• Build an MVP and iterate

A ‘minimum viable product’ is the minimum feature set for your product to be in a releasable state. Since I was worried about not being able to finish in 48 hours, one of the first things I did was figuring out the absolute minimum requirements for the game I *knew* I could implement in a few hours (e.g. basic main menu, player controlled entity, basic enemies that move towards and destroy the player), and built a working bug-free version. Then, I did this again with another logical grouping of features (tilemap+collision detection, different screen-sized rooms, ability to move between rooms). I repeated this process until the 48 hours was up.

• Made use of available libraries

Little to say on this except I now love Flixel. Even being fairly unfamiliar with it, things like animations, pathfinding and collision detection were ridiculously easy to implement. I guess my point is: don’t try to reinvent the wheel in a weekend (unless that’s the theme).

What went poorly

• Tried to implement two mechanics

While I really do like the Pipeline/level editor subgame, I essentially had to split my effort 50:50 between that and the main game. The entirety of day one was spent on the main game and day two on the subgame.

• Doing the graphics

I’ll be honest: I’m really bad at art. I should have accepted this early on and gone for a minimalistic style from the beginning, but instead I kept coming back and adding a little extra colour here and a half-finished animation there. The end result is a complete lack of consistency.

• Chasing annoying bugs

The example earlier wasn’t the worst bug I came across – I spent over an hour trying to figure out why my sounds weren’t importing and it turned out that when exporting from as3fxr to Audacity and converting to mp3, I should have saved them with IDV1 tags rather than IDV2. One simple click and I could have had an extra hour to add another cool feature. But is there really a way to avoid this entirely?

• No time for balancing

This was one of those “I’ll do it last” tasks. Unfortunately, given how close I was developing up to the finish, I ended spending less than 15 minutes playing through a couple of times to mess with the variables.

What I’ll do differently next time

• Focus on a single mechanic

This really should be an obvious one, as it’s pretty much Game Jam 101: come up with a single innovative gameplay mechanic and get it working really really well.

• Balance the gameplay as I go

While I was constantly playing it, I could have easily spent a bit more time playtesting as I went and tweaking the variables to make it a bit more playable, rather than planning to set aside a few hours at the very end but running out of time.

• Use the theme to guide the project, not just the initial brainstorming

My use of the theme was simply writing ‘Tiny World’ on a piece of A4 paper and brainstorming mechanics around it. Once I’d come up with something I liked and thought I could achieve, I completely forgot about the theme until a few hours before the end. Ideally, the theme would guide every one of the metrics you’re scored on.

• Implement basic tracking

Playtomic takes <10 minutes to set up and implement, and it would be really nice to actually see how many people are playing it and for how long.

• Get a good night’s sleep ahead of the compo

After a long work week and a heavy Thursday night, I was already knackered on Thursday but decided to stay up until 2am GMT to see what the theme was, in the hope that I’d have a spark of genius in my sleep and wake up with a pre-designed game in my head. Instead, I slept until about mid-day and dreamt about ducks.

Hi,

i finally decided to write a little postmortem of my first LD experience. I will do a classic “what went right” and at the opposite, “what went wrong”.

What went right?

The coolest part to write : )

• I found an idea quite quickly. I did not start to write code like crazy at the early minutes, i took times to think about a cool idea to not realize at the middle of the compo: “ho god… this concept sux and does not fit and i don’t have enough time to do something else…”. So i think i acted pretty wisely (at least for this part of the work).
• I love game development and i do some little game since few years, i usually work with Python/Pygame (cause i love Python sooo much) but i’m, most of times, focused on the programming part, not on graphics. So, to be honest, i was afraid to think i will have to do my own graphics… FROM SCRATCH! And regarding this apprehension i had on making graphics by myself, i’m pretty glad of what i did. I think i was able to communicate the mood of the game i imagined through the graphics (even if they are really simple, pixel art blablabla).

What went wrong?

Of course for a first LD, there are things that i did wrong. Obviously!

• Bad management of Sleeping/Working time. I don’t really know how to express it properly but, i really think my organization was so wrong concerning my sleep times. I will not over extend myself to much on this part but i will definitively think of how i could optimize this for the next event : ) I think my dad was right: “Les heures avant minuit comptent double.”
• Worked with the company of others people. For some people i think it’s perfectly fine. To me… it was not smart at all. I was able to stay focused more that 15 minutes… needed to stand up, walk around, ask people some dump questions: “what are you doing?”, “can i see it working?”, “where did you buy your t shirt?”. Next compo, i think i will just buy lot of foods and stay at home in my room avoiding all human contacts : D. No seriously… i need to work my focusing ability… i have this problem since my first hours of school.

Conclusion

So. To conclude. I’m pretty glad of my work for my first LD event but definitively need to work on some details for the next time. I will of course continue doing some games with time restriction to train myself and try correct the points i mentioned in the above part. This experience was awesome anyway and i don’t regret to have lost my LD virginity and i hope i will do better the next time!

Big kiss to all the people who submitted for the LD because indie game development is awesome and because YOU are awesome!

Bye!

PS: You can check out my game here : http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=12915

Hi guys,

So I created My Little Planetoid in 48 hours. Read on to find out what I thought afterwards (a post-mortem, if you will).

What went right

Genre/Setting

This is both a science-fiction and city-builder game. The combination itself is rather rare.

Building stuff

It just feels awesome. And I love the “Build now on moon”-gag, which I think is quite good game-design.

Timelapse

According to people this video is “intense”. It might be due to the orchestral music, but probably because my facial expressions during Ludum Dare varies between “frown” and “manic laughter”.

Soundtrack

I composed this over the course of the 24 hours. The first idea of the music I had immediately after I decided on the idea, and it grew from there. It has been quite well received, with many people saying they like it and find it relaxing.

Also, the idea of a space-banjo is just awesome.

Graphics

Having empty space as background meant I was able to concentrate more on the 3d-models in the foreground. And while they could be improved a lot, you’ll notice there’s a lot of detail to be found.

Mood

The combination of the somber soundtrack and the space-y visuals worked quite well, which people also remarked positively.

What went alright

Theme

This time I actually prepared. I made a list of ideas for every possible theme. Tiny World was the one where I didn’t have anything brilliant ready, so threw in an idea I already had before. After the announcement I developed more of them, but threw them out when I saw others made them first.

Scope in fiction

My Little Planetoid has a somewhat weird range of buildings. You start out with houses and farms, which could position this game anywhere in the past or future. Then you quickly advance to Science-Laboratories and advanced-space-stations. So while it is a progression through technology, I feel it could’ve been more focused.

Scope in design

In design-terms My Little Planetoid is huge.  It has more unique features/elements than any of my previous games. It has multiple complex 3d-models. It has a somewhat extensive GUI. And, most importantly, a huge web of each other influencing resources and variables.

I was even glad when something emergent happened, but there was lot of potential for bugs and unforeseen combinations. Which led to…

Balancing & bug-testing

I literally coded in something 10 minutes before the deadline. There was no time left for dedicated balancing and bug-hunting, only what I noticed during test-plays myself. The resource-balancing now kinda works, but it does feel off sometimes.

In the end the basic resources become abundant, so you aren’t really thinking about them any longer.

Textures

I used a basic pixelated diffuse-map on all things. Sadly there was no time to take care of UV-maps, but it doesn’t really show unless you really look.

What went wrong

Failure to realize how bloody huge this project is

This led to a (frankly mental) development-speed in the last hours, and the incomplete balancing.

All in all

This was an awesome and fun gamejam. My Little Planetoid is right now one of the most-played games, and people really enjoy it. The general consensus is that this could be huge if further developed. And so I will

Play | LD-page | Mini-Review (at 9:50) | Review

-Matthew

Alright, I’ve finally written a postmortem for Rock ‘n’ Slash, in which I talk about what went right and wrong. You can the blog post here: http://nova-fusion.com/2012/04/29/rock-n-slash-ludum-dare-23-postmortem/.

(quick game link for reference: http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=7860)

Since ours was a team-based jam entry we got 3 postmortems for ya. spacemars/mroushey’s first:

Just finished up my second Ludum Dare, and my first time in the jam version of the competition. Myself and two other darer’s ( adhesion, and emarcotte ) joined forces to take on LD23′s theme: Tiny World. Pretty much all of the first day was spent coming up with ideas. After 4 hours of tossing ideas around we boiled it down to “Escape from MiniMars”.

You are a robot that finds himself on the surface of mars (well, minimars… but its the same damned thing ) and must escape. For all intents and purposes it is a mario style platformer. We loved the idea however, that there would be tons of tiny people in this tiny world that love the shit out of robots. They chase after you and jump on so they can hug you! Killing them was to be incredibly easy as youre… a goddamn giant robot. The difficulty is such that the people can never really kill you (except in maybe one or 2 areas) so its more of a way to kinda color the world and just make you chuckle a little bit whist mowing all these tiny dudes down with supercharged eye-lazers.

Now since this was a JAM entry, we had a team. Emarcotte adhesion and I all programmed it up.  (although they did most of the work, I just tweaked jump arcs and stuff like that XD ) While Adhesion rocked his chiptune magic and I was free to spend pretty much the entire weekend making art assets.

Tools: 

For the art and level design I used a combination of Photoshop, Graphics Gale (http://www.humanbalance.net/gale/us/), and Tiled ( http://www.mapeditor.org/). The game was programmed using MelonJS (http://www.melonjs.org/) (a html5 canvas game engine).

I really can’t say enough about Tiled. It’s a map editor thats incredibly easy to use and can export data in a buncha different formats, one of them being XML.

All you do is import your tileset, and start to paint. You can have multiple layers of map tiles, setup entities within the level, as well as setup your collision maps. Flash’s Flixel and MelonJS both have native support for this guy. It’s a must in my opinion.

Graphics Gale is a pretty nice freeware pixel animation app. The interface is a bit clunky, and the Layer stuff can be a bit annoying, but It works really well for animation.

Photoshop is an obvious choice, but it pretty much blows for animation. XD If Graphics Gale’s UI was better id never close it~

MelonJS is pretty easy to work with.  You can make a platformer basically out of the box. The engine is pretty high level though, I found that you have to hack in even the most basic of additional features.  I also have some pretty large complaints about html/js games and javascript in general, but that is a rant that will go on and on and on forever. :/

JAM vs COMPO :

Last LD I did the compo and I must say, it was brutal. I didn’t get to put as much time as i wanted into either programming, art or.. cough cough sound. (if you saw my last game, the music was actually playing a randomized selection of notes. ) With the jam, you get more time, and more manpower. I really do like both, but I think the jam comes out a little bit ahead in my book. I got to work on art to my heart’s content (and drawing arm’s discontent) and got what i feel to be quite a bit of stuff done. I think i will do the compo for my next LD competition, but the JAM was damned fun.

and now adhesion’s postmortem:

I’m very pleased with how this LD went overall – we made a solid game, didn’t overextend too much, and learned quite a bit about HTML5 game engine issues & melonJS. I’m super proud of what we accomplished.

what went right:
Music/sound – I was really happy with how both came out. I was so pumped to actually hear them in game; audio just makes a massive difference in the overall experience. I ended up doing the music in 2 separate chunks of time (thanks to the extra time of the jam), which felt a lot better than the one giant slog when I did the LD22 compo – that got a bit frustrating at the end. The tools I used, Ableton Live & bfxr, worked great as expected. I focused more on FM synths for the music which made it all the more awesome.

Graphics – I obviously can’t take credit, but I have to point out how much of an intense badass roushey is, and as such his art is amazing as usual.

Coding (mostly) – Despite being not all that familiar with Javascript, and despite all the horror stories I’ve heard about its awful innards, I found it quite easy to use – didn’t have any huge (core JS-related) bugs, and I was able to figure out the built-in data structures and such without too much trouble.

what went wrong:
Time management, again – was an intense rush at the end to get the final polish done, particularly the RADMARS intro screen (waaaay worth it though ). It was also hard to be productive on saturday before a lot of the art assets were done, which is kind of a weird side effect of melonJS providing a lot of the core gameplay functionality very easily. Plus, I had to work on the Monday the jam ends and ended up miscalculating how much time I would have to work on it that day which didn’t help.

Code framework, a little – had some major memory/memory leak issues right at the end which was really frustrating to deal with. (Wish I caught that earlier, it kinda drove me insane for a while.) I managed to fix it but more familiarity with Javascript, melonJS & browser debugging tools would’ve definitely helped. Struggled with a multiple collision issue for a while too – in retrospect it was pretty obvious, hopefully I’ll wise up to this stuff as I do more game dev stuff. Otherwise I’m pretty satisfied with melonJS in general.

Whew! Overall LD was a great experience again. I’m so glad to have the opportunity to do this sort of challenge and have something awesome to show for it at the end. See you in August!

and emarcotte’s:

- Dedicated time would definitely help, coming in and out of the project is frustrating and anti productive
- flexibility of javascript makes time very productive, melon’s tool integration is also very flexible and simple.
- asset pipeline is still a mystery to me, roushey just does magic and we consume it…
- polish is 90% of the battle. the rest is easy.

Extra bonus stuffs!!:
Timelapse:

Soundtrack:

http://adhesion.mu/sic/Adhesion-MinimarsOST.zip

OK, so here’s some development shots and various assets for our game, Kumiho

This is my visual reference chart, the visual references that most influenced how the game looks. Ikaruga has a prominent role visually, even though I did play some Jamestown, Touhou 8 and Xenon II to get a feel for things. I used a 21 color palette which grew organically as I added more and more stuff. It’s the strange shape at the bottom left of the timelapse. I also tried to keep with a vertical composition and Korean text, in its (less usual) top to bottom form, was a huge help in establishing the look. Korean and chinese drawings were also a big influence on the style.

I always like to have reference for everything before I start to work. In this case there’s background ideas, spaceship designs, photos of insects and stylized korean drawings.

Here is my timelapse.
I used one main photoshop file to draw new stuff, so that I could see them relative to other assets. Essentially, a mockup/overview of the game.

When something needed animating, I just copied it into a new file and went on from there. Cases in point:

Long explosion. Again, Korean and Japanese art influenced the shape

the flappy wings of the squid boss. I realised, from looking at slow-motion squid videos on youtube, that the movement is essentially a sine wave. Even so, this took about 2 hours

The ship was my first animating challenge for this game. I had chosen an asymmetrical design, so left and right animations would have to be different, and not just a flipped over version.

The tentacles. This took 3 hours. Sine wave movement again, but these were harder. The two right tentacles are flipped versions of the two left ones, with a time delay of 3 frames, so that the movement looks more organic.

Hope this helps,
Christina

Angle Isle is my second Ludum Dare game. Here’s how it happened.

Friday

The theme arrived at 6pm PST. After throwing out the first 60 minutes of work on a bad idea, I started sketching in Photoshop for inspiration. Soon after I developed a 45 degree angled art style. It seemed interesting enough, so I spent the rest of the evening creating tilemaps and characters.

Saturday

During the morning shower I tried to figure out what the hell I was making. I liked the world, but most of the characters didn’t fit. I only liked this angled bird and before I dried my hair, the bird became the hero.

After a quick cup of coffee I started the code. Angle Isle was coded in Flash Builder on top of the excellent Flixel engine. I don’t have much experience with Flixel or Actionscript, so I was often reading Flash Game Dojo and the Flixel documentation.

I hoped to create the levels in Tiled Map Editor, so I first worked on importing TMX files. This took longer than I anticipated. By the time I got a test level loading, I needed to break for lunch.

In the early afternoon I coded and animated the player. The desktop playtesting was done with an Adaptoid and my original black N64 controller. Once the bird’s flapping felt pretty good I started thinking about levels.

A large chunk of time was then spent on level transitions. I could have made it simple, but I wanted the levels to change dynamically. The player would seamlessly fly between one level and the next. It took awhile, but I think it was worth it.

At this point it was late. I needed to start designing levels, but there was much to tie up including touch controls, the breeze, and the shark. (More on this later.) I was delirious by 4am and went to bed a half hour later.

Sunday

I slept two hours and awoke a bit groggy, but anxious to start. First task: writing music. The gameplay theme was written in Textmate with MML. The tunes didn’t flow, but In four hours I had a passable melody.

I moved on to sound effects and finished them with six hours remaining.

The levels still weren’t designed. I set a twenty minute repeating timer and tried to make, playtest, and finish each new level before it went off. This was a tall order. I spent extra time in the early levels trying to figure out what the player should experience and learn. I also found the tileset incomplete and had to spend more time adding tiles.

Halfway through level design I stopped to create the title and ending screen. This took another hour. When it was time to submit I had squeezed in 8 levels.

What Didn’t Happen

I had started to add an antagonist to hunt the player in later levels. The shark would jump out when the player was trying for the lower hanging berries. But time grew short and the shark was cut.

I also hoped to add a continuous day-night cycle with parallax stars. Ran out of time.

Clearer Communication

When the player collects more than half of the fruit on a level, a wind appears to the right and the player can ride it to the next level. A bird chirp sound effect signifies the “exit wind” is available. Although I like the chirp sound, it doesn’t communicate a connection between the berries and the wind. I should have used a wind visual and sound effect instead.

Mobile Port

I submitted an iOS port to Apple the morning after Ludum Dare. But as I’ve been playing it more, I’m less satisfied with the performance on older iOS devices. Instead I’m looking into porting to Axel or perhaps Objective-C for the post-compo version.

Conclusion

Ludum Dare is awesome. I’m amazed by the results of some good ol’ pressure. Angle Isle blew away my previous entry and I’m pretty happy with the results.

If you entered the competition, please take a chance to rate my entry. I’d love to hear your feedback.

Twitter: @rustym

A tiny NES puzzle game. Read the postmortem here

Pew Pew

Entry

What a fantastic recollection of 48 hours. This was my first Ludum-Dare and my second Game-Jam. I now wish my life was structured in a way that I could benefit from these short-bursts of inpsiration, motivation, and commitment to goals, I would not only get more done, but better time management would also mean better social life, health habits, etc. Oh well! Something to keep in mind.

The good:

• Having worked constantly on Unity3d for more than a year now, I had no problems with the engine or tool itself. It was a smooth ride in every step of the way.

• RagePixel by keely,  a fee pixel editor plugin for Unity made making sprites a breeze. It was my first time using it, but the tool is easy and intuitive. Its only drawback for Lilac.27 is its stubbornness to work in Orthographic cameras with specific distances. I set up a scene specifically for making the sprites as a work-around.

• Sculptris by Pixologic, a Sculpting tool in which I modelled and paionted the organic-looking planets. Again an amazing free and easy tool that sends pleasure waves down your spines just from comparing it to other possible workflows. Just Press “ImageMap” and  “Export OBJ” and Unity will import them with no problems (Apart from choosing 2 as the scale, 1 gave triangles so small Unity didn’t render them).

• Propellerhead’s Figure for music. While limited on its instrument offering, Figure has enough tweaks and settings to give your song a unique personality. It was specially great for this Ludum Dare as making drum beats is almost automatic.

• The relatively simple concept allowed me to get the movement and shooting feeling good in the first day, that way I would focus on all the content during the second.

• Less than 100 lines for all that has to do with orbits and planet switching. All stemming from this simple algorithm made open in the following Unity Forum topic: http://forum.unity3d.com/threads/8873-Faux-Gravity-making-my-brain-spin…-Help!

• The Art Style was grounded from early in the development (2D sprites in 3D environment), so it was more fun than difficult stitching the colours, textures and camera post-processing effects together.

The bad:

• Making the shooting feel right must have taken a good 30% of the time. I spent a long time trying to align some bullet arrows to both the character’s direction and the Planet’s gravity, but gave up and ended up a spherical bullet that of course doesn’t show any rotation.

• Configuring all the particle effects felt dragged beyond necessary.

• Forgetting the need of a certain sound effect made me close and re-open programs and change mindsets more often than necessary.

• I added the camera’s movement in the end, so it feels quite iffy. I would’ve liked to have it automatic, aligned the best possible way for jumping and showing the goal in each section.

• Jumping can also use a bit of work.

• Lack of sleep gave me a huge headache by the end of it.

The interesting:

• Figure does not let you save or export at all, so I had to use a input-to-input cable to record and process the music in the pc.

• One of the original ideas had to do with a more interesting tiny chess world, where pieces interacted and somehow grounded their behaviours around Chess. Too ambitious!

The future:

• I will definitely be expanding the game, with mobile platforms as the first goal. This is something I aimed for since deciding the concept and Graphical Style.

• All in all, this was a great experience that taught and gave me a lot.  The premise of the Ludum Dare challenge pushes you to explore and understand your strengths, weaknesses and limits.

The plugs:

• Entry

• My Twitter

Thank you for Playing!

Here’s my brief Postmortem for my game Tiny Crash Landing.

Play the game Here:

In game screenshot of Tiny Crash Landing

This is my first game I’ve made for Ludum Dare! I had to be part of the 10th anniversary.

What went well:

Art – I spent around 5 hours the first day doing the main tiles and character art+animation. I used Photoshop for doing animation for the first time, it’s not that well suited to it, but I didn’t want to download and mess around with any new software. I’m quite pleased with the character and animation, especially since I did it in a few hours.

Music – I think I spent about an hour making the music and sounds. I’m glad I made the music before I began programming, otherwise I would not have had time for it at the end. I mostly randomised some notes and played around with SynPlant and added some filters and stuff until it sounded ok!

Sound Effects - I mostly used sound effects in place of proper presentation, since adding a sound effect is a lot easier than adding a proper intro/outro screens. The only difference between what happens when the player wins or dies is the sound effect!

Programming – I liked my decision to use Haxe/NME I haven’t been using it more than a couple few weeks but I think it’s very easy to pick up for ActionScript users. I got a lot of code written, but most of it wasn’t gameplay code.

What did not go well:

Programming - I completely ran out of time regarding the code! I probably spent around 3/4 of the time doing code, but didn’t really get enough done to make a complete game. I think the biggest problem was I was coding everything from scratch, so I spent most of my time writing a blitting renderer, collision code and a scrolling camera etc and not enough time on actual gameplay.

Missing Features – I had no time to add an options menu with a mute option, or reconfigure keys. I had planned on having enemies, that is why the guy can shoot, but has nothing to shoot at! I also planned on having procedurally generated maps that wrapped around, I also planned on having a minimap that revealed as you explored. Story was also a main part, but I will save that for the post Ludum Dare version.

Feedback:

I haven’t had a lot of feedback yet, but all of the feedback I’ve received so far has be very positive and constructive over all. I’m very pleased that people have complimented my art and audio!

What I would do differently next time:

Use a game framework, or make my own! I should have used a framework like Flixel or Flashpunk so I could focus on writing game code instead. My goal before next Ludum Dare, is to get familiar with Flixel/Flashpunk so I could use them in a 2 day jam.

Until next time:

I would like to work on a post Ludum Dare version of my game, with story, extra characters, proper procedurally generated maps, enemies etc.

Thanks for reading, now I’m off to play and rate other people’s games!

First LD done – game submitted. Well of course I haven’t implemented lot of ideas but the main idea is there. Endless waves of soldiers and player can possess one of them to help others. It’s more of a simulation than an actual game but we will get there

LD is great thing. First: you can try ideas you hadn’t time for. Second: I don’t feel pressure to do everything tip top as when I’m doing normal games(mostly ones that end up in limbo). There’s not much “ok now let’s rewrite it again adding bazzilion new features/cleaning” or “it sucks because is laggy/buggy”. It works == it’s good. Next please. So this is really about being creative and work fast which is great test of skills.

Things I “learned” / went good:

Time is of the essence. (always wanted to say this) This weekend I was kind of busy with some social activities – thus didn’t fit into 48h (btw it came out that suspiciously lot of my friends are taking lessons in sword/katana fighting – incoming zombie apocalypse or what?). Next time I will go off the grid for two days. But no regrets there because…

I submit == I win. I don’t see LD much as a competition with others. It’s all about fighting with clock/skills/monsters/ideas. Lots of people say “the failed” because their game is incomplete or drifted away from original idea. I’ve tried, I’ve learned. Those are things earned. No loss there.(oh yeah I like some preaching from time to time)

I love to code. Don’t know if I should share this but there were moments, rushes of code compiling into new features, that almost gave me a boner. Let’s hope my girlfriend won’t consider this as cheating(I know she won’t – she’s great). There is something about writing games that makes my soul smile. It’s like this feeling when you were kid and was unpacking new box of LEGOs but here you have unlimited amount of bricks and shapes. It gives wings. Also in narcissistic spirit I must admit that I was implementing things pretty smooth. Particles arrived in no time from scratch(they are total mess though) same with shooting and obstacles. But next time I will come with more ready blocks and focus on gameplay/logic.

Game development is about making lies. You don’t have to code things as there really are. They only need to ACT like they are “real thing”. Applies to physics, AI, general game logic. I remember in “Game programming gems” book there was a part about pathfinding in Total Annihilation. It was in old days, not so powerful computers. So while unit was computing path to given destination it was performing tricks: blinking lights, rotating turrets/body, releasing smoke etc. It looked great, making units seems to be more alive when in fact they were dead stupid and lying about it(like some Miss World candidates).
In my game there is obstacle avoidance. At first I was thinking about some A* pathfinding or sth like this. But then added simple “If(obstacle before you) go up/down for few seconds then check again”. It’s not perfect and would break with rotated buildings but who cares, right?

Details matter. Visually at least. Added particles and it was more alive. Blood, dirt from explosions, guns urinating, I mean shooting. The last one actually hides fact that soldiers are not really shooting bullets. Each few seconds they look for enemy and do simple luck test:
if (this.doYouFeelLuckyPunk()+0.3 >= enemy.doYouFeelLuckyPunk())
which compares sums of random roll, experience, cover, hits taken etc. Works right?

Artist is of the HUGE FUCKING essence. I don’t have fellow artist able to do decent game graphics. It shows especially with cars – yep those small obstacles are cars. But… but I was focusing on the code Anyway even small games/experiments with good graphics have better experience. I know that with great gameplay it doesn’t matter(old S.T.A.R.S. player here) but it adds a lot.

All you need is war

What went not so good and should be corrected next time:

Gameplay. There is none. There is no goal, no level end. I’d like to say I didn’t have time but it was more lack of idea what is should be. Ofc I’m still working on the game and have few concepts. So there is hope to end that battle With next LD I should have more solid/complete idea of gameplay before I start to code.

Graphics. They are programmer art and it shows. Next time I should go for some minimalistic/artsy style or team up with somebody. Or hire or bribe or kidnap one… but maybe I talk too much.

Sound. There is none. Haven’t time to sfxrize them

Anyway I had great time. It was very refreshing and  energizing. Came up with few good ideas that I hope will be implemented soon and maybe released as a full game. Saw lot of great games that were very inspirational. Definitely will participate in next LD. So… sex, coffee and CODE ON!

PS: If you are an artist/pixelator and would like to work on this game please give me a note! [dx0ne monkeygoeshere laislacorporation dottery com]

Through the Blue Sea is my entry for Ludum Dare 23, its a small randomly generated abstract platform game. You goal is to pick up all of the yellow pips, without falling off the tiny world. You can grow larger by eating the asteroids that fly in, if you don’t eat them then one of your platforms will be destroyed.

What Went Wrong:

> The Theme, on my blog I outlined the themes that I hoped would win, and Tiny World was not on of them. It took me the first six hours (Friday night for me) to come up with an idea for a platformer set on a tiny world, and then I wanted to scrap the idea all weekend as I found it an incredibly uncreative game.

> Time during the weekend, I knew going in that I would have limited time during the weekend, as I had a job going on.  This coupled with the theme, led to even less inspiration when it came to finishing the game, and more procrastination.

> Scoring, there was a point Saturday night, when I was working on the online high score table that I wondered how scoring was going to work. So I took a few minutes and decided to leave it really simple, so each pickup represents one score. Looking back now, It doesn’t give me the variation I would like to have.

> Level generation, I decided to randomly generate the play field and about half of the time it generates impossible levels. I knew about this the entire time, but decided it would help the lacking score system. Now that I have had about a week to think it over, I wish I had made it generate levels that could always be completed, or that I had added a pickup that ended the level.

> I found myself lacking a couple programs that I needed, I was using a new laptop this time, and hadn’t installed python yet, and I needed VLC. It didn’t take much time, but it would rather have already known what I needed and had it installed before hand.

Timelapse Video:

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

What Went Right:

> The character, I am glad that I changed it back to a square and just added a face to the square, it fits more with what I am interested in. The first character sprite was an odd Llama Elvis creature. but I ran into issues with collisions, and it didn’t really fit with the background or platforms.

> The planets, I knew from the start that I wanted to use colors once again, the colored planets in Through The Blue Sea represents the difficulty of the generated levels (based on how many pickups, and how many platforms). So a Cool color (Blue and Green) are easier than the warm counterparts (Red and Purple), and Yellow is somewhat neutral in that it has quite a few platforms, and a bunch of pickups.

> Sounds, some people in the comments have liked them, most have hated them. I personally think they fit the strange, wierd style I was going for with the game, I mean just look at the character expression:

> Music, I once again used a python script to generate music, and it once again performed perfectly…After a few generations anyways. I then used VLC to convert to mp3.

> Online Highscore table, when I first started I didn’t plan to include one, but on Saturday I had about finished the game, and still had over 36 hours left. I made a online highscore table for my last entry (Alone in Space…) and made one for the final version of Untitled. So writing one wasn’t a big deal, in fact it only took me a half hour to have the basics working. Then I decided on how many score pips for each world and secured the highscore table using the maximum (So for the Red planet that has a maximum score of 8, any scores submitted higher than 8 are ignored)

Gameplay Video:

http://www.youtube.com/watch?v=6-jMNjRN77E

What is Next:

I don’t plan to do much more with Through the Blue Sea, but I do want to release a Post-Compo version that adds a better scoring system. The new scoring system would be based on a multiplier bonus, you would have 100 seconds on the clock and finishing before 0 would give you a bonus. My first idea would be to make asteroids give you a multiplier, so catching more asteroids and finishing faster would give you a higher bonus. But I am not really sure what it will be like until I do it, and it will most likely be another week or two.

This was my first time competing, and overall I’m happy with the outcome. I only ended up with four of the five levels in the game, and there are bugs and oddities in the game. The feedback I have received has been all positive, with suggestions saying to consider an external library, have some visual indicator of enemy health, you can fly on the second section of each level, etc. This screenshot also shows a few things I would’ve changed if I had more time or had planned more.

What went right

>> I did end up with something playable on Sunday, and I am working out some of the bugs and
        improving it in my free time
>> I had quite a fun time and this was a great experience.

What went wrong

>> Bugs, bugs, bugs… some more apparent than others, nothing really game breaking but bugs
       are to be expected when trying something new.
>> I never got audio working, that will be implemented on the fixed version and posted to
        StaticVoidGames.com
>> Some of the pixel graphics look weird

What I would do differently

>> Definitely acquaint myself with my tools beforehand. I was only using standard Java classes
        and Paint.NET for graphics
>> Dedicate more time to it. I started a few hours late and didn’t stay up for the entire 48 hour
        time period

Final thoughts

      >> Overall this was a good experience, and I will be entering the next one.

Its probably about time to write this.

Design
I had a good selection of ideas at the start of this competition, something I have had trouble with in the past, The only problem was which one to choose. Unfortunately I did not spend any time fleshing out the ideas and properly designing the games which i believe is where everything went horribly wrong.

First Idea
This was supposed to be a game where you played as a cell in a petri dish. There are other cells around that either try to kill you, block your path or various other behaviors. I spend about seven hours implementing this concept but stopped when i couldnt think of how to make it a fun game. Te prototype was not headed in the direction of my initial vision of the game. I also wanted to try out the other idea.
You can play what I ended up with here.

Second Idea
I had spend a bit more time thinking about this one. I didn’t start with it as I thought it did not fit the theme as well as the other idea, but the extra time would definitely have helped.
More design time would have been mush better, as I did get stuck a few times in the implementation due to not having a clear grasp on the game’s structure. I ended up re-writing the code to display the blended dimensions a few times and I got stuck with the collision blending.

I eventually ended up scrapping everything but the level loader and started again from scratch about five hours before the deadline, taking a completely different approach that works much better. Unfortunately five hours was not really enough, and I ended up hacking in some elements right at the deadline, like the ability to drop orbs, which is why the controls really suck.

Tiled
I tried out Tiled during the last Ludum Dare. It saves so much time not having to write your own level editor. It was definitely very useful for this competition as I had no time to make a playable world at the end of the competition.

Conclusion
Generally I should have stuck with a single idea, or at least not spend much time on prototypes if I am unsure. Also I should really take the time to fully design the structure of a game before I start ANY implementation. I never do this which is why nearly everything I program gets re-written at least twice. Maybe I’ll finally learn…

Post Competition Version
I have had a lot of positive feedback about the idea which is encouraging. I have already started writing a new version of this game. It is currently about the state of my entry with a few extra features. I want to add monsters and other puzzles that make use of the dimension blending in creative ways. I will upload a version of it soon.

Play my final entry.

Almost a week has passed since LD23 started and I think it is time to look back at what actually happened. I didn’t really have a favorite among the themes, so when Tiny World popped up I had nothing prepared. I got a few ideas while having breakfast, but nothing that I thought was interesting enough. Tiny World to me is about relative sizes, but all I came up with was not relative to anything else in the game. So I took a shower and not only did I get clean, but the idea of summarizing another game into tiny bits was born. I went with Super Mario Brothers pretty much straight away as it both widely known, but also said WORLD x-y on every other screen.

Can’t be bothered to read the post mortem? Go straight to the game and play/rate it here.

Things that what went right

Engine

I used my own developed engine Pixelizer. Even if I’ve been working a lot on it lately and this would be the first true test. Luckily it stood up to the challenge and allowed me to cram a lot into the game in little time.

Graphics

Straight and simple, but colorful. I obviously had original graphics to start from, but I wanted to put my own touch to it to make the game as a whole a quite different experience from the original. The first thing I did on the project was actually animating the main character as I knew I would be spending a lot of time with him and didn’t want to stare at a purple box. From there I build the rest of the graphics to work with the character.

Scope control

I knew making 32 distinct levels would take it’s time, so I decided to find a way to control the scope in case I ran out of time. The solution I choose was to alternate between making levels from the start and making levels from the back. Ie, first I made world 1, then I made world 8, than world 2, then 7, etc. Should I run out of time, I would at least have the start and the end of the game. Also I didn’t implement anything until it was needed in a level. That way I could focus on the task at hand at all times.

Company

Being part of the LD meet up at Free Lunch Design worked great for me, it was very relaxing which allowed me to focus when needed, and chat with friends at other times. Kept me from burning out which very easily could have happened.

Things that what went less right

Original scope

In retrospect, this was way to big for a single weekend. I churned out levels like a crazy person the last few hours before submission. Even if I had control of the scope, it would have ruined the idea as a whole if I had failed to recreate every level.

Engine

Pixelizer was good to me in many ways, but there are also some glitches in the game which are due to the engine. Needs more work.

No music

The game feels a bit flat without any music. But there was simply no time for this and I am no composer by any means. I decided not to include music as it would probably do more harm than good unless it was really good.

Misjudgung the audience

A lot of the decisions I made for the game design concerned how to make the  game more puzzly and less actionly. I thought I would get away with this, but it caused the game to be somewhat less similar to the original than what players expected. For instance being able to jump over the flag pole or nog being able to stand safely on pipes, made a lot of players frustrated.

The aftermath

I didn’t do much noise about having completed my game. I was tired and went to bed. When I woke up again the game was mentioned on some sites and I thought ‘hey that’s great’ but didn’t think more about it. Later that it started appearing on more sites and suddenly it was featured on Kotaku. From there everything exploded, with the game appearing on everything from destructoid and boingboing to barstoolgames. Tweets kept rolling in with comments and questions, from all over the world. It was an amazing experience to see something that I had created spread like a wildfire. I had never imagined that people would take the game to their hearts the way they did and I feel incredibly humble and fortunate to the whole experience.

Conclusion

Ludum Dare 23 was an amazing experience for me. Not only did I had a great time making the game, seeing the response has been thrilling beyond compare. Browsing the entires I am amazed by the sheer range of awesome game concepts and implementations. The sky is truly the limit for this fantastic event. I am happy and proud to be a part of it and so should you!

If you’re still interested in the actual game after reading this, please play/rate it here.

Introduction

Spitoon was my first ever Ludum Dare submission. As I mentioned in my previous post, I had watched Notch’s live feed of his entry for LD 22 and was inspired to participate in the next one. Here is how I think it went.

What went right

• I managed to make a mostly-playable game with (AFAIK) a somewhat unique mechanic.
• My graphics, though simple, got the job done. I was pleased with how they turned out, mostly.
• I learned that I can perform under a very tight deadline and for very long periods of time.
• I made my first Timelapse as well as my first ever upload to YouTube!
• I had a lot of fun!

What went wrong

This is always the more interesting part, I imagine:

• Many bugs made it into the posted version. Among them are the spitballs appearing at full size for a split-second before being resized (this one bothers me a lot, as it messes with the visual style and happens repeatedly), and spitballs sometimes stopping dead in their tracks when they aren’t supposed to.
• The game uses up way more memory than it should, particularly by the later levels. This was a problem I had spent a good portion of time trying to fix, but, alas, I just don’t know enough yet about proper and efficient garbage collection. This is where my relative lack of experience with ActionScript, Flixel, and programming in general really shows through. It is something I’m slowly working on, however.
• No sound! I had even practiced a bit with generating sounds with SFXR before the competition, but in the end, I spent too much time fixing bugs and designing levels (both of which took up more time than I had originally planned on) to get to this stage of development at all. A game like this really deserves some nice spitting sound effects to round it out, but I had to prioritize, and sound I deemed was less important than the other stuff.
• Too short! I realize that the bar isn’t necessarily very high as far as length of gameplay with this sort of competition, but I really wanted to shoot for a minimum of 10 well-thought-out levels at minimum (20 if I could help it). That said, I had to settle for 7 levels, with 2 of them being pretty bare in terms of “puzzleyness.” I also wanted to have an actual menu and a way to restart the current level, but I just didn’t get to implementing it.
• I misspelled the name of my game! :O I don’t know whether to chalk this up to being tired or what, but yes, it’s spelled ‘Spittoon,’ not ‘Spitoon.’ I didn’t name my game til right toward the end, and although I’m usually a pretty decent speller most of the time, this time I got it wrong. A 5-second Google check could have shown me I had it wrong, but it just didn’t occur to me until the next day to do so. At this point, I can either fix the spelling for the post-compo version, or leave it as is and just call it my own. Does anyone have any preference on this? Should I leave it “Spitoon” or should I fix it and call it “Spittoon” from now on?

For the Future

Shortfalls aside, I really did have a blast participating, and I absolutely plan on being in future competitions for Ludum Dare. Feedback has been wonderful and it’s so encouraging to hear people’s thoughts about the game. I’m also planning on releasing a “post-competition” version of the game with all the bug fixes, sound effects, and additional levels I wanted to include in the original version. Hopefully, work schedule and family life permitting, I’ll be able to put that out sometime in the next 2 or 3 weeks. Thank you for reading and thanks to everyone for making this a great experience! I’ve already played quite a few of the other entries, and I’m terribly impressed; I can’t wait to play even more!

I thought I’d write a quick postmortem of This Precious Land. Haven’t tried writing one before!

The Invaluable Shower (or – Keep it Simple)

I woke up to the theme – Tiny World – on the Saturday morning (I live in the UK so the competition fits nicely with my time zone and takes place across two solid days). I started sketching some ideas and stuff, and settled on the idea of doing some sort of puzzle game set on a tiny cube. As the engine I’m using is 2D only, I was thinking along the lines of showing various isometric views of the cube on the screen, to show all sides of it at once. I did some mockups.

Then I thought it all over in the shower and came to the sensible conclusion that I was overcomplicating the whole thing. Not only would the co-ordinates and stuff be a pain to manage, and the rendering awkward, but I’d have to draw objects from quite a few angles each for the various views involved.

So I stripped it right down to a simple single-plane isometric game. Once dressed and back to work I was able to get the basic grid system and rendering done really quickly. Then I could move onto gameplay.

The majority of my previous Ludum Dare entry was also thought up in the Saturday morning shower. Which brings me to..

Take it Easy

I’m a firm believer in giving my subconcious time to process things while I’m doing other stuff. It’s amazing what you can come up with when you’re not trying. So even during a short competition, I like to have the aforementioned long shower, go for walks, cook and eat properly, and go to sleep at the normal time on Saturday night. As well as having time to step away from the game and think it over, it makes the whole weekend generally more enjoyable. Less chance of burning out.

No Distractions

I spent most of Saturday at the Coventry Ludum Dare jam. In the end there was only two of us. I tried to connect the laptop to the wifi there, but it wasn’t happy with it for some reason. This actually worked out extremely well, as I just got in the zone and made tons of progress when it was most important. After about 8 hours at the jam I went home with a mostly playable game, and added the rest of the content pretty comfortably on Saturday evening and Sunday morning.

Vague Design

I didn’t have a solid idea of how the game would play before I was almost finished with it. To be honest, I actually prefer to work this way, and in a 48-hour competition it’s pretty much necessary anyway. In the case of This Precious Land though, it meant I never came up with an actual in-game goal for the player to aim for.

I considered a few different possibilities: some sort of scoring system; a threat of some kind which acts as a time limit; in-game opponents or something. In the end the easy option was to leave the game as a sandbox where the player just creates a landscape they are proud of. I quite like the optimistic vibe behind this goal, and the freedom it offers the player – I found I enjoyed setting myself challenges to try within the game, for example creating an entirely non-military village, or only using forest tiles, and not leaving any poor-looking level 1 tiles on the grid at the end.

So luckily I think it turned out OK, although it could have fallen apart towards the end just as easily.

Lack of Testing

I didn’t make any plans for testing the game, and it basically got none. Draknek played it very briefly during the jam on Saturday, and we talked about the design while I was working on it, but other than that no-one else saw it.

Bugs-wise there wasn’t an issue, as I managed to keep the code pretty solid throughout. The game could have done with more balancing, though. There are a lot of values kicking around in the game – resource costs for building tiles, the resources gained from harvesting them,  the size of the grid, etc. I just had to make educated guesses about what would work.

Originally the jam was intended to take place on both days of the weekend, and with more people involved, which would have helped. I could also have turned to the internet for testing, but I think seeing people play the game in person is far more useful.

Overall

I’m really proud with how the game turned out, and am getting a great response from other people so far. Thanks to everyone who has played / is going to play it!