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.

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!

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.

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.

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!

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!

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.

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 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…
(more…)

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 ), 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.

Check out my official entry for a link to the Win32 version of Mineral Miner. Now more of you can play it and rate it! I didn’t have time to make in game instructions nor did I have time to make things obvious, so please read the instructions on the entry page before playing.

LD15 timelapse from Hamilton Lima on Vimeo.

as the title said … Cavern Crawler (now) Packaged for Windows

you can find it here!

I’m pleased I managed to finish this. Here’s my post mortem.

I spent most of my first day wrestling with a bug in libnds associated with the way it calculates sprite addresses in VRAM. I managed to fix it, but by then I’d lost all motivation for working with the console.

That’s when I started to get a bit … creative with the theme, and really got my teeth into it (no more, I swear). I really wanted to make something that wasn’t cave-based, so I contemplated other things that might be considered cavernous, and thought of mouths.

Gameplay

Overall, the gameplay was close to my original vision. The core gameplay of shooting and healing is all there, I just would have liked to put some more extras into it, like the ability to level-up lasers. I also wanted to make it a lot more silly … but I might do that sometime post-compo.

I quite like the input scheme of mouse-look and X to walk, and C for jumping instead of the more ‘traditional’ WASD. I wanted to make the dentist walk more like a person and not a usual platform-game character – he can’t walk backwards or change direction mid-jump. Some people will hate this, but I thought it suited my theme more at the time.

Coding

I used BlitzMax for the game, which I don’t use very often. However, it was a perfect choice, given the limited time available. It has an incredible range of features built-in, and I doubt that I’d have been able to make the deadline if I’d have to write all the graphics and sound code from scratch again. (Also, SuperStrict is cool.)

Graphics

Using Illustrator for the graphics was an enormous help; I used it to mockup the design and then was able to make sprites from the different visual components. I’d definitely recommend using some sort of vector editor for quickly prototyping visual styles. The only drawback with using Illustrator was the need to manually find the origin of sprites, which was time consuming.

Sound & (lack of) Music

sfxr is really useful for deadlines. I originally wanted to put in some cheesy sounds of pain, but time prevented it. Music was a complete non-starter.

Overall

Although I probably won’t win anything, I really enjoyed my first Ludum Dare. And that’s what it’s all about!

Ludumdare 15 is over! This was my third time entering, and my first time having a successful entry. It wasn’t without its problems though, so I figured I should do a write up of how it went.

The idea behind the 3D environment was to make 3D ’tiles’ that can be put together in a grid arrangement. These were made in 3D Studio Max and exported to be used in Unity. The shapes had their texture co-ordinates setup so that they share one material for all of the objects. PCs can render a LOT of geometry so long that it shares the same material. This concept worked out pretty well, as the final game runs nicely on even the shittiest laptop!

I also decided to go with low-resolution textures, with 32×32 per metre square. This didn’t quite work out unfortunately because 3D Studio MAX’s UV texture co-ordinates are pretty inaccurate at low numbers, and even unfiltered textures suffer. This method was a thoery that didn’t work out, but that’s okay.

The graphics in general are very rough. These are all my ‘first pass’ attempt at graphics, and I didn’t have enough time to clean them up. The tiles for the walls were never really finished properly, and some of the areas didn’t get a proper treatment for the floor. In general I think the graphics look okay though, and I was pleased how consistent the visuals are.

Building the 3D environments also took me a while longer than I had hoped. Things because faster when I started from scratch, but I didn’t expect the environments to take so long. Unity’s editor isn’t too helpful with this either because there are no easy ways to select multiple objects, so I had problems with things like enclosed areas being invisible or hard to click on.

I lost a bit of time by wasting time on code that wasn’t important. I spent a while trying to get good keyboard only controls working, which I later scrapped because they clashed with the mouse controls, and I didn’t have time to make a toggle (despite the mouse controls being a bit annoying for some). I would have been better off spending that time on a title screen and ending screen, which I regret not implementing.

I used ‘SFXR’ (CFXR on the mac) for sound effects, and I was massively pleased with the results. I started work on some music but I couldn’t get anything to suit the theme. Sorry the sound effects are a bit loud! I was pleased to get some sounds in there though, it makes the whole game feel much more responsive!

In terms of game design, I didn’t really have a solid game design figured out. Towards the end I decided to use what I had working well (doors and object-keys) and make the game progress based entirely on those. I think this worked out okay, with the game being a bit of a challenge but not so long to become boring.

