This game is moving at an incredible pace. Which is nice, 'cause we get to play it sooner rather than later ;-).

Suggestion: don't make the checkpoint disappear. Once the player "checks a point", change the hue (to something vivid as opposed to neutral gray), so players will have a clue where they left off (they can link a visible icon to a recent checkpoint event). Disney's Hercules does this, and I'm sure tons of other games have something similar.

Other than that, the overworld looks great. This art-style is really fitting and reminds me of some good old times, when I (amongst others) was programming some of my first games in VB6.

Small tidbit: the spikes now resemble more of an iron fence. Spacing them apart and making them cone-shaped as opposed to rectangular might do the trick. Kind of like a "bed of nails" :-). Easy talking as you have to do the art yourself, and I bet you already knew it too.

Quote:Original post by Todo
This game is moving at an incredible pace. Which is nice, 'cause we get to play it sooner rather than later ;-).

Thanks [smile].

Quote:Original post by Todo
Suggestion: don't make the checkpoint disappear. Once the player "checks a point", change the hue (to something vivid as opposed to neutral gray), so players will have a clue where they left off (they can link a visible icon to a recent checkpoint event). Disney's Hercules does this, and I'm sure tons of other games have something similar.

Certainly worth thinking about, although I'm pretty happy with the current system. On a well designed level, you wouldn't really care about exactly where the last checkpoint was.

Quote:Original post by Todo
Other than that, the overworld looks great. This art-style is really fitting and reminds me of some good old times, when I (amongst others) was programming some of my first games in VB6.

I guess the naff blocky graphics do look a bit old-hat, but it is only for the in-between levels bit, and the alpha shadows and scrolling water make it look a bit more modern when it is in motion. I think the brown "front" bits could do with being improved.

Quote:Original post by Todo
Small tidbit: the spikes now resemble more of an iron fence. Spacing them apart and making them cone-shaped as opposed to rectangular might do the trick. Kind of like a "bed of nails" :-). Easy talking as you have to do the art yourself, and I bet you already knew it too.

Totally agree that the spikes look awful. I keep meaning to get round to that. [grin]

Cheers for all the comments.

Quote:Original post by EasilyConfused

Quote:Original post by Todo
Suggestion: don't make the checkpoint disappear. Once the player "checks a point", change the hue (to something vivid as opposed to neutral gray), so players will have a clue where they left off (they can link a visible icon to a recent checkpoint event). Disney's Hercules does this, and I'm sure tons of other games have something similar.

Certainly worth thinking about, although I'm pretty happy with the current system. On a well designed level, you wouldn't really care about exactly where the last checkpoint was.

Point taken, but repetitive game levels such as those in the Super Mario Bros series could benefit from this.

Quote:Original post by EasilyConfused

Quote:Original post by Todo
Other than that, the overworld looks great. This art-style is really fitting and reminds me of some good old times, when I (amongst others) was programming some of my first games in VB6.

I guess the naff blocky graphics do look a bit old-hat, but it is only for the in-between levels bit, and the alpha shadows and scrolling water make it look a bit more modern when it is in motion. I think the brown "front" bits could do with being improved.

I meant that purely in a good way, kinda like "pleasant nostalgia" ;-).

I'm actually thinking a bit about the checkpoints now, after this conversation.

At the moment, if you hit a checkpoint, then kill a monster, then die, the monster that you killed is gone, sort of like the checkpoint saves your position but nothing else.

Perhaps this would be better if the checkpoint actually saved the whole state of the level so that only monsters and pickups removed when you hit the checkpoint are missing when you restart.

Not sure how to implement this, so I'll waffle a bit.

At the moment, each object has a unique ID (assigned by the level editor) and when it is killed or collected, its ID is pushed onto a vector of dead IDs.

When you die and the level restarts, the level is loaded in its basic state, then the engine runs through all the objects and if their ID is in the dead ID list, it removes them from the level before commencing.

I guess I need two vectors - the first one (A) acts like the current one in that dead IDs are pushed onto it as they occur. The second one (B) could be empty at the start of a level.

When you hit a checkpoint, A is appended to B then A is cleared.

When you die with lives left and we restart the level, A is cleared then B is used to remove dead items. B then maintains its contents and we continue like before.

That would make the checkpoints more like a snapshot of time rather than just position. Not literally since moving objects would still start at there origin position regardless of where they were when you died, but it would still be better than the current system and if my thoughts above are correct quite easy to implement.

Tonight's tasks are stacking up a bit. [smile]

Cheers for all the input, and I didn't take your comments about the graphics as anything other than positive, I'm just not very happy with them and think they could be improved.

For example, the brown rocks at front of the map could easily produce a fake 3D effect by sloping down at the sides into the water.

I remember something similar a few years back. It's quite easy to implement and could be (ab)used for other means, so here goes:

1) each object has a checkpoint counter (CC). At the beginning of each level, this counter will be reset to the total number of checkpoints in the level;

2) each time an entity "dies", it's CC gets set to the last visited checkpoint (0 if the player hasn't passed a checkpoint yet);

3) when the player dies and respawns at the last checkpoint, every entity whose CC is greater than or equal to the last visited checkpoint respawns too (and its counter gets reset).

I could have left a few bits out (or made a mistake in reasoning) but the general idea should be clear: you save a second vector (or even both, if per frame you need to check whether or not an entity is dead, looking at its CC is cheaper than looking up its entry in a vector. However, a vector has other benefits and you probably use it for good reason).

I might have missed something specific you needed, but as always I'm only babbling :-).

That seems like a feasible system but the trouble is that the way Udo works is to lose all level information and reload from the original file when you die, so there is no way to save any state inside the items themselves. It would be a hell of an overhaul to change that now [smile].

The two vectors of dead IDs works pretty well now. My map editor can now assign unique ID numbers to every item you place on the map so it's painless setting up and now if you die, any enemies that you killed before you hit the checkpoint are removed and any you killed afterwards respawn. Same for pickups.

Only slight concern is that this system may break if I need to store the state of anything more complex, like whether doors are open or the position of switches and so on, but I'm sure I can find a solution when it comes up.

I can't believe I didn't see this project before. I love the art style.

Are you expecting the player to move backwards through a level at all (perhaps going back to get more collectables or something)? If so then you may want to have your checkpoint system such that previously-visited checkpoints become visible again once you touch a different checkpoint. That way you can touch checkpoint A near the start of the level, touch checkpoint B at the end, then go back and touch checkpoint A so that you can search the vicinity without having to come all the way back from checkpoint B if you die.

Also, with checkpoint data... it's basically a saved game you're generating. Have you considered simply dumping all data from the current level state into a buffer when you hit the checkpoint and then loading it as if it were a full level file?