Ok, I have downloaded and verified the source code of every entry in the compo.

All sources available guys, thanks!

Also, people are posting their compo source code counts on this thread. I am going to try to do some reports based on the source code for statistics on things like language used, framework used, average lines of code, etc. Anything you can add here about your source would be helpful.

Things are starting to come along but only have a few hours left to work on the game (gotta work tomorrow :/)

If you’ve played the “final” build on FreeBSD, chances are you would have been severely violated by the garbage collector. Here’s a version that’s actually playable on FreeBSD (no, not all the lag has been cut out, but it’s smooth enough to… uh, something)

http://pubacc.wilcox-tech.com/~greaser/stuff/ld18/HeadTrauma-MemoryImageSource.jar

You can enjoy being a cupid in my game! thank you!^^

Wonder Cupid

http://www.ludumdare.com/compo/ludum-dare-18/?action=rate&uid=2022

Well look at that, we’re already at the last day! Textmode, our night shift, improved the collision a bit, which is great coming from a self-proclaimed maths idiot (no offense Textmode). So now we’re at the final touches I guess, we just added some gameplay elements, so we mostly need to add some finishing touches. (our primary artist is working on some animations at the moment of writing)

Looking back at the start, where I had no faith in this project at all, we have made huge progress, after a first day of.. well, nothing. And now? Now I’m feeling extremely confident (this can only backfire..).

I missed the deadline for the main compo, but I can still submit my game to the Ludum Dare Jam. The deadline is 24 hours after the end of the compo, so I have until 9PM tonight to finish this game.

After a good night’s rest, I woke up with bug fixes. Seriously, I was lying in bed, slowly waking up, and I thought, “Oh, yeah, I implemented cooldown for the entities after they attack, but I forgot to ensure that cooldown ends.” I fixed a crash bug which also prevents the creatures from trying to leave the world map. And I improved the exploration mode of the AI so that the entities should no longer wiggle or fidget. They pick a direction and go until they reach it. I found that the reason why the hero was getting stuck in place. It was due to the fact that I was checking if he had reached a very exact location, and with his speed, he sometimes overshoots it. When he tries to go back to it, he overshoots again, forever. I enlarged the collision detection box to compensate.

When I finished Iteration 4, I found out that accidentally implemented some stories from Iteration which deal with entities attacking each other. I’ve simplified combat so if entities are not in cooldown and are touching, they’re attacking. That implementation left Iteration 5 fairly moot. In fact, I decided to skip the remaining story in Iteration 5 which dealt with some nuanced AI that I’m not even going to look at, so I’m on to Iteration 6. You can see the backlog of skipped story cards under the Iteration card.

I’m pretty excited. It’s only 10AM, and I’m on the last two iterations. Iteration 7 is basically sound effects and packaging the game up, and frankly (and sadly), sound is optional at this point. B-)

About time, too!

clicky

Hope you like my music choice 😉

Some of you were having problems figuring how to play my game because of the complexity and the lack of tutorial, so here’s a two parted video of me playing it:

Part 1

Part 2

Anyone know how to do a youtube embedding? (i promise to be a nice boy and put it after the more tag!

I decided to record a gameplay video of my game Defend Your Glacier.

I was going to record clips and edit them together but for some reason my video editors can’t read the AVIs put out by my screen recorder. =< Also forgot to record from speakers and recorded from my microphone instead. ;-; But anywho, the video's here.

Should skip near the end, as it starts out slow. =P

Defend Your Glacier Entry Page

Trust your Enemy

…train them and then use them!

Lets get into some details…

First: another Screenshot:

download:
http://games.spunkmeyer.de/downloads/Trust_Your_Enemy.zip
source:
http://games.spunkmeyer.de/downloads/Trust_Your_Enemy_Sources.zip

I started saturday morning with no idea in my mind. After my breakfast I had my idea of a game with team-switching units.

You should be able to upgrade units to make them stronger and faster. But what if your units change the team? You need to keep a balance between strong units and defending your homebase.

That was my idea.

I am working with my own little 2D framework. And I wanted to write code in a way that I could use it afterwards. Mainly GUI-Code. That was not a good idea since it took nine hours 

In the end I have some GUI code which I can extract, polish and complete later. Thats the good side. The bad side is that it took really long to get even buttons to work and therefore I started with some core game mechanics on the second day. Far too late.

Next time: Just write down idea, write some cards to work on, and dont think about tomorrow

The cards are really helping. First you get an overview of what needs to be done. Second you get motivated if you can go to the next card.

I had a friend with me, who was coding for LD, too. Thats inspiring at one side and a bit distracting at the other side.  Another friend joined on saturday and coded some hours with us. I would do that again, but be more strict with schedule.

Dev-Log:

Also watch the Timelapse-Video!

saturday
4:00 Dreaming about theme… zzz…
6:22 Shower
6:44 Thinking… watching blog…
6:56 go for a walk, buy food
7:25 Brainstorm
7:33 Think I got an idea…
7:55 more detailed designwork
8:26 Breakfast
9:09 refining design
9:17 starting implementing/drawing
10:41 implementing core mechanics
11:00 need a more detailed plan…
11:34 starting card 1/16 (Core)
12:06 starting card 2/16 (bases)
12:20 buying stuff to eat….
13:44 continuing
14:52 Writing a generic GUI class
16:35 need to get GUI done…
16:47 GUI Mockup
18:00 gui class continue…
18:51 food ordering
19:08 gui…
19:49 foodum dare
20:04 gui…
23:15 Card 3/16 enemies…
sunday
0:28 sleeptime
7:07 cant sleep… must code…
8:09 Card no 4 (Energy sources)
8:36 buying breakfast
8:50 coding
9:30 breakfast!
9:54 coding again
10:34 card 5/16 yay, progress
11:25 card nr 6/16 bases
17:22 Card 7/16 Towers!
17:33 need a POWERNAP!! 😉
18:03 I need a showr!
18:26 continue
19:14 tower graphics
21:40 tower logic
22:13 Card 8/16: AI!
monday
2:22 finishing the unfinished (random cards)
4:00 submitted game, go..to..bed….

I made recordings with several programs during the competition. Here are the useless details:

Stats:
80000 keystrokes (I think the tool missed some…)
2.7 km mouse movement
11,500,000  pixels mouse movement
23000 leftclick
51000 wheel
350 rightclicks

programs used:
codeblocks  17.6 h
irc/icq  3.5 h
firefox  2.9 h
photopaint  2.1 h
test/debug  1.2 h
windows  1.1 h (moving files, searching files, open,…)
gimp  0.9 h

And a heatmap where I clicked (mostly in code window, taskbar, tabs, menus)

Thats my summary of the LD #18 competition.

I really enjoyed it and will participate in the future.

If you are interested in the polished game, follow my blog dev.spunkmeyer.de or visit games.spunkmeyer.de in the future

Here’s my timelapse, for my entry “Fratricide”:

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

I’ll have a postmortem and some general thoughts sometime in the next day or two…

In the meantime, I might make a quick game for the jam too… just got an idea and I have some assets I could reuse.

Tags: timelapse

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

My entry is found here:

http://www.ludumdare.com/compo/ludum-dare-18/?action=rate&uid=1066

I just uploaded a Time lapse of the making of my entry, Illusion.

Enjoy. =]

Hi,

Since the competition is over (good luck jam people!) I thought I’d share some of the lessons I learned during the 48h in the making of HOME.

What went right:

1. I got a complete, working game. As someone who started many projects, but finished very few, this is the best thing about LD for me – I actually FORCE my self to finish this, and it rocks! It happened in LD17 as well, but this time was as good!

2. I think the style and general feel of the game is quite good, and as I intended. Everything runs fast and smooth, and has this vectorized look, which I like. Although I implemented this using sprites, it look quite crisp IMHO.

3. Music turned out to be atmospheric as I wanted it, maybe a bit boring, but it’s background anyway…

4. The code (available, of course) is surprisingly neat – it only started getting messy towards the end.

What went wrong:

1. Gameplay – I think the whole tractor beam mechanism is not fun enough, and not really necessary for finishing the game (although it helps) – this is both due to the physics code which should have been tweaked more, and possibly the general game idea.

2. The game is WAY too short, it’s not that easy (sometimes it is, depends on random values) but you can finish it in under 30 seconds if you’re lucky. not good.

3. No sounds effects! This is actually a technical issue, something weird with how clanlib handles sounds – I got the music to work after a LONG time, but sound effects were very problematic. ANYWAY – you can’t hear anything in space.

4. I wasted a lot of time of getting rigid body collisions (spheres, actually) which I didn’t use – it’s a shame really..

That’s it, I think.

You are welcome to play my game and of course, VOTE!

Can’t wait for the next LD!

Daniel

Click for the full page of notes

Phew, finished my game last night at very much the last moment.  Above is the page of scribbled notes accumulated over the 48 hours – a mixture of design ideas and remembering how geometry works.

Post mortem style words after the ‘more’ link.

The good:

My sprite drawing base code worked almost fine.  Although I did have to add a class or two to allow it to render sprites that should not be affected by lighting, such as the glowing bullets of the gunship.

Those lighting effects hid my poor art quite effectively.   Without it I could have easily spent the two days trying to get a ship that I didn’t hate the looks of.

I draw this..

..and it comes out like this

I think the basic design was pretty sound.

I’m really fond of the parallax background clouds, especially as it’s generated at runtime from a few layers of Perlin noise.

The bad:

No sound or music at all.  Just plain ran out of time for it.  Which leads on to..

Lack of feedback.  It’s fairly clear that something happens when your ship collides with something, but not that you’re punished for that by losing points.  More importantly it’s not at all apparent that a missile hitting the gunship is a very good thing.  The missile just explodes as it does hitting anything else, and if you happen to be watching your score you’ll see it jump up.  Except your score is always ticking up just from staying alive, so you need to be watching your score and taking notes.

The screen shake effect if the player collides with something.

Feedback that’s missing in the game:

A happy sound on damaging the gunship.  Display the points earned or lost as floating numbers over the location of the event. A warning sound on the approach of the gunship.  A sound on the launch of a missile.  The gunship visibly taking damage from missile impacts.  The gunship actually being destroyed if you hit it with enough missiles.

Lack of tweaking, especially to timings.  I was able to spend enough time so that I was happy with how the ship handled, but had almost no time for adjusting the timing of missile launches and when the gunship arrives.  The missiles could also have done with having their movement tweaked a little too.

I’ve not had any time to test it on machines other than my own, but I suspect that the framerate will suffer on many computers.  There’s still a lot of low hanging optimisation-flavoured fruit.

The other:

Didn’t make full use of my lighting base code.  I threw in obnoxious swirling lights for the title screen, but there’s virtually no dynamic lighting in the game.  I briefly added some on missile explosions but it was behaving oddly, and I didn’t feel I had the time to fix it up.  Ultimately I don’t think it’s actually a bad thing; graphics that compliment the game are more important than showing off fancy effects.  But does make me acutely aware that the engine is doing much more work than is needed. I could have pre-rendered the lit sprites before the game started and it would have run much smoother on much lower spec machines.

I spent the first day doing just graphics.  That should be a terrible idea, but it actually worked out not too bad.  That night I decided to quite significantly change the game’s design which would have meant I’d have wasted most of the programming work of the first day.  But I had done almost none except the graphic processing, which was easily applied to the new design.

This was my first Ludum Dare and I  made a game in a weekend.  Which is pretty exciting!

I’m going to call it good for this LD. At this point, I’ve got a long way to go before I’ve got a complete game. I don’t want to turn in what I’ve got, as it’s rather buggy, so there’s nothing from me.

It’s not for nothing, though. I discovered that 3D game dev is very troublesome on a netbook. OGRE3D is a monster to install, Irrlicht’s forced real-time clock caused big frame rate issues, and Panda3D just didn’t have the muscle I needed. I may get back to it once I’ve got a Real Computer, but it’s well beyond what this netbook can do.

I also discovered that Flash/AS3 is wonderful. Its learning curve is fairly shallow, and it’s still fairly powerful. I plan to use it in future LD’s and in my own projects.

I think I’ve finally learned my lesson when it comes to changing ideas half-way through a compo. I really created a problem for myself doing that. I’ll try harder to not do that from here on.

That said, good job to those who finished. I envy you right now.

The OSX and *NIX ports of The Lair of Fungal Wonder are up now (and amazingly required no edits to get them to compile on the other platforms – that must be the smoothest porting of a game I’ve made to date).

I’ve also uploaded my timelapse, so you can see me making the game.  The only slight hiccup is I made the music and SFX on my other computer, so during that part you’ll have to make do with watching the screensaver.  Also I didn’t think to point the webcam at my paper while I was doing the watercolours, so for that part all you see is me hunched over, occasionally looking up with a paint brush in my mouth.

I’ll do a post-mortem later.

Tags: timelapse

Woooo hoooo I finished my game. Overall it was a great learning experience and I even got to a point where I ALMOST gave up. I’m really happy that I stuck with it, got past “the wall” and polished it until it was done.

You can view my entry here and I would be grateful for your comments.

Streaming flash video, high score list, downloads and web version here:
http://www.orangeview.net/puzzabomb/

Use the arrow keys to move.

PuzzaBOMB in action!

PuzzaBOMB is a simple action-puzzle game. The objective is to lure the time-bombs toward castles which contain powerups. Collect the glowing powerups to go the to next level.

When a bomb is flashing red, it is about to explode!

Features: Five levels, including a “speed round” where the bombs get really spammy. Hand-painted textures. Music featuring me on electric bass and mandolin. Online high score database using php and mysql. Really damn high framerates. nVidia Physx rigid body physics simulation. And lots of explosions!

Programmed entirely in javascript.

There are three versions available:
– Windows (does not require shockwave: uses directX)
– Mac OSX (does not require shockwave: uses openGL)
– Online (in any browser: uses adobe shockwave)

You can get Adobe Shockwave here:
http://get.adobe.com/shockwave/

Have fun, and thanks for playing! This was a blast to make. Ludum Dare ROCKS.

I have really loved playing everybody’s games and reading your posts. This was a wonderful experience and I’m grateful for PoV’s hard work hosting it.

Kindest regards,

– Breakdance McFunkypants

P.S. Double ZOMBIE Rainbow! =)

Tags: complete, final, postmortem, PuzzaBOMB, screenshot

