How to control execution in the void Draw(GameTime gameTime) method

1

Before my game starts the user is presented with a menu (Lines 3 through 7). This occurs if the DrawMenu boolean flag is true. After the menu is displayed is their a way to pass control to line 200
without having to execute lines 9 through 199? Of course I want ohe Draw method on line 0 to continue to execute after each update, I am just looking for an easy way to bypass lines 9 through 199 to avoid a bunch of messy if then statements to control what is drawn?

0 protected override void Draw(GameTime gameTime)
1 {
2 GraphicsDevice.Clear(Color.CornflowerBlue);

3 spriteBatch.Begin();
4 if(DrawMenu==true)
5 {
6 spriteBatch.Draw(background, Vector2.Zero, Color.White);
7 spriteBatch.Draw(Menu, Vector2.Zero, Color.White);
8 }
9 else
10 {
11 spriteBatch.Draw(firstSprite, Vector2.Zero, Color.White);
12 spriteBatch.Draw(secondSprite, Vector2.Zero, Color.White);
13}
14 // More code here
15 // More code here
16 // More code here
.
.
200 spriteBatch.End();

2

An easy way without getting too complicated is to create a state machine

Create an enum called Gamestate. That could be Inmenu, or Ingame.

Put all your menudraw stuff in its own method (it should really be in its own class with its own logic etc)

Then, if gamestate == inmenu, Drawmenu()

If gamestate ==ingame, Drawgame()

1 Like
3

Alternatively, you could create an interface called GameState…

public interface IGameState
{
  void Update(GameTime gameTime);
  void Draw(GameTime gameTime);
}

In your main game state, you might want something like…

private IGameState m_currentState = new SomeInitialState();
private IGameState m_nextState = null;
public IGameState SetNextState(IGameState nextState) { m_nextState = nextState; }

Then, in your Game’s update method, maybe do something like…

public void Update(GameTime gameTime)
{
  m_currentState.Update(gameTime);

  if (m_nextState != null)
  {
    m_currentState = m_nextState;
    m_nextState = null;
  }
}

So in your case, maybe you create your menu state and give it a reference to your main game. When you detect the menu condition that you want to transition to the next state, you can do something like this…

if (playMenuClicked)
  mainGame.SetNextState(new GameplayState());

Anyway, hopefully you get the idea. Now you can put all the logic relating to each state inside their own objects.

1 Like
4

The way my game engine works is i have an abstract class called screen. This class stores things like uicontrollists and containers etc and for drawing and updating all these.

Then you have different screens derive from this class.
Menuscreens
Gamescreens
Settings screens

Then have an activescreen variable which you change depending on which screen you want displayed.

Then all you need to call in update and draw is activescreen.draw or activescreen.update.

You can keep all the individual logic separate to each screen class and don’t need to worry about having if statements for separate states.

1 Like
5

I typically make up my own system that is governed by a manager class and makes calls back and forth to notify when one wants something from the other. Or that calls down a chain and executes till the child completes. however that is just my janky way of doing things.

You can take a look at the Original GameStateManagement Example.
Who tomizechsterson ported from the original xna4.0 version to monogame.

I just tested it the nuget had to download or something but it runs.
The example itself is very nice and it works very smoothly.

If thats all to much then consider that you can pass anything you need from game 1 to another class.
Either by a methods parameters or by directly setting the variables needed in them provided they are public.
You could make a class with just regular old public update and draw methods and a switch case in your game1 in update and draw to call those class methods.
In that you switch to one that does the job you need when some conditions you define are meet.

That alone would drastically help you organize your game1 and cut out all that fat.
That’s the idea behind most all of them with just more bells and whistles and abstraction.
But ya you definitely need a system to organize that and clean it up into nice chunks you can call on that’s a mess its too fat and confusing.

The main thing is to you keep your sanity… keep in mind always the goal is…
That you find a way to organize things so that the way you code works for you.
Not you work to figure out the code, worst of all your own.

Personally i follow heavily the "single responsibility principle and the kiss principles because im so bad naturally at following either.

You might want to take a look at these two topics.
S.O.L.I.D Principles.


and Design Patterns.
1 Like