Warning: Here be SPOILERS. Don’t read if you haven’t finished it. It should take you about 10 minutes to play through if you finish each level at a decent pace.

Yes. Heroic Cat has Spoilers. Can you believe it?

This was my first Ludum Dare I’ve ever participated in, and I had no idea what to expect and how far I would get in 48 hours. I didn’t prepare that much. I had my tools (visual studio, paint.net, bfxr and audiotool), but I had no pre-existing engine code or whatever, nor did I have any external libraries, engines or frameworks (bar XNA of course) to use.

Progress

When the theme was announced at 4 AM, I immediately started working out my idea. 2D sidescrolling platformer, cat being hero, save princess, common enemies, etc. This didn’t take that long. I had a rough idea about what I wanted to do, and figured I’ll just expand on it when I get to it. I then started working on the engine. Tilebased, basic collision for that, and collision between entities. I also wanted simple AI commands put into the map itself to control the green guy. At 9 AM I had the first 2 levels, including an enemy and basic AI. The core of my engine was done! I then went to sleep.

The next day I continued working on content and levels. I added the crushing dude, rope, the feather, and continued working on levels. Progress didn’t go very fast, with each level taking an hour or more to develop. I think the last level I did that day was the one with the ‘castle’ entrance with the heart. And I made the ‘final’ level, which is the part with the princess. At that point you weren’t trapped in jail yet, but you couldn’t get out either, and your cat would turn into a skeleton after the narrator stopped narrating.

On the last day I continued working on some levels. I added the fireball dudes, fixed some issues with map transitions, and then I got a brilliant idea at about 6 hours left. Instead of dying alone, you’d be rescued by a firebreathing guy, and then you’d go back and burn the house down of the hero. An epic plot twist indeed. So I worked on the firebreathing hero, and recreated the second-to-last level. But then I realized backtracking was silly, so I took the underground route. I only ended up making a few new levels, but there’s still room for more in between them.

Anyway, I had a lot of fun making the ‘final final’ ending, where the guy burns their house down with combustible lemons. Then I added the level before that, with the guards. I also replicated all changes to the first levels before the plot twist. And after adding the credits screen, the game was practically done, and I had about 1.5 hours left. Enough time to give it a few full playtests, package it up, let someone else test, and then to finally submit it!

Things that are missing

Things that didn’t make it were the ability for the green guy to get a sword or shield, and other random items/powerups. But that was before I came up with the plot twist. In hindsight I should’ve added a few more woodburning puzzles, but I had trouble thinking up puzzles as is. Also, I’m glad I didn’t do animations. I wanted them at first, but thought ‘meh, it will just take up time’. If I chose to do animations, I’d be swamped and it would probably take me another day to finish. Also, I wanted the ending cutscene to be the firebreathing dude and the cat making baby firebreathing dragon kittens or something for a sequel, but alas, I didn’t do that.

Things that should’ve been done differently

I wish I had time to fix my tile collision code. Sometimes it freaks out and warps entities away. I suspect it’s rounding issues (I casted lots of stuff to ints because I was lazy) but instead I worked around it by preventing it from ‘naturally’ happening. I sort of know when the bug happens as it is a little predictable. But still, nasty stuff that’s bugging me now. Also, in hindsight, I’d add a music mute button and I’d also make escape work a little different. Full screen toggle would be nice as well. But hey, you can’t have it all. I’ll remember those for next time.

Final thoughts

But still, I’m very happy with the result. I learned a lot from it as well, especially about what I can do in 48 hours. For my next game I’ll probably create something with less levels, or levels done in a different way. Creating puzzles is not my strongest point, and often I’d have no idea what to do for 30 minutes.

For the next time, I might try another language, probably one for the web. Developing in XNA is sweet but I noticed that the few people testing it never had XNA 4.0 installed. And like them I know the pain of installing crap like that when all you want to do is extract and play (or only play).

In any case, I’m in for LD21 😀

I was too tired after submitting last night to write a summary, but here goes…

What I used:

• FlashDevelop
• Flixel
• Box2D for rope physics
• Reason
• Photoshop
• SFXR

Flixel turned out to be  a pretty good option for this type of game. I had some basic platforming going in minutes, and even though most of the first day was spent implementing the rope mechanic, I got more done on Sunday than I expected- largely because Flixel made development easier.

I ended up using the map editor DAME (http://dambots.com/dame-editor/), which I would also recommend. It has a few quirks (and I was a bit nervous about how I was using it to structure levels; basically each one being a “group” that was shown while I edited it, and hidden if I was editing another one), but it worked through to the end without any real problems.

For some things, I found the AS3-generation to greatly simplify my code: for example, when creating a “LevelExit” sprite, I simply created a property on the sprite type called “targetLevel”, which I would set to “Tutorial”, or “Level3”, or whatever. Then in DAME I set the sprite’s constructor field to “new LevelExit(%xpos%, %ypos%, %prop:targetLevel%)”, and in AS3 I created my LevelExit object to do something like… “playState.level = new targetLevel();”, and it would create a new instance of the target level. I’ve got no idea if this is a standard way to use Flixel/DAME/etc., but it felt pretty neat to me. Pity the rest of my submitted code is so shocking, hah!

I realized that creating sprite animation in Photoshop is *much* easier if you use layer groups. Once I had the body part groups (“head”, “torso”, “left hand” etc.) set up, and realized that you just need to right-click on the group and “Duplicate Group” for each new animation frame, I was actually really enjoying the process. Select layer, Ctrl-T (for free transform), move pivot, rotate body part. Repeat.

Box2D was relatively straight-forward to implement, although I couldn’t get the debug-view (with all the rigid bodies overlaid on top) working with Flixel as smoothly as I wanted. I ended up with a hacky solution, which at least allowed me to see where my rope rigid bodies were going wrong. It felt right at home amongst the rest of the hacks, so it stayed.

Unfortunately, it appears that I’ve made the game a bit too difficult. At least from the comments on my entry, it seems that people aren’t getting to end, which is a pity… I spent hours on that end cutscene! ;). I should probably release an easier version.

Alright, that’s me done – hopefully see everyone at LD21.