I’ve participated in a lot of game jams and spend many weekends not sleeping and rushing to get my prototype done. My Ludum Dare experience was completely different.

I started late Saturday and met up with a few friends who was working on their own entry. We had some coffee and started brainstorming. I had already realized that I didn’t have the whole weekend to work on my entry and I had also realized that I usually work together with people doing sound and graphics. This time I had to do it all in less time. This affected my brainstorming process and I came up with some very simple ideas. The one I stuck with was: Avoid homing enemies and make them crash into each other.

Concept draft

I’m a programmer, but I probably ended up spending more time doing sound and graphics. However, at the end of my Saturday I had a playable game. A simple game, but very playable compared to other entries. I showed a lot people the game and got some feedback. I’ve tried to sum it up:

• What do I do?
• It’s too hard in the beginning (very classic when you’re the only one who have played it)
• I don’t feel in control of what’s happening. It seems too random

I used the last day to perfect my intro screen with some better instructions and balance the beginning of the game so the player can learn the basics without panicking!  I spend a lot of time on the “straight targeting” robots (the red bullet like ones) to make it visible that they are targeting you. In the beginning they where big walking robots, but I made them into bullet like robots that pointed in the direction they were moving.

Cause the game mechanics felt kind of almost done and polished (for a 48 hour game) I started improving the visuals with shaking camera, particles, combos and pretty explosions.  I love particles and explosions!

The original concept in my head was about a horde of robots that was crazy in love with this cute little monster and wanted to hug it (which obviously meant hugging it to death), but I couldn’t really express that in the art and sound due to lack of skill so I ended up with the robots just trying to kill the cute monster. However, I kept the title  “Robots <3 Monster” 😀

Introscreen

Ingame screenshot

Ingame screenshot with combo

The final game can be found here:Robots <3 Monster entry

My game is almost finished, now that I’m working on a restful night of sleep. It’s got a heavy emphasis on the fact that it’s moddable, and as a result the actual game isn’t terribly long. I expect to get my entry up and available within the next couple hours.

Special thanks goes to LandsharkMeww for helping test the game and taking a look at its data files a bit and giving me a second opinion.

My ludum dare Jam entry is called U.F.O. where you play with a UFO which have an absorbing rays which absorb any enemy and make it a part of it so it can use the enemies powers against other coming enemies

Hope to finish it soon
ScreenShot:

Tags: LD 18 Jam

I admit it – I already had a game idea coming into this compo, and then I took the theme and merged the two.
Here’s a retrospective post on how that happened…

A bit ago I read an article somewhere (possibly on the excellent www.designer-notes.com) mentioning that Civilization’s combat is actually it’s weakest point.
There’s not much strategy in the actual fighting – it’s mostly making sure you have a ton of decent troops in the area.
This set me thinking – how could you make the combat in (the excellent!) Civ 4 more strategic? Could you add flanking into something like Civ? I thought if they got that working for Civ 5 it would be totally awesome.

Then came Ludum Dare 18, with the theme “Enemies as Weapons”.
Bugger. All my thoughts of doing an abstract arty game with no baddies, no guns, and no nothing went out the window.
Probably for the best – I’m no artist.
How about a platformer where the baddies have guns, and you don’t – you have to move to the baddy and then can use their gun? For extra depth, maybe you have to get behind them before you can grab them & their weapon?

Could be good. But I’m already making one action game… I want to make something different. Something more like….. Civ? Bing! The two thoughts came together in a crazed shotgun marriage fuelled by ginger tea:

Civ with flanking, where you grab baddies from behind, and then can use their guns

You can see that my final game differs from this in places… but that was basically how I started.

hey guys just saying remember to vote!
my game http://www.ludumdare.com/compo/ludum-dare-18/?action=rate&uid=2197

vote and play other peoples games!

Tags: vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

Not that anyone watches these, but here goes 😀

Only 10 hours left, let’s show some gameplay, while we refine it.

My gameplay video on youtube.

SUMMARY

AVOIDAL page here on Ludum Dare (for rating and comments!)

Gameplay Trailer (watch me score 1.5 million points!)

Watch my TIMELAPSE

Play the LD48 Official Compo Version of AVOIDAL

Play the Post Compo Version

I had a lot of fun this Ludum Dare! After missing the past few it was good to participate again for sure. I’ve never done one of these post mortem entries but I enjoy reading the other ones people post so I thought I’d take a crack at it.

POST MORTEM

You can read my detailed post mortem below:

FRIDAY

I had an idea within two minutes of the theme announcement. This doesn’t always happen so I’m pretty excited.  I normally spend Friday night sleeping on the theme announcement after drawing a few mockups but this time was a bit different. I had an idea that I figured would be simple enough that I fired up photoshop and drew the following mockup:

I read over my notes and the concept felt solid for fun potential as well as being in line with the scope of a 48 hour competition. For my game studio work I typically develop within the 1 to 3 week time period but I’m familiar with the 48 hour marathon since I’ve competed in about 6 or more of these 2 day game competitions. I’ve also worked on learning my lessons (failures) well!

I refine the idea into a color mockup by doodling it again in photoshop:

You can see that I’ve got the basic enemy and player elements of the final game already in place. Spike and seeker type enemies. A large and silly player character that eventually becomes a stylized robot character. The gold stars as targets for the enemies to collide into.

Having fleshed the idea out more I’m ready to open up the Flash CS4 IDE and start implementing a graphical mockup:

Now the graphical assets above are all usable as initial art once I’m finished creating the mockup in Flash. It is a really cool thing about prototyping in an IDE like Flash that I can quickly put game logic into ActionScript 3.0 files behind each of those assets.

I work for about 3 more hours trying to get a first playable prototype. Getting the first playable prototype build is so crucial to iterating on the next part of the game that the earlier you can get feedback and play the game–the earlier you will be able to see how much more you need to implement. This couldn’t be more important than in a 48 hour game competition scenario.

I manage to post the following prototype build at 2am–four hours into the competition:

You can even play the first prototype here if you want to see what I started out with.

I was very happy with what I was able to come up with at this point. I was able to know that the game idea was solid and more importantly–already very fun!  I knew that I’d sleep well Friday night and was looking forward to beginning to iterate on Saturday with a good start in the competition.

Time spent at this point was four hours.

SATURDAY

I awoke Saturday morning after about 5 hours of sleep. I checked out the Ludum Dare blog and found that a few people had played my game already and had left some encouraging feedback. This was a big morale and motivational boost as it meant more than just myself found the game fun.  I also found I had been awarded two funny LD awards: One for “Flash prototyping like Flash!” by Zlash and a second “Silver Star for Prototyping goodness” by Tyler. Thanks guys–you really made my morning!

Now today I was also excited because I was going to be driving over to Portsmouth NH for an in person meetup with some other Ludum Dare participants I had never met before. I’ve been working on getting out more into the game community around the New England area and this was an excellent opportunity to meet some other people who enjoy making games.

We met up in an awesome cafe called “Me and Ollies” and found an entire downstairs community center with AC and wifi and plenty of nice seating!

That is me on the left and billkyne on the right.

Here is a short YouTube video filmed by Jonny D of the beginning of our meetup.

The meetup went really well. It was so refreshing to be able to see what others were working on and to just talk about game development and Ludum Dare related things. I also enjoyed the strange looks I got from others in the room when we would talk about our games to each other or when I would take photographs of my food:

I ended up getting less than four hours of work in on my game but the small lack of productivity was more than made up for by getting to meet Jonny D and billknye. I was able to post version two of my game from the cafe.

I had so much fun and was inspired to drive back home after 6pm to get cracking again on my game!

Once I got home I was finally able to decide on the name AVOIDAL for my game. It took me longer than normal to pick a name this time. I like picking out unique names as well as names that often have domain name availability.

Avoidal isn’t a real word but it is in use lightly on the internet and has Urban Dictionary entries strangely enough. I decide that the low Google search noise will allow my game to eventually place well in search results for Avoidal.

I discover that avoidal.com was available and I register it and quickly setup some HTML and CSS in place on my sever to hold the eventual competition game entry. Why go through this extra effort? I enjoy crafting the entire experience for the player and I like the elegance of the idea of having my competition entry hosted on a dedicated, short, and memorable domain.

Having prepared the final destination for my game I get back to work on the actual game itself. Here is a screenshot from version three:

I spend some of Saturday night implementing SWFStats gameplay analytics. I love using an analytics package like SWFStats so I can start getting valuable aggregated play testing data to help improve the game as early as possible. It allows me to track custom metrics like average scores over the various difficulty levels and highest chain multipliers reached. Stats like that help me see graphs of what the difficulty curve is and make intelligent decisions about the mechanics and settings. I can also analyze play length data and number of views versus plays to see if my game is holding player interest or not.

I then focus on getting the bulk of the menus and game flow logic in place. I know from past competitions that once Sunday rolls around my brain will be a chaotic and spastic place. I like to handle all the mundane things like online highscores implementation, preloader and initializer, game over screens, game state tracking, main menus, pause menus, sound mute widgets and all the other miscellaneous ephemera that goes into making a polished game. I enjoy putting a high level of polish into my games so it helps to still be fresh when I implement these things.

All told I put about four hours into my game getting all the non-gameplay stuff in place. I know that tomorrow will be reserved for final tuning, final graphics, sound effects, and music composition. I am preparing myself mentally for what I know will be a long day. I head off to bed and plan on getting another 5 hours of sleep.

That brings my Saturday development hours in at this point at about 8 and 12 total for the competition so far.

SUNDAY

Final day and I am PUMPED!  There is so much left to do to bring AVOIDAL to life and it’s time to get going.

I start off by redesigning the mine asset:

Those white spikes will become projectiles that eventually fly off if the player let’s the mine explode before destroying it. Those spikes also do the most damage of any of the enemies in the game.  I want the player to be motivated to destroy the mines with the other enemies so I do two things. First the the chain multiplier goes up each time you destroy a mine. A mine has a lifespan and will eventually explode if left alone for too long. When it explodes it releases the projectiles as well as resets the chain multiplier.  The second motivation for the player is that when the mines explode the spikes move pretty fast and in eight directions so they can be quite deadly. I’m hoping that this will be another aspect of excitement and tension in the game.

In order to get my coordinate offsets and angles correct I draw the following mockup:

This will let me spawn the mine tips at the correct coordinates when the mine detonates so that it will be a seamless visual effect of the tips of the mine sprite flying off. It ends up working quite well and my Sunday is off to a productive start.

I then go through and revamp all the graphics replacing all the placeholder art.  I pick new colors for some things while others remain more or less the same. I put in animations for most of the assets.

I then spent some time to tackle the main character design:

On the left is the placeholder art for the character from the prototype. Next to that is the character I had doodled in my original mockup. I still wanted to capture the light-hearted and goofy feel of that doodle instead of the cool mathematics of the pentagon.

I initially drew the third image overtop of the original sprite in the Flash IDE. This was so I would have the dimensions be equivalent so that gameplay wouldn’t change. I couldn’t get a freehand style I liked that I felt blended in well with the polygonal style I was already working with.

I scrapped the third freehand concept and started using basic primitives to sculpt out what would eventually become the little flying robot. I even sort of think of him in my mind as being named Avoidal.

Once I saw him animated I knew that I was happy with how I captured my original intentions with the doodle of the little flapping guy with the target on his chest.

I now had all my final art in place:

When I wasn’t working on the final art for my game I was playing it as much as I could and posted two more playable builds to get player feedback and start working out balance and difficulty issues.

Here is version four and version five for reference.

Now at this point I’ve been working since about 7:30am Sunday morning and I’m starting to really feel it. I find myself zoning off into space and starting to lose track of my train of thought.

I realize that I need to grab a quick dinner since I only have less than three hours remaining in the competition and there is still final menu polish, sound effects and music to create! I run out and grab some pizza and come back and inhale it. I didn’t even have time to take a photo because at this point the game is clearly the priority for me.

It may sound weird but participating in Ludum Dare competitions over the years has really helped me to remain cool under pressure when developing. When I feel the brain-tightening stress start I remember to relax and breathe in and out. I then refocus and keep working. I find using an online todo list web app really helps me stay on track.

With just a few hours remaining in the competition I fire up the web version of SFXR and start cranking out sound effects like a machine. During this part I keep a list of sound assets I need and the game playing in the background. I tab back and forth between SFXR and my game in the browser and imagine what kinds of sounds I am going for.

Then it is a frenzied mashing of buttons and hoping I get lucky on the randomize feature. I really love this part in that it feels like I’m fishing and I don’t know what I will catch.  I score some really lucky hits on randomize as well as some old standbys from the more normal themed buttons. I import them into Flash and tie them in with code. I even take the time to add some nice stereo panning to applicable sound effects based on sprite screen location.

I also have been taking care of various other tiny polish items from my todo list. I wanted to get a slight left and right lean to the robot sprite when the player is moving quickly back and forth. I also wanted to make sure to add an instructions screen in the event that someone gets stumped and actually decides to read the instructions (hardly ever happens I know…)

I now have less than 45 minutes remaining and I fire up Reason and use my Alesis midi keyboard to layout a quick menu chiptune loop.  I compress it into MP3 and put it in place in the game.

Holy crap only 15 minutes remains to do final screenshot and upload. I’m sort of a purist in I like to have my game fully submitted by the deadline. I managed to get everything filled out in the form and turned in with 5 minutes to spare.

Now comes the relief knowing that I’M FINISHED.

Total time spent on Sunday was over 14 hours–phew what a crunch!

Total game time spent developing was 26 hours. I’m getting faster…

FINAL THOUGHTS

I’m really quite pleased with how my game came out and my weekend in general. I feel lucky to have come up with such a simple and fun idea very early in the competition. I had a playable prototype so early it really let me focus on polishing the heck out of this little game and putting in all the normal bells and whistles I’d put into a releasable Flash game from my studio. This has been my most successful Ludum Dare yet–now I just have to see how other players like it!

I have to really pump myself up sometimes to participate in something as demanding as the marathon that is Ludum Dare. I almost want to collapse or feel like I might vomit sometimes from the amount of strain and wear that hits me after working 25-35 hours straight over the two days.

Why do I do it then?

Despite the wear and tear it is just an amazing concept to participate in a global event with so many other passionate game developers. I have a strong sense of competitive spirit and I like the opportunity to demonstrate my skills and love for game development. I like feeling the inertia of 100s of other game developers trying their best and simultaneously creating awesome games!

