Diragor's 48 Hour Game Programming Contest log

Jul 12, 22:07 Just found out about the log thing when I noticed other people were doing it so I guess I'll recap the last 4 hours.

I spent maybe half an hour brainstorming before I decided on the basic premise of my entry. I then spent maybe another hour sketching (I'll post a scan) and doing test graphics to see what I wanted it to look like and what size I wanted things. Until about ten minutes ago I worked on the main graphic components of the game - bricks and a poorly animated character. I took a few minutes to decide on a file format and then export animation frames in that format. NOw I'm ready to dive into the code and make this stuff move around! First I need some food....

Jul 12, 22:40 Oops. I'm starting into some of the drawing code. The game's going to run at 800x600 and the tile size for tiled graphics is 32. Of course, 600 divided by 32 is not an even number but I didn't think of that when I was deciding these things. Well, I've already got the tiles drawn so I'm not changing it now. I was debating whether to do a grass tile or just a green fill for the background anyway so I guess I'll do the green fill.

Jul 13, 00:18 That's a decent start - I'm going to bed. Since the last update I've written a map class that loads the whole set of map images and loads maps from simple text files. Tomorrow morning I'll be getting right into map drawing code and then sticking some calls in the main loop to use all of this map loading and drawing code.

I suppose I could go ahead and describe the game concept. It's kind of inspired by Zoo Keeper only in reverse. Your job is to guard the "goal" (Haven't really decided what that is yet) inside your castle walls. Warriors will be attacking from all sides and tearing down the walls. You have to run around and repair the walls to keep them from getting inside. I have some ideas for other forms of defense and retaliation (catapults, friendly guys inside the wall, more) but we'll see what I actually have time to implement.

Jul 13, 12:24 I got a bit of a late start around 10:15 this morning. I guess I can make up for that tonight. I decided to go with a treasure chest full of gold for the "goal" I mentioned in the last update so I spent way too long this morning making that graphic. I modified the tile drawing code so it can handle the transparency of the treasure chest. This would be going a lot quicker if I didn't have to keep looking up how to do everything in SDL. I'm already getting what I wanted out of the contest - a jump start into SDL.

Jul 13, 15:46 Good Lord, this would be so much easier if it wasn't the first time I've used SDL. Over the past hour or so I think I've discovered every wrong thing to do when loading and blitting images (wrong unless your goal is to produce as many access violations as possible). Fortunately I won't be doing any crazy visual effects or anything so I think the rest of the drawing code should go just fine. Man, I've been programming for years but this is making me feel like a newbie - it's been a while since I did any game programming. I'd post another shot but all I've got is the actual in-game rendering of the title screen mockup I've already uploaded. Now I'm going to hit the website to look at other peoples' progress and cry.

Jul 13, 16:50 Ok, had a snack, finished the title screen and got font rendering working with SDLMonoFonts. Won't be making too many fonts though, it's a pain in the ass. Surely there's a utility to generate those things in the correct format but I haven't found it yet.

Jul 13, 17:32 The map drawing code works. I just posted two screenshots - the first is a horribly botched drawing of map1 and the second is after a little code correction. Actually it's still a little bit off - the wall is stacked one brick higher than I meant it to be. Gotta find the off-by-one error causing that.

Jul 13, 20:55 After a little break for some dinner and TV I've spent quite a bit of time reinventing the wheel. I'm going to have a variable number, eventually large numbers, of enemies that use the same sprite set. There's a sprite engine included with JEDI-SDL but it would've loaded the sprite graphics seperately for each enemy, which is obviously a huge waste of memory. I didn't like the way it handled the list of sprites anyway so I've coded my own sprite and sprite engine classes. I have yet to get a moving guy on the screen but at least the enemies and the player will share a bunch of code. They're also going to look very much the same except for the color of their clothes and maybe a shield or something because I won't have time to do a whole new set of sprites. I still have to draw the character sprite facing in other directions or all the guys will look pretty goofy walking around always facing the screen.

No new screen shot but I did take a couple minutes to code a real screenshot grabber.

Jul 13, 21:52 IT LIVES! This is cool - now that most of the foundation is in place the advances are coming much more quickly and they're much more exciting milestones. I now have a moving, player controlled sprite going and animation should be up within a few minutes. Maybe I'll have time for sound and music after all! Well, I still have a bunch of game logic to do. Moving around graphics ain't the whole ball game.

Jul 14, 10:24 Oh my God, the time I just wasted. Last night I went to bed about 1:30 and got up around 7. Besides a little timeout for breakfast I've spent all morning on collision detection. The original plan was that movement would be calculated, the new bounding box would be tested against each brick. If there was an intersection it would push the sprite out until it wasn't intersecting. I wanted to be able to slide along a wall but that code was just screwing up big time. It was crazy - the guy would go flying all over the screen when he touched a wall. I got in more under control but it still sucked. I ended up with a simpler scheme that works just fine - when any collision is detected it simply ignores the movement (apply movement, if collision then undo movement). Man, what a waste of time that complicated response code was.

Jul 14, 11:54 I'm still a bit worried about having a playable game 6 hours from now but I feel better than I did 90 minutes ago. Enemies are now in the game. Because of the custom sprite routines that can share an image between them I can easily stick 1000 enemies in there, though it takes a couple seconds for the round to load. The test shot I'm uploading has 100 enemies on their way in (many are still off screen) but there will probably be far less in the final game (in the early stages, anyway). Next is the code for pounding, breaking (enemies) and repairing (player) bricks.

Jul 14, 18:14 So that's it. Game over. It was down to the wire but I managed to get a marginally playable game uploaded about a minute before the end of the contest. (There was some leeway at the end for uploading but it seems more dramatic if I pretend there was a hard cutoff.) Here are some notes about my final product.

BUGS

There was something slightly off in my "pick nearest brick" code, which caused a few problems. If you stand dead center right up against a brick (based on the position of your feet) it won't find a brick to bang on. Move slightly off-center and you'll be able to hit one. This code also didn't plan for corners, so there are some bricks near corners that will never be chosen as the closest.

I overlooked something about the brick collision code. If you build a wall outwards and there's a bad guy standing on the other side (which would be most of the time, or you'd have no reason to build there) the baddie will get trapped in the brick. I had to greatly simplify the collision code at one point because it wasn't working so there's no longer any code to "push" a sprite out of a collision. Hopefully he'll keep banging away on the wall that's trapped him, but see the previous bug: sometimes they'll be trapped and just stop banging, which starts to make the game pretty easy if a bunch of them happen to get trapped. I would've liked to at least put in some code that checked how long a guy has been motionless even though they're in "walk" mode and do something to fix it. No time.

STUFF I DIDN'T HAVE TIME TO DO

• Sound and music are the biggest things on this list - didn't have time for any of either.
• Some way to win - if nothing more than a timer for each round..."congratulations, you held off the enemy!"
• More maps.
• Sprites for characters facing the direction they're moving.
• Combat - so you can bang on guys with your hammer when they get through the wall.
• Projectile weapons, like grenades or catapults, that you could lob over the wall.