Checkpoints in HATPC will be difficult to implement, and potentially hard to work and reason with for level designers. So I'm proposing a basic encoding for checkpoints to be placed at the bottom of HATPC level codes. This is just a rough idea for a first stab at checkpoints and is totally up for debate. I think there are lots of different ways of doing checkpoints, many of which I've failed to consider.

Checkpoint Types
* Simple: upon respawn, the state of the level is unchanged from when the player first arrived at the checkpoint.
* Complex: upon respawn, the state of the level is set to a configuration specified by the level designer.

Activation Requirements
* Checkpoint ordering is the same as the order in which checkpoints are declared in the level code.
* The level designer can specify treasures that need to be collected in order for a checkpoint to be activated.
* Checkpoints can be skipped, but those that are skipped cannot be activated.
* e.g. If checkpoint B follows A, the player cannot activate A if they reached B first.
* The activation of each checkpoint is dependent on the requirements of previous checkpoints.
* e.g. If checkpoint A requires the collection of a treasure at (1,1), and checkpoint B requires the collection of a treasure at (2,2), the player must have collected both treasures if they want to activate checkpoint B before A.
* The state on respawn of each checkpoint should respect the states specified by previous checkpoints. The exception to this rule is if they conflict, in which case the latest checkpoint's specification takes precedence.
* e.g. If I pass through checkpoint A, which specifies a boulder appears at (1,1) on respawn, pass through checkpoint B, which specifies a steel crate appears at (1,1) on respawn, and then die, a steel crate will appear rather than a boulder. However, if I had died before checkpoint B, the boulder would appear.

Encoding
* Could go at the bottom of each level code.
* Begins with 'checkpoint' followed by its coordinates and type (simple or complex).
* In complex checkpoints, this can be followed by a 'state' section that specifies the delta between the starting state and the respawn state, using triples of the form <xCoordinate, yCoordinate, entityTypeOnRespawn>.
* At the end can be a 'treasures' coordinate list, specifying treasures that need to be collected to activate that checkpoint.
* To make a checkpoint that just recreates the starting state on respawn, specify a complex checkpoint without any state.
* e.g...

I don't think that the "complex" checkpoint type is really necessary, and as its name implies, it would be very complex, both to implement and to use. I think the level state upon loading a checkpoint should always be the same as the level state when the checkpoint was activated.

However, I do like the idea of coding checkpoints on separate lines in the level file and including the option to require treasures for them, as well as possibly some other parameters. Here's a proposed syntax for checkpoints:

Checkpoints are defined by a line beginning with  

!cp

. That line can be anywhere in the level code except before the first line of the cave (because the 5th line of the level file defines the width of the cave). In practice it will probably go after the end of the level file, but the parser won't care if you put it in the middle of the cave.

After the  

!cp

, there will be a list of the parameters required for unlocking the checkpoint in the form  

!parameter(value1, value2, value3)

. Marking each parameter with  

!

  will make it easy for the parser to separate them, and since  

!

  doesn't code for anything in the level file itself, it'll be easy to tell which lines code for checkpoints (or anything else I want to add with similar syntax).

Here are a few example parameters:

Coordinates would be one-based counting from the top left corner, so the top left corner would be (1, 1). In the game code, the counting is zero-based and y comes before x due to way the arrays are constructed reading through the text file, but I'll adjust the values when reading them in to match the internal standard.

Here are a few examples using the syntax:


Of course, it would be possible to make checkpoints with many more parameters than that, but you get the idea. It allows you to make checkpoints either very specific or very general.

Seems like a good step towards developing a clean syntax for declaring checkpoints.

From an implementation perspective, I would have thought that the simple checkpoints would be harder to implement than the complex ones, purely because the level designer does more work for you. On the other hand, enabling the designer to specify those respawn states could be cumbersome in terms of the user interface for that.

Look forward to seeing what you come up with.

Um,
some ideas just throwing in here:
1. a checkpoint which saves EXACTLY how it was when you touched it (like, an arrow can be still in the air)
2. a checkpoint which reloads the same level from the beginning, but hannah with a different starting position
3. a checkpoint which saves the static values. so like, an arrow is hitting you but you got the checkpoint, then you reload to the same spot with no arrow.

These look pretty are to implement imo, but I'm really not sure how you guys actually program this. I may have the time to look somewhen.
Sooooo ideas, use'm!

@shos:
I'm basically proposing that #1 be the only option of those 3. In some ways it's the hardest option to implement, but it's also the most useful and implementing the others in addition to it would be extra work without much point to it IMO.

I would try to keep it simple. I'm not even sure if checkpoint functionality could be implemented, but if it can, with my limited knowledge of how things work, I'd just suggest basically re-using the way tutorial messages are done. Numbers for checkpoints, a bunch of lines at the end with a ? followed by the number of treasures required to activate the checkpoints, and something to indicate the use of checkpoints vs tutorial levels/enemies.