Ludum Dare really teaches me how to distill a game down into what is critically important and make hard decisions about features and scope that I have found I can apply outside of the stringent competition to my normal game studio work.

I started my independent studio and returned to game development largely because of participating in Ludum Dare a few years ago. It will always hold a dear place in my heart because of putting me back in touch with mychildhood dream of game creation. I’m just glad it clued me into what a great game development movement was going on that I was unaware of.

I can’t wait to play all the other games here!

MY LINKS

AVOIDAL page here on Ludum Dare (for rating and comments!)

Gameplay Trailer (watch me score 1.5 million points!)

Watch my TIMELAPSE

Play the LD48 Official Compo Version of AVOIDAL

Play the Post Compo Version

Tags: as3, avoidal, browser, flash, gameplay, postmortem, summary, timelapse, trailer

I promised a lengthy post and I guess this is it…

This is a screen of my post-compo game, a few things changed. Play, comment and read the full list of changes here.

Today I spent most of my day sleeping and making the post-compo version with a few bugfixes. Next compo, december probably, I’ll use my own chronolapse that will rock, and will be out of my way. I’ll also write a tool or two that compensate for actionscrip not having templates/generics, and add a few base classes that make the flixel game development even faster.

I’ll probably do food shopping on thursday/friday instead as that is taking up too much precious time

The only other bad thing I did was not making the graphics at the start, and instead used temporary graphics for most of the compo. The good thing about this is that I focused on gameplay early on, the bad side is that I spent too much time tweaking and playing the game. With these changes I might have a showable game earlier, allowing me to get feedback from irc/other people instead of post compo feedback; and this good folks, really is the only thing that I want

Food photo times, you know you want to hit more…

Chokladboll batter and milk

Meatballs, garlic sause and rösti

Cashew nuts and milk

Newly made orange juice

Choclate chip icecream and milk

Tags: final, foodphoto, post-compo, post-mortem, screenshot

Check it out!

http://www.ludumdare.com/compo/ludum-dare-18/?action=rate&uid=1540

Architector (compo page link)

This was one hell of a weekend. This is my second Ludum dare, and the experience from the first one shows. I spent a lot more time doing and a lot less time learning this time around. Compare: LD17, The Naturalist

I panicked a bit when I saw the theme, it didn’t inspire me too much at first. But in the end it did make for a pretty funny weapons system. The end result is something like Kirby meets Sburb meets Tuper Tario Tros and they have a pixelated child in some horrible freak accident.

I liked:  Getting results faster than last time with Flixel and actionscript 3. Having music this time around, it’s pretty nice to have a piano plugged in. The little red dragon running all over the place at incredible speeds due to some bug during development.

Didn’t like: Composing music for the first time during the last few hours; I really should have practiced that. It was also a bit hard to make sure the game was playable and not too confusing. Naming this in the last half-hour.

Overall I surprised myself, I didn’t think I could do this much.

Hi people, I couldn’t make it into the main compo, so I am goint to enter the jam instead.

You move the ship (ball with a yellow star) by moving the mouse, and have to make the turrets fire at you so you can avoid the bullets and have them hit other turrets. You also have a shield (hold left mouse button) which reflects bullets avoiding damage, but it drains energy which is slowly replenished. When there is only one turret left you win.

For now there are only two simple levels implemented.

You can try a working version here:

http://www.gemserk.com/prototipos/dudethatsmybullet-webstart-release/launch-webstart.jnlp

this url always has the latest “released” version and is updated as I work.

hope you like it.

Ruben – Blog

Tags: jam, java, progress

So this is it. I started looking for ways to make my game more interesting 3 hours before the deadline, then I made 8 new maps in half an hour (you can imagine the quality work 😉 ), but finally decided that the game wasn’t fun enough to be submitted to the compo. Plus I was too tired to do all the packaging and stuff.

It’s still playable and almost fun, so I submitted Stupid Squares to the Jam (Linux, FreeBSD and Windows builds available).

I don’t want to work on this anymore for the moment, so there’s almost no change since the compo deadline. If you’re bored, you can try to create fun maps…

Tags: final, jam, screenshot

I’m at the final iteration!

Basically, the tasks I have left:

• create instructions screen
• add sound effects
• package this baby up!

In the last iteration, I was play testing and balancing as best as I could. I decided that the bat was too expensive, so I moved it down in front of the slime in terms of costs. I lowered the starting health of the Hero and gave him fewer lives. I also tweaked the level design a bit to accommodate the AI’s inability to see too far ahead. There are also victory and defeat screens now.

I finally got the AI working well enough that I realized that I wasn’t just debugging the program anymore. I was playing the game! And it’s actually not that lame! B-)

I’m glad with the JAM, I might even get something playable done this time!

So we finally submitted our sourcecode you can find the link here: CLICK

Still jamming away. Got the writing and code all done. Now I’ve just got to do backgrounds and title screen. Looks like I’ll be speed-painting them somehow (there are 13! EEP!!!)

Screenshot (sans background):

Bac-Attack is a little action based game, where you assume the role of a virally infected bacterium, and you have the ability to spread your virus among the healthy bacteria, from simply coming in contact with them helps spread the virus which can then spread even further.

So your main enemy is the antibacterial spray which a clean freak is spraying in order to make sure their house is clean, now be careful not to get in the line of the spray as it’s deadly to bacteria, which generally results in your demise.

Healthy bacteria also harms you when coming in contact with it, only slightly though as they aren’t a major threat, also when hurt you will slowly regenerate your health back. 

So LD18 is now my 3rd Ludum Dare that I’ve taken part with and I swear it’s my best yet, it’s the most finished a game I’ve developed has been (excluding games I make outside of LD of course) and for that I’m happy. Of course there are lots of things I would change now looking at the game, but that will always happen when working on a game, especially when in a little time frame.

I made the game in Game Maker 8 as some may have guessed, I’m not an excellent coder like most of you on here, but I love the fact that I can take part in this competition thanks to Game Maker, games are my life and I’m happy I can spend spare time making games in 48 hours.

I will be writing up a post mortem for the LD blog, which I will attempt to write in my little spare time that I’m not at work.

I hope you enjoy my game, and I look forward to playing everyone else’s games!

Tags: bac-attack

Who wants a wallpaper made out of thumbnails from all the LD games?

This here python script (and png for the LD logo) will generate them in various sizes for you.

example output:

Once all the jam entries roll in, I’ll run it and make a post with wallpapers in various sizes for download.

It also dumps a non-resized-for-wallpaper grid.png and an xml file containing each game’s author, game id, title, etc. that maybe someday I will have a good use for.  You can quickly customize it or update for future LDs by changing the variables at the top of the file.

It requires this Python module which you may have to download and install.

EDIT:  whoops, I had a stupid bug in the part that was supposed to center the thumbnails within their grid cells and instead right-aligned ’em.  It’s fixed if you download now.

Tags: grid, python, screenshot, tool

So this is my second Ludum Dare and I’m now declaring my first failure. My game project was too ambitious. I’ve done loads of work on it and it’s really coming together but there’s no way I’m going to be done even for the jam deadline without rushing it out and I don’t want to do that as I think it’s going to be a nice little title.

Guess I’ll post on the blog later this week when it’s done. NEXT time I will make sure it’s something I can do in 48 hours.

A patched version is now available. (only minor bugfixes/crash issues updated).
you can get the updated binary and source here:

http://pixelsiege.net/Hacking4DummiesPatched.zip
http://pixelsiege.net/Hacking4DummiesPatched_Src.zip

Please note that your vote has to be based on the unpatched compo-binary.
http://www.ludumdare.com/compo/ludum-dare-18/?action=rate&uid=2196

Here’s the time lapse for my 72 hours of development on Stop That Hero!

Tags: timelapse

I’ve been too busy at work and at home (and sleeping this afternoon ;-)) to write a post-mortem yet, but now I’ve finally got some time – so I’ll just jot down some quick lessons learned…

The previous time I participated in Ludum Dare I spent a lot of time designing a very complex puzzle game, it was so complex that I failed to complete development of the features needed to build interesting levels and gameplay… so this time round I went in the opposite direction and hardly did any design at all, fearing that I won’t be able to finish an entry. So this time round my game is pretty much feature complete – it’s just not much fun :-(!

Once I’d finished coding all the features, I found that it was quite time consuming and difficult to build interesting puzzler levels, I think this stemmed from a number of problems:

• Enemy features were not interesting enough
• There wasn’t enough interesting interactions between enemies
• I was quite tired / sleep deprived by the time I started on level design
• Designing good puzzles takes time, I think the time constraints on this competition maybe make puzzle games a poor genre choice (too dependent on good content)

I also had boatloads of problems with publishing my entry, I wanted to do Java Applet or JNLP, but I still haven’t gotten around to either – both are a bit difficult to get working, so this is something I should figure out how to do before competition as part of setting up my tool chain.

So my list of things to do differently next time:

• 48 hours is a long time (6 work days) – even if you lose 12 hours to sleep, etc. you still have 4.5 days.
• Following from the above:  spend at least 4-8 hours on design at the start (including level design on paper) you’re too tired in the last 8-16 hours to design fun levels then.
• Tool-chain setup should include testing web publishing of the game.
• Puzzle games are a poor choice of genre, rather do something more arcadish with running or jumping or shooting.

All that said, I’m still quite satisfied that I managed to complete an entry – flawed though it may be… I can’t wait for LD19 as I definitely have lots of room for improvement!

I finally made it ! Abemus windows binary. Now you don’t have any reason to not try it out 8)

bye

Just made these two videos. One is the timelapse video I took to show my development process and the other is to show off the gameplay for those that cant run flash (Linux) or dont want to actually play the game, just want to see what the fuss is about 😛

The timelapse was produced using 2300 ish screenshots, one taken every 60 seconds by Chronolapse.

Enjoy:

Timelapse

Gameplay

You can play the game here: http://mikecann.co.uk/ludum-dare/ludum-dare-hour-40-complete/#thegame

Tags: 48 hours, game, timelapse

Yeah I ‘finished’ in time for the Jam! (Okay so I just tacked on lives/game over, and avoided all polish I’d hoped to add, but it’s fully playable now!)

I hope you enjoy it

entry page

Made timelapse and gameplay videos. Even though I didn’t have enough time to finish the game this LD was lots of fun again for me

timelapse

gameplay

Here’s a well known method to not achieve much of a tangible result for LD48; try to learn a new tool from scratch during the compo. In my first hour of coding I decided, what the hell, let’s learn how to use the Akihabara HTML5 game engine … Actionscript, Javascript, all the same to me ….

Akihabara appears to have no official documentation at this stage, hence I spent about 4 hours trying to learn how to use it properly by following the examples and comments in the demo games (namely a Pacman clone ‘Capman’, a shump ‘Solitude’ and a simple Zelda-esque RPG demo). Only when I was about to quit and fall back to using Flixel instead, did I think to search for a tutorial .. and found this excellent one (which doesn’t appear to be linked from the main Akihabara site. Hmrph. I’d also bookmarked it 3 months ago and forgotten. Double Hmrph).

Examples like swellmades ‘Attract‘ make me wonder if I should have bothered trying to use an HTML5 game engine at all.

Tags: post-mortem, postmortem

After hours of hectic development by myself, Bartbes, Roybie, Textmode and thelinx, the LÖVE-PARTY is proud to present: Fistful of Beef!

Click the pretty screenshot to see a gameplay video!

As was explained in a previous post, the objective is to destroy all cattle by catching a bull with your lasso, swinging it around your head and smashing all the other bovine scum to pieces – preferably as quickly as possible!

We were off to a horrible start, and after the first 24 hours, none of us really thought we’d get anything done in time. But here we are, some 45 hours later, and we now have a pretty cool little game! A proper post mortem will be posted tomorrow, but for now, we’d just like to get some sleep. Have fun playing the game and please do leave a comment.

Go play the game!

The LÖVE-PARTY, out!

Tags: final, Fistful of Beef, Love, the LÖVE Party

A bit late to post this, but I thought the submission entry would show up on the blog. 😛

So yea, the game is finished and submitted. You can play it here: http://www.ludumdare.com/compo/ludum-dare-18/?action=rate&uid=2311

Enjoy!

Timelapse: http://www.youtube.com/watch?v=IIOyWFkWTdw

Tags: finished, timelapse

My girlfriend’s sister was in a fairly bad car accident last night, and is in the trauma center of the local hospital as we speak (or type, really). I’ve gotten nothing done today, and there’s no chance my team will be able to finish in time as a result. I really like our game though, so it’s likely that we’ll complete it and post it up here afterwards, just for kicks.

Peace, all.

Some stuff came up today, and I didn’t have time to do anything whatsoever with my game. So it doesn’t look like I’ll have anything for the jam tonight. Oh well

Here’s a final playable build, from what I had finished up last night! I decided to embrace that placeholder music and use the rest of the loops from the game it’s from, which, as it turns out, is kinda thematically similar to what I’ve got in mind.

Again, good luck to everyone racing to have something finished up tonight

So what happened was this….

I tried to make and RTS right….Yeah. Anyways, due to alcohol, illness and guinea pig births. I was unable to finish in time for the compo, but i figured hey, I’ll get it in time for the Jam. Then I discovered my game sucked, the logic was borked and AI + Turning Circles  = HELL.

So I started again… like 5 hours ago…. and here is the result. Credits to go mkevin747 for CC image of the Demon. Really made my day 😀

FROM THE CLUTCHES OF SATAN HIMSELF (windows)

Title Screen

In Game

Hi all

I won’t finish my entry in time cause live got in my way…

I will finish the game later so and will post it here when it’s done

(id software style)

here is a short timelapse video:

So now that everything has settled, I’d like to take some time to explain the process that went behind making Fromulus.

Firstly, I spent most of the time disconnected from the internet.  This wasn’t exactly on purpose, but I think it helped me focus a bit more.

The competition started at 9pm my time, and I devoted the first night to ideas and sleep.  I came up with a few decent ideas, which I blogged about earlier.  I settled on Fromulus as it seemed like the best option.  I woke up a bit later than I had really intended, but got to work fairly straight-away on art.  I did all of the art in one sitting, which was probably close to 8 hours.  Most of that was playing around with different styles for things.

Originally, the grass was a standard green, and the ground a purplish-brown.  I opened up the hue editor in Photoshop and played around with it until it became red.  For some reason, it just seemed a lot better.  You compare:

Red vs. Green: Fight!

