search

GreenFour / pencil-knight

TCSS 491 Computational Worlds project
MIT License
0 stars 1 forks source link

QOL Features: Checkpoints #72

Open DevonS3 opened 6 years ago

DevonS3 commented 6 years ago

Checkpoints to respawn Hero.

The game state at the checkpoint should be restored. This is likely where a game board could be useful.

pilocchii commented 6 years ago

I'm going to mark this high priority for now, since I think it'll be a fundamental part of the difficulty gradient. If you feel differently we can talk about it.

DevonS3 commented 6 years ago

I’m with you 100%. One thing we might want to do before that is the “Back-End: Move Item/Entity additions from Core to their respective levels. #87” issue.

I was looking through the lecture on game boards, and with a couple additions our level classes are basically game boards. So, resolving the issue I mentioned up there will mean restoring the game state to before the checkpoint was activated will be easy.

Doing checkpoints that just reset Hero for now is fine too. Gives us a template and basic proof of concept.

pilocchii commented 6 years ago

So maybe levels inherit from the exiting GameBoard? I can think of a lot of things that would benefit from a redesign, between moving things to gameboards as levels and the engine as references, we could cut down on a lot of parameter creep I think.

DevonS3 commented 6 years ago

I can’t recall what’s currently in game-board, but making it a super class is definitely a good idea.

A gameboard is literally a state machine with memory. It keeps track of the game state and can be used to restore prior states if needed.

An alternative might be keeping levels as is, aside from moving items/enemies inside their respective levels, and then passing them to game-board when it’s time to load a given level. (That’s a spitball. Haven’t thought it through, but throwing it out there anyway.)

Whatever you think makes more sense.