So! I didn’t finish my entry. I submitted it, but it wasn’t finished and I can’t help but feel a little defeated. The levels needed more design and more content, I wanted to add a jetpack (mobility enhancers are mandatory in metroid games :P), 2 more guns, at least 2 more types of enemies, a boss fight, and narration. I’d have been happy to have gotten there, but looking back… I was pretty screwed.

So I’ll start with my mistakes, first:

– Not the base code I wanted: I had planned on prepping some base code beyond Flixel (perhaps even writing my own flash game engine), but didn’t get around to it. This alone isn’t a huge deal, since the starting point I had is still quite good.

– A bit lost: Not much dev experience with the sort of game I was trying to build. Coding wise, it was mostly pretty simple 2d logic, but if I had had more experience, I would’ve used (or created) a level editor and I would’ve gotten the characters up and running much faster. Not to mention I would’ve prioritized dev for gameplay features a lot better. At least I learned a lot!

– Bad planning with my time: On top of mistakenly thinking I had 2 hours longer than I really did, I wasn’t really in gear on Saturday, yet Saturday accounted for more than 1/2 of my dev time. I still got a lot done on Saturday, but I left a lot of important stuff for Sunday, stuff that would’ve allowed me to begin designing levels much sooner.

Point by point:

– Gameplay: I wasn’t trying to do anything particularly clever, just good fun sidescrolling, action/adventure gameplay. I do like what I got, but it was a shadow of what I wanted. Unfortunately the game is such that more gameplay depth requires a fair amount of new content, which is time intensive, which makes it a bad fit for LD. Still, of the stuff I did get around to adding,  I feel like I got it right.

– Art: I’m really enjoying drawing sprites, it’s not something I normally do. I love the walk animation on the guys! I might try drawing some sprites in my free time now. With some more practice, I think I could put more detail into my characters.

– Graphics, tech wise: My shadow implementation could be way better, but despite this, I was able to make it look okay. It tripped me out when I realized I was placing static lights in my levels as decoration! The fx and such were okay, but now I want to make a serious fx-oriented particle system.

–Sound!!!: This one really tore me up. I wanted to use pretty realistic sounds and couldn’t bring myself to use sfxr. That left me in a pretty bad spot, so I just gave up. Lame!

Overall? I like it. It can be played and enjoyed. But it’s clearly unfinished. It makes me want to work on it more.

And a parting thought:

I didn’t realize this at first, but looking back, I clearly approached this LD as an excuse to prototype a game – but not necessarily finish a game. Next time I’ll be seriously considering going for a smaller game design.

Tags: post-mortem, postmortem

First off: Many thanks to PoV and phillhassey, and others who donate their time to this event – Seriously, they don’t get enough credit.
LD is great partly because it’s so well organized – thanks to having the infrastructure and so many people involved it’s easy to get and stay excited about the idea – I think this is a major component of the fun in LD, and it wouldn’t be possible without a lot of effort on their part. (besides of course, what fun would going insane be if you weren’t alongside 150 of your closest friends? )

So, on to a postmortem of my game…

My project went immeasurably better than my last entry, in LD11; To recap, in LD11 I spent about the first 30 hours building (And debugging) a rendering engine, which didn’t bode well for coming up with anything spectacular in the remaining time. I was also preoccupied with a few other things (including an addictive online game – hah). Ultimately though, I wound up with a minorly neat techdemo type game that was mostly thrown together near the deadline; I didn’t really want to finish it at all really, besides just to have something playable.
This time around, I had most of the rendering code done beforehand (and released in a library) – I didn’t get very tired of working on this project until very nearly the end – it was a very enjoyable experience.

A list of things that went a lot better than I planned:

• The pre-LD library release
  Having a library of basic rendering / audio code made a lot of the menial tasks of game development a thing of the past; I still wound up having to write some additional rendering code, but it wasn’t a long and drawn out process of debugging to make it work.
  All of the graphics in my entry are in fact procedurally generated or rendered by simple code, there are no art assets (except perhaps the font; that’s a windows system thing) – Having a coherent graphics library helped with this substantially. (I’m not an artist, you might be able to tell)