After choosing this odd palette, I decided that I needed some equally weird plant life.  I decided to go with spirals, as they were very visually pleasing (to me, anyhow!).  They were a bit of a pain to do, but I think it was worth it.

A very large bulk of the time then came doing animations.  I drew the Slimer first, but ended up redrawing him later as his animation didn’t look great.  Next came the Chomper.  Each has two animations, and fits into a 16×16 block.  The ice cube and fire graphics are just drawn on top with code.  When I get more time, I will likely draw each type of creature on fire, to make the animations look better.  Here’s what the Chomper’s spritesheet looks like.  The first row are of him walking, and the second are of him getting thrown back.

Chomp chomp chomp

The largest animation is, of course, Fromulus himself.  He has five different animations, which all needed to be smooth, as you obviously see him the most.  His death animation is the longest, at 10 frames.  Here’s what his spritesheet looks like.  In order of rows, the animations are: walk, cast, jump, fall, die, and then the rest of die.

I am a wizard!

I had very clearly two images in my mind:

1. When he falls, his robes needed to fly up.  Although there isn’t really enough room to show some boxers with hearts on them, I did manage to show a little skin.  (How’s that for ‘humor?’)
2. When he dies, he should disappear and his hat should float down.  This is definitely my favorite animation.

On to the coding portion, things went relatively smoothly.  I used the wonderful flixel library, with which I am very comfortable, as I have been using it for quite some time.  I made a poor choice in map editor decisions and went with one that is a little flaky (Wasabi M) over Ogmo Editor, just as it was easier to use the maps straight away with out delay.  Ordinarily, Wasabi M is a great editor… however, this time around it had all sorts of problems, namely not letting me see the entire map and then, towards the end of the competition, eating the map that I had drawn out.  So, in the last minutes, I scrambled to make the map you see now–which is why it’s not very good at all.

I actually made some sound effects, but you don’t hear them in game.  Why is this, you might ask?  Well, sfxr only makes wavs, and I didn’t have any software to convert them to MP3.  I tried an online converter, but Flash wouldn’t take the files.   So, I will fix that in a later version (or just embed the sfxr player into flixel).  This really made me mad, but I didn’t really have any time to keep fussing with them.

Before the competition started, I played around with musagi to see how to make chiptunes.  The plan was that if I had any left over time, I’d write a track.  However, before the competition even started, I came to a grand realization: I really, really suck at making music.  So, I gave up on even thinking about trying it.

Anyways, that’s pretty much the tale of making Fromulus.  I enjoyed the experience thoroughly, and will definitely be competing in more Ludum Dares as I can.

Edit: removed responses to things on the voting page, as I see you can make comments there.

Now the part you’ve all been waiting for: here’s a shot of what I’ve done since the competition ended:

Look ma, I have the fire spell selected!

As I couldn’t make my game in time for the compo, I will try to finish it for the jam.

My game is very simple, grab enemies with right mouse button and then shoot them to other enemies with left mouse button.

Here is a screenshot of the game, in the next hour I will try to improve a bit the graphics because current graphics sucks 😀

If you want to test it, please follow the next link: GrapplingHookus

It took a bit of research and a bit of waiting but my time lapse for Cat Splat! is available.  IN HIGH DEF!

48 hours of game competition, ~24 hours of development compressed into… 6 minutes!

Cat Splat! Time Lapse

Ignore the black bars, that’s me working on my macbook instead of my iMac

Sorry I couldn’t submit a separate entry so I’ve just tagged it alongside my compo entry (it’s essentially unrelated to that).

It’s called Enemies A. S. Weapons and you have to kill that guy with that name by picking up bullets lying around, of which bullets are your enemies.

Made in 15 minutes using MegaZeux, you’ll need that to run this (it’s open source, you’ll just have to go hunting for it on sourceforge or something).

http://pubacc.wilcox-tech.com/~greaser/stuff/ld18/easw.zip

Although it’s not as finished or feature-complete as I would have liked (what is with Ludum Dare), here’s my jam entry Cannonon. A simple top-down 2D shooter where you hack weapons to take control of them. Includes 3 simple levels and two different types of weapons.

View the entry here or play it here.

I’ve just submitted my Revenge of the Living Dead “enhanced” version to the Jam, thanks to your feedback! Now it has a “compass” to guide you to the nearest human. Also fixed a lot of positioning bugs and improved the graphics a bit. Here’s the entry link: http://www.ludumdare.com/compo/ludum-dare-18/?action=rate&uid=1572

Well, i was going to enter an updated version of my game into the Jam, but it won’t be finished in time :/.
But do not despair! it /WILL/ be released, but not as part of the competition (‘ll add it to the current entry, etc)

I finished in time, yay!

😀

I apologise if there are any bugs… as I have had no time to test it! Also, I would like to spend more time on the artwork at some point, give it a proper proof read (ANY proof read), and make some music… But for now, this is it. 😀 (It’s really, really stupid. I apologise.)

So I managed to wrap my JAM entry! My good friend @DirkRugged helped with the artwork and @IamGreaser composed the music this afternoon. Hope you like it!

As promised, wallpapers of screenshots from all the LD18 games:

• 1024 x 768
• 1152 x 864
• 1280 x 768
• 1280 x 800
• 1280 x 960
• 1280 x 1024
• 1366 x 768
• 1440 x 900
• 1600 x 900
• 1600 x 1200
• 1680 x 1050
• 1920 x 1080
• 1620 x 1200

(Want the Python script that generates these?  See this.)

Tags: grid, wallpaper

A little late uploading but I’ve not made a timelapse with quite so much in it before so that’s why =p

• Play/comment/judge/whatever The Game
• Watch the timelapse
• See all my LD18 posts (with progress builds of the game playable)

It was really fun making games alongside you guys again (even if I do frown a lot in the timelapse lol)

in unrelated news, I’ll be posting an announcement regarding the september mini at the end of the two week judging period, but the date will be the last weekend in September, so keep it free (and find a friend who hasn’t worked on a game before, they may come in handy for my rules )

Tags: timelapse

This entry was posted on Tuesday, August 24th, 2010 at 3:29 am and is filed under LD #18 - Enemies as Weapons - 2010. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

This is a dissection of my LD18 entry Architector which details some of my design decisions and processes, good and bad. Hopefully this can be helpful to someone.

I was the only one testing this game, and I only did very short testing sessions. This makes for a very hard game.  I didn’t see things like the player’s survivability or how hard it could be to scale a high tower. The double jump was actually a last minute addition that proved to be very necessary to facilitate climbing.

Killing enemies is what makes the game advance. This is meant to keep the player in the action and to keep them from avoiding the dumb enemy AI too much. I struggled between this and time-based block dropping which would have put an emphasis on survival, but I felt that the sudden shifts between the gun mode and the block mode needed to be under the player’s control somewhat.

The game feels a bit slow to progress; the goal is pretty high due to aesthetic decisions and the blocks are a bit short. I am considering having multiple blocks drop in a row for a post-competition version.

The camera is a frequent complaint. Due to some limitations in the framework, I could not have it zoom out, which would have been best. I instead opted to have it be under mouse control. In gun mode, this makes for difficult aiming when the player is moving, which encourages the player to stay still while shooting.

One hurdle was making the falling blocks not too confusing to control. The layered colors in the sky give a sense of height, and the camera control helps give a better sense of the surroundings. Still this is no replacement for a good zoom out.

I had to make the blocks so that the player would not get stuck too easily and could make something scalable. The blocks collide on their background tiles, which creates space between the tiles the player can interact with.

Scaling the tower is facilitated by the double jump and the dragon, which can be used as a rocket pack by firing it downwards while jumping.

A good platformer jump is a tricky thing: it needs to happen right away, but its height must be controllable. I do this by making the gravity lower on the player when the jump button is held down.

There are three kinds of enemies in this game: the flying fish, the bat and the dragon. Enemies are the first thing I programmed into the game; the blocks falling and tower making dynamics were an idea I had when I saw Lame Castle, Skyscraper and build the level you play in the suggested themes. It’s also a bit of an homage to Homestuck.

The bat homes in to a fixed distance from the player, which varies from bat to bat. Its quick scattershot is hard to avoid but deals low damage. This, coupled with the fact that it keeps its distances and that none of the weapons are good against far away targets makes the bat dangerous, hence its low damage and health. In the player’s hands, it becomes a  low damage scattershot, good against other bats and groups of enemies.

The fish fires bubbles which float upwards, making it dangerous to enemies above. It deals a lot of damage but can be difficult to use against ground targets. As enemies, they slow the player’s ascent; the floating bubbles miss often when the player is bellow, but when the player is above they are deadly. This makes it dangerous to move past the flying fishes.

The dragon is the only ground enemy. As such I made it allergic to being too far below the player. It drops from the sky like the rest. It walks towards the player, periodically jumping to navigate the terrain. When it’s near enough it locks in on the current angle towards the player and waits a moment to fire. This makes it possible to avoid it by going behind it. As a weapon, it becomes a short range flamethrower/jetpack.

Am I missing anything? I’d like to know where I am right and where I am wrong.

It’s been more than a day since the end of my first ever participation in the 48 hour Ludum Dare competition, and it’s time to take a retrospective look at what I did. The goal here is to spot where I made mistakes, where I did well, and what I can do differently in the future.

Let me start off by saying that I’m already very proud of how well I did. This not only is the first ludum dare I’ve done and completed, it’s also the first non-trivial game project I’ve undertaken and completed. That being said, there’s still plenty of room for improvement. Let’s see what happened after the bump…

What Happened

I started off this competition hatching out a lot of ideas in my notebook within the first few hours:

• Dwarf Mage Mind Control
• Bomberman Spinoff
• Sumo Vs. World
• World Domination (Political)

The astute reader will note that my game idea is nowhere on there. What I ended up doing after I came up with that set, though, was ruled out ones I thought were too ambitious, or too uncreative, and revised some that sounded too generic. So Dwarf Mage Mind Control became Trance Cat, and the rest were ruled out, mostly due to overambition.

I was planning on referencing Futurama’s Hypnotoad by modeling the main character of the game after it. I quickly switched gears however, for a different idea. I wanted to insert some social commentary into the game by unsubtly using memes as the actual weapons of the game, and how memes would affect the enemies by turning them into enemies of your enemies. Thus, trance cat became lolcat.

At this point, I had the basics of my game idea down. Everyone loves lolcats, I said, and these memes are also quite hilarious. The enemies would be zombies of various schools of thought, (an oh so subtle commentary here,) who are placated by “lolisms” and other cute or funny moves that my cat would spout or perform, and would subsequently fight to protect their beloved lolcat. This was going to be a game about survival. If you beat the clock counting down from ten minutes, then you won. There was also to be an unlimited mode, where you just lasted as long as you could. As you played, the music would get faster and faster until it reached a nearly incomprehensible tempo, hopefully ratcheting up the tension as the enemies came at you faster and more often.

So I began work on the first day, a mere 2 hours in, everything sketched out on my notebook or my whiteboard. (Sorry for the lack of pictures, I have no camera.) My first task was to make sprites for the cat. To do this, I decided to look for some rotoscoped cat animations and reference them in my sprite creation. For this purpose, I found this little gem that was most helpful. You might even recognize it if you’ve played my game and I did well enough in drawing.

I think in retrospect that this was the first mistake I made, even if I still wonder what would have become of “trance cat” a la Hypnotoad. I spent over half of my first day just getting the animations of my main character down. After that, I realized far ahead of my scheduled time that I would have to make feature cuts due to the amount of time left. I cut the number of attacks or moves that lolcat could do from 6 down to 1. I cut the number of types of enemies from 6 down to 1.

Now I began setting up the code to make all this work, and by the end of the day I had a fairly reasonable beginning, and I was confident that I could still finish this. Happy at this point, I slept.

When I awoke, I decided to get to work generating the attacks for lolcat’s “lolisms” that he would spout, his only surviving attack from the original 6. I generated 42 different known memes, meta-memes, or silly self-references in the form of words that would appear over the lolcat when he attacks. This was my second mistake, in my mind. I spent way too much time doing this, (probably about 3-4 hours), and even researched memes a bit when necessary from knowyourmeme. “Cheat! Charlatan!” you say, well, you may be right.

Now, armed with the attacks, I could finally have some integration in my game between the NPCs and the main character. I got the zombie placating working, and began to circulate my first “playable” build. This is when the “Oh god the shit has hit the fan” realization moment began to happen. I hadn’t even begun to work on the game logic like winning and losing and even just making it fun, and we’re well into the second day.

To make things worse, the consensus was that the lolcat’s attacks were not having the effect that I had originally hoped. A sharp player (MikeP from gamedev.net) noted that while these memes and such were funny, it was usually because they were in context, with an accompanying image, music, or some other media. He was totally right. Here I am thinking that just referencing the memes was funny, and my lolcat just looks like an idiot for it. Another smart playtester (Sargon, also from gamedev.net) noted that it would be funnier if the zombies went flying off after I attacked them, and collided with each other on the way. The message was loud and clear. The way it was now was too boring, and there was little time left for very radical ideas.

So things had to change, and fast. There was just one problem. Actually, I lied, there were two problems. I still had to sleep soon, and I also had to do a few hours of Real Life Work after that. This was midway through the second day, so this left me about two hours to complete my game.

Things were not looking very peachy.

After I got back from work, I entered a frenzy the likes of which would make a salty sailor gape in awe. I had even less time than I had hoped, just about an hour and 40 minutes.

In this time I altered my plan; I decided to leave music until the very end, and focused on getting the enemy vs. enemy collision working first.

This was relatively easily done, considering that I was at this point writing desperate brute-force hacks at lightning speed.

10 minutes later I had them simply canceling each other out instead of flying off all happy-faced and awesomely. This will have to do.

I moved on.

Now I had to have a new attack. I settled on something simple, and quickly drew up a little blood spouting out sideways.

It looked like I had used MS Paint.

I motion blurred each frame, made it work, and moved on.

I had 15 minutes left.

I quickly hacked up an endgame scenario. A “You died” screen. I began to construct a notification of how long you lasted, and then…

Time’s up!

It was over. I was done. You couldn’t win, but you could lose, and that would have to be all.

I built my port with py2exe, submitted my build and source, and realized that in my last test of the end-game screen, the notification of how long you lasted hadn’t even showed up. I’d messed up.

Too late now.

The Aftermath Inspection

