WRONG! There is so much for you to get ready and practice. You could be doing any of these:

• Draw some sprites for a random animation, either directly in a bitmap editor or on paper and scan them.
• Polish that basecode to fix that thing you found last compo that really bugged you.
• Install GIMP or Audacity or other development related application and practice how to use it.
• Pull out your microphone and record yourself and other sounds around the house to create a song in Audacity.
• Create a Towlr.
• Think of witty motivational posters.
• Rip CDs to MP3s and create a great 48hr in-the-zone coding playlist.
• Stock up on food for the weekend.
• Clean and organize your desk.
• If you are feeling adventurous, take your first steps with that new language.
• Vote!
• Spend some quality time with the family so they know you still love them when you ignore them over the weekend.

Whatever you do, please share it with us on Ludum Dare! And also, no matter how much or what it is that you do, you’re a winner in this pre-compo competition!

Of course, none of these things will actually be used in the LD competition since that is against the rules (except the basecode) however they can’t keep you from using the skills you just learned!

Download it here.

Goals are pretty much repeating what I said last time:

• Keep the same art style as last time.  I sketched things out on paper and scanned them in so I could colorize.  Keeping with bold colors and gradients is probably what I’ll do.
• KISS – Keep It Simple, Stupid!  Making something too complex is just a recipe for a headache at 1pm on Sunday afternoon.
• Make useful additions to the basecode that can be used in later competitions.  The screenshot stuff is an example of something I did previously that helps out a lot.
• Finish most of the work by Saturday night so I can spend Sunday polishing.
• Don’t run into dumb problems that eat up eight hours.

Tools in use:

• Java 6 SDK (though last time I included a version for JDK 5)
• Eclipse IDE
• Photoshop, maybe some Illustrator
• DrPetter’s sfxr for sound effects
• Audition, if I can get it to play well with my sound card
• HP OfficeJet 6450 All-In-One for scanning doodles
• No Fear Energy Drink Sugar Free (Hopefully Boris Said and Carter Racing will run some Sprint Cup this year)
• Everlasting Gobstoppers
• mIRC for chattery
• Killer Game Programming in Java and the base code I mentioned above.

Can’t wait to see what the theme is.  Hope it’s a fun one!

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!

• Classes are now organized into the package net.lonestranger.common, game and network.
• Network isn’t really too useful yet.  The only class that exists in it is called Report.  It’s job is to take a string of data and send it via POST to a website, where it can be digested as fit.  For example, sending scores back to a central repository.
• You can take jpg screenshots by hitting F10.  They are named based on the current date/time and dumped into the working directory. 

Here is the link to download it.

I didn’t really list my goals in my declararion post a few days ago, so I’ll do it now.

• Keep the same art style as last time.  I sketched things out on paper and scanned them in so I could colorize.  Keeping with bold colors and gradients is probably what I’ll do.
• KISS – Keep It Simple, Stupid!  Making something too complex is just a recipe for a headache at 1pm on Sunday afternoon.
• Make useful additions to the basecode that can be used in later competitions.  The screenshot stuff is an example of something I did previously that helps out a lot.
• Finish most of the work by Saturday night so I can spend Sunday polishing.

Ok, time to finish work and then I’m off to Thanksgiving, The Sequel, but I’ll check in after 8pm Pacific tonight to see the theme I need to start thinking about.  I expect everyone to be in FULL CODE MODE when I get back. 

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.

In this first jam, they created a game called Gravediggers.  The post includes a video with five people playing through a round.  The graphics themselves remind me a little of the original Joust game, with the brown floating platforms and blockish characters.   The players are represented by small rectangular blocks, and the playing field offers a lot of space to run around and shoot.  The object is to kill the rampant zombies with a gun and collect the heads to return them to the crypt for points.  Heads of the other players can be returned for extra points.  The side-view perspective shows generated terrain and two crypts randomly around the field.  The players hop from platform to platform, and over little hills.  They can also shoot through the terrain if they can’t get around it to score those zombie heads.

This reminds me of Ludum Dare’s 48 Hour Game Programming Competition held twice a year (voting starts for the LD11 theme April 11th).  There are a lot of neat little games that come out this competition, many of them that look as good or better than the NES games we used to spend hours playing as kids.  They’re just as fun too.  Entrants are allowed to use a wide range of development tools and can create on any platform they wish.  The only caution is that if other people can’t play your game, they can’t vote on it, so most entries are done on Windows.  If you are an amateur game programmer, give the LD11 a shot.  If I can get a decent desk for my computer by April 11th, I may try to enter.  Trying to type with the keyboard on an endtable is not fun.  I submitted a sad entry for LD2, many years ago.  Sad enough that I won’t bother to show you.

Shake these two things together in a glass, add a little lemon–here’s my third topic.

Sony hasn’t moved forward with any kind of amateur software development kit for creating PS3 games.  Sure, it is possible to create games for the PS3 running on Linux, however, there is no formal tool package to make the process easier.  Requiring an install of linux in order to play these also doesn’t do anything good for widespread distribution to the community. 

I don’t have a 360, so I haven’t tinkered with their system but based on what I have read, Microsoft seems to be doing a good job with their XNA community development project.  Everything from providing the tools, developing on a PC, MSDN reference, and the end-user distribution is fairly well thought out.  Of course, Microsoft has been giving out development tools for years now, whereas Sony has only been distributing professional tools directly to the game developers.  They have been touting how much easier the Playstation EDGE dev kit is for developers so perhaps a stripped down version of it would be the answer for the amateur side.  

These little amateur games fill a niche in the games industry but they haven’t really penetrated console systems.  How many hours are spent each day playing silly little Flash-based games.  It doesn’t take a three year cycle to create an interesting game people will spend hours playing.  All you need is a simple concept implemented in a way that is fun.  Bejeweled and Tower Defense are good examples.  PixelJunk even took the Tower Defense idea and twisted it enough in an attempt to get Japanese players to like it.

While we’re at it, I think I’ll mention that Microsoft is expanding their XNA in version 3.0 to allow development on their portable Zune system.  I don’t know about the technicalites of the PSP hardware and how software is run on it compared to the PS3, but I think that Sony should not forget the PSP when working on their dev kit.

There are more high-profile things that people might like Sony to work on, including Home and better in-game communication with our friends.  I agree, these things are important.  In fact, Home has arcade machines in some of the spaces, and I think that is an opportunity for people to create mini-games.

There are many aspiring game developers who could use this kit as a valuable experience for a future job.  There are also people who don’t want to submit themselves to the grind that is the professional development cycle and they can use it as a way to express themselves in a less-demanding manner.  There is no reason why Sony shouldn’t spend the resources to get a dev program going.  It really is the ultimate in user-generated content.