• The cavern generator
  In case you hadn’t noticed, the cavern is randomly generated every time you play the game – Most of my effort in this LD went into building this cavern generator; Ultimately I wound up with some simple rules for generation that worked rather well. I had to special case some logic about which caverns are allowed to connect to others, due to some really odd glitches when it was completely random (sometimes a connecting passage would run on top of another cavern somewhere.) – But the end result is really rather nifty; It sometimes builds some insane and highly unusually shaped caves, and it always connects all of the caves together. If I actually had an interesting gameplay mechanic, this would have been an excellent platform to execute it in 😛
• Other technical things
  I love LD because it’s such a good platform for just trying random stuff out. One thing I did in my entry was to split the rendering across multiple threads – So there’s a one frame lag in the world position, but it’s not noticeable at all in the game. The helper thread renders the cave world to a backbuffer one frame ahead, and then the next frame that backbuffer is copied, and used with the lighting code to composite the final output bitmap. I thought it would be harder but the simple signalling system I used was rather painless to implement, and I guess I’m fortunate that my rendering was simple enough to split off without having to deal with more complex synchronization. So if you’re on a multi-cpu system, you get a slight speed boost from this (And I did test that it works fine on single-core systems as well.) Additionally, this second thread performs all of the cavern generation, which leaves my main window thread free to render a progress bar – Having the player wait while the game appears to be frozen didn’t seem like a good idea.

And, things that didn’t quite go as planned:

• The Theme
  This theme was really the sticking point for me – I couldn’t come up with any gameplay ideas that I thought would be doable in the time limit; And I wound up not picking one to attempt until it was too late to do anything serious. As such, my game has a very simple goal. One of the early themes I came up with was one of “Exploration”, but I couldn’t work out how to fit that into a game without being boring and repetitive. So, I guess you’re free to explore the game world in this game, and if you don’t want to explore, there’s not much to it
• Music
  Hey! I had music! I’m reasonably happy with that. It’s very basic, and procedurally generated (just a set of predefined sequences playing with a random base note)… I just feel that so much more could have been done with this.
• Rendering speed
  Well, everything is software rendered. I was so happy to use my brand new shiny rendering lib – but it is a little on the slow side (it’s highly generic) – some of you have noticed this, on slower computers. The lighting effect in my game is built using essentially a pixel shader that copies pixels from a backbuffer to the front buffer with some lighting value – It’s rather far from the most optimized way to do this… However, I expect the game will be playable on most semi-modern computers. If I had to do it again, knowing what I know now, I would probably opt to set up direct3d or something, and use hardware rendering for this effect.

Overall, as I’ve said, I had quite a lot of fun this LD, and I think I’ve come up with a number of good points I can improve on: I should probably work to secure gameplay sooner, even if it means trying something that doesn’t seem possible. I should probably expand my rendering library to make it easier to import external graphics, so I won’t be so tempted to procedurally generate everything (Or just build much better framework code for procedural generation)… And all games could use to have more cats in them.

That is all, thank you for your time
-Stephen

Tags: postmortem

A GROSS OF CAVERNS!
(all 144 screenshots in one big 12×12 grid!)

http://benhem.com/dumpage/ludumGallery/

Because it’s there. And because 12^2.

–Ben

First the bugfix release:
GoblinHome 1.0.1 bugfix release

This was my first Ludum Dare and I’mhooked. Last weekend was really fun trying to get a game completed on time. I didn’t get the game I originally envisioned done but I got a good start for it and it does have a winning and losing condition so it is a game.

The good:

Time – I was able to schedule the core game first to result in something playable, even if I didn’t get all that I wanted done.

Blender – It was my first time using blender’s texture painting mode. I was able to make the troll’s texture in blender much faster than I was able to make the goblin’s texture in photoshop. It works very well.