I think that I made 2 key mistakes here. The first of which was spending an insane amount of time on doing the animation of the cat. It looks great, except for animation problems, (and a duplicating sprite bug that I wasn’t able to track down before time ran out), but there was no real reason that it needed to be so detailed.

The second problem was spending so much time on an ineffective attack, generating a bunch of images that I didn’t even use. There’s just no real reason to spend so much time on any one thing in a competition like this.

These mistakes cost me precious bugfixing and polish time later on down the line, and in reality then were at least a double-whammy, especially if they were cut.

I’m sure I made other mistakes. I suspect that my idea was not funny enough. This will have to be worked on by improving my funny bone, or brainstorming process, or both. I also don’t like now that I’d not had much of a base of code to work from, but this can easily be fixed over the coming months.

Speaking of Fixes…

So what can I do next time, to do much better than I did this time?

I’ve decided to do the following:

• Build a Good Foundation
• Keep It Simple, Stupid!
• Practice Concurrent Time Management

In order to build a good foundation, I’m going to have to spend time between competitions polishing my existing code base, making it extensible, reusable, and of course free to use by others before the competition.

In order to keep things simple, I’m going to have to not go overboard in my planning stages. Deciding to try and capture the live movement of an animal by drawing each frame agonizingly in too much detail is murder on time. Having quantity over quality is a time killer, and makes for a shoddy product as well.

In a previous post made before the competition started, I laid out a sort of time-frame for working during the competition, compartmentalizing designing, working, analysis, fixing, and polishing.

Things didn’t happen even close to that after the first design then work stage, and the second day beginning analysis stage. I quickly found out that after I did something really stupid, I had to react immediately, and not just wait till the next analysis stage and plod along meanwhile as if everything was hunky dory. In this spirit then, I’ve decided that while some of it was good for the initial planning and second day broad analysis, I’m going to try and do more concurrent time management, or at least fake that by having more micro-cycles of design, implement, polish. In these micro-cycles, I’m going to have to keep one eye on the big picture as well.

The Big Picture

Even after all this, I feel like I’ve won simply because of what I’ve learned, and the improvement steps that I will have to take before the next competition. The feedback I get now is just cake on top, even if they quite rightly call my game a hunk of shit. I’m enjoying playing other peoples’ games, and leaving some notes on my experience too, as that is broadening my horizons with regard to game design; This is altogether unexpected, but not unwelcome.

If you’ve made it this far down, congratulations, and I hope that you got some use out of what is a personal analysis for yourself. Thanks for reading!

-AndrewBC

P.S – Leave a comment if you have some useful tips, observations, rants, or some cookies for me!

Well, after somehow getting through Monday without actually falling asleep at my desk or something, it feels like the time is write for a bit of a general LD18 retrospective.

First off I want to say a huge thanks to everyone for making it such a huge and brilliant event. I had a really great time. This goes double for PoV, who made it run so smoothly despite being too busy to actually enter; and to the crowd in #ludumdare that made sitting in a room on my own for two days a far less antisocial way to spend my time than you might expect.

Speaking of sitting in a room on my own for two days.. Here’s a video of me doing just that. Apparently I fidget a lot.

Right, Post Mortem Time. I’ll put it behind the break so I don’t need to worry about spoilers. Or in other words, if you haven’t played my game yet, try it now 😀

During voting Enemies and Weapons was just about the only theme that I really didn’t fancy making a game for. Typically I try to make non-violent games, less for any moral reason, and more because they’ve been done before in so many different (and sometimes excellent) varieties. I was distinctly un-impressed when I woke up (at 5am!) on Saturday, and blinked blearily at the theme.

Given my initial reaction I was surprised to find a game idea I liked relatively quickly. I started off trying to find ways of putting a non-violent spin on the theme. I couldn’t find a metaphor that fit well enough, and I liked, so the non-literal approach wasn’t going to work. I then came up with the idea of a game in which the enemies are weapons and you desperately wish they weren’t. The prase “reluctant pacifist” stuck, but from early on I had this quite strong vision of a stereotypical game-y beefcake soldier, who is trying (and largely failing) to prevent his actions from destroying a (comparatively) innocent army.

The game ended up being a bit more violent than I’d initially planned, but the comedic bouncing of the enemies made that entirely worthwhile. I think/hope that, when played the pacifist way I captured a certain amount of that initial concept.

What went right:

These were to an extent a happy accident, originally I was going to go forth and just stick some regular shooter bullet spray fighting mechanics in, but, lead initially by the crouch-to-fire animations I put in I came up with something a lot more medative, and mechanically deep. I’ve stuck the game on newgrounds and kongregate, and this style hasn’t been winning all that many fans, but I don’t care, because *I* like it.

Over the last year or so I’ve been building up some real comfort and familiarity with a smallish set of tools, and now it’s really paying off in heaps. The reason I managed to find so much time to work on bits of my game was that I didn’t have to spend a moment thinking “How do I do this?!”, I could just get on with doing it.

It wasn’t a comic game until the first moment a dead enemy bounced about spinning wildly. That moment was basically the core moment the final mood of the game was decided, and it’s a mood I don’t generally strive for; but that I’m really happy with.

What went wrong:

The biggest problem with the game from my perspective is that the “get hit by a bullet to ‘jump’ higher” mechanic is too challenging to pick up from just observation. It is also a bit too challenging to actually execute sucessfully. A lot of people have quite reasonably been saying “You can’t get back up!”, and it’s something I really should have anticipated and dealt with.

Whilst I do like the idea of decending and re-ascending themeatically, combined with the previous mechanic it lead to a situation in which the difficulty spikes *massively* at the halfway point. This is plain old fashioned bad design, at that moment the difficulty should be going down not up for a moment, but the level layout I chose made that a little unworkable. Live and learn I guess.

Anyway, I think this might have been a little bit epic. Congratulations if you got through it all!

Till next time o/
Jonathan Whiting

Sorted out some issues that were breaking the Linux port (CTD and corrupted font). Unfortunately, I had to change the font to achieve this, since a bug in the library I was using to render fonts caused the original font to be displayed completely wrong! I’ve updated the Windows version to use the new font, so every version looks the same.

Linux port

Alpha Channel

OS X port will be with you ASAP, as soon as a friend on a Mac comes online so I can bully them to build the .app file

First, I thought it might be worth posting all the images I made for the game:

(I’ve hidden one image above the second ship to avoid spoilers)

This LD was pretty much a dream.  I’d already decided I was going to be using watercolours for the graphics (since I’ve been painting with them quite a bit lately), and then on seeing the theme I had an idea for a game that would really benefit visually, and tie into my current reading habits (again, Jeff Vandermeer’s City of Saints and Madmen).  From there the whole thing went incredibly smoothly, with no major roadblocks.

What went well: The graphics, obv.  I’ve only just started to find my feet with watercolours, and they were perfect for this game.  I also really like how the game environment reacts to the player’s actions and starts fighting back if they start destroying the fungi.  That’s something I’d like to explore further.

What went not so well: The explosions when a fungus or the player dies.  They’re just rubbish.  I think the coloured particles are all wrong, and also I need to improve my particle generator; it’s just too simplistic as it is.  And while I think the music is basically perfect, the SFX are really clumsy.  They’re a mix of recorded and synthesized sounds, and they don’t really sit together.  I think I need to study foley techniques to get better at this sort of thing.  Also the endings are a bit perfunctory; I should have probably had some images or animations rather than the simple wipes accompanied by text.

Oh, and I’m not sure if I made it clear enough that there are essentially two styles of play: peaceful (scan all the fungi) and destructive (destroy all the fungi).  This was related to the whole business of the game environment reacting to your actions in a smooth manner, so it’s fairly benign until you start to poke it with a stick, at which point it becomes increasingly hostile.  i.e. the point where you collide with a spore and start destroying fungi is the point at which your mission goes bad, and it becomes all about survival rather than scientific research.

What I’m unsure about: The difficulty.  Judging difficulty’s always hard, and from the comments I’ve had so far it may be too difficult.  I’m not sure if anyone’s seen both endings yet?  But then my benchmark for difficulty in this kind of game is Hydorah, which I’m rubbish at, whereas I can easily beat my Lair.  So, yeah, I’m not sure.

The Future?: I might possibly do more with this setting.  Certainly the visual style is worth exploring some more.  And (perhaps because Vandermeer’s book currently has such a hold on me) the whole idea of basing an environment around fungi seems incredibly rich, and full of potential.  We’ll see.

Oh, and fwiw I’d definitely recommend other people try the watercolour route for this kind of competition.  I found it so easy to create graphics that looked good (and unique).  Just draw some simple shapes (pencil), then pick a couple of colours and let them blend together on the paper.  Really I spent more time waiting for the paint to dry (during which I got on with other things) than I did painting.

Tags: postmortem

I’ve updated my submission to include a post-compo edition, with bugfixes and some new features. list at submission page
http://www.ludumdare.com/compo/ludum-dare-18/?action=rate&uid=1844

Sorted out my OS X port at last! Sadly will only work on OS X 10.6, but that is a limitation of the package system I’m using, not my code. Honest

Alpha Channel

Many thanks to Deps for building the application, since I don’t have access to a Mac (incidentally, his excellent entry is even better than mine!).

It seems that the windows version of PySFML was compiled incorrectly or something. By recompiling PySFML from source, I believe that my game should now work fully on windows. If you are able to test, please do, the game’s post is here. Make sure you read all the instructions as the game can be quite confusing otherwise.

As you may recall, last night with three hours to spare, we managed to finish and submit our game Fistful of Beef for Windows, Linux and Mac OS X. After a good nights rest, the LÖVE-PARTY has had some time to reflect on the last few days and the work that has been done. As such, we felt it may be fitting for us to round off our participation in this Ludum Dare with a post mortem, and sharing what we’ve learned.

In a previous post, we mentioned that we spent the first 24 hours doing nothing constructive other than putting together our intro screen. There were a few reasons for this:

1. We didn’t have our workflow set up. We hadn’t decided on what frameworks and libraries to use, so for the first 8-10 hours we were trying to use a custom framework that only one person really understood. After deciding that it was rubbish, we switched to yet another -even stranger- framework that I don’t think anyone at all understands. It wasn’t until after 24 hours that we decided to rip all of the complex stuff out and replace it with something with loads of documentation that everyone could grasp in minutes.
2. Our team structure was unclear. Our team was originally far too big. I think that we were originally going to be 7 or 8 people. It’s really, really hard to manage a group like that. Especially when you’re spread out across timezones. It wasn’t until about half of the group had defected that we could really start focusing and getting things done. If your group is larger than 3 or 4 people, I would advice splitting it into two groups instead.
3. Coordination problems. This ties into the above mentioned point, but it can be equally as much of a challenge even in a smaller group. Because we were spread out all over the globe, some people were never around when the “core” of the team were awake. While we were unconventionally organized with proper game design documents (okay, so maybe not proper design docs. But they were better than post-it notes.), it was still hard for everyone to know what had been done and what was going to happen next.

It wasn’t until we had solved all the above problems that we were able to get started, but once we did that, I’m amazed at how efficiently we worked and how everyone stepped up and took care of what needed to be done. The team did great and I would certainly not mind working with them again (albeit in a smaller group). I’m very much looking forward to participating in another Jam, but I hope that in the future there will be a competitive version of it. Making games together is damn fun, but it does feel a little anticlimactic to have worked so hard and then just have your game sit there.

As for the game itself, I’m pretty happy with it. In the best of worlds, I would have liked to have implemented a highscore and prerferably a way to upload that highscore to a central server, but what the hell. It’s a game about beating bulls down to a pulp.

Before signing off, I would just like to thank all the LD:ers for an amazing time. I would also like to thank all the members of the LÖVE-PARTY for their hard work. And finally, to my incredibly supportive girlfriend who kept comparing my cowboy hat to a vagina and my bull to a turd: I will have my revenge…

It's not a vagina nor a turd...

If you want to try the game out, go grab it from the game page!

Tags: Fistful of Beef, Love, LÖVE-PARTY, post-mortem

Ok, I give up. I tried (again) to do a double timelapse, merging screenshots and webcam pictures into a single, hey-this-is-what-I’m-doing-and-what-I-look-like-while-I-do-it kind of video. But I can’t for the life of me get the timestamps to line up. If it helps, think of this as two timelapses of my writing this game which may or may not have been made at the same time. Anyway, my timelapse for Double Bounce:

I can't figure out how to embed YouTube videos on WordPress, so...

I spent several hours this afternoon trying to put together a trailer, but I can’t seem to get anything out of CamStudio that is A) not terribly encoded and B) readable by iMovie. Any tips?

Tags: timelapse

I created Undermine in 48 hours, and for 24 of those hours I was an hour and a half away from home, attending a wedding.

I really liked the experience Ludum Dare gave me, from the first moments of brainstorming while watching Robocop for the first time to a character with no attacks and enemies with abilities that could be activated by pressing buttons on their various sides… and then on a tangent to messing around with a slide ability (for the hell of it– it was fun!) to popping up under enemies. And then the SPACE INVADER.

Anyway: thinking of an idea, drawing on past concepts (I had a similar concept a long time ago, about a giant boss enemy flying around in the sky while you platform on the ground as it attacks you and you attempt to destroy it using occasional fixed rocket launcher emplacements), making graphics, making music, and making code all in the span of 24-48-ish hours is really amazing!

The limited time meant I knew I’d never have to worry about feature creep (at least not for this… cycle of development life) or ‘what if’ or procrastination because oh look there’s the deadline! Looming!

That said, while I got a lot of focus, I didn’t give up any regular habits: I still went to the wedding, I still had a regular amount of sleep (perhaps not a ‘good’ amount of sleep), and I still ate when I would have.

~

Anyway, I ended up with Undermine, a flash game that I am ultimately very proud of. It’s short and sweet and not without its imperfections but certainly to the point. It definitely isn’t for everyone– but then again, what ever is?

I’ve spent two months on a game, two weeks on a game, and now two days on a game; thanks for existing, Ludum Dare.

Greasemonkey, I’ve noticed in the comments you have spoken against using flash libraries such as Flixel and FlashPunk for retro games with pixel art.

I was wondering why and what you would recommend instead (anyone else is welcome to chime in if you have an interest in the subject of course)? I think people like those libraries because they are so damn easy – no dll hell, etc. Is there something better out there?

I was pretty impressed with what notch did with just the standard java in making his pixelly platformer so I’m sort of torn about whether a framework is really necessary or useful.

