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.

Kingdom of Kroz

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!

So let’s take a look at what I’ll be using…

The two additions are the USB devices.  I actually used the mic last compo to make the sounds for the monster, arrows and stair-stepping in my tower game.  I will have to go stock up on Gobstoppers and No Fear Energy Drink.

I’ve just fired up Eclipse to create my workspace for this Friday.  It helps to have a clean app that opens up a window so I can get down to business once the theme is announced.  I wanted to add some functionality to the base code to make things easier.  For compo 12, I added the screen shot button so that I could easily take snaps of my progress.  This time, I want to integrate a simple logging class to make debugging easier.  If I get it done in time, I’ll link to a new base code zip file later in the week. 

Anyway, I’m looking forward to completing a decent entry.  One of my personal goals is to crack the top five in any of the game categories.  It was nice last time to get in the top five for Food, but it would be even better for a game category.

See you then!

‘tabletop’ wargame – Something along the lines of Axis & Allies.  Simple combat and strategy.  Perhaps even as simple as the old Global War bbs game would be doable in 48 hours.  Global War was troops only, while Axis & Allies has many unit types. 

Economic/Military strategy – Like Nobunaga’s Ambition.  Might have to simplify the combat a lot in order to get it done in 48 hours.  It also would be difficult to balance and tweak the economics.

play by email game – There was a game a few years back where your Kung Fu fighter fought against another person’s Kung Fu fighter.  You would challenge them by sending them an email and then it would play the match, and send the results back to you and the main server.  After awhile you would level up.  It got kinda weird when you had multiple challenges out and leveled up after one of them, but I’m sure there is a way to work around it.

sidescroller – I’ve always sorta wanted to make one of these, but never really got around to trying it.  When I was in 3rd grade, my friends and I used to make video games–on paper–and it would be neat to actually do it.  I think I have one or two of these sheets back at my folks’ house, so next time I’m there I’ll grab them.

Driving game – I think if you break it down to the basics, and stick to simple features, you could do a driving game.  Wouldn’t want to overdo the physics.  I’m thinking a lot more like Outrun than Gran Turismo.

Sports – It would be neat to come up with some kind of new sports game that could be simple enough for a 48 hour compo… and also fun.  Combine two sports or come up with a new one. 

Any types of games you’d like to prototype if you had a chance and a compatible theme?

I’ve been keeping myself busy working on a reborn and re-imagined project from back in ‘03.  I’ll probably release more info on that when I have something good to show off.  If we get a compatible theme, perhaps some of the work on LD48_12 can be reassigned afterward to my other project.  Honestly, working on that project the past week has kept my skills and mind frame in the perfect place for the LD48.

Last time around I had to take time out from the alotted 48 hours to attend a baseball game.  I won’t have that problem this year, though I am in the mood for a good egg and bacon breakfast at a local joint Saturday morning.  I hope to remember to take a picture of that for the food compo.

This time around isn’t going to be much different than last time.  I’m going to use mostly the same tools as before:

• Java 6 SDK
• Eclipse 3.3.2 IDE
• Photoshop CS2
• HP OfficeJet 6450 All-In-One for scanning doodles
• No Fear Energy Drink (Go Boris Said #60!)
• Everlasting Gobstoppers
• mIRC for chattery
• Killer Game Programming in Java and the base code I used from last compo.

The only thing we need now is a theme!

Good luck, and see you in 1 day, 9 hours and 48 minutes!

It’s a concept that I had been toying with this past week, jotting down some ideas and refining it along the way.  Quite simply, it’e the game Breakout, only with a twist.  In regular Breakout, you move the paddle back and forth on the bottom to keep the ball from falling off the screen.  At the same time, you are trying to use the ball to destroy all the bricks on the screen.  In my game the computer plays the part of the paddle and you instead try to defend a goal at the top of the screen by placing bricks. 

It’s a neat idea, but I by no means was able to implement all my ideas.  The number one thing that was lacking is multiple types of bricks.  This version only has two: normal and 2X Hit.  As you can probably guess, normal takes one hit to be destroyed and 2X Hit takes two.  I wanted to add more bricks that did weird and interesting things when the ball hit it, like explode or eat it. 

You build your wall of bricks by buying them from money you’ve earned while playing.  So far, the only two ways you can earn money is to play, where you get one credit every so many seconds, or when the computer misses the ball with the paddle and it goes off the bottom of the screen.  Eventually you’ll be able to get money by doing other things.

One thing that doesn’t seem to work very well is the collision.  The ball seems to react well when it hits the top or the bottom of the bricks, but if it hits the side of two bricks, it can sometimes bounce in a way that causes it to go ‘inside’ the wall.  I have a few ideas on fixing that but I didn’t have enough time to implement them.

The AI could be improved, letting it think ahead instead of having it just react to the current position of the ball.  If I project the location it will be at when it gets to the bottom, I could have the paddle waiting for it.

There are no skill levels implemented.  Smarter AI, less money and multiple bouncing balls would make it more challenging and could be set to differing degrees.

I also didn’t do any sounds for it, as the compo requires that all resources be generated within the 48 hours and my recording soundcard is not quite working.  I will create some for the post-compo version of the game.  Same for music.

I tested it on the Sun JVM 1.6.0, though it should work on on JVM 1.5.0.  It will not work on the JVM 1.4.2, as it requires System.nanoTime() that was introduced in JVM 1.5.0.

I programmed it in Eclipse 3.3.2, and used Photoshop for the graphics.

You can download the game here or the source code here.

[update: changed the above link to the .zip file.  The jar just wasn't handling some class-pathing stuff well and I don't have time to troubleshoot it right now.]

When all is said and done, and I’ve completed a game, I’ll post it here.  If for any reason I don’t get it done… well, I’ll still post something.

So if you have a (mostly) free weekend and you want to try your hand at designing and coding a game in 48 hours, come by the compo. Even if you don’t have the time, come by and check out the reports and progress of those who are.  You can also check my personal coding blog at LD.