The bad and what I will do better next time:

Blender – It’s been a few months since I modeled something and I forgot a bunch of the myraid of hotkeys and functions and spent time looking them up.

Art – It took 6 hours to make the goblin and 2 hours for the troll based on the goblin. I probably could have used my time better for features by making worse models. Part of this is probably also because I forgot my blender commands.

Photoshop – Photoshop stopped responding to my tablet’s pressure sensitivity right before I created the title and conclusion screens, which was a pain to figure out.

Group selection and health bars – I’ve been getting a lot of comments on these. When it came down to the end I had the choice of group selection, health bars, or a selection indicator for the currently selected goblin. The selection indicator won out as the most needed. The others were next on the list!

Framework – I didn’t have one so I spent a good chunk of saturday writing code to glue ogre, cegui and ois together and make a basic blank screen app. Next time I should make a framework to use to skip some of that.

The crash – There was a crash that took a while to track down that I did not see while developing. If you were to click on the goblin’s selection circle it would crash with a null pointer error. This has been fixed in the bugfix release. The bugfix release also fixed a rather nasty memory leak in the pathfinding which I originally thought was the crash bug but wasn’t.

I got a couple of reports that my game, Cave of Peril, was unplayable because of a bug that only showed its ugly head on certain systems. I have finally tracked down this bug, and updated the .zip files (just the bugfixes, no cheating here!), so anyone who has experienced this can now enjoy and/or be completely frightened by the Cave of Peril!

I hope you enjoy it!

This was probably the best Ludum Dare weekend I’ve had.  My game was more than just a tech demo or an ‘unfinished’ idea.  Of course, they never are truly complete after 48 hours time; there is always something else that can be tweaked or added.  When all was said and done, however, my entry was a playable game.

Background

The theme was not one that I had put much thought into before it was announced so I really had zero ideas at Go time.  One thing that kept popping into my head was the Kroz series of games by Apogee software back in the late 80’s/early 90’s.  They’re all pretty much the same engine with a new collection of levels, but one was called Caverns of Kroz.  The object of the game is to take your hero through twenty or thirty levels to find or capture some relic.  Along the way you had to run, whip or out-maneuver swarms of monsters and solve puzzles.  I had always thought those games were neat, and it would be interesting to try and ‘recreate’ some of that nostaliga.  Caverns of Kroz didn’t have anything special that made it more caverny than the rest in the series, but I thought I could do better with actual graphics instead of ASCII art.

Top-Kingdom of Kroz, Bottom-LoneStranger's Caverns

Graphics

One of the first things I do in a LD is grab a piece of printer paper and start sketching some objects.  More is better, even if I think I may not use them.  For LSC, I sketched a few doodles and scanned them in.  The designs were done in homage of the original ASCII characters and colors.  For example, my monsters look remiscent of the Ä, Ö and Ω characters.  The first problem I had to resolve was how big to make the map.  Kroz uses something like 60×24, but I don’t really like how smushed that is.  I wanted a square ratio on an 800×600 pixel window.  This led me to pick 16×16 as the tile size, which seemed small to me.   For the first couple tiles, the floor and the walls, I used 16×16 image to create them.  That went OK.  Next I took a look at my scans to turn them into tiles.  I did an overhead view of the player, basically just a head and shoulders.  I created the tile originally as a full 120×120 image with margins.  I colored him yellow and red like the Kroz hero.  I copied the merged image and pasted it into a new document that I then resized to 32×32.  Inside the drawing routines I have it again resized on the fly as 16×16.  The reason for this was that I may want to add a ‘zoom’ feature to the game in the future and it would be great if the images didn’t get pixelated.  I followed the same procedure for all the rest of the tiles.