I have mostly recovered from the rigours of last minute bug killing before submission last night. So I have made a little time lapse video. Hopefully you’ll find it interesting as I really tried to tackle every part of the game in big chunks at a time (scripted my story in one go, then re-wrote in Ren’Py, then composed all the music in Sibelius in one go, then did all the artwork). Please watch it at full size to see the tits & arse- I mean, to see the artwork and the scripting clearer.

 I can’t seem to embed the YouTube on here, so here’s a selection of stills from the video and the YouTube link below ^^

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

View my entry: Let Me Save You! Your Faithful Companion

Link to entry: http://www.ludumdare.com/compo/ludum-dare-20/?action=rate&uid=3407

As I said in my submission, Mine Escape was my first attempt at a game and my first entry into Ludum Dare. I feel like I learned a lot in a short amount of time and I’ll definitely be back for the next one.

Mine Escape was “finished” in that it’s a self-contained playable game with an opening, levels and an ending. Due to running out of time I wasn’t able to put in many of the levels and different traps to fill them but the underlying “trap” system is in place so it would be fairly easy to add more. I’ll expand on that below.

What worked:

• The graphics –  I’m a programmer, not an artist, and all of my art is usually programmer art of the worst kind. I can barely draw a circle freehand. By using tools like Photoshop I tried to draw with shapes and lines where possible instead of freehand sprite art. I learned that when working solo it’s easier for me to apply filters and approximate a ‘pixel’ look than to try and draw it “legit”.
• The coding – Mine Escape is the last of a long series of failed projects and unfinished tutorials, I’ve never been able to see something through long enough to do anything more complex than draw a static sprite. Basic elements of game dev like scene management and platformer physics were things i’ve never been able to get my head around before, but they’re working in Mine Escape.
• The controls – I’m keen to get started making Xbox XNA games and so I wanted to do the controls properly instead of  hacking them in. The title screen detects if you press a keyboard key or gamepad control and responds accordingly. The mouse cursor is not drawn if you’re using gamepad input and you can play with any controller index (1-4) regardless of how many are plugged in.

What didn’t work:

