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