The style of the art is not much different than the other LD entries I’ve done.  I don’t try to draw the straightest or the best.  I just draw to my ability.  Those are then scanned in and then modified in Photoshop.  Since I shrunk these down, you don’t see the imperfections as much, and maybe that’s better?  I don’t think some people ‘get’ that the imperfect art is part of my style and I think I get marked down for it sometimes.

Coding

This is the fourth time I’m using the same general base code for my LD entry.  I think it shows because I have a hang of it’s abilities and limitations and I can get what I need to get done faster and more efficiently.  Also, each LD I add more basic functionality to it so I don’t have to reinvent the wheel each time, as they say.  Additions this time are an unfinished menu system and a tile/map data structure.

Most everything that I coded worked fairly soon thereafter, even the changes that take 30 minutes in between builds.  I think I had only two major problems: monsters moving over walls and monsters not dying when they move onto the player.  The first problem was because I couldn’t figure out why my collision detection logic was failing for monsters.  And it wasn’t.  I had an errant semicolon tagging along the end of an if statement.  My logic was fine and the if was completing an empty statement.  Then the next line moved the monster anyway.  The second problem was weird in that the monsters would sometimes die when they moved into the player, but not always.  A majority of that problem was due to how I keep track of the monsters.  I have two references for them.  One is in a two dimentional array similar to the tile map.  Either the cell has a link to a monster, or it’s null.  The second reference is in a linked list.  The grid is used for monster-monster collision detection since I only have to check the cell next to the monster for another monster.   The linked list is used when I have to traverse each monster object and is faster than checking every cell in the grid.  It’s actually a great idea but I was trying to solve the monster-player collision problem without actually having a fully implemented monster-monster collision.  It turned out that the monsters were moving into the same spot and the second monster was overwriting the first monster’s entry in the grid.  It was weird but once I finished implementing that code the rest fell into place.

These two problems cost me about eight hours split over Saturday night and Sunday morning.  If I didn’t have those problems, then my game would have been that much more complete.

I didn’t try to do anything too fancy in my code.  I could have spent more time doing things in a more efficient way for the future, but instead I hardcoded some functions just to get it done.  For example, I have eight different functions for the different directions in many parts of the code.  Those could probably be pared down to one in each situation if I passed some variables in.  I’d also like to combine the collision detection and movement between the player and the monsters.  Maybe base them from the same Mobile class or something.

What I did Wrong

Other than those two issues that I mentioned above, there wasn’t a whole lot that I did wrong while coding.  I did have a few too many distractions over the weekend.  My folks came over on Saturday to swim (which is great because it was triple-digit weather) and have dinner so I lost a few hours there.  That by itself wasn’t a problem but when I was actually coding I had the TV on which split my attention.

I also forgot to tie the score in with anything being done by the player.  Not a big deal, since score isn’t really much in the game yet, but it should have added some points for killing monsters and grabbing gems and whips.

Apparently my sounds were a bit harsh.  I used DrPetter’s sfxr to create them, but I must have used some weird settings because they sound fine through my 5.1 speakers, but they are harsh through headphones.  I guess I’ll have to do sound through headphones next time and hope that translates through the speakers.

What I did Right

I think I was helped by trying to emulate the Kroz series of games and it wasn’t because I had a model to ‘copy’ from.  I think the key was that the limits on what I was setting out to accomplish were already fairly firm.  I didn’t have to try to build in some weird functionality for the future, since I already knew where I was ending up.  The other LD weekends started with an idea that was to be flushed out later.  The only problem is that later usually doesn’t come and I am stuck with an incomplete game or a complete ‘thing’ that isn’t fun.

What I Wanted to Do After Last Compo

I wanted to work on my basecode after LD48 #14, and I did that.  I also wanted to scale down my goals, and I think I was able to manage my goals this time around by not setting them too high.  I think it’s a win.

What’s Next?

I’d like to continue with this project and there are a few obvious things I can do.

• Make the code more efficient and easier to read
• Profiling execution.  I haven’t tested lots of monsters or animated tiles yet, but it will probably suffer from performance issues.
• Level editor
• More objects and tiles
• Better level file format
• Continue adding basic functions to the basecode