So I thought I’d take a quick look back at my first experience of a Ludum Dare event now that I’ve fully recovered from what the final push did to me! I ended losing about 10 hours of my 48 to my day job: combined with my inexperience in producing something in such a short space of time… well, it was certainly a challenge.

Overall I’m very pleased with how this weekend’s development of “The Robots and I” (link) went: I genuinely feared I would fail to have anything to submit by the deadline, but I managed it. At the same time there are so many little additions/improvements I would have liked to get in there that could have made a difference.

FAIL

Success – Concept. I had my idea within a few hours of seeing the theme and quickly committed to it. I knew I had to do this to have a hope in finishing my entry, but if I had not been able to turn the idea into a game I could be content with it would all be for nothing. Thankfully the idea remained pretty rock solid in my mind.

Success – Productivity. With my time limited (and a history of losing motivation in my own little projects), I had to get my head down and produce. And for the most part I did! I was very happy with how my “shifts” at my PC went. With the possible exception of the last hour-or-so when I had become almost delirious with mental fatigue. Hey-ho!

Failure – Missing features. There’s no doubting the game is far from clear on what you have to do when it starts and this has been called out to me by most people who have given me their opinions on it. I had planned to have some sort of help text guiding you to your first “hack” but, like several other features I had hoped to get in, didn’t make it due to time. It also might have been worth adding a couple of alternative maps to mix things up a little.

Failure – Tweaking/polishing. While I obviously couldn’t have justified polishing when the core game was not yet completed, I regret to some extent that I wasn’t able to afford any time whatsoever to getting the game playing a bit nicer and looking a bit more interesting. I think a little bit of work on the player movement and interaction with the robots could have had a big impact.

I may return to this game shortly to try making it into something a bit more fun and rewarding to play, but right now it serves as the end result of a greatly entertaining and educational experience that I’m sure to build on in future. Bring on LD19! 😉

I want to thank everybody who tried out my Ludum Dare #18 entry, Infiltrator. In particular, special thanks to those who took the time to comment and vote on my entry. You can still play/vote for my game right now, just click on the banner!

This was my second Ludum Dare, and despite the warnings from senior Darers plus my own analysis of my previous performance, I ended up making a few old mistakes and plenty of new ones. I’ll cover that in…

ChainedLupine’s post-mortem for Ludum Dare #18: Infiltrator.

First 12 hours – Friday night to early Saturday morning

Friday was relatively uneventful. When the theme was announced, I knew that a majority of the games were going to try to use enemies literally was weapons. I wanted to try a more subtle approach, in that the player would not have a weapon of his own save his cunning and speed. The first thing that popped into my head was an infiltration game which relied upon stealth. The player would never directly pick up and use a gun, but instead would have to use his wits to survive.

I didn’t even need to do much idea sketching; My idea was a top-down game, using beams of shadow as a place to hide, plus a visible sight cone that would indicate where the enemies were looking. More ideas naturally came from this: Doors that needed enemies to be unlocked, holes that they could fall into, mines to step on, automated sentries that could be reprogrammed and utilized against enemies, etc. It wasn’t hard to fill my notebook with ideas.

The problem was choosing ideas that would be doable in 48 hours.

I decided that this criteria was important for my game:

• Working game-play. I didn’t want a repeat of my LD#17 entry, where the game was visually complete but not very fun due to running out of time to implement core game-play.
• Having more than just one or two levels, but a complete map that folks could explore.
• Completed and stable bumper code. I call bumper code all the pre- and post-functionality of a game. Title screen, level selection and transition, etc.
• Finish art/sound early in the development cycle.
• Have a series of building blocks that I use in a level editor in order to construct the aforementioned wide and expansive levels.

All of these I accomplished save the second. I ran out of time, due to the abundance of ideas and the complexity of implementing all of the last requirement. Building blocks are nice and open up possibility, but I learned the hard way that Infiltrator was at its core a puzzle game. And a puzzle game is very difficult to do in 48 hours unless it’s very simple.

I started to write the code for the game. This wasn’t difficult, as it was fairly simple. The primary difficulty would be in fine-tuning the game-play so that it was fair but flexible enough. Within an hour, I had a simple level displayed onscreen.

I spent some time making pixel art. Creating the over-head perspective man character was going to be simple; I intended to reuse that sprite extensively by re-coloring it programatically. After animating the sprite, I created some basic level tiles. I probably spent an hour tops on both of these tasks combined, and I am glad I did. I would later have very little time to spend on assets.

At the end of the first day, I had most of the game-play mechanics in place. You could run around in the level, attract guard’s attention, lead them to each other, and then get them to kill one another.

At this point, I decided to sleep, to prepare me for the largest phase: Finishing the bumper code and adding the rest of the game-play mechanics.

Next eighteen hours – Saturday noon to Sunday morning

This was the gritty time. I had to write all of the game-play features and finish the bumper code.

Once I had the core level parsing system in place, I decided to create a “How to Play” tutorial level. Perhaps this wasn’t all that wise, considering how I would end up running out time on Sunday, but I knew that the game’s objectives wouldn’t entirely obvious from the start, and it would be good to give the player a fairly calm level in which to test the game-play mechanics out.

The bumper code was easy to do. Tedious, but I had already thoroughly tested the system for switching levels during the creation of such system. I added a timed-score mode that eventually would not matter much. Unfortunately, the timed mode didn’t fit in with the radical change of level design that occurred on Sunday.

By the end of Saturday, I knew had a really solid and fun game. I was quite excited, and my brain was filled with ideas. It was then that I started to consider switching from a linear game to a more exploratory style level design.

In the final hours of Saturday, I spent a lot of time implementing tanks. I wanted there to be a heavily-armored enemy that could not be easily lured to death by the player. It would require a massed effort in order to take down a tank, via scripted level objectives. I ran out of time to put these script hooks into place, and in the end just used the tank like a nastier, meaner form of a soldier. By having mines destroy it instantly, it wasn’t quite as deadly as I intended.

Final ten hours – Sunday morning to Sunday evening

For designing levels and basic tile-map editing, I used a program called Flan.

Here is a screen shot of the first level I made for Infiltrator:

I wanted to keep the game as data-driven as possible. So all level control logic occurs from the level itself. Two tile-maps are loaded. The first is the displayed level itself. This contains all the necessary collision/shadow information for the entire level.

Next is a control level. Tiles are placed in this level to control how the level responds. “h” is a hole, the crate icon places a crate, the “s”/”sg” tiles place soldiers (or soldiers with guns, respectively). Surrounding the enemy tiles are toggle logic for the enemies, such as their initial facing direction and what team they belong to.

The idea being that once all of this was in place, all I had to do was spend the last ten hours or so making levels. Unfortunately, I only realized during that final ten hours, I had over-allotted the amount of content and under-allotted the time needed to complete levels based upon it.

In the end, level design was my downfall. I had a great series of building blocks, but not enough time to assemble them together!

It also didn’t help that I made a few last-minute design decisions which required me to swap out of level-editing mode and back into coding. For example, I had originally intended the game to be linear. You just progressed from level A to level B, until level n, when the game would end. But as I was making levels, I realized that a more open structure would fit the game better. So in the end, I didn’t actually use much of the time-trial code which I had put into place on Saturday. Only the secondary levels which can be accessed from the main base are timed.

The only purpose for those levels ended up just score-related, when in reality, I had wanted to include a story and a set of objectives. But, again, too much I wanted to do, and not enough time.

So, that was that. I finished up the final levels, packed it up, and posted it on the web page as an entry.

What went right

• Actually finished it.
• Feature-rich game for such a short time.
• Emergent game-play made it fun, according to those whom I had test.
• Finished most of my objectives concerning this Ludum Dare.

What went wrong

• Too broad of a scope for a LD48 competition.
• Not enough time allotted for level design.
• “Wouldn’t it be cool if…” interfered too much with core objectives.
• Spent too much time testing out components that would never be fully utilized.

Tags: LD18, post-mortem

OK, here we go.

• Flixel, flashpunk, et cetera… just go for it, you’re making a game. I’m still not a fan, but if it gets you making a game, then you’re playing your part in this competition.
• Speaking of platforms, it helps if you pick something that’s truly cross-platform as not everyone uses Windows (I’m actually going to suggest a figure of 90% who do, which means 10% who don’t, which means 1 in 10 people). There’s Wine, but some things (especially Game Maker) run horribly, and it doesn’t run .NET binaries (and Mono doesn’t have XNA). It’s not against the rules but it’s a pain in the butt.
• Also speaking of platforms, make sure you give an idea of how fast your game is supposed to run. Or something like that. In most cases, your game will run “too slow” on some systems.
• Try to make it get progressively harder if it’s an endless game.
• Don’t use a “lives” system, unless it’s purely for score reasons – I kinda just want to get through everything.
• Don’t spend too long on the graphics. Best just to stick with placeholder art to start with, and then improve it as you go along.
• If you’re going to code an engine which is quite different from the target platform, code it beforehand. This is a tip for myself, who spent roughly 26 hours on getting the emulation working.
• The competition is more serious than the jam. If you’re afraid of criticism, I would suggest the jam. I think. Bleh.

If you want some throttling code, here’s some pseudocode.

CPS is Clocks Per Second.

CPF is Clocks Per Frame. If you have something which returns milliseconds ( 1000 ms == 1 second), and you want 50 fps (== Hz == occurences per second), use CPS/50 == 1000/50 == 20.

next_tick = get_time();

while(doing_your_loop()) {

current_tick = get_time();

if(current_tick < next_tick) {

do_video();

sleep_for_a_short_moment_say_5_ms();

} else {

do_logic();

next_tick += CPF;

if(current_tick – next_tick > CPS/10)

next_tick = current_tick – CPS/10;

}

}

This is essentially what I do in my entry. I thoroughly recommend that you use this. Alex the Allegator 4 uses it, which is an old LD48 (?) not sure what it was entry, but forgets the short sleep so it runs at a nasty framerate on FreeBSD (and I’d assume at least some other OSes, too), and it doesn’t do the lag clipping thingymabob.

It always pays to at least yield to the scheduler every now and then so other stuff can get done, ESPECIALLY if you’re using Java (I did a port of Shawn Hargreaves’ SPEED once and I encountered a problem with the sound being really, REALLY sloppy).

EDIT: Added in the lag clipping. It helps if you get an interrupt storm or something and you lag out for a second or two.

Wow, It seems my game is popular enough to use up all of my website bandwidth.
I will be moving stuff over to another host as soon as it becomes available.
My website has had ten times more the visits in the last two days than in the last year.

Here’s a video of me playing through my game.

Tags: game play, playthrough

AVOIDAL – Post Compo Version!

I’ve made a bunch of improvements to AVOIDAL since the compo and I’d love your feedback!

Play the post compo version of AVOIDAL here

The LD48 official compo version for judging is here now

Changes to the new version:

• Added 1 second of invulnerability if you take damage (this helps a ton!)
• Rebalanced the difficulty curve to make it progress a tad slower
• Mines spawn a tad further in from the edges to help player not get stuck on walls as much
• Reworked How To Play screen to be simpler and clearer
• Changed ‘Energy’ to ‘Health’ in UI
• Fixed some sound volume and playing issues
• Added a nice visual effect of little random twinkling stars in the background

I’m gonna keep listening for feedback and working on this game but I think it is pretty close to me calling it done at this point. Thanks for the great feedback I’ve gotten already to everyone who left me comments on my rating page.

Tags: avoidal, feedback, flash, improved, postcompo

My game has been moved to a different server with plenty of bandwidth.
Now hosted here

Hi folks- I’ve been refining my Ludum Dare 18 game since the competition ended, and I’m ready to release another build. This is still an early version. The game will see some major changes before it’s done. Changes in this build include:

• lots of tuning
• wider field of view
• circular view
• indicators which display the direction to castles
• improved notification when our castle is attacked
• improved animation for the tiny creatures (the ones that come out of the creature pumps)
• pulsating bubbles
• green enemy bubbles
• carried castle pieces now form a train behind our character
• transition animations for castle building

http://vacuumflowers.com/temp/bubble_tag_current

The next step is a major one- I’m going to alter the flow of the game so castle upgrades are rarer and more significant, and also focus on making sure there’s more of a swing between offense and defense. To accomplish this, I’m currently thinking I’ll add destructible protective walls around castles. These walls would bear the brunt of most attacks, protecting vulnerable turrets and other components. Walls could be repaired by expending resources, which would be collected during exploration. More builds soon!

Did you find Grabman too difficult? If you weren’t sure how to win the level, here’s a video walkthrough by me that might inspire you to have another go at it.

Okay, first off, I’m going to say this shouldn’t really be a postmortem as such. Why? Because I’m going to develop my game from here into something much better! So it’s not really dead yet

Mind Control Monster Madness

Anyway, the final game, in my opinion, was pretty ropey. Mostly the controls were horrible, with the camera zooming off from here to there whenever you click on something. But also the game lacked a lot of clarity. The gameplay isn’t explained very well at all, and it’s very hard to tell when you’re clicking on a monster and when you’re clicking on land. This is all stuff I fixed up for the Jam version, as best as I could. I still think it’s hooribly awkward to play though.

I thought it was a disaster when I submitted it on Monday morning (or Sunday night depending on where you are!), but playing it again now I can see a lot of value in it. The rock-paper-scissors mechanic on the monsters works a treat, and because they differ in other attributes (most notably speed), it makes it weighted in a way that’s quite interesting to play.

For example, dragons are the fastest monsters, so you normally want to get them first. You can use them to beat up the Godzillas. But you need a certain number of Godzillas on your side to beat up the turtles, otherwise you’ll get screwed by turtles. You can’t mind-control every enemy fast enough, so you need to start fights to defent your control tower. This means that you need to think on your feet at all times, and judge what’s the most pressing issue on the fly.

That, to me, is nice gameplay, and it’s a shame the concept doesn’t really shine through because of all the other issues with the game. That’s why I’m going to work on it more and make a decent game out of it.

So what went wrong?

Time. Time is the enemy of us all! I think I suffered a dent to my productivity due to travel. I spent 8 hours travelling on the Saturday, to Cambridge and back, to spend time with the Cambridge Friendship Club, who were jamming for the weekend. And, of course, while I was there, I spent a lot of time chinwagging. But I do not regret that at all! It was great to meet everyone, I had good fun getting to know other developers, and it was motivating to be in the same place as a bunch of other people working on their own projects. Without other people around to chat to I would have gone stale very quickly!

