vprette, on Mon Jan 30, 2012 2:31 PM, said:
If I understand, after Title I move to ST_LVL_INIT
from this to level to level?
In fact in my case I need a new level for each text page, when I press a direction I should go to next level(page).... this code implement only one level and tape the text according to the direction..... I should modify so that taping a direction I call next level instead of printing the direction... it's lot different... and messy for me :-)
Valter,
Printing the direction is done as a demonstration of using the controller input decoder.
The input decoder accepts a table that contains "callback" routines for each controller event. For instance, when a keypad key is pressed the routine at the entry in the table for the keypad will be called automatically.
The same happens for disc input. I think the value in R0 (I'm not sure which register right now, sorry) corresponds to either the key or disc direction pressed. The code should specify I the comments.
P-machinery does not have a concept of "levels" per se, so it is open to many types of games. The term "level" may be used in the code, but it is just a vestige of working on Pac-Man. It actually represents the "game-play" state, as opposed to the title screen or game-over states.
For most part, you'll only need three states: title screen, game-play, and game-over.
Once the game enters "game-play" state, the P-Mach state machine should remain there until the player dies. You could add more states, but it is not really necessary.
An example of an extra state is Christmas Carol's intermission screens between levels. It requires special game logic that does not really qualify as "game-play" since it is autonomous.
Keep in mind that each "main" state can be sub-divided in up to 8 sub-states. This allows you to break up, say, the title screen state into something like init, draw, and wait for input.
As an example, consider that the "game-play" state in Christmas Carol is broken down into:
- init level
- play level
- replay level (after player death)
- end level (after completion)
- end game (after last death)
- wait for input.
In the case of a text adventure, I would imagine that you could treat the many rooms like I treat the levels on Carol. In that case, the "game-play" state could be broken up into:
- init room
- wait for input
- process command
- exit room
- player death
You wouldn't need a new state per room, you just keep that state of your world in variables and update them as the player moves from room to room.
That's just an example, of course.
Once I return later this week, I can offer more concrete examples and even code samples.
dZ.
Edited by DZ-Jay, Mon Jan 30, 2012 4:17 PM.