So Mortem?  This thing’s just getting started!

Tags: ld48_15, post-mortem, postmortem

Here is a post-compo, not for judging build of my game.  3 additional levels, improved player movement and various minor tweaks.

The graphics are still very primitive, but I think the new levels are interesting.

Since I didn’t have the opportunity to test my game on other machines I was guaranteed to run into something bad. Apparently my game is dependent on two versions of the crt – fun fun! I should’ve checked the final binary for dependencies. Will fix that as soon as a I get back home from work.

The game should still compile on *nix (and mac) systems as long as you have a c++ compiler, sfml, boost, box2d and anttweakbar installed.

This is the last time I’ll use a prebuilt library!

Tags: crash

Just fixed a dumb bug in the way enemy selection was working in my entry that was causing minor problems with the way they reproduce and die.

Now you can have proper out-of-control slime populations to hack through!

Update: I’ve also just added an optional “crisp” executable for those who don’t like the blurry filtering. I can’t actually remember why I went with the original version but I seem to recall having a reason. Anyway, now you have the option.

Hint: I composed all the music on a gameboy.

I added “ports” to make my entry easy to run on Windows and Mac OS X. Windows now has double-clickable ‘cavern.exe’, and Mac OS X comes bundled with love, so you can drag ‘cavern.love’ onto ‘love.app’. No source code changes, just some repackaging.

Thanks to those that commented remarked on why they didn’t run the game. Those encouraged me to make it easier on everyone else.

ld15-cavern-secelis-windows.zip Windows version

ld15-cavern-secelis-mac.zip Mac OS X version

p.s. I don’t know how to update the links provided on the actual entry. My hope is that an admin will see this and either show me how to do it, or that it’ll just magically happen.

Tags: mac, port, windows port

So the competition is over, but I was interested in exploring my entry further. My hope is to turn it into something more enjoyable. Here’s a ‘day after’ version with a few less crippling bugs (don’t worry, it’s still possible to tunnel out of the world and fall forever).

Features include:

• 6 levels
• tuning
• more accurate particle effects
• rewritten player movement
• two creature types
• limited ammunition
• debris vacuum for refilling ammunition

<w, a, s, d> or <arrows> to move

<mouse> to aim and fire

<space> to vacuum up debris and refill ammunition

http://www.x2d.org/misc/misc3/wallsFixed.html

I didn’t intend to take part in this Ludum Dare.  A friend told me about LD a while ago, so I had looked in a little after previous competitions and liked the idea, but I didn’t intend to take part .  The same friend told be he was going to take part in this LD which I thought was neat, but I still didn’t intend to take part myself.  In browsing through the comments on the “Welcome to Ludum Dare 15!” post a few hours before the competition started,  I got to reading about what people said they were going to be using to make their entries and thought I’d check out LOVE for a bit of fun, not at all intending to make something for LD.

I’d never used Lua before, but found it simple to pick up and the LOVE libraries made doing things very easy.  I looked at a tutorial or two, then went out to get some fresh yeast so I could bake some red bean buns.  I was feeling a little inkling to maybe take part in this LD, but didn’t really intend to take part.  While  making the buns a friend of mine came over and we went off to wander around town and find somewhere for dinner while I let the dough rise.  Before heading out I checked to see what the theme for LD 15 was, as it had just officially started.  Getting back later that night to my over risen dough, I finished making the buns while chatting with my friend. The buns turned out pretty good.

My friend headed home and I wandered the Internets a while before going to bed, still not intending to take part in LD.  But I had seen the theme and as I drifted off to sleep I couldn’t help but buzz ideas about in my head.  I thought about how the theme cavern would be a alright for a concept I’d thought about a while ago.  Sort of super minimal survival horror with a limited view, though that was about as far as the idea reached.  I had no idea if the idea was possible using LOVE and lua, but I reasoned if I could draw back rectangles of varying opacity, I could get some cool pixelated lighting effects going, and I’d be happy with that.  So when I got up the next day, I got coding.