• My timekeeping – In retrospect, I didn’t make  the best use of my time during the 48 hours. I surprised myself by creating art+sound assets I didn’t hate and so spent a lot of time producing more. You can see this in my first video (http://www.youtube.com/watch?v=r4qASBnUXpo) where most of the assets from 18 hours in made it to the final game.
• The game length – Games like Mine Escape live and die by their levels, and on that count this was a failure. Most of my time went into the “overhead”, the engine + mechanics and I just ran out of time to implement more stuff to do.  I was going to have more dangers such as acid drips and electrified floors which would eventually start being arranged so that you had to rely on the BUDDI rather than just swinging the torch about to see what’s ahead.

What I learned:

• If my game needs lots of levels to be playable, I should spend more time crafting them and getting their mechanics working. If the intro screen’s art is amazing but there’s only 1 level then it’s the length people will comment on. Speaking personally I’d rather play 20 levels with  placeholder art than 2 levels of finished sprites before game over.
• Game making is FUN. When I first started out I quickly realised it’s also a lot of hard work, but once you push past that it’s a rewarding hobby. I’m glad I proved to myself that I can do this, even if I’ve only scraped the surface.

What’s next?

Entering LD48 was a ton of fun and I’ll be here to take part in the next one, too. Now that the compo is over I’m wondering what to do next. I feel like my thought process has been changed from “what am I able to do?” to “what do I WANT to do?”. There’s a strong possibility I’ll add some more levels, fix some bugs and take Mine Escape for playtesting. If it turns out there’s a fun and engaging game idea in there I may clean it up to fit the Microsoft App Hub guidelines and publish it on the Xbox Live Indie Games section.

Entry link: http://www.ludumdare.com/compo/ludum-dare-20/?action=rate&uid=3407

I thought I’d jump on the band wagon and do one.

I was at a friends house for the first night – we stayed up ’til 3AM to see what the theme’d be, then got about 4 hours sleep, so I was kinda tired.

The first day went pretty well – I had the idea when I first saw the theme, so I dived straight in.

This was my first major project using AS3 & Flashpunk, I learnt them last week (although I’d done quite a bit of AS2 coding previously).

It took me longer than I would have liked to get all the platforming elements done, especially since my game stopped working randomly for about an hour then randomly started again – but hey! I then started implementing all the features – such as the “tool”, and the mechanisms, like the switches and buttons and doors.

On the second day, I added the remaining features – the enemies, spikes, and then got started on making the actual levels. This was harder than I thought – making challenging platformer levels is quite a challenge!

I then decided I needed another feature with about 5 hours left – specifically the half block, which was surprisingly easy to add.

After 6 levels though, I was way too tired – it was about 1 am, and I couldn’t think of any more levels, so I called it a night.

WHAT I’VE LEARNT:

I need to test less. Seriously, half my time was wasted on waiting for the code to compile, testing silly minor features.

I much prefer AS3 to AS2.

One thing that I don’t think I could have done without is OGMO editor. I had some trouble parsing the XML at the start, but once I got past that it was amazing. The project file for it is a complete mess, but it works, and works well.

OOP is amazing.

Quick “hacks” are ok for things that will never be uncovered again, rather than huge workarounds…. especially if you only have 48 hours :L

I CAN FINISH GAMES! 😀

My pixel art isn’t half as bad as I think.

Was too exhausted last night to post a recap of development.

Overall, I hit my “minimum” game design. I had some more elaborate ideas involving inebriation; but, alas, time took its toll.

My one regret is not allotting enough time to bug fixing. The game, as is, has a few moderately annoying bugs. Additionally, since I did no play testing, I didn’t discover that not having a “skip dialogue” button is essential when you have a lot of dialogue.

Regardless, amazing! I need to do this again! I’m hooked!

Tools:

FlashDevelop, SFXR, Chronolapse (time lapse coming soon), Sonar 5, Finale, Photoshop, Notepad++

Hope people enjoy the game!

So, my LD20 entry was my return to game-making after a considerable hiatus. I didn’t do much in the way of exploring new technology or tools, opting instead to stick with what I knew and focus on turning in a solid result. What went well, and lessons learned:

Going over a collection of design ideas, figuring out which one I was tending to gravitate toward, and then getting some sleep to let my brain digest worked amazingly well. When I woke up, the idea was much “cleaner” in my head – scraps of notions that weren’t going anywhere had been pruned away, and the core notion of “what does this game feel like” was a lot clearer as a result.

I spent 3 or 4 hours making the movement controls feel awesome, before coding any other aspect of the game. I mean, I literally just sat there with a black circle hopping around on a black line, tweaking variables, augmenting equations, until I was having fun making that dot move around. Taking a principle I’ve been aware of in game design, and putting it into dedicated and deliberate practice, really paid off. If you want a game to be truly, viscerally satisfying, then each building block that goes into the gameplay should be satisfying on its own. I recall a story that in the early development of Super Mario 64, the game started with just the physics – an untextured cube running around an empty room. And Miyamoto wouldn’t let development progress further until that was fun. That’s another benefit to the Dragondot franchise, I think – the minimalist graphics make me focus on movement to convey things instead, and movement can be ‘felt’ more viscerally by the player than animation on its own. There’s the special attack with the knife weapon, for example, which is intended to be an acrobatic backflip sort of thing. And I think I managed to convey that with the way the attack is done, which is made up of basically three numbers. Three numbers, versus who knows how many hours it’d take for me to make a pixely character animation look decent doing the same thing.

On a related note, I discovered once again that you should never feel guilty about seizing the opportunity to make something more awesome when an opportunity inspires you. One of the core concepts of the game is picking up a fallen enemy’s weapon, and I wanted to make that moment feel cool. So I spent a good several hours making a sweet sound and particle effect to announce the occasion, even though at that point I’d done absolutely no code for enemies or combat mechanics. In terms of productivity in a ‘crunch’ situation like Ludum Dare, passion beats the pants off of diligence. I procrastinated on the combat mechanics for quite some time, because when I started working on it, my immediate response was “this is a cool design, but it’s gonna be really unpleasant and boring to code. I’ll slog through it later.” So instead I worked on adding awesome in other areas. Particle effects are always one of my favorite things to do, so I did some of that. Then later, I came back and looked at the elaborate weapon code I’d designed, and went – you know what? I can make this way less featureful, do some fearlessly kludgey code, and still do 80% of the cool stuff that this game actually wants. Ranged attacks, attacks at different angles, attacks that vary based on your current movement – all that was in the initial design concept, got cut, and the core of the game is healthier for it.

I was a bit torn as to whether I wanted to have lengthy levels you walked through, or a series of discrete screens. I went with the latter, and in retrospect I’m certain that was absolutely the right choice, at least for a 48-hour development cycle. Having things compartmentalized like that, much like the original Dragondot, let me develop and test monsters modularly. I could do 3 rooms, variations on a theme, and then say “okay, they’ve learned their way around these critters, time to throw a new one into the mix”, and just go code that. And if there needs to be a new variable for a monster or weapon to hook into, I just toss it into the base class, set a sensible default, and then it’s an easy new dial to twiddle for future design. For instance, the club makes you move slower – I added a ‘weapon weight’ variable and a multiplication in the appropriate movement functions, set the default to one, and then increased it for the club. As it turns out, that’s the only weapon that has a higher weight, but the design space was open for more after that point.

There are a few areas that I wish I’d had more time to dedicate to, though I’m happy considering the game “done” at this point and don’t feel the need to polish it up for a Jam version like I did last LD. In particular, the worg fang works great for a boss weapon, but the same thing that makes the boss difficult but beatable makes it kind of a lame weapon for the player – you’re wide open after attacking, and the speed tradeoff just isn’t worth it. In retrospect, I probably could have given it a more aggressive primary combo attack. The pacing between rooms isn’t as well-tuned as I’d like it to be – while I made sure that individual rooms were beatable, the spacing of hard and easy rooms is a bit haphazard. Room 7 is basically the ‘midboss’ of the game, and can be rapidly lethal unless you’ve mastered dodging the worg’s lunge and turning enemy attacks against each other.

That’s another thing about difficulty, in a development setting like this – I’m doing all the coding and playtesting, so I’ll be getting practice against a boss as I tune its AI and such. So when I get an enemy into a state that I find “tough, but satisfyingly beatable once you figure out the trick to it”, it might be a bit brutal when you’re just coming into it fresh. I woke up this morning and tried to do a “fresh” playthrough of the game, and kept dying in room 7 over and over. So yeah, it’s not just you.

The AI in this game is kind of a happy accident. It’s stupidly, stupidly simplistic, and I think it’s mostly the fact that moving around is so much fun, and that enemies show up in groups, that keeps the player distracted from it. Basically, they’ve got some really simple rules tied to virtual button-presses; if the player is left of me, hold down the left key, if they’re closer than a certain distance mash the attack button. That’s pretty much all there is to it, for most enemies. But it works. The ninja enemies seem sophisticated, jumping over your attacks and leaping to intercept you in the air… If you don’t want the magic of their AI spoiled, don’t look at the code, that’s all I’ll say. Actually, don’t look at the code anyway – as usual for my time-crunched style, it’s uncommented, hacky, and horrendous. There’s four or five important-sounding vestigial classes, like Attack and Melee and Weapon, that don’t actually get used anywhere. I did put one easter egg in the code itself, in the bit that handles the extra “ending” of the game. Fun with variable naming and whitespace abuse.

Anyway, I appreciate you reading through all of this, so I’ll let you in on a secret – I once again forgot to remove the cheatcodes I put in when testing the game. Oops, silly me.

Uploading my timelapse video.

For some reason the webcam breaks after a few hours.

Trying out video editing software, for LD19 I downloaded Cinelerra, but that was confusing and didn’t even load my videos properly. I just discovered Kdenlive which has a really nice intuitive interface and actually works.

Tags: timelapse

(yeah I’ve posted this before, but it’s a handy thing many people will have missed the first time around)

While you can subscribe to an RSS feed of comments on a blog entry, the LD website doesn’t have anything like that for comments on your game. So I made a bookmarklet that uses some Yahoo Pipes magic to make one!

Screenshot of me checking my game's comments in Google Reader!

WordPress wants to mangle it so I can’t give it to you directly in this blog post, but you can get it and see instructions for using it over here.

It is a bit fragile in that it is looking for particular bits of html, so if the site changes a little it will probably break horribly, but so far so good!

GET IT HERE

Tags: rss

So, Ludum Dare #20 is over, and voting has started. I intended to write a post where I sum up my thoughts about my own performance.

But first; I want to applaud this community, for being so warm. People are encouraging, and the admins do not accept trolling. Everything is very well organized, and I can’t really see what can be done better. This guarantees for my intent to participate again next LD.

About my own performance;

What went wrong?

I found quite a few bugs in my own basecode, that did cost a lot of time. This is a direct consequence of the basecode being made FOR Ludum Dare, and not being tested on any other real projects.

Basecode lacked some features that would speed up the development. Asset management, a camera, sprite-position correctioning (to be able to easier enter doors when missing them slightly), dialogue system, a standard set of good collision detection algorithms, and probably much more that I can’t recall at once. These are all things that I intend to fix before LD21.

A direct consequence of this shows in my source code, as a great pile of doodoo.

What went well?

I started drawing, and things turned out much better than I expected. I even had an animated main character that worked out decently well – he didn’t get to have an attack animation, though.

I did manage to dedicate the time to do this.

I did finish, and the game is beatable. And I’m very happy for that.

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

TL;DR: I like making games and hence created Cuboc for LD20. <3

Design Phase #1 and Prototype

I read about the theme of the LD20 about 6 hours after it was announced. My first thought “woah, companion cube”. For me it signifies the one thing in game history that really fits the theme “it’s dangerous to go alone! Take this”. The word “alone” signifies to me that what you receive is actually something that is a companion, not just a mere tool like a gun or a shovel. The companion cube is both a tool and a “friend”. A silent friend, but a friend never the less.

The overall idea would be to have a companion cube (yes, how original) but deviate from the formula in Portal. While the cube serves pretty much the same purpose as in Portal, you are also able to control it directly. That makes for some interesting game mechanics atop of what we saw in portal. It’s also a way to ease the burden on the programming side as the cube would automatically follow the player which would mean a good path finder. Something i didn’t have time for.

Given this idea i settled for a puzzle platformer, where the protagonist was accompanied by a cube which he can control and anchor in the world for a given time. From there on i tried to come up with game mechanics. I spent 6 hours implementing the basics (protagonist movement & collision detection, cube following) to get a feel for everything. For this i had to settle on a unit system so i can give my game objects proper sizes and positions. I settled for the following:

• One unit in the world equals one meter. The protagonist called Bob is 0.8×0.8 meters in size (comic like proportions). The cube is the same size.
• The viewport into the world (the porition that is visible on screen at any one time) is 24×16 meters wide. Why? Because it is easily mappable to pixels as you’ll see in a bit.
• I settled for a mapping of 1 meter == 20 pixels. From this and given the viewport of 24×16 meters i derrived my target screen resolution, 480×320 pixels.
• With these measures i started pixeling the tile graphics, Bob’s animation cycles and the cube, all arranged in a 20×20 grid so i can adhere to the sizes chosen in world coordinates easily (e.g. 0.6×0.6m ~ 12×12 pixels etc).

I implemented Bob’s movement (acceleration + damping makes for some nice movement) as well as collision detection. The later turned out to be a problem and took me 4 hours. Once Kivan told me an easy way to handle it in my setting i was able to completel scratch and rewrite it in 20 minutes. The more you know.All in all i spent around 6 hours for this first phase.

In terms of language, tools and so on i settled for the following:

• Java plus libgdx. I wanted to eat my own dog food
• Deployment would happen as a single self-contained runnable JAR file. Easy to distribute, no installation required, the closest you can come to an executeable in Java
• Eclipse, cause it’s what i know best.
• For graphical asset creation i used Paint.NET. While i really like Gimp, it’s interface still turns me off and i find it a lot easier to work with Paint.NET’s more streamlined (but less capable) interface. Sadly it’s only available for Windows (not a problem for me).
• For the tile maps and object placement i also turned to Paint.NET. Objects and tiles are color encoded in a bitmap. Objects that span more than a tile are represented by a pixel indicating their starting position only. The rest is constructed during run-time.

Downtime, trying to give up

With this prototype i ended the first LD phase. I had a feeling that there was not enough time left for me to fully finish a playable game. I started on sunday, 1:30am GMT-2, so there were only ~27 hours for me to work. My woman and I planned to go to an HR Giger exhibition the same day. Let’s say she was surprised to see me awake at 8am in the morning in front of the netbook. I went to bed at around 8:30am and got up at 1pm. At that point i gave up on LD as i figured i’d only have 8 hours when i come back from Vienna (trip was estimated to take ~6 hours). Some impressions from the exhibition (couldn’t photograph the actual artwork).

The toilets in the Hundertwasserhaus are especially artsy fartsy.

Aliens with Penises and Tits, Phase #2

On our way to the exhibition we talked about the game in the car. For 2 straight hours. Steffi wrote up all the ideas we talked about. When we arrived in Vienna i had a full fledged game design in my pocket. I was psyched. I knew with this in my hand i could easily finish of a basic version of the game in the remaining 8 hours i had when we came home at 8pm. Here are the notes in German:

Translation:

• Chambers
  • Entry/Exit, use cube to open the exit.
  • One or more cube dispensers/respawn points
  • If there’s not cube in the scene, the last touched dispenser generates one
  • Cube follows automatically
• Controls
  • Keypress activates cube control via usual means (w,a,s,d)
  • Pressing the same key while the cube will return control to Bob, the cube freezes for n seconds and is collideable (useable as a platform). Once the time is up the cube follows Bob again.
• Obstacles
  • Bob can die in which case he respawns at the last touched dispenser. Same is true for the cube
  • Spikes – kill Bob
  • Lasers, vertical and horizontal – kill Bob, can be blocked by cube
  • Moving Spikes, vertical and horizontal – kill Bob & Cube
  • Homing Missles – kill Bob, blocked by cube
  • Robot – kills Bob on collision, no effect on cube
  • Shooting Robot – kills Bob on collision, shots blocked by cube

A sequence of levels was also losely defined:

1. Introduce dispenser, cube & exit
2. Introduce jumping and cube following
3. Introduce spikes (no help from the cube needed)
4. Introduce moving spikes
5. Introduce non-shooting enemies
6. Introduce spike pit only traverasble via the use of the cube mechanic
7. Introduce shooting enemies and corresponding cube mechanic
8. Introduce Lasers and corresponding cube mechanic
9. Introduce homing missles and corresponding cube mechanic
10. Be creative with the elements from here on
11. …
12. EOL!

Back home i looked at this and was excited. I had 8 hours left, a very simple prototype and a full-featured plan. I started by prioritizing game elements. The doors went the way of the Dodo, they didn’t add anything to the game play. While they would be a motivator to keep the cube alive they were ultimately point-less: you can always get a new cube from the last dispenser, the only effect would be that you have to replay the level from start without any real benefit. Frustrating!

The enemies were cancled as well. I thought the other game play elements (spikes, moving spikes, homing missles and lasers) where interesting enough. I was also confident i could implement them all in the remaining time.

After some reordering of the level sequence i decided to have a single big level with multiple dispensers. Sort of like in VVVVVV. Continuous level for the win.

The level itself would be tile-based as said earlier. Objects would be encoded as pixels with specific colors, e.g. a dispenser would be red (0xff0000), a laser cyan (0xffff00) and so on. An object’s pixel would only signify it’s position in the world, not it’s extend. Lasers and moving spikes span multiple tiles in-game for example. I could easily derrive all properties during runtime given only their position, e.g. their direction and so on based on their surrounding.

With all this ready i started hacking again. And hacking i did.

Hackaton, Phase #3

Everything went a lot better then excepted. I added one game element after another. I set a time-frame for each feature and a sequence of implementing them. 7 hours to go!

• Cube control & following with Collision detection: 30 minutes, code is basically the same as the one for Bob in the prototype
• Spikes and collision detection & response: 60 minutes, this included respawn points, animating Bob’s death
• Homing missles: 45 minutes, this included spriting the rocket and an explosion plus the usual physics/logic implementation
• Moving spikes: 60 minutes, a simple afair of figuring out the direction based on the position & surrounding of the spike in the map as well as collision detection with the map and changing direction in that event
• Lasers: 80 minutes, basic setup as with moving sprites (figure out direction and end position of laser) plus some more involved collision detection with the cube (blocks the laser mid-way) and Bob. I knew this could get hairy but it turned out better than expected
• Screens: main menu, intro screen, game over screen: 30 minutes. I decided to go with a rather “make-your-eyes-bleed” single image per screen style which could be implemented quickly.
• Exit & Gameover state: 30 minutes. Another simple afair, just place the exit somewhere in the level and trigger a screen transition to the game over screen
• Level Design: 80 minutes. I wanted to have one continuous level. For this i made a special respawn object that let’s me test different chambers immediately on the go. This system let me test a specific chamber immediately. I just moved the object around the map when i created a new room. This way i could generate a level that takes an average player (Steffi) around 6-7 minutes to complete. Not a lot but enough for my needs.

As you can see in the timelapse i could stick to that schedule pretty much 100%. The final packaging took about 5 seconds. Export -> Runnable Jar.

I delivered the submission at pretty much excatly 4am local time, a spot on submission so to speak.

What went Well

• The decision to use a bitmap to encode the level information was a good one. I did not have to battle any editor i wasn’t familiar with and could make up new encoding rules on the go. Previewing was also painless and always only two keystrokes away.
• Since i decided to eat my own dog food in form of using libgdx for this i was curious if our design decisions would hold up in an extreme situation like Ludum Dare. Thankfully the framework never got into my way at all. Everything i needed was in place, from input handling to rendering and some math & collision helpers. Of course, the game is pretty simple so i did not have to make use of any of the more advanced facilities in the framework. Never the less it turned out to be extremely simple to work with.
• Having a full design is something i can’t state the importance of enough. Seriously, if you enter something like Ludum Dare, spent enough time to make everything watertight. It’s so much easier to work from a design then to make up shit on the go. Of course i first prototyped before i went full-design-metal. Once you know your prototype works start designing, not coding!
• Paint.NET is a joy if you know all the keyboard shortcuts. I was able to pull of all the asset and level creation in no time.
• Having ~20 people in our IRC chat was valuable as well. I had some test slaves and some of the folks could even give me tips on how to approach the fsm damn initial collision detection problem (never did a platformer before…). Thanks Kivan!
• The schedule was also very helpful and allowed me to make the deadline. It would have been very easy to get sidetracked with a small detail otherwise. Keeping my eye on the clock was a “good thing” and mostly responsible for me making the deadline.

What went Wrong

• Having done some rather elaborate math and computational geometry in the past i thought that the collision detection for a simple platfomer would be a piece of cake. Not so. I spent full 4 hours out of the 13 hours total to get Bob to correctly react to his surrounding. That was rather embarassing as i thought i was knowledgeable about most game development stuff. The more you know! A humbling experience.
• Due to me starting on the second day and spending a good 7 hours on none Ludum Dare related things i was really short on time. I think i could have created something a lot bigger if i’d used the full 48 hours.
• Sleeping for 4 hours is useless. Sadly there was no other option. I really wanted to see the Giger exhibition and spent quality time with my woman. Note to self: sleep at least ~8 hours before and dacuring Ludum Dare!
• I did not have time to include sound effects. Which is funny cause i really think sound makes up 30% of a game easily in terms of immersion. I’ll do better next time (sfxr & my own sequencer to the rescue!).
• The level design is very basic. I underestimated the time needed to come up with something fun and engaging. I think the basic game mechanics and elements would allow for a pretty decent game. 80 minutes are simply not enough to explore the full potential of the game. Spent more time on this item the next time!
• The game is controlled by w,a,s,d and e. It was my goal to keep the controls as simple and intuitive as possible. To bad i forgot to add an option to “unfix” the cube. At the moment it will stay fixed for 5 seconds which can disturb the overall flow quite heavily. I didn’t think of letting the user press e when the cube is fixed so it starts following again. Oh well

Conclusion

I haven’t written a single “real” game in over a year. The three games i wrote for the book felt a lot like work due to the time pressure, so i don’t count them. Hacking away on libgdx, while game development focues, is not the same either. I nearly forgot how enjoyable game development can be. So, thanks Ludum Dare you reminded me why i do this

My Ludum Dare 20 Entry

Source Code

Playthrough (Warning, Spoilers. Or so…)

This entry was posted on Monday, May 2nd, 2011 at 2:46 pm and is filed under LD #20 - It's Dangerous to go Alone! Take This!. 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.

Forever Alone

Play and Rate!

Not sure exactly what’s meant to go in the post mortem, but here’s my lengthy shot at it. This was my first attempt at the Ludum Dare competition so I went into it with no knowledge or expectations, but I did completely underestimate just how hard it was going to be to whip up a game and all of its assets within 2 days (A huge mistake considering it usually takes me 2-3 months just to create a engine/framework for my game projects which I never end up finishing anyway).

So I was reading up on what tools people were generally using and FlashPunk/Flixel and Flash Develop were the most mentioned so I thought I’d check them out. I used to make little games in Actionscript 2.0 a couple years ago so I thought Flash wasn’t going to be a problem, then I learned that with Actionscript 3 they made the shift into more Object Oriented waters, which also wasn’t a problem, and when I noticed how close the syntax/principles were to Java I thought that all I had to do was look at the API for both AS3 and Flashpunk and just throw my game together, and this derailed about an hour before the competition when I tried to make a quick SHMUP to see that I could make a game using these tools. Now the reason I didn’t just use Java was because I didn’t have time to make an engine absolutely from scratch and a game on top of it, and I didn’t know any Java Libraries / Engines in the same respect as Flashpunk. I found that even though I was well versed with OOP design principles I had no clue how AS3 operated and where to find this Class and that Class and what do I need to extend to make this work, etc. So I realized there would absolutely no way I could create a game within the time constraint while fighting against the tool that was supposed to help me do it. So I bit the bullet and decided to use Game Maker 8, and only be able to distribute to Windows and Linux users with Wine, and with no hopes of web distribution.

The moment the theme went live I sat down for exactly 10 minutes and wrote up a draft in Notepad detailing the extremely complex(not really) and silly/good natured premise of the game, this was a wasted 10 minutes because I ended up using absolutely nothing other then the title of the game! After the 10 minutes I cracked open Game Maker 8 and decided to not think, and just do. This was my first obstacle because I had to relearn all of the different functions available in Game Maker since I haven’t used it in any respectable amount for years.

After I quickly looked over the well written documentation for GML, I created a room, this would end up being the Main Menu Screen and this is where I implemented the first playable version of the platforming. I decided to first get the platforming engine out of the way before doing anything else, and this was a lot of fun since I never created a platforming engine before, so I created the player object and just started cracking away at it. Essentially I made it work like this: There are blue and red squares placed in the room and are invisible to the player, blue blocks vertical movement, red blocks horizontal movement. Player movement is done using velocity which is incremented when the user supplies input, and is constantly reduced to imitate a simple man’s friction/gravity (Since I don’t really know physics). Jumping creates a sudden jolt in vertical velocity, and the walls/floor set velocity to 0 when impacted. Now the first Issue that I saw was simply checking for collision with the player and an instance of blue/red would make the player stuck in the axis corresponding to the color because it was constantly setting velocity to 0. This made me think a bit and I learned a new principle for future games I make, and that is for good collision I shouldn’t be checking if the object collides with the wall, but rather if it is going to collide with the wall, this breakthrough allowed me to implement smooth movement in both x and y and when I was happy with it I decided to create my first couple of blocks of my tile-set, which ended up being only used in the Main Menu, which is why you will notice the graphics get better from that point on.

Platforming

Old Main Menu

Then I realized that I needed a theme song! So I downloaded the program Pxtone because that’s what I read some people were using. Something must have been wrong with the download because all of the message strings in the program looked like they were written in the Wingdings font, but the program itself was simple so I figured out how to make a loop, although exporting took some attempts since I didn’t know what anything said,For the creation I used a basic dubstep beat setup along with a melody I created on my piano and that’s how you get the theme music! I also downloaded SFXR because I wanted sound effects in my game for everything from little things like the player jumping/hitting the floor to contextual information in the minigames.

Next I decided I wanted to inject a tiny little plot, or some purpose into the game, and that’s when I decided it would be cool to have an mysterious Announcer character who is visually represented by a spotlight, this also gave me a tiny little break from making the game assets to create the ray-casting routine for drawing the spotlight. Then I decided the spotlight would basically serve as a guide through the game so that you know how to progress. For the implementation of the theme I had the spotlight give the player a “Sword of Confidence” which basically sets up the mini-games and the idea that the character needs confidence to stop being so alone.

It's Dangerous to go Alone, take this!

From this point on I decided that I wanted to make the player do basic tasks that build his confidence and ultimately get him a date. I decided on the following gameplay: Platforming to explore the level and find the task, and then have the task be a timed event minigame sequence of having to press the correct arrow before the timer runs out a certain amount of times. The object I created to handle these minigames was dynamic enough to allow me to simply specify how many arrows I want it to display, and then it proceeds to run the minigame with that amount of arrows, and decreases the time the player has to respond which each following arrow. When the minigame is finished it awards the player Confidence Points based on how many arrows he completed and then plays a short ACHIEVEMENT-esque animation to add some flare to the game, and to allow for a few bits of humor.

Minigame

Confidence Boost!

After I had these basic systems in place I got to work on drawing the tileset for the level in Photoshop 7, creating the tileset and then placing it was the most time consuming aspect of the project! It took me roughly 12 hours just to implement the first level because I kept going back into photoshop because I wanted to add something like a toaster, or a sink faucet, or some towels, etc. I’ve never really done pixel graphics before so it was a lot of fun seeing a whole game made out of pixel art that I created because I don’t consider myself an artist! One thing I can take away from this process for future projects is that I should probably map out my levels before I create them, that way I know what kind of graphics I need and what the design of the level will be, here I just created the levels one section at a time, and it really wasted a lot of time.

Early Version of Level 1 (Zoomed Out)

After I implemented the levels and the objectives, I decided that it would be good to add the announcer as a colored light at the end of the level that tells the player what objective they should complete next, this way, the player isn’t just running around the level trying to find objectives to complete, and that he knows which one he should focus on next, however if he chooses to, he can complete the objectives in any order and ignore the announcer.

Quest for Confidence from the Mysterious Spotlight!

And then comes the twist ending to wrap things up. I wanted to inject some more humor into the game and make the player look at the events that transpired before and after the ending with a new perspective, and to also tie in the name of the game! A strange coincidence that I noticed that goes nicely with this ending is that when the announcer throws the sword at you and it chases you, the only way to indefinitely run away from it makes the sword follow a path the resembles a sideways 8 or infinity =D Unintentional but does help drive the ending home.

Thank you for reading what I hope is a correctly done post mortem, I had an absolute blast making this game and participating in this competition, and the knowledge I picked up implementing the platforming and mini-games will be invaluable to me for future projects!

So this was my first Ludum Dare – ever. The only thing I had expected was to have “something that doesn’t crash – and it has a gameover screen” and a funfun time doing it. Largely, this was a succes.

First of, a few things of note about the compo itself. One thing is some of the submissions that are simply astounding for a mere 48 hour project. Several of them are basically “Newgrounds-ready” and with a production value that compares to games with several months of dev time. Being able to launch that much content (and of such a high quality) in so little time is both intimidating and inspiring.

The other thing of particular note to me is the very liberal interpretation of the theme. Being a hardcore rule jockey I intended to infuse my game with every ounce of the theme I could muster, the phrase itself being not only a corner stone but the very pivotal point of the interactive experience. This stands as a stark contrast to by far most of the entries I’ve rated so far (about 70 as of the time of writing). Mostly it was a question of slapping out the phrase within the first 15 seconds or two game screens and just have it done with – then send the player onwards to something else. It strikes me as unfortunate, as I perceived the theme not only to be a loose constriction (and at this point, more a labelling requirement than a constraint at that) but a creative demand on the developers. However, several games managed to use the theme in subtle and unspoken ways. All manner of partnering mechanisms have been displayed in ways I wouldn’t have dared to imagine, and it’s been a thrill to experience an actual interpretation of the theme as a gameplay mechanic more than simply a phrase or a meme. Thank you to those devs for the experience

Now, back to my poor excuse for contemporary satire. As I woke up four hours into the compo and saw the theme I had an instant vision of the game and its purpose. I wanted to expose and criticize the theme as it has manifested itself in modern-day zombie horror games, basically from the transposition “it’s dangerous to go out alone. but I’m not going to go out with you and instead offer you something that may or most likely may not be of any assistance to you in your coming challenges”. Intended as a light-hearted jab at the large body of zombie games I wanted to depict the eternal and largely futile journey of post-apocalyptic survivors in the wasteland. The actual gameplay challenge would lie in very simple mechanics from one round to another against a horde of enemies with no particularly discernable features.

What became my downfall, I think, boils down to experience – pure and simple. I have never constructed a “finished” product before this weekend, and I spent a lot of time getting to know library mechanics of flixel I had never worked with before. I spent time getting to know musagi and sfxr and lost almost an hour of work trying to make musagi export wav files (an issue most likely caused by sound card and driver). Being an incarnated code monkey I live by the addage “content comes later”, constructing frameworks, boilerplate, mechanics and anything that is made with a text editor until I absolutely have to put something into image or sound.

To be fair, though, the final version differed primarily only in content, but I would have liked to do these things:

• More items. Either 12 distinct items with different mechanics or 3-4 base mechanics and a slew of aesthetic variations on them. I ended up with 3 release, 1 coded item. The final item started out as a sparkler (don’t ask), turned into a flamethrower (simpler implementation), finally a stick (even simpler). The stick was basically a burning spear and so I removed it.
• An actual way to die from the challenge, not from boredom.I had planned more zombie types and I would have liked distinct options for defeating each, to make sure the player actually had to think while playing.
• Prettier graphics. All over. 6 hours before deadline I was suddenly struck with a graphical style I could’ve pulled off if I had the time. I had to rely on a mouse and Paint.NET to draw the barebone necessities.
• A more solid soundtrack. I wanted to make a single ambient musical soundscape underlying the complete game, while subtracks would play within each game state to underline their purpose. I simply didn’t have the time or skill to compose something that could have done it properly.

In the end, however, I’m satisfied with myself, and I’ll prepare better next time. Buy a drawing tablet, have all the necessary software installed beforehand and spend weekends up to the compo running drills to prep myself.

Now then, I’d better get back to enjoying the other entries. I’ve been laughing steadily the past two hours over one entry or the other and there seems to be no end in sight

Here it is, in all its shining glory.

2 days of me not working, frowning, and faffing around in front of my PC, while I allegedly create this game.

View it here.

Also: HOW CAN I EMBED VIDEOS. Nothing seems to work. This is driving me nuts.

–Matthew

Tags: 3dsmax, max, photoshop, timelapse, unity, unity3d

My first LD, and well, that was a lot of fun!

I called the game I made Deadweight. It’s a puzzle-platformer which revolves around a boy taking his narcoleptic sister on a day out.

Overall I think it’s pretty successful. The gameplay is simple, with variety and challenge coming from level design. There are 12 playable levels, plus two for intro and outro.

I economised on art by choosing a cartoon style, and having all characters made of circles. I think they turned out with a lot of personality, considering…

Assorted technical details

Levels are defined by way of numbered PNG images, starting from 0.png. Pixel colours in each file define the world, and gameplay parameters such as start and goal position. Each pixel is one game metre, so the images are small.

Here’s the first level and seventh levels:

Each level PNG has a text file for dialogue — this is a pipe delimited file displayed before gameplay begins. It’s used for the start and end levels as well as the name of each level.

Source documentation

A quick tour. The source looks like it was rushed because it was!

• BallEnemy: this is the red enemy balls, which try to knock you around. Before each physics step, they apply an impulse toward the player. You can probably tell the ‘prephys’ method was hacked a lot to balance their strength.
• BoxEnemy: these were originally enemies, but I changed my mind. They are the grey cubes and circles which are mostly inert.
• Consts: tuning constants.
• Eyes: shared code for eyes. I spent a long time on this. Eyes have three modes: search, random or movement. In ‘search’, a small AABB is queried around the eyes for other things with eyes — the eyes look at the eyes of this other thing. In ‘random’, the eyes choose a random target vector each blink (so, they look around). ‘Movement’ makes the eyes look in the linear momentum vector.
• GoAloneListener: libgdx ApplicationListener. This manages movement between levels by instantiating ‘LevelStage’ objects and directing calls to them as necessary.
• Help: big heap of boring static functions.
• Input: a libgdx InputProcessor. This stores input state which is applied each physics frame. It also allows input to be blocked for a number of physics frames for debouncing purposes.
• LevelStage: you know God classes being bad? This is one. This takes care of physics steps, entity management, rendering the level, level state management, building the background gradient quad, panning the camera to follow the player, reading and rendering the dialogue, and reading the world. Phew!
• Player: this is the player entity. It draws itself, and implements movement left and right (both on land and in air, which was irritating to implement!) and jumping (with debouncing).
• Runme: libgdx stub which makes a GoAloneListener.
• Sister: the inert sister entity, and also the mother.
• Sound: Plays game sounds and music.
• Textures: loads the single texture atlas and doles out textures from it by name.
• Weight: unused (a precursor to the sister class which I forgot to delete!).
• WithPhysicsBody: A bunch of concepts common to most entities in the world — like ‘things with eyes’ and ‘things subject to physics’ and ‘things with a position, size and rotation in the world’.
• WorldTile: cloud and world tiles. Includes bonus layering violations!

Things I would have done differently

• Be happy with the physics parameters before making non-trivial levels. The size, mass, bounce, friction of entities changed late-on which required rework of all levels — a total waste of time which would have been better spent adding to levels.
• More frequent breaks. I was burned out 6 hours before deadline, so I could have taken it easier on Saturday.

Things which worked out

• The level construction method was pretty fast, if a little ghetto.
• libgdx. Really useful features, without imposing structure. I found a bug part-way through which happened to be already fixed, so I rebased on a later version.
• Fruityloops. I got this only recently, but I turned out some satisfying music in a couple of hours.

Things still to do

• Android port. It’ll need some onscreen controls building and I’m a little burnt out now.

Get the flock out!

So yeah, first LD.  and I survived!  Woo!  48h to create a game is certainly even a bit more intense than I expected.

What went right:

I finished a game – more or less.  I certainly wanted lots more stuff to go into the game, but given the time constraint, I felt like I was able to prioritize.

Monocle is a pretty great framework.  It simplifies a lot of the grunt work of building a game, but doesn’t get in your way.  The abstractions are natural and flexible.  The documentation is still very in progress or missing, but the code is easy to read, and the examples do a great job of documenting how to use the framework as well as some basic game algorithms.

C++ didn’t kill me.  This was some of the first coding in C++ (or any statically typed language) that I’ve done in years and years, and it really wasn’t that bad.

Saturday night, I was figuring out how to go from “toy” to “game.”  I had some game ideas together, but I just wasn’t feeling good about the game.  In a non-crunch environment, it was the kind of feeling that would make drop the project and go watch Doctor Who.  I stepped back and thought about what piece of my game idea I liked – the ridiculous personality of the sheep – and focused on that.  It let me do informed design and better prioritize what do do with the remaining time.

Recording your friends making sheep noises is fun.

Playtesting!  I actually got to watch a person or 2 play the game.  It really helps you realize when things are unpolished and really need to be fixed.

What went wrong:

Bugs.  A few bugs definitely made it into the final version that I maybe could have caught if I’d been able to play the game more than once in its final form.  Not bad for a first run though.

Do it the simple way.  It’s way too easy for me to want to tackle a difficult design challenge.  Early on, I implemented a boids-style wander algorithm for the sheep.  It took a couple hours to get working and integrated, and it looked awful.  Sheep don’t move like birds.  Late Saturday, I tried to integrate entity spawners into Monocle’s XML-based map system by overloading some map loading code.  Although there could be some merit to that approach, this was way too complicated for a weekend competition and required way too much understanding of a complex system for being sleep deprived.

Environment.  LD seemed like a fun excuse to have an “art party.”  I was in a space with people designing a puppet theater piece, sewing a cartoon quilt, making monsters out of old sweaters, and building an accordion.  While this was fun, it was not very helpful for deep thought for code and game design.

Lessons for next time:

No really, sleep.  I wasted probably 4 hours early Sunday morning trying to work on things and definitely making things worse.  I would have been way better off going to sleep and being fresher on Sunday.

So yeah.  Thanks for a great weekend, all.

My game, Princess Mystery Dungeon, is now available in savory Windows and sweet OS X flavors! A big thanks to Spooner for packing up the Windows build for me.

If you haven’t tried it yet, give it a go!

(One warning: There is a very occasional crash during the initial dungeon creation that I haven’t fixed yet. If the game crashes on launch, try running it again, it should work most times).

(There are may be other crashes, too. Probably there are! If you run into any, let me know, and I’ll try and get them fixed.)

Final Version:

We’re kind of sorry not beeing able to submit in 48h, we had to polish it a little, but here we are.

It’s been a great experience beeing able to work with me good chumps abe and Aries in this ludum dare.
We’ve loved the ludum spirit, thank you all for this great human experience.

See you next time, maybe in the comp !

if your fancy, you could “rate” it too, we would be happy to have your feedback.

The submition is here. (with decided to give the full Code/GFX/sound sources if you want to take a look)

Asteroid Explorer by McFunkypants

A Molehill tech demo programmed in 48 hours for the LD48 game jam.

Featuring high-poly Flash 3d hardware acceleration, .obj file parsing, heightmap terrain generation, terrain “splatting” multi-texturing, cube-mapped skybox, mp3 engine sound with pitch-shifting, rigid-body car physics simulation, flash sprite 2d overlays, and Molehill (AGAL) vertex and fragment programs.

This game requires Flash 11 or the incubator beta version which can be downloaded here:
http://labs.adobe.com/downloads/flashplatformruntimes_incubator.html

Please visit my blog: www.mcfunkypants.com for more games, music, art and code.

I warmly invite you to follow @McFunkypants on twitter (I *only* tweet about game development)

Play the game here:
http://www.mcfunkypants.com/LD20/

I would LOVE your comments and feedback:
http://www.ludumdare.com/compo/ludum-dare-20/?action=rate&uid=2297

Tags: 3D, as3, baby, cute, final, flash, McFunkypants, Molehill