I've decided on a vertical-scrolling top-down shooter for my next project. I've a good idea of how to do most of it but I just want to ask for some advice on some aspects first... 1. I plan to have buildings in the game. So you're walking on the ground, then there's a rooftop with a ladder on the side with more enemies on top or whatever. So... to implement the varying levels of height would it pretty much be sufficient to just give each map tile a "height" variable and go from there? 2. As for the ladder... should that be something like... move into the ladder-> enter "ladder-climbing" mode -> wait 2 seconds -> you're on top of the building? 3. How should enemies be placed? Should I just make a vector of Enemies and then have each one initialized in their position right from the start or would it be better to somehow spawn them as the player comes near? I've never done a game spread across more than 1 screen before though I'm comfortable with the basic idea, just a few things like enemies are making me think.

Is it in 2d or 3d->2.5d?

Currently with mine, I place the enemies at a specific world position when they are created. I have a camera that gets updated and when the camera view contains the enemy position the enemy spawns and/or acts.

In terms of the varying levels of height you would have to have a variable tracking the depth or height of each object in the game world atleast probably for drawing purposes.

2D. C++ and SDL.

Hmm... ya I suppose giving everything a height variable is the general idea...

Quote:Original post by Sean_Seanston
1. I plan to have buildings in the game. So you're walking on the ground, then there's a rooftop with a ladder on the side with more enemies on top or whatever.
So... to implement the varying levels of height would it pretty much be sufficient to just give each map tile a "height" variable and go from there?

You can give each tile a height, and then the objects will be able to tell what height they're at by the tile they're on. Things like ladders or elevators would be special tiles that don't necessarily mess with an object's height until the object "interacts" with the tile is some way. For instance, the player interacting with a ladder would probably display a little climbing animation before his height was changed (or it could gradually change during the animation depending on other gameplay factors).

Quote:2. As for the ladder... should that be something like... move into the ladder-> enter "ladder-climbing" mode -> wait 2 seconds -> you're on top of the building?

Sure. I personally like some sort of visual queue that the player is climbing and how far up or down the ladder he is. This can be implemented by slowly moving the player left-to-right and right-to-left (or top/down) across the ladder tile as he climbs, complemented by a climbing animation.

Quote:3. How should enemies be placed? Should I just make a vector of Enemies and then have each one initialized in their position right from the start or would it be better to somehow spawn them as the player comes near? I've never done a game spread across more than 1 screen before though I'm comfortable with the basic idea, just a few things like enemies are making me think.

For a basic top-down shooter, I would spawn a few enemies in key positions so that you have some control over the action and what the player is up against in different places in the level. But at the same time if something like an alarm goes off, it wouldn't hurt to have a bunch of enemies spawn. I certainly wouldn't make it any more complex than it has to be.

Are you having two tilemaps on top of each other? getting some parallax on there might look pretty cool :)

As for the ladder climbing, you would probably use a finite state machine or something of that nature. So your entity would have states of say "Walking", "ClimbingUp", "ClimbingDown", "Dead" or what have you. Touching the ladder in "Walking" when your height is 0 would trigger the state change to "ClimbingUp", which then ends with your height of 1 and a state transition back to "Walking". Hitting the ladder again at 1 would give you a transition to "ClimbingDown", etc.

You could add another state for "Falling" in which you try and move off the building and you fall down (eg: you're at 1, the tile you wanted to go to was at 0), but maybe take some damage as part of the state transition.

As for spawning enemies; I'd probably use a basic trigger system to spawn them into the world when they're needed.

Alright cool thanks... that pretty much confirms the general idea of what I was thinking.

Few more things though:

1. In Lazy Foo's SDL tutorials, he suggests putting each level in a separate game state. Surely that would be a bad idea when presumably every level of your average game is only going to differ by terrain, enemies etc and have the very same mechanics? Would it not be easier to just have 1 state for playing where a certain level is loaded based on a switch statement and the same with enemies?

2. I reckon I can do a basic level editor for the game without too many problems, I've seen some examples. However, would it also be a good idea and relatively simple to use a level editor to place a level's enemies? Something like... right click on a tile to set that tile as the starting location of an enemy and then save all that to a .map file or whatever?

And on this subject, if you look here:
http://photos1.blogger.com/blogger/2754/2691/1600/untitled.png
Toolmaker (who actually posts here come to think of it <_<) has made a pretty cool little level editor with radio buttons for the different kinds of tile. To make something like that, you'd need to use the Windows API right? Though I suppose you could make buttons with the mouseover functions of SDL just about as easily...