Without too much trouble I got a bit of a torch like effect, pointing from the middle of the window to where the mouse was and making what was lit by it visible (only a piece of text at the moment, which actually stayed till the end of the game, if you can find it 😉 ).  Then I added a bit of wobble to it so it would slowly waver back and forth when still, for a bit of flavor.  Neat.  But simply pointing a torch wasn’t so fun, so I made it so you could move around too (well, move everything else around technically).  Now I needed a protagonist to fill the void of the torch beam source, so I got to pixel drawing.  I didn’t really know what I was after when starting to draw, but felt I was heading towards something almost Lovecraftian in theme, so wanted something that wouldn’t look out of place with that.  Somehow this little guy developed (you can never really see the full sprite in the darkness of the game).  I like his tie.

(the 2nd and 4th line are the same, because it
saved me a few lines of code and a lot of hassle)

It kept on like this for pretty much the whole rest of the time, adding little bits, checking they worked, not really knowing where I was going exactly (kind of like the protagonist really…).  Probably the most important bit of code was the bit that cuts off the lightbeams from the torch.  This is pretty much single handedly what gives the game most of it’s atmosphere and charm in my opinion.  I also hit upon a rather amusing bug at one point that had me for a while.  When walking into a wall, instead of pushing you back like it should, you could walk into the wall and then the pushing back code let you walk inside with controls reversed, leaving you unable to walk out and trapped in the boundries of the wall (basically the reverse of what I was after).  Reversing the conditions for hitting a wall almost worked, except left the controls backwards now outside the walls.  The solution?  Reverse the keyboard controls 😛  Adding sounds was also a big part of the atmosphere, being the only real indicator for how far away the other occupant of the cave is,  That and I like the protagonists plodding footsteps.  I went to grab sfxrfor the sounds at first, but the site apparently hosting it was down.  So I looked around a bit and grabbed and tweaked a few things off Freesound, which a commenter informed me was actually a nono.

Overall the development went pretty easy. I was surprised how long the 48 hours seemed for me, even minus the first half day and first night.  Like pretty much everyone else, there are many things I would do differently if  I was to do it all again, but all up I am fairly pleased with what evolved for my entry.  Not really sure how the game actually plays for other people (after mass playing it throughout development) but hopefully it’s not  terrible.  Good luck getting out if you do try it.

Anyway, this was a little account of my accidentle unintended first Ludum Dare.  I might write up a bit of a afterthought on how the game ended up later, with some thoughts on how it could have been made better if I’d known where I was going when I set out.  I have to say I’ve had rather a lot of fun and plan to take part with a bit more intention and involvment for the next one.

P.S.  Does anyone even read these posts?

I fear that most of you wont enjoy the game enough to actually play it through, but I must say that I enjoyed the game by myself a lot, so I decided to record a video ‘walkthrough’ (of course this can’t be used as more but guideline, since the cave is procedural). Once again, I had really great fun with the compo, and for the first time ever I’m going to explore the game idea deeper (maybe I’ll even manage to make it more deriving from Spelunky)!

Watch the video here on vimeo!
Somehow the embeddation didn’t work…

My original concept for this game was to make a metroidvania type game with at least one normal enemy(a bat; every cavern game needs a bat) and one boss. The end result was much different than the original concept but things seemed to work out in the end even after dropping a few elements.

The game

What went right

• The language chosen(haXe)
  Learning to use haXe and using haXe for the game worked well. The language is very similar to actionscript 3 so there weren’t many times where I had to search for documentation while programming the game. This made porting my as3 framework much easier.
• Dealing with game assets
  I had an asset loader written in perl so that would run before the game built. Any asset that I wanted to add could just be placed in an image and sound folder and used in haXe with all the needed classes set up. This saved a lot of time and let me see how things looked in game instantly without having to change any code or playing around in FlashDevelop.
