Discussion: Game Flow Management

[weilies]

hi all,

Would like to open a discussion that "may-be" most of us will fast the issue.
"How to make our code more friendly, expandable, readable when deal with Game Flow Management" (in General)

Game Flow can be
- SplashScreen
- MainMenu
- Game Over
- Game Starting
- Game Running (where different events may happen due to user input, game rule which causing game to change to different states)

I believe Love2D is a cool enough engine/framework but i am facing issue like my code getting messier where i put all my logic scatter in
- love.load, love.update, love.draw, love.mousepressed, love.keypressed functions

I came from web development and we hv several design pattern. Like MVC (which seperate business logic, locig flow, GUI)
I really hope someone can suggest this kinda approach in Love2D


Thanks!

[Robin]

The most common approach is using states, where each state has their own callback functions. That removes a lot of clutter. Another way is separating more high-level and low-level aspects of the game.

Separating GUI code can partially be achieved by using GUI libraries, rather than implementing them in your callbacks.

[Ryne]

I asked a similar question on how to use separate ".lua" files instead of one huge main file, which could also be useful to get rid of clutter. Robin posted a pretty easy way of doing so, if you want to take a look at the last few posts of this thread http://love2d.org/forums/viewtopic.php?f=4&t=2036.

[vrld]

The separation into states Robin mentioned is the most useful approach to manage overall game-flow. It comes naturally:

- SplashScreen
- MainMenu
- Game Over
- Game Starting
- Game Running

Your states would be (not sure what you mean by game starting, so i am omitting it):
splash-screen/Intro, main menu, main game, game over screen.

hump has a gamestate handler. You can look at the sourcecode of Fistful of Beef (directory states) for an example.
There is also kikito's MindState, which can be used for the same purpose, but is more generalized and can be used for stateful behavior in general.

You can use a MVC scheme to structure your game, but most of the time this is overkill, since you don't need multiple views of the same data. Multiple controllers only make sense if you want the player to be able to pilot the same characters as the cpu or plan to include multiplayer (Lua's ability to swap methods at runtime make this really easy).

Since OO makes much sense in games, you probably want some implementation of classes. There are some libraries on the wiki: kikito's MiddleClass is fairly advanced, while SECS is rather basic. hump is somewhere between those two.