Photo: ’Watermelon’ by Harsha K R
Work on #ProjectWatermelon, my retro side-scrolling pygame project, has stalled the past few months, but I’ve spent this week trying to get things back on track. Rather than just jumping right back into code, I’ve decided to take a step back and take another look at some big picture design things, starting with ways to reorganize the program’s design in a way that encourages less tightly-coupled classes. Right now I’m looking at ways to refactor my existing code into something using the component design pattern and I’ve decided to use state machines to manage state for the individual components. Here are diagrams I’ve completed to model the states for some of the individual components.
These diagrams represent states for the program execution. Once launched, the game enters an attract mode loop until the player presses the start button.
Attract mode cycles the screen between the intro cinematic, title screen, gameplay demo, and high scores. Pressing any key while not on the title screen will cause the attract mode to jump to the title screen, where the player is prompted to press start.
Once the player has pressed start from the title screen, program flow is passed to the appropriate level. Each level will use the following state machine to manage flow of the individual screen states that make up a level. Reaching the success final state will cause the game to advance to the next level (or the primary Win state in the case of the final level), while the failure final state will advance to the primary Lose state.
Each entity (players and enemy AI) will consist of at least 4 components managing health/damage, ground, movement, and carrying states.
These states determine whether the entity may receive damage.
These states determine what type of actions/movements the entity may perform based on their relationship to the ground.
These states determine whether the entity may move left or right.
These states determine whether the entity may pick-up or throw objects.