• The removal of original game concepts
  At roughly six hours before the end of the compo, I only had the player art and code done. If I tried to add an enemy and a boss, I would probably have gotten stuck on the art portion and would have had a game with just a player walking around. Adding the relics made the game a little less empty with some sort of objective to reach while keeping the implementation time low.

What went wrong

• Collision detection
  Implementing collision detection took almost a day to get somewhat right. Additionally, I never added the collision for ramps so walking on those tiles may have seemed a little odd. Jumping into a tile from the bottom sometimes warped the player to the left or right edges of a tile.
• Music
  There was actually music in the game. If you turn your volume up enough you might just be able to hear it. The music was originally much louder than it was now but it was repetitive so I turned it down so that no one would notice it.
• Art
  I only had one set of tiles done and no background tiles in the game. If you look closely at the player, he never alternates the foot that steps forward when walking.

• Game length
  The game was very short. Originally, it was only about collecting three relics and the player would win. Even after adding in the secret path, the game still felt like it should have had some more things in it.

How the relics came to be

• The double jump relic was planned for in the original metroidvania concept.
• The ability to look backwards was made due to not having backwards implementation done yet. I originally decided to just have the player moonwalk backwards due to time constraints before I changed my concept.
• The sight beyond sight relic was really just enabling the user to see the debugging hitboxes on the player. The white rectangle represents the player hitbox, the yellow boxes represents the tiles checked and their hitboxes, and the red represents colliding tiles.

Overall, I was pretty happy with how the game turned out. I was planning on moving from as3 to haXe on newer projects and this compo gave me a crash course on it.

Yesterday I set up a survey to collect some demographic information, for our own curiosity. We’re currently sitting at 72 of 100 allowed polled people, so I’d like to reach 100 before posting the results. If you haven’t yet taken our survey, go here:

http://www.surveymonkey.com/s.aspx?sm=0XGGBruHxeEbdl24Y5zi0Q_3d_3d

It’s a simple one page, 3 questions multiple choice. Pick all that apply.

Thanks!

This entry was posted on Tuesday, September 1st, 2009 at 4:45 pm and is filed under LD #15 - Caverns - 2009. 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.

I’ve just uploaded an OSX version, and have added the following updates on top of the previous version’s fix of the jumping bug:

• Fixed the performance on 16bit displays.  Thanks to Endurion for pointing this out.
• Reflectors can no longer be placed on top of each other.  Should make the game slightly easier.
• The game was accidentally set to default to antialiasing being on.  This seemed to cause slowdowns on the linux version, and may cause other issues for folk on other OSes.  It’s completely unnecessary anyway, since the graphics are entirely made up of (pre-antialiased) bitmaps.  If you’ve already run an older version though, you’ll have to either delete the CavernsOfLight.conf file (see the readme for the location – it’s different for each OS), or change the ‘a 6’ line to ‘a 0’.

Quite a few of the comments I’ve had have complained about the game’s difficulty.  My only defense here is that I’ve been playing a lot of Spelunky, Mighty Jill Off, and When Pigs Fly lately, all of which rely on pretty accurate jumping skills.  I think when I have a bit more time I’ll probably do an updated version with 3 different levels: easy; normal (the level currently included with the game), and sadistic, which will be massive and absolutely punishing .

Incidentally, if anyone likes the game enough to make their own level for it, I’d love to hear from you!

I wrote about Rock Warrior to my blog and added a separate page which also has a sort of mini-mini-post mortem – including a YouTube video of the game.

When I saw “Caverns” I quickly thought MinerVGA and decided to make a sidescrolling game about mining for gold and facing dangers like cave-ins and enemies. I decided that wasn’t going to work for some reason, and went to bed to come up with more ideas. (I always go to bed when I need ideas because late evening and early morning is when the mind is most creative.) The second concept was a sidescroller about shooting at cave formations like stalactites/stalagmites and suspended bridges to make them physics down onto enemies. After thinking about it for a while on Saturday morning, I started to hate that idea. It seemed gimmicky and hard to pull off well.

