Is it possible to put the game logic in the draw function?

Question

I am making a game, and I finally finished its gameplay, but now I need to create a menu and a high-rated screen. I'm not quite sure how to do this, the game will be in a different state (MENU_STATE, GAMEPLAY_STATE, SCORESCREEN_STATE), and in each state I want to draw different things on the screen, is it ok for me to do something like that?

draw function() { if MENU_STATE draw menu if GAMEPLAY_STATE draw game if SCORESCREEN_STATE draw scores } 

I follow strict logic in the draw function, and it has been good so far, but I really can't figure out how to do this.

Answer 1

You can use separate classes for three states, implementing a common interface and instead of setting a constant for the state, specify an instance of one of the classes:

 interface IState { void draw(); } class Menu implements IState { void draw() { // Draw menu } } class Game implements IState { void draw() { // Draw game } } void draw() { state.draw(); } 

This is still not perfect (you really do not want to draw code in your state, you want something to be a little more separate), but the abstraction is general and can be relevant (and it’s hard for her to advise further without knowing more about your architecture) .

Answer 2

You call some drawing functions in this procedure, but that does not mean that you should call it a draw.

Perhaps this is more appropriate in your case:

 // pseudocode on_game_state function(state) { select (state): MENU_STATE: draw menu GAMEPLAY_STATE: draw game SCORESCREEN_STATE: draw scores } 

Answer 3

Using statemachine will make this easier. Each state will have its own set of update and drawing functions that are called when it is on top of the state stack. Instead of having one drawing function with internal state switches, you would have Game_Draw (), Menu_Draw (), HighScoreScreen_Draw (), etc. Similarly, your upgrade functions can be separated.

 static void StateMachine_DrawTopState() { switch(stateMachine_topState) { case STATE_GAMEPLAY: { Gameplay_Draw(); } break; case STATE_MENU: { Menu_Draw(); } break; } } 

Answer 4

Like Andrew Aylett's answer, and assuming an object-oriented language, perhaps you could do something like:

 Interface IState { void init(); void update(); void draw(); } class GameplayScene implements IState { void init() { // initialize gameplay } void update() { // update game logic } void draw() { // draw game } } class MenuScene implements IState { void init() { // initialize menu } void update() { // update menu logic } void draw() { // draw menu } } class ScoresScene etc... class TitleScene etc... // Somewhere else, probably in the Game class void Main() { // Init game Scene currentScene = new TitleScene; while (Scene != null) { Scene.init(); Scene.update(); Scene.draw(); } // Exit game } 

You also need to think about how to handle the transition between scenes. You can have a member variable in each scene class, called the same as nextScene, and the main function queries it at the beginning of the loop to switch to the corresponding scene.

Unless you have the luxury of using an object-oriented programming language (e.g. C ++, Java, C #, Python, etc.), Colin and Nick D's Answers can help, although I would try to include the switch statement in one place ( let's say one big function game_update) to add new states by making changes in one place. Alternatively, you could build a regular Colin apparatus to do something more general, and this clearly does not require a hard-coded switch statement. (although, to be honest, I can't think of a good way to do this at the moment)

Answer 5

Absolutely not ok to put the game logic in the drawing function.

However, if it makes your life easier in this particular case, it's okay anyway.

You can always change it later if it becomes a mess.

Answer 6

Yes, fine, game programmers are allowed to bend the rules for improving performance. The representation and model of the game world is often the same thing to avoid the latency created by decoupling the look and model.

There is no reason why you cannot make menu objects and records a part of your game world; this has been done in quite a few games.