The train journey wasn’t too bad. Instead of starting programming right away, I planned out my ideas on the train, thinking through each aspect until I was happy with my ideas. But other than that it is hard to program while on a train or metro. I managed a bit, but didn’t really get stuck into it.

Was I too ambitious? To be honest, I don’t think this was a massively ambitious project. It was fairly simple, and there weren’t many gameplay elements to consider. The problem is the indirect control style. You don’t move your guy by pressing a button and he moves. You have to choose a monster monster, and click on something to tell him to do some command, and he’ll work out the rest himself. All the elements, the user interface, the AI, the camera controls, and so forth, were very much intertwined. If I’d made a platformer and the enemies’ pathfinding didn’t work it would be fine, but if the pathfinding were bust in this game then the whole thing would be unplayable.

The pathfinding, simple as it was, was buggered for so much of development, mostly because of silly typos of single forgotten lines.

So I think in that respect, I wasn’t overambitious on the amount of content required, but having so many elements that needed to intertwine and work together meant that it was only very late on when I had some thing that was playable at all. I spent a lot of time wrestling with some nasty bugs, some of them caused by tiny little things (like forgetting to put a “break” in a “switch” condition), and by the time it all came together I was too tired to really make it all user-friendly, making the whole game look awful.

But I don’t regret doing it like that, because at the end of the day, had it all come together then it would have been great fun. Maybe I just needed a couple more hours earlier in the day, or maybe a shorter train journey. But ultimately I took a gamble. I knew I was making a game that would either work great or not work at all. The gameplay was self-generating and didn’t need a lot of content (graphics, dialogue trees etc.) to make it work. And this time it didn’t work. The game was fine, but the interface makes the whole thing a struggle to play.

I’m glad I gambled, because now I have a game that could be developed into something really cool. Looking back I’m much happier than I was about it when I submitted it. I thought it was complete tosh and was actually quite depressed about it! I’m glad I don’t feel that way about it now 😉

The game was a failure, sure, but a failure I’m very happy with, because it was so close to being a resounding success.

Tags: postmortem

I’ve just gone through the pain of booting an old WinXP box that would want to upgrade (and so, with some reason, I’m sure there is a reason, would eat up all my RAM and start swapping like hell) without asking me, installing python, PySFML and cx_Freeze (well, I agree, that’s more complicated than “aptitude install python2.6 python-sfml”, but hell, is that so hard? I mean, when your system isn’t responsive because of Windows Update…).

As a result, you have a Windows build! (and a Linux static build since I wanted to make sure everything was ok before attempting to build the Windows version)

http://www.ludumdare.com/compo/ludum-dare-18/?action=rate&uid=2432

I didn’t quite have enough time to finish even with the extra jam day.  I am still working on it and I hope to bring it to completion relatively soon. In the meantime, enjoy this timelapse video of me working on the game.  It covers 32 hours worth of work over a span of three days.  More information is provided in the YouTube video description.

Link to ArmchairArmada’s LD18 timelapse video

Tags: desktop, timelapse, video, youtube

I’ve updated my LD final entry page, but I wanted to let you know that I finally created a Stop That Hero! Windows port (2.2MB)!

Now you have no excuse not to play! Well, assuming you don’t use a Mac. Or some other OS. Then you have an excuse.

This entry was posted on Wednesday, August 25th, 2010 at 1:29 pm and is filed under LD #18 - Enemies as Weapons - 2010. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

So its been a couple of days since my game went up, and I thought it was high time I did a post-mortem. To give a bit of background: this is my 2nd flash game ever (number 3 is in the works), and was my first time doing a Ludum Dare, so I’m fairly new to the whole experience. Overall (spoiler alert!) it was an awesome experience that I’m looking forward to repeating(end spoiler).

The game can be found here – I’m looking to polish it up and do a re-release, so any suggestions are more than welcome.

Now, onto the experience:

Part 1: Brainstorming

My brainstorming session involved me, a whiteboard (pictured below), and Google. The first thing I did was to break down the theme into its two important points: Enemies, and Weapons. Ultimately, the idea of enemies proved to be the more interesting of the two.

Brainstorming!

Then I looked up google for sayings about enemies and weapons, and noted the most interesting down. The two that stuck were ‘Know your enemy’ and ‘The enemy of my enemy is my friend’. The first implied a game where you turned your enemies into weapons, but you had to figure out who your enemies actually were. The latter made this more interesting by suggesting a complicated web of alliances which.

These two basic ideas are what informed ‘The enemy of my enemy is my heat-seeking missile’. Essentially, the idea is that you find out who your enemies are, find out who their enemies are, and turn them into heat-seeking missiles so they kill your enemies.

At first, I wanted to use a mechanic of asking people questions to find out their allegiances, but this struck me as way too complicated and messy for a 48 hour game. This lead to the idea of using a colour-based detector for allegiances, and so the ‘allegiometer’ was born.

I’m pretty happy with the basic ideas that came out of this initial brainstorming stage, though they may have been slightly too complex to explore in terms of level design and balancing (the programming aspect turned out to be fine). Which leads us to the next stage:

Part 2: Coding and all things new and shiny…

I should probably mention at this stage that this is my first game that required any level design or sprite animation (I’ve done the graphics programmatically in the past). At this stage, I was putting off the graphics, but one of my first steps was to find a decent level design program and test it. I ended up using Ogmo, and am ridiculously happy with it as a level editing tool.

I got a framework together (using flashpunk as a base) that would read in the map, place the player and the bad guys in and have them interact. I’m really happy with my collision and basic movement code – I simply got it working in a way I hadn’t really done before.

At about hour 10 I hit a bit of a brick wall. First, there was a few dodgy dependency-based bugs (the kind of ‘include’ loops you expect in C or C++, not in Actionscript), and secondly, there was trig. At this stage, I have to emphasise how much I hate trigonometry. I’m not bad at maths, and really enjoy most math-based aspects of game programming. Trigonometry is not one of them, and it seems to come up every god-damn time. There’s too many cases that I never seem to get right the first time, and it often degenerates into guesswork as I get more and more frustrated.

In this game, the trig problem was the angle to point the missiles at as they were rising (so they’re pointing at the target at the top). Ultimately, I got it working if the target was below them but not above, but it took so long that I needed to just leave it and move on.

Overall, I’m pretty happy with the code base I made. There’s some real dodginess in the scoring screens (magic numbers galore), as they were done really late, but otherwise it’s a fairly elegant system.

Part 3: Graphics, (aka why there are Summersaulting Robot Ninjas)

At about hour 13, I started working on the graphics. I first tried to do silhouetted stick figures, but without a tablet (hell, with a tablet might not have helped) I suck at drawing, so Robots it was!

Robots were easy, and I’m pretty damn happy with how they look in the end, considering the timeframe and my ability. One or two frames in the transformation into missiles were a bit dodgy, and there’s a lack of a jump animation.

The lack of tilesets was probably a good move given the timeframe, but the simplistic nature of the graphics did hurt the game a little. It’s something I’ll definitely look into in the future.

I’m particularly proud of the summersaulting ninja robots that emerge from the terrain (this was half animation, half programming)…

Part 4: Level Design

This is the part that probably suffered the most due to the short time frame. I managed to create 20 levels, which was great, but without any playtesting, the difficulty curve was way off and the explanations of mechanics untested. In addition, any playtesting I did was kinda defunct, as I knew what the allegiances of all the robots were (as I had just placed them). So yeah: no playtesting = bad.

I think the levels I came up with demonstrated a decent range of the ideas that could be explored with the mechanic, but often I erred on the side of too easy (apart from a few of the later levels, which go the other way) or on the side of too guess-like. The mechanics of the game can make it easy for levels to devolve into guesswork, and that’s something that I worked to avoid, sometimes more successfully than others.

Part 5: Mechanics/Conclusions

In terms of the overall mechanics of the game, the problems are more in omissions than in alterations: a ‘duck’ feature would be good, and different types of robots would allow me to better emphasise types of gameplay.

One thing I didn’t really get to explore was the idea of the colour wheel. The colours used are the primary and secondary painting colours (not digital colours), and a colour will befriend colours that are next to it, and be enemies with all the others. Even though this was never really used in the game, the decision to do this allowed me to have a pretty nice choice of relationships within levels without ever giving up on consistency.

Another issue is probably the ease of simply killing the evil robots, and the rigidity of the win conditions. Sometimes I should have made it so that the level ends after the timer counts down, and other times it should have put a loss condition of when certain required resources were destroyed.

Overall, I was really happy with this game as a 48 hour attempt. I’m really interested in feedback so I can fix it up (particularly anything on particular levels and their difficulty), so let me know if you have any.

Since this was my first Ludum Dare, making the game Alpha Channel, I didn’t make an effort to post my progress as it happened. However, through the magic of git, I’ve pulled some old versions up and seen how things developed. Interesting to see how the game progressed and if you have git you could also look at the progress made throughout the development via the repository at github.com (if you were very bored, of course).

I’m using my local time, not that of the competition, in the entries.

Day 1, 8:46 am: Created the project

The competition had started too late the night before (3 am my time), so I didn’t stay up. I got up early to eagerly discover the theme and was really happy that it was one of those I’d voted up because it sounded potentially inspirational for a game (the more vague themes were not as interesting to me).

I can’t think of a name, so spooner_ld_18 becomes the working title. I have several ideas at this point and bounce them around my friends, but soon decide that I want to:

• Use Gosu/Chingu libraries on Ruby. I’d used these a bit for another long-term project I’d started, but that was more GUI-based than real-time.
• Pixellised (partially from style, but mainly to allow me to rapidly create graphics that didn’t look terrible).
• Not a platform game (just too many of them about).

I wouldn’t actually start coding for a few hours, until I’d formulated a bit of a plan. I decided to make a game where you played a wizard who was being attacked by monsters, but who could somehow control those monsters in order to survive. Although the game-play didn’t change much from this initial blueprint, the concept would actually change to fit the initial “placeholder” graphics!

Day 1, 2:00 pm: First “playable” version

The sprites would be 8×8 and zoomed out, so 1 game pixel would cover 4×4 screen pixels, but I decided to use simple blocks for prototyping; I’d be able to draw the sprites properly later…(but never would :$).

The “monsters” were red blocks, which they stayed throughout the whole development. The wizard was white, turning grey when he was controlling a monster. A controlled monster was blue and sprites could still overlap each other, which didn’t look terrible in this “blocky” version, but I knew would be terrible when the sprites were actually drawn. I was showing health and energy (the time you could keep control of a monster) in numbers at top of the screen, but this was pretty impossible to keep track of while playing. I was, at this time, planning to replace the health/energy numbers with bars later on. The screen was initially green, to represent grass, not a computer screen!

Day 1, 3:00 pm: Sound effects

The first sound effects were added at this point, being created in sfxr. The main impetus for this was wanting aural feedback for taking damage. I didn’t spend a long time on this, but I felt I’d got the sounds pretty right within a short space of time. As it happened, I got some grief from people playing my game in the end, because the sound effects were too loud, mainly because I was being quite slack in how I played them (every Pixel contact generated a separate sound, so if lots of objects were touching, the sound got quite loud).

Day 1, 4:00 pm: Bad pixels

Because levels were a bit flat, I decided to add randomly placed obstacles, originally called Bad Pixels. They’d be something to hide behind and to avoid since they would slowly damage any Pixel pushing against them. This was also the point at which I prevented the red Pixels from overlapping. This was also the first time I considered my game objects to be Pixels, rather than wizards and monsters, I think.

Day 1, 8:00 pm: Transparency is life itself

Again striving for feedback in the game, I set the alpha channel of each Pixel proportional to its current health. This made the health shown at the top of the screen irrelevant and since I had already put the large level (0001) indication in the background of the game, I was just about to move the score into the background as well. Energy would soon be indicated by the blue colour channel mainly so I could remove all those numbers on the status line.

Also the first point that I drew a link between player and controlled enemy, which was to be a place-holder for some sort of fancy electricity or particle effect, but which I never actually got around to improving upon.

Day 1, 10:15 pm: Exploding on death

Added some particle effects that made it look like the Pixel was breaking into 16 pieces that shot off in different directions. The sound effect had been there for a while, but I thought it would be nice to add an effect for this rather than just have things disappear. Unlike the rest of the visual and aural effects I added, this was more aesthetic than for improving the feedback given to the player.

At this point, the player had a lot more health and could pretty much barge through the levels without actually using the enemy-controlling effect! I had to tone this down later, since it made the main point of the level pointless and the game pretty easy once you realised.

Day 2, 1:30 pm: Particle effects on contact

To make it much more clear where contacts were being made, and therefore where damage was being done, I added some simple particles along the edges of contact. Half of the particles would be created in the colour of one contactee; the other half the other colour. Again, this was added because it needed to be added for player feedback, rather than as a flashy effect in itself.

Day 2, 2:14 pm: Finally decided on a name

Struggling with a name, I’d come up with “Pixhell”, but then found that name was already used by other things. I wondered what was the most important thing to the Pixels characters in my game and that was the alpha channel (this respresents health; Pixels fade out before finally dying in a shower of particles). So…”Alpha Channel”. Not going to win any awards for great titles, but I feel it fits the game well.

Day 2, 5:01 pm: Added a high score system

I considered adding an online high score system, since the framework for one was available in one of the libraries I was using. In the end I chickened out, since I felt that such a system would be very likely to fail as well as taking a unnecessarily long time to implement and test). In the end, I just showed the current high score at the bottom of the screen and the current score at the top, the player’s best score just being stored in a local text file. I think that implementing the online high score system was the thing I really missed out on. My friend ippa’s game used it, and I think it did encourage some players to play it more so they could beat each other. Probably the first thing I’d add if I was continuing development…

Day 2, 11:30 pm: v1.0 (Windows only) – Three and a half hours within the time limit (well, that was when I committed the final version; my actual upload was a bit later).

Finally finished, though I’d barely changed anything in the evening, since I was just play-testing it and tweaking numbers here and there to correct the balance. I tweaked the difficulty as the levels progressed and replaced the font with one that was more boxy, since that was more in-keeping with the game’s aesthetic. Watch a game-play video of this iteration at youtube.com.

Day 4 (after event): v1.1 – Entry ported to Linux and OS/X

