Difference between revisions of "Game (Chili Framework)"
| (12 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | The <code>Game</code> class is where you put the code to make the game do the things. The predefined member functions <code>UpdateModel()</code> and <code>ComposeFrame()</code> are where you put your game logic and your rendering code, respectively. <code>Game</code> is composed of the <code>Graphics</code> object used for drawing and keeps a reference to the <code>MainWindow</code> object to interface with the Windows system (which includes the keyboard and mouse inputs). | + | The <code>Game</code> class is where you put the code to make the game do the things. The predefined member [[function|functions]] <code>UpdateModel()</code> and <code>ComposeFrame()</code> are where you put your game logic and your rendering code, respectively. <code>Game</code> is composed of the <code>Graphics</code> object used for drawing and keeps a reference to the <code>MainWindow</code> object to interface with the Windows system (which includes the keyboard and mouse inputs). |
| + | |||
| + | == How to Do the Thing == | ||
| + | |||
| + | The <code>Game</code> class is meant to be modified by the programmer (that's you dawg). I'm not talking some crazy bagel head shit here, I'm talking about pure C++ crack codecaine (hook it in my veins!!). Slam some drawing code into <code>ComposeFrame()</code> and watch it ejaculate ropey strands of pixels onto your screen. Add some member variables to the class definition (in the <code>Game.h</code> file) to keep track of game state between frames. Add some private functions to <code>Game</code> to break up complex procedures into simple ones, or to allow code that appears in multiple places to unified to a single function. | ||
== Members == | == Members == | ||
| + | |||
| + | === ComposeFrame === | ||
| + | |||
| + | <code>void Game::ComposeFrame()</code><br /> | ||
| + | |||
| + | This is where you draw what is happening in the game's world on the screen so that the player will know what the fuck is going on. Try to avoid putting game logic here, and Chili will try to avoid putting his Möbius dildo up your butt. | ||
| + | |||
| + | === UpdateModel === | ||
| + | |||
| + | <code>void Game::UpdateModel()</code><br /> | ||
| + | |||
| + | This is where you put the code for updating the game's internal simulated state. Read inputs, move shit, spawn shit, kill shit, it's all good. Just don't put any drawing code here or Chili will fuck you with his Möbius dildo. When you get a little more advanced, you'll want to measure the time between frames so you can step the game simulation forward at proportional rate. | ||
=== Game (constructor) === | === Game (constructor) === | ||
| Line 7: | Line 23: | ||
<code>Game::Game( class MainWindow& wnd )</code><br /> | <code>Game::Game( class MainWindow& wnd )</code><br /> | ||
| − | Gets called when the Game object is created and creates the Graphics object. Put your initialization code here and it gets executed once at the start of the program. Good deal. | + | Gets called when the <code>Game</code> object is created and creates the <code>Graphics</code> object. Put your initialization code here and it gets executed once at the start of the program. Good deal. |
| + | |||
| + | === Game (destructor) === | ||
| + | |||
| + | <code>Game::~Game()</code><br /> | ||
| + | |||
| + | Gets called when the <code>Game</code> object is destroyed and destroys the <code>Graphics</code> object. Put your final dying statements here and they get executed once at the end of the program. | ||
| + | |||
| + | === Go === | ||
| + | |||
| + | <code>void Game::Go()</code><br /> | ||
| + | |||
| + | <code>Go()</code> is called from the Windows message loop, and it causes the <code>Game</code> object to simulate and render a single frame of the game. The body of <code>Go()</code> calls <code>UpdateModel()</code>, clears the framebuffer, calls <code>ComposeFrame()</code>, and presents the frame to the user. Generally speaking, ''ne touche pas''. | ||
| + | |||
| + | === Member variables === | ||
| + | |||
| + | ==== gfx ==== | ||
| + | <code>Graphics Game::gfx</code><br /> | ||
| + | |||
| + | The <code>Graphics</code> object is embedded in <code>Game</code>. Use it to make pretty drawings. ''My name is Simon and I like to do drawings. - Simon'' | ||
| + | |||
| + | ==== wnd ==== | ||
| + | <code>MainWindow& Game::gfx</code><br /> | ||
| + | |||
| + | <code>Game</code> maintains a reference to the <code>MainWindow</code> object so that you can get keyboard and mouse input (the <code>Keyboard</code> and <code>Mouse</code> objects are embedded in <code>MainWindow</code>) and so that you can access certain Windows functionality (like checking if the window is minimized or displaying a message box). | ||
| + | |||
| + | == See also == | ||
| + | * The [[Chili Framework]] | ||
Latest revision as of 13:20, 1 August 2016
The Game class is where you put the code to make the game do the things. The predefined member functions UpdateModel() and ComposeFrame() are where you put your game logic and your rendering code, respectively. Game is composed of the Graphics object used for drawing and keeps a reference to the MainWindow object to interface with the Windows system (which includes the keyboard and mouse inputs).
Contents
How to Do the Thing
The Game class is meant to be modified by the programmer (that's you dawg). I'm not talking some crazy bagel head shit here, I'm talking about pure C++ crack codecaine (hook it in my veins!!). Slam some drawing code into ComposeFrame() and watch it ejaculate ropey strands of pixels onto your screen. Add some member variables to the class definition (in the Game.h file) to keep track of game state between frames. Add some private functions to Game to break up complex procedures into simple ones, or to allow code that appears in multiple places to unified to a single function.
Members
ComposeFrame
void Game::ComposeFrame()
This is where you draw what is happening in the game's world on the screen so that the player will know what the fuck is going on. Try to avoid putting game logic here, and Chili will try to avoid putting his Möbius dildo up your butt.
UpdateModel
void Game::UpdateModel()
This is where you put the code for updating the game's internal simulated state. Read inputs, move shit, spawn shit, kill shit, it's all good. Just don't put any drawing code here or Chili will fuck you with his Möbius dildo. When you get a little more advanced, you'll want to measure the time between frames so you can step the game simulation forward at proportional rate.
Game (constructor)
Game::Game( class MainWindow& wnd )
Gets called when the Game object is created and creates the Graphics object. Put your initialization code here and it gets executed once at the start of the program. Good deal.
Game (destructor)
Game::~Game()
Gets called when the Game object is destroyed and destroys the Graphics object. Put your final dying statements here and they get executed once at the end of the program.
Go
void Game::Go()
Go() is called from the Windows message loop, and it causes the Game object to simulate and render a single frame of the game. The body of Go() calls UpdateModel(), clears the framebuffer, calls ComposeFrame(), and presents the frame to the user. Generally speaking, ne touche pas.
Member variables
gfx
Graphics Game::gfx
The Graphics object is embedded in Game. Use it to make pretty drawings. My name is Simon and I like to do drawings. - Simon
wnd
MainWindow& Game::gfx
Game maintains a reference to the MainWindow object so that you can get keyboard and mouse input (the Keyboard and Mouse objects are embedded in MainWindow) and so that you can access certain Windows functionality (like checking if the window is minimized or displaying a message box).
See also
- The Chili Framework
