Uprising's Time log

qux's 48-hour game timelog

Files: http://ludumdare.com/user/index.php?viewuser=571

Friday

7:21pm Just writing something here to get the log started. And I need to make sure this thing is wrapping at 80 columns. Yep, it is now. I love UltraEdit :)

8:14pm My framework is approved! Here's the features link:

features.txt

No ideas on the topic yet, but it's great to hear Chu Chu rocket is acceptable.

8:45pm Nothing.

Maybe I should write some ideas here. No one on IRC has any substantial ideas besides the egg launcher where you have to design the protective shell.

9:04pm I'll keep a list of ideas I see here:

Scorched Earth: Would barely qualify.

Gradius: Repair Crew. The ship is AI-controlled and the player does repairs and ship refits. I didn't get much response on that.

Domino simulator.

Car rolling down a hill. You design it and maybe place ramps on the course.

Trap placement. You could set them in a house to defend against intruders. Level of violence might be high :P

Battleship?

Rampart

Self-playing RPG (impossible's idea)

Robo-ramblers. Looks like a simplified Chu Chu Rocket. (LoneWolf's idea)

10:59pm Finally, I have an idea that I think might work. It's a combination of Rampart, jovoc's description about defending a mountain pass from an undead army, the traps (Home Alone) idea, and some other stuff I can't remember. The player has to set up a castle to defend against a horde(?) of enemies. Maybe not a horde right away though. The idea is nice, but it all comes down to details. What can you make the castle out of? How smart are the enemies?

The simplest case is a mass of enemies and just walls of the same thickness to defend with, and one target the enemies are after. No scoring (just win or lose). If you surround the goal with a rectangle of even thickness, if the enemies are stupid, they'll just grind it down evenly and the player chose an optimal solution. But if the enemies are smart, they'll all attack one spot, but the player's solution is still optimal because he doesn't know which spot the enemies will chose.

Let's list things I might use to build a castle:

walls of varying thickness/hardness

walls with special characteristics?

explode on contact

covered in tar to slow down enemies

fall over on enemies (effectively exploding in one direction)

on fire, which spreads among enemies, but wall might burn down

moats

offensive weapons

catapult

archers

boiling tar

offensive people?

maybe one or two heros? maybe even player controlled? yes! this would keep the player involved

defensive people

melee fighters

wizards?

What kinds of enemies could there be?

melee

archer

catapult

bomber - would need to be smart enough not to kill its own people

Okay so with all these long-range weapons, I'd have to decide if "getting" the target meant blowing it up or actually getting an enemy to it. Or I could have both. Like one "king" who can't be harmed, and two treasure rooms that could be looted. These enemies would have to be really smart though, smart enough at least to find their way out after finding treasure. So they'd need some sort of path-finding algorithm to the outside.

11:20pm Or I could update this whole thing to science fiction, and that would probably make things easier. Or maybe not.

Sci-fi advantages:

Teleporters can get rid of the path-finding requirement when enemies find loot.

Land mines.

Probably easier to draw!

Since it would be a base and not a castle, the top wouldn't be open. If the base is underground, there's no top. If it's above ground, the top is exposed to enemy fire. In that case, the enemy could actually climb on top and drop in through holes in the ceiling. This sounds very complicated.

Sci-fi disadvantages:

Things are made of metal, so they can't burn. Even setting people on fire in a sci-fi game is not very cool.

No wizards, no magic. Actually magic could teleport enemies out maybe.

Let me rewrite the above lists for sci-fi. Base elements:

walls of varying composition

walls with special characteristics?

explode on contact/proximity

magnetized?

radiation?

fall over on enemies (effectively exploding in one direction)

proximity mines

offensive weapons

rocket launchers

gunners

offensive people?

player hero

defensive people

guards would be armed with phasers

Sci-fi enemy types:

human

robot

tank

Saturday

6:56am I just woke up and added a few logs to my log browser. So where was I with my game idea. Let's see.. I should probably decide on a minimal set of.. what? Enemy types (one?), defensive structures (just walls?), and enemy AI (dumb). Yeah I should probably concentrate on that now, and making it easy to change, so I can just playtest instead of thinking about what will work and what won't.

7:10am I'm sitting in Photoshop thinking about how to do the mock-up. It will definitely be a tile-based map, but I don't think I'll show the tiles. Or maybe I should in the beginning? Nah.

7:40am Do I really want tiles? Now I'm imagining these enemies coming in just moving from one tile to another. But wait, Starcraft is tile - based and they move pretty naturally. So the building can be tile-based but the enemies can have a position at any x-y coordinate. I think SC does that because building on tiles is easier, especially to line things up.

7:47am Text sucks, I'm converting my log to HTML, especially since most others are doing it too.

8:17am Sitting here thinking about how to draw a king, I think, why not have the player hero the target? Or even better, the player can choose any of the live defenses he's placed including guards. Hmm, so the enemies want to kill you, and you want to.. what? Escape? Kill all the enemies? If it's escape, where do I want to escape to? I could have the map divided into two zones, with an enemy zone enclosing the player zone. The player would have to make it through the enemy zone to win.

Obviously this will require careful balance so the player can't just run for it and make it. Of course I have to be careful to make the game about the setup and not about the escape.

Maybe I need to rethink having the enemies come from all directions. What are the alternatives? They could come in groups, from one direction, two, or four.

I just thought about having the hero protect the "king", but that is definitely straying from the theme. Well, maybe if the hero is very weak it would be okay.

8:35am I'm trying to imagine these different setups and what base designs would be effective in them. With simple walls, player escape, and enemies from all directions, you might design a base like this:

#

#

#####

#

#

#

And hope you could take out any enemies that happen to come down the narrow corridor. That's not very exciting, but then again that's what the extra defenses and other enemy types will serve to do. If the enemy had archers, they would run towards the corridor and shoot over it and possibly hit you. So you would need a second layer of walls for the archers.

Or if you had archers, that might be enough to keep away their archers. I think this game will definitely need characters that can shoot over walls, which means it can't be sci-fi. So, back to that grass texture heh. But how will I show the grid then? I'll have to overlay a grid of gray lines or something during the build phase. Maybe that's better actually, since the tiles won't matter in the escape phase.

Escape! Hmm. Escape from Castle ... something. Oh well, titles aren't important.

8:46am Okay so would melee and archer characters for both enemy and defense, along with simple walls be enough? I don't want to start coding until I know that at least my design would be submittable and minimally playable. I think that it would be interesting. And once I have all that, adding things wouldn't be too hard. Oh, about AI.. they will at least have to follow the hero. That and attack when in range. I can add more later.

9:57am Blah my corporeal form is forcing me to do things like laundry, eat breakfast, shower, and get dressed. I might as well go to the grocery store right now and get pizza, veggie burritos, apple juice, and milk, so I'll be set through tomorrow night. When I get back I'll finish my mockup in Photoshop, and then start coding by noon, which I decided should be a goal a few hours ago.

1:26pm Food is out of the way, and I finally have a knight sprite! It's the first sprite I've ever made that even looks humanoid, so I'm pretty happy about it. I'm more confident about the coding part than the art, so I'm making sure I can do this before I start coding. Now I need some enemies. I think I'll stick with one frame for each character until I get the game working, probably around

2am tonight. Then I can add extra frames for different directions, and a walk/attack animation.

1:49pm What the heck, I'm sitting on IRC daydreaming about how to draw my enemy, and I don't even know what it is. Will they be ogres? Humans? Animals? Well, ogres are tired, but humans even moreso. Maybe the humans could be dressed as civilians though.. so it would be like a peasant uprising to overthrow the evil king (the player). That would make the peasants weak but there would be a lot of them.. which is what I'm going for.

2:59pm There we go, enemies! Is that enough to start coding? I think it is. In the scene above, the peasants would move straight in and start hacking at whatever they encounter, while the hero makes a quick getaway. He'll have to fight the one peasant that will come down the entrance though. So, first iteration will go like this:

Download Allegro, read the docs :P

Draw the grass tiles

Draw the grid

Draw the hero (CPlayer)

Make the hero move (no collision detection yet)

Draw a wall (CWall)

Create a map representation (CMap)

Fill CMap with a pre-defined map for now (the one in the mockup)

Render the map, which is just a few walls right now

Move the update()/render() calls for CPlayer in to CMap

Add collision detection to CPlayer.. it will have to somehow query CMap to see what's in its way

Draw an enemy (CEnemy)

Add a bunch of enemies to CMap, which should now be rendered

On CMap::update(), update each map element. Enemies should probably be updated before walls, so walls can show immediate damage.

Now write CEnemy::updateFrame(), which will just go towards the hero and attack anything in its path (including the hero).

3:21pm One more thing I'll have to figure out before I code the hero or the enemies is exactly how collision detection will work, and the exact layout of sprites. I want my game to be pixel-perfect, even if the pixels aren't the prettiest :P

I think the sprite's position will need to be near its feet. Maybe it will need more of a positional area, like the middle of its feet plus a diameter of 8 pixels or so. That sounds reasonable.

Also I need to remember to render everything from the bottom up. This means the hero needs to be rendered along with the map, since a map element might overlap from below and be overlapped from above. So CMap will be responsible for rendering CPlayer. That probably means CMap should update CPlayer too. So I just added an item to the list above to add CPlayer to CMap's render list.

Actually CMap should keep the hero, enemies, and non-intelligent items in separate lists, so they can be updated in order. Should the hero be updated before the enemies? It only matters if they are interacting with each other. And if I set it one way, that means one person always gets the first hit. So I should add an 'updated' flag to each enemy; if the player interacts with one, they will decide between themselves who gets hit first, who dies, etc. Then the flag will be set on that enemy, and it won't get updated a second time when the rest of the enemies do.

I should write some code before this falls out of my head.

void CApp::mainLoop()
{
pBkgrnd->render();
pMap->render();
}
// CMap will be a singleton?
void CMap::render()
{
// clear updated flag
for (int i=0; i<vpEnemies.size(); i++) vpEnemies[i]->bUpdated = false;
// react to player input
pPlayer->update();
// enemies will try to move, then try to attack
for (int i=0; i<vpEnemies.size(); i++) vpEnemies[i]->update();
// objects will react to player or enemy interaction
for (int i=0; i<vpObjects.size(); i++) vpObjects[i]->update();
}
void CPlayer::update()
{
for (int i=0; i<CMap::p->vEnemies.size(); i++)
{
if (CMap::p->doesCollide(pos, CMap::p->vpEnemies[i]->pos))
{
// interact with enemy
}
}
}
void CEnemy::update()
{
if (bUpdated) return;
// ...
bUpdated = true;
}

5:54pm I took a break to make an intro screen:

Loading the screen is also a good first thing to get my hello world Allegro proggie to do. Which, by the way, already says both Hello, and World!

Sunday

7:01am (DST)

Oh man, don't get me started on last night. I have reaffirmed my hatred for Allegro. I got the intro screen running quickly, but then I tried packing everything in to the exe to make it easy for people to run my game. I can't even go over all the things I tried, but mostly it was concentrated on dat2s, dat2c, and exedat, all three of which must not be meant for use with VC++.

I swear I won't touch that today. Zipfile distribution for me. Now I have a lot of ground to make up. I just couldn't believe every single method would fail. Allegro's ineptitude is total and overwhelming.

7:23am Of course, the one thing I actually need won't work either. I'm not packing a 450KB title screen in to my game, and jpgalleg just plain won't work.

9:03am Help screen is added, and I'm in CGame now. I set my desktop wallpaper as the title screen, it's somewhat inspiring :)

10:56am I'm showered, dressed, and fed. I'm also making steady progress on my To Do list I made yesterday. I'm glad I have design out of the way.

Interesting that CMap is a reserved keyword in VC++. It's taking me 10 minutes just to come up with another name. CMMap? CUpMap? CCMap? Just Map? SMap? Argh. CCMap it is.

11:02am Here's a shot of where I am in the actual game. The wall is actually the mouse cursor. I'm going to have the user actually "draw" walls. I haven't decided how to erase yet. Click the image for full size:

And here's a shot of the help screen:

2:28pm Whew, I had some nasty bugs that I "fixed". First I wrote a test program just to check that I hadn't lost my mind. Then I realized the bug (the really bad one) was just that any function I called was failing in this one class. So I thought it was probably writing to memory out of bounds or something. I "fixed" it by changing the class to a Singleton, which I was going to do anyway. Oh well, right now there's no time for hunting down root causes.

Anyway, I can draw walls now! And of course I need to draw things from the top down, duh. I think the wall drawing is pretty intuitive, and I decided since people will be constantly erasing walls, I made that the right mouse button. I'm not sure how to select what to place now though. Maybe I'll put a big icon in the lower right with a note to hit space to change it or something.

7:05pm No time for updates, just furious coding! Well ok, I'm working on action mode, and my knight can move! I will weep for my spaghetti code later.

7:19pm Okay I swear this code is going to blow up at any second, but the enemies now follow the knight! Oh yeah, and it uses about 1,000 times as much memory as it really needs due to some gloriously large memory leaks. I could fix it, but it would take all night :P

9:34pm I can't believe I did it. I'm in shock. My eyes are so tired! But I'm going to submit this log before I rest my eyes.