Several random walks. The final level generation algorithm isn’t much different.

I really wanted a dark cave sort of game where you’re sneaking around shooting evil demons, like a rougelike, so my third concept was a top-down procedural cave shooter with realistic line of sight, styled in cavey gray and brown. I liked this idea and began working on a level generator which was a simple random walk that varied the size and direction of a “brush” at each step. I then did the line of sight by projecting 3D walls towards the camera from the 2D ground, not planning on adding any 3D beyond that. The level generator worked surprisingly well, and I decided not to write code for making rooms like I planned, instead letting the path wind around enough that it made rooms by itself.

I thought the final game would essentially be this.

I felt demotivated all day for various reasons, so progress was slow. By Saturday night I had a square player who ran around in procedural caves. I half-heartedly went back to bed for more ideas. Then, with great disgust, I realized the game was turning out to be another generic shooter, and that there were probably at least five others like it in the competition. Plus, I knew I was bad at coming up with actual content, like interesting enemies and non-abstract graphics.

I needed to have something more to present. If I couldn’t think of a good gameplay mechanic, then the only other option was to dress up a mediocre one as much as I could with crazy colors and special effects (don’t underestimate this strategy). I looked at my 2.5D game and realized that simply pointing the camera forward would give me a first person shooter, something I considered but hand-waved as too difficult and unnecessary. I knew then what I needed to do.

Fog is trivially simple to implement in OpenGL, but is a beautiful effect.

I used a color value that roughly cycles through the rainbow as the basis for most of the visuals. I took care to avoid staying within the 0.0-1.0 clamp for color values. The camera needed to move a lot, so I made it shake, recoil, and bob. Making explosions that feel good was critical to the game, so I added flashes of light with every bullet and enemy death. The enemies started as the most obvious thing I could think of, bouncing diamonds, and didn’t change much after that. The walls and enemies had directional lighting. I turned enemy deaths into laser light shows.

Unfortunately, all of this took up a lot of time, and since I only started Sunday morning, the compo was already nearing its end. I thought about the last compo’s complaints that I didn’t have a proper menu screen in my game. I saw little need for one, but figured as long as I’m going for show I might as well try to make a “real” game. Thinking about whether I should learn how to use fonts in OpenGL, I decided to just hard-code a 3×4 font. Much simpler. I slapped it on the start/pause/win screens, added a HUD, etc etc, and the entry was complete.

Complementary colors create a balanced, high-contrast color scheme.

My biggest regret is probably that I didn’t have time to make the enemies explode into actual debris. That would’ve finished off the visual effects, and is definitely going in the update. Sound and music would’ve made this the best game ever, but I hadn’t done much with sound before so I knew it was going to take too long to do it to my satisfaction. Better to leave it up to the imagination than to pollute the game with shoddy art.

Lessons I’m going to keep in mind for next compo: Everyone complains about polish, but polish takes at least 50% of development time, so make sure to finish the core game in the first 24 hours. This is difficult because good ideas can be a lengthy iterative process, so spend the day before the compo being well-rested and chillin to get into the creative state of mind.

I’m extremely happy with this entry because it’s a good demonstration of what I think big commercial games should be capable of. It’s retro and arcadey and exciting. This is what I want to play.

Download

Well I fixed some of the more glaring bugs in my game, so here’s the latest, post-competition version:

Dwarf Caverns 1.1

Stuff changed:

• Fixed enter key crashing game *eyeroll*
• Fixed bad map data causing crash in Linux
• Fixed “unknown door” problem
• Esc key now works on game over
• Added intro text
• Changed the way dirt is piled
• Now runs in fullscreen mode

Note: If compiling from source you need to copy “world.dat” and the “gfx” directory into “ld15caverns”. I only included them once so as not to bloat the download size any more than it already is 😉