All in all, I think it went okay! I am looking forward to the next ludumdare!

Here is a timelapse of my entry. It shows some of the game at the end.

Here’s my post mortem…

Darkening

I wasted a lot of time trying to do something which I thought would have been easy with pyGame. I was trying to draw the wall sprites darker the further away they were, to give the illusion of depth. I’d assumed it would be one function call to do this, especially as Allegro has a function to do it draw_lit_sprite (though on reflection, that’s using a colour table in 256 colour mode) but I had no such luck. Blitting a transparent black rectangle to the sprites didn’t help either, because I needed to preserve the transparent pixels of the sprite. In the end I gave up trying to darken the wall graphics but I did waste a lot of effort here.

Artwork

I chose to paint all my graphics in GIMP, which was a marked deviation from my usual comfort zone of pixel art. As such, the artwork probably took longer than it should have and looked a bit crappy to boot. That said, I do think that my tablet skills were improving over the course of the weekend. It’s certainly made me want to practice drawing more.

Text / Graphics Hybrid

My game was a strange combination of text and graphics. I wanted to do the whole eye-of-the-beholder-type first-person view thing, because I think they’re cool. But I also wanted to make the game a text adventure because I thought I would be able to inject more gameplay elements into the thing without having to generate graphical resources to accompany them. But by the end I realised that it didn’t quite work out like this. For example, I wanted to have the player looking around and finding items on the floor, text-adventure style. But I couldn’t get away with this without drawing said items to display in the graphical viewport, because otherwise there would be nothing to indicate their presence and the player would have to use the “look” command on every square or something. Maybe with a bit of tweaking I could have established a system where I could add features without having to back them up with graphics.

Text Input / Output

I was somewhat delayed due to having to roll my own text input and output in pyGame. I had to write my own word-wrapping and stuff using the character width information from the font metrics. As for input, I had to manually map key events onto the letters they should represent (hence the lack of uppercase). The more I think about it, the more I think that maybe I should have just gone with a plain old console-based text adventure and scrapped the graphical part.

Perspective

I made a bit of a goof when I was planning out the first-person view. Somehow I ended up with something whereby the graphic for the square that the player was supposed to be on ended infront of them. That is, you could see the front of the block instead of being inside it. I realised too late that possibly the row of squares at the same depth as the player were probably a special case which needed to be drawn differently and I couldn’t get away with just scaling the same graphics. As a workaround I chopped the sides off the viewport so that the graphical mistake was no longer visible.

Combat

With around 4 or 5 hours until the deadline, I decided to throw in some monsters. I drew a bat and a skeleton and threw together the worst combat system known to mankind. This was a stupid decision in retrospect – the game didn’t need it, and its presence worsens the overall game experience. I was going to have a “sleep” mechanic whereby the player could sleep to regenerate their health, and a maybe a time limit to reach the goal so that there is a downside to sleeping. Not to mention some kind of experience and levelling system. I didn’t have time for any of this, so there is actually no point in fighting the monsters – the player doesn’t gain anything from it. So what we have is some monsters that keep turning up to annoy you that you have to keep running away from. It was pretty hilarious to see a skeleton appear while talking to a dwarf, though.

Puzzles

I started hacking together the puzzles and map with around 3 hours to go. At this point I was tired and my enthusiasm was dwindling, and as a result my imagination was just plain broken. I could have done more interesting things with the puzzle system I’d put in place and I wish I’d made more time to do so.

Overall: Playable

I finished a game! Well, at least in the sense that I got something to the point where there is an attainable goal, and it provides some kind of challenge along the way. After my last 2 ludum dare entries not going anywhere and being totally unfinished, achieving something playable this time was a nice thing to accomplish, at a personal level. I think it’s restored faith in my own game-making ability. I didn’t have time for sounds or any kind of proper intro or ending. But then again, I never do! I must leave time for polish next time…

Looks like a few people are having troubles running my entry ‘Life is Guano’

I am working on the OS X port of it right now. I will look into the problem with the windows build failing to start.

I am 99% sure this is just a library problem (I am linking against a specific version of DevIL and SDL_mixer both which I have not used in the past)

I’ll post another entry when this is fixed.

Here’s my timelapse. Enjoy!

“Dwarf Caverns” Timelapse

So I intend to flesh out Killbots over the next week and then see if I can get a sponsorship for it. Current ideas include:

Your two squads are composed of different types of dudes: one fast squad, one powerful squad (assault and fire team).

Choose from one of 3 different heroes to accompany each squad (3 fast heroes, 3 powerful heroes)

Heroes get exp and levels, allowing you to get skills with special abilities

Spend money to upgrade your squads (more in-depth than currently)

Several levels, still partially randomly generated, including attack missions, defense missions, etc.

Cover is destroyable, and buildable (with engineers).

That’s about it — any other suggestions? I want to make the best game I can over the next week .

This was my first LD, and it was a lot of fun. I’ve learnt quite a lot from it I think, and I don’t think I’ve ever got so much work done on a game in such a short time-span.

I used C++ with several SDL libraries. Graphics were created in the GIMP (and Paint…), and the sounds were created in about 10 minutes using SFXR.

I did briefly consider using GameMaker instead, and at several times I thought to myself ‘All I’ve done so far I could have done in GameMaker in a couple of hours!’ but I’m glad I didn’t. It would have felt like a cop-out really. Not to say that anyone using GM was a cop-out, but I’m glad I took the challenge of using C++.

What Went Well

• I got an idea fairly quickly, and actually managed it in the time frame (I would have liked to add more stuff, but at least it is a game).
• I had a horrible, game-breaking memory-leak but managed to fix it in very little time.
• I knew my way around the GIMP enough to animate Ted using layers – I’m always very frightened of having to animate things.
• Mostly, it all works. The collision-detection between moving things and the ground is pretty random and bizarre, so you can climb walls much higher than planned. The dinosaur movement was put in in about 10 minutes at the end when I realised the game was impossibly easy. The game is hacky, but it’s pretty close to what I wanted.
• Click-to-shoot! Wow, I was pleased when that all came together. The bullet heads toward where you clicked, and always at the same speed – at first I got in a complete muddle as to how to do this, but then it was really simple. I like it. The whole ‘click, shoot, bullet hits wall, rock breaks off and falls’ thing works really well I think, and I’m pleased with it.

What Went Badly

• That collision-detection is awful. Checking collisions between the ground, which is a grid where 1 across = 1 tile; and the coordinates of everything else which are 1 across = 1 pixel, was tricky and horrible. I did it badly. When I eventually gave-in and added proper box collisions for the interactions between player, rocks and dinosaurs, it was instantly much better.
• The levels aren’t interesting. I hadn’t originally intended it to be an infinite, random tunnel, but I hadn’t originally had much idea of how it would be a game. I just knew “Shoot rocks so they fall on dinosaurs”. One, random level seemed much easier. The first area is fixed, then the rest is generated as needed, one column at a time. I tried several ways of having each column based off the previous one, but slightly altered, but they all went wrong. So I got it to generate a random number, and pick a pre-defined column from a list based on it. Less interesting, but at least I could guarantee that you could actually get through the cave.

What I Would Do Differently

• Prepare in advance and get a basic… I can’t think of the word. A basic code-base which has drawing and tiling stuff already there. I spent far more time getting that set-up and working, and repeating code that I could have used a base class for.
• Framework! That’s the word.
• Get more sleep the night before it starts. And, in fact, several nights before that! I kept making silly mistakes, like copying code and forgetting to change x to y in the copy, because I wasn’t firing on all cylinders.

Things I Didn’t Have Time For

• Graphically, the cave looks pretty horrible. I’d hoped to get time to have a tiling system based on what was around each tile: so a piece of rock hanging from the ceiling would look like a piece of rock hanging from the ceiling, and not just a square block.
• I’d also hoped to animate the dinosaurs. Just didn’t have time.
• It would have been good to actually show Ted holding a gun, with bullets coming from it. With the image flipping though, it would have taken time I didn’t have. I wanted several animations for Ted, but like the dinosaurs, it didn’t happen.
• Improved collision-detection! It’s abysmal.
• Particle effects! Another thing I’d hoped to have time for.  Would have made it look less boring, possibly.
• A proper menu. The menu in the final thing is the one I bunged in as a placeholder because I realised it would be handy to have later.
• The text-drawing function I used has an awkward quirk in that it always draws an opaque background. I got it from the internet a while back, and though I tried fiddling with it, I couldn’t make it transparent. Makes the menu look even worse.

I may well make a post-compo version with lots of these things added-in, but then again I’m incredibly lazy at this sort of thing. So maybe not. Still, I’m pleased I managed to do it, even though I’m not going to win any prizes.

~AtkinsSJ