Unfortunately, the very boxy font I’d chosen for the initial release, which worked fine on Windows, was so badly displayed in Linux (only the top half of the characters were actually shown) that I need to pick a new font that was consistent across all three platforms. The first font I’d used didn’t display as I wanted it to on OS/X, which is one of the reasons I’d replaced it originally, so I ended up with this one. I don’t like it as much, but it is still mostly in keeping with the overall style and ensures that all 3 OS versions look identical.

I’ve taken a few days of a break, and now I’m ready to come back and write a post-mortem!

Play illumynate here

This was my first LD, and I didn’t really know what to expect. I’ve only ever finished and released one game before, so I was pretty worried about what I would get done in 2 days.

My goals, before the competition:
-I wanted to make a game that I would want to play
-I wanted to make a game that I would enjoy making
-I wanted to finish a game
I’m happy to announce that I was able to achieve all 3 of those!

The preparation

I decided I would enter the competition about 4 days before it started. I knew for certain that there was no way that I would be able to design a game engine as well as a game in the time allotted, so I really wanted to try to learn a framework that would do some of the engine stuff for me, namely flixel, since I have a soft spot for pixelly games. Getting flixel + flashdevelop installed and working, as well as going through the tutorials, were unquestionably the best uses of my pre-compo time. I also learned how to use some accessory programs, like sfxr, Mappy, and GraphicsGale, which I would end up using. By the time the theme was announced, I was comfortable with using these tools the way I would need to during the competition.

The idea

I’ll admit, some of the idea of my came was conceived before the theme was announced. I had two ideas for games, each which could be tweaked to accommodate several themes. My first idea was a tower defense game where the player couldn’t place turrets; they had to control a little guy with a gun, and use the impact of the shots to push the creeps into tiles that would convert them into towers (enemies as weapons), and pushing more creeps into the same tile would slightly change the turret depending on the type of the creep (evolution). My second idea was a cave crawler, where the player had two weapons- a flashlight and a gun, fighting trolls, which would encompass darkness, claustrophobia, hidden depths, and anachronism.

Basically, the theme was announced, and I realized that I really didn’t want to make the tower defense game. The cave game sounded much more atmospheric and interesting, so I went with that. I threw away the gun from the design, and put in different types of enemies who reacted differently, that the player had to use as tools.
The story of the game was one of the last things I came up with. What would be at the end of the cave? A damsel in distress? A rare artifact? Nothing? Once I decided to use notes as a storytelling technique, however, the current idea (and ending) just jumped into my head, and I liked it.

Making the Game

The actual creation of the game went pretty smoothly. I created the player, the fog/flashlight, then the enemies, and by the end of the 24hrs I had pretty much every class I would need finished. The second day was designated to finishing the details- the story, the level design, and the art. I got plenty of sleep each night, (5-7 hours), but I made up for it by taking very few breaks- even at meals I had a notebook with me, doodling and scribbling ideas. The only notable break was when I went out with my family to the Renaissance Festival, which did a brilliant job of clearing my mind.

I spent a lot of time on optimization, which ended up being overkill, since the .swf ran ~2.5x as fast once ran it outside of flashdevelop.

As the time counted down, I still had a ways to go. Eventually I only had 5 hours to finish everything up, and it wasn’t very polished. It wasn’t until 2 hours from the deadline that I had someone else test my game, which was a terrible mistake- I learned I had to fix a ton of bugs, make a bunch of tweaks, and clarify a lot of the gameplay, with not much time to do it.

I didn’t spend much time evaluating the gameplay. In all honesty, before I submitted my game, no one had even played it from beginning to end. As a result, I wasn’t sure if the game was any fun. I’m still not sure of that. But whatever, it was a great experience making it.
I plan on tuning gameplay a bit based off of feedback, fixing some bugs, and adding sound/music, after which I’ll release a final version of it somewhere!

What I learned

-I can make a game in 48 hours
-Have someone else playtest for bugs as early as possible
-Frameworks help a lot
-Autotiling is awesome
-Breaks and sleep are important
-Test early and often to fine-tune gameplay

Thanks to everyone who played my game, especially to those who gave me feedback in the comments!

My f****** internet died just when i was about to see the theme. And i’m still connection-less. Im in a cibercafé =(

I would cry if i werent in public.

Well… that was my third attempt… you can “not win”, but some times you also “EPIC FAIL”.

Bye, i gonna get a chansaw to kill Arnet. =P

@ LoneStranger

“Is that a Lego setup on the left shelf? Is it a battle or some kind of scene?”

Yes it is! Allow me to get kiddy for a second or two. That is actually my main sci-fi base. On the right top shelf is my custom Jedi temple (which is partially covered by plastic trash. On the farther LEFT, out of the picture, is my castle fortress. In the center, behind the laptop, is a slightly trashed town set up.

@Spiridion and Osgeld

No, it’s more of a time thing. I go to church on sunday mornings and evenings. So that means get up 9-ish, church for 2+ hours,  dinner, nap, dishes (maybe), bout an hour left, then church again. So I really had no time at all left. Also, any bad programmer art is better then my bad pixel art.

@alistair aitcheson and madk

Thanks for the suggestions! Although, if I’d use a starfield again, I’d probably just go with one color. Maybe white. Though pink does sound lovely.

@everyone else who posted on the quitting thread

Thank you! It’s nice to see this sort of encouragement. I’m gonna really gun for it in december and try and make a game in time. Thanks again!

Now that I don’t have to rush to get everything done, I’m going through and redrawing everything in Fromulus.  Everyone seems to think it’s got good art (and I do, too), but it could certainly be better.  I was definitely rushed to get it all done in time, so now that I no longer have the pressing time constraint, I can do things the proper way.

The obvious first place to start is with the character graphics.  Fromulus in the old version was in a profile view, which was certainly easier to draw in a short time, but not as good to look at as a 3/4 view.  The enemies are already drawn in 3/4, so it makes even less sense for him to be in profile.

Here is a comparison shot of Fromulus’ old casting animation versus his new one:

The most important difference is that I increased his saturation quite a lot.  On top of this, I got rid of his single-color border and used darker versions of the color being outlined.

So, what do you think?

Hey guys
We made an Jam-Game, so our game is not in the list to be rated, so it would be very nice if you try out our game and leave some comments. This would help us to improve our games and our iteration.

Here is a link to our game: LINK

Thanks a lot
glethien for BazingaProductions

My timelapse is uploaded!

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

Tags: timelapse, uploaded, youtube

Just wanted to let people know that the source code for every single compo entry has been verified and is available for download.

That’s 172 games, all with source code, for your learning pleasure.

I’d like to request that if you did a jam entry to consider uploading the source as well, if you can, because it is just cool to do so.

“Alien Super Mega Blaster” in play test  and can be downloaded and installed on your XBOX for those of you with an XNA Creators Club account.

http://tinyurl.com/23h3cr6

Same gameplay as LD18 submission, just changed a couple classes to allow the game to  be controlled via a game pad and added a splash screen for selection of the active controller.  The last remaining change was to tweak the rendering to allow the 800 by 480 resolution to be displayed centrally on a TV screen.

The windows compo version is still here  and appreciate all the feedback: http://www.ludumdare.com/compo/ludum-dare-18/?action=preview&uid=1516

And another competition has gone by… Awesome fun this one…

Time for a quick postmortem of my entry, Conquest:

What Went Right

– Theme: My first impact with the theme was “I hate this one”… On retrospective, it is an awesome theme, really made me think out of the box
– Initial concept: although it took me 3 hours, I got an idea that really got me excited and thought it fit the theme
– Excitement throughout: I was excited with the game the whole time, instead of being excited for 2 or 3 hours and then losing momentum.
– Tracing: the idea to trace over the graphics made by Oryx for the Assemblee competition for the characters was great: it allowed me to save time and have something passable visually.
– Music: I was scared of leaving the music for the end, and with good reason… didn’t have much time to do it, and had to use WolframTones… Although my first tries didn’t yield anything decent, after a bit tweaking the parameters I got something that while it isn’t Mozart, it’s passable for 48 hour game music…
– Cutscenes: While not terribly interesting, I really love doing those small cutscenes, they add to the flavor and they’re fun to program (even though they took me 2 or 3 hours to get right)
– Using my LD framework instead of my engine: I was going to participate on the jam instead of the compo, but looking at the idea I had (and the fact I thought I would take 10 or 12 hours completing the game) made me go for the compo. My engine wouldn’t have given me any advantage over the framework anyway…

What went wrong

– Time managment: What I thought it was going to be a 10 hour development cycle for this kind of game turned into 28 hour… So my managment and estimation was appaling.
– Family visiting: Although I love having people over, having family visiting on the weekend took away some time I could have spend programming… thankfully my wife did most stuff by herself, leaving me with just entertaining the guests… while I wasn’t running towards my office to program a couple more lines (jeez, I sound like an addict… )
– Bugs: Ran into some bugs after the deadline, which meant the game seems more buggy to everyone than it seems to me… :\

What went “meh”

– Thousands of ideas flowing through my mind while I programmed the game… This is a mixed blessing… I look at the game as it could be, while people will look at the game as it is… Lots of ideas made me be excited about the game the whole time, but it also was source for some frustration, since I couldn’t put everything I was thinking off…

The game has circa 2000 lines of C++ code, and the framework about 17000 (most of it 3d related and stuff I’m not using though).

Tools used:

Code: Visual Studio 2005
APIs: DirectX 9 (Feb), FMod, Win32
Graphics: Photoshop CS4 (mostly traced from Oryx’s pack for the TIGSource Assemblee compo), 3d Studio Max 2010 (for title screen)
Sound: WolframTones (very awesome, only had 20 mins or so to play with it), Midi Converter Free (online free midi to mp3 converter)
Blogging: Zoundry Raven, Internet Explorer
Reading LD: Omea Reader
Listening music: Winamp

I’ll probably want to play around with this idea for a bit longer, add some of the ideas I’ve had during the development… Hopefully I’ll post the new version in the future, albeit I don’t know when, since I’m starting a new job next week… :\

Last week I participated in Ludum Dare 18 and after some intense work delivered an interesting little game called Protractor, here’s a link to my competition entry.  Leading up to the comp I played some winners of the previous Ludum Dare to get a good feel for what I could hope to accomplish.  I prepped my dev environment, picked up groceries, and set up a special SVN branch for this comp so I could make engine hacks or workarounds without any worry about breaking other projects.

On Friday night when the theme was announced I just sat there and thought while scribbling some ideas on paper.  I wanted to do something with physics and attaching enemies or weapons to yourself.  At first I was thinking of doing a round planet with humanoid figures using telekinesis.  I started to set this up in code but wasn’t really feeling the idea so I just went to sleep.

Saturday morning I took a quick look at games with a similar concept for inspiration, specifically TUMIKI Fighter and Captian Forever.  My design is based on simple abstract shapes so they are easy to recognize on form alone allowing for the color to represent health.  I also planned on having random weapons with random colors and lots of trails all over the place.  For color values I have it set up so I can randomize over HSV space to get away from the RGB kind of look.

Building off the clean project in my game engine I set up an object oriented structure where there’s a base class shared by the player and enemies, a base class shared by all part types, and everything derives from a GameObject which is part of the engine.  By about 3 PM Saturday I had the player moving around with the ability to pick up parts and attach them.  But so far the only part was a weapon and it was always the same default weapon.  I took at least 2 hours to put some polish on that system with grabbing and attaching the weapon parts.

Around this time I did a little art pass: tweaking colors, particle systems and other visual aspects.  I threw in an enemy that just randomly tried to pull parts to it and shoot.  By the end of Saturday night I wanted to have all of the core functionality in game so I could take the next day to add better AI, polish, balance and tweak.  So I trudged along adding the other 3 part types in a very rough state.  Around midnight Saturday night I posted a screen shot to demonstrate the core functionality.

Sunday I started out by just tweaking lots of little things.  There needed to be some background for movement reference so I just threw in an extremely simple particle system of gray squares.  I worked on the AI a bit and improving their tractor beam use a little.  I made them move around pretty much randomly in near the player.  I tried having them turn to aim but that isn’t very reliable because of their poor ability to configure their ship so I just made them cheat and rotate their weapons directly.  There just really wasn’t enough time to make any kind of real AI at this point.  For all this time I just had the player spawn in next to some parts and an enemy that I had all placed in the editor so I added logic to randomly spawn in enemies and parts out of view of the camera.

This felt good enough so I wanted to spend some time adding random weapons to add both visual flair and gameplay depth.  As a simple balance measure all weapons have the same DPS with different firing rate, bullet damage, and bullet count.  Other aspects like speed, spread, and color are just randomized.  It seemed like a big part of this game was reading where damage was coming from and going too so I had an idea to make bullet size proportional to their damage to facilitate a quick visual read.

As the deadline loomed I started to freak out a little becuase there were only a few hours left and I harly spent any time actually playing my game.  So I took a while to just play and polish random gameplay issues.  I experimented with several different control schemes but decided to go with the simplest which seemed like a good enough choice given limited time.  I threw in some random large solid black boxes to both add an interesting element to game play and visuals while also making the world feel more solid to the player.

With about an hour left I focused on sound by adding more firing sounds and a tractor attach sound.  I scaled fire sound frequency by bullet damage so weaker weapons sound higher pitched to make it sound a little more dynamic.  In the last half hour I just tried to play my game only tweaking a few minor things.  I had a score display of how many enemies were killed with high score tracking but decided to remove it a the last minute.  Adding a scoring system can add a lot to a game but it can also detract if done incorrectly.  I like the idea of just providing a pure experience without the need for imposed goals. The implicit goal of growing your ship is as motivating a factor as any.

It’s was hard to come up with a name for my game in such a short period of time.  I went with Protractor because it sounds sort of abstract and mathematical while also containing the word tractor for tractor beam.  I’m happy with the way my entry turned out and after playing it for a bit since then it still seems to hold up pretty well.  Next time I’d like to try to get some testers lined up, people offered but I was so focused on working that I didn’t take the time to contact anyone.  Also I’d like to plan my time a little better so at the end I have more time to just play and tweak.

It’s impressive how well put together the Ludum Dare competition is.  The judging phase is currently in progress and it’s great fun playing everyone’s game and doing my best to judge.  It’s sort of like playing Wario Ware on a grand scale.  Thanks to everyone who put it together and congrats to those who successfully delivered a game.

Tags: post-mortem, protractor