encompass-cs-docs/content/getting_started/project_structure.md

29 lines
1.8 KiB
Markdown
Raw Normal View History

2019-05-22 20:56:04 +00:00
---
2020-07-11 00:06:40 +00:00
title: "Project Structure"
2019-05-22 20:56:04 +00:00
date: 2019-05-22T12:19:55-07:00
weight: 15
---
2020-07-11 00:06:40 +00:00
TODO: CREATE AN ENCOMPASS-FNA STARTER TEMPLATE
2019-05-22 20:56:04 +00:00
Structuring your project is a crucial component of keeping your Encompass development sane. Let's review how an Encompass project is typically structured.
If we look at the Encompass/FNA starter project, it looks like this:
2019-05-22 20:56:04 +00:00
(screenshot goes here))
2019-05-22 20:56:04 +00:00
2020-07-11 00:06:40 +00:00
The top-level of your game will be located in the (GameName)Game.cs file.
FNA's top level functions are described as follows.
`LoadContent` runs once after the initial setup is done. I usually like to put my initialization and, you guessed it, content loading code in here.
`UnloadContent` is where you clean up after yourself so the game can dispose of itself properly.
`Update(GameTime gameTime)` gets called once per frame. It's where the update code goes. For Encompass there probably won't be anything in here except `World.Update(gameTime.ElapsedGameTime.TotalSeconds)`.
2019-05-22 20:56:04 +00:00
2020-07-11 00:06:40 +00:00
`Draw` also gets called once per frame, after `Update`. All rendering logic should go in here. For Encompass you'll probably just put `World.Draw()` in here but there might be some externalities as well.
2019-05-22 20:56:04 +00:00
The rest of it is pretty straightforward. Put your sprites and sound effects and such in the **Content** folder. Define your components in the **Components** folder, your engines in the **Engines** folder, your messages in the **Messages** folder, and your renderers in the **Renderers** folder. (Again, we'll start getting into exactly how to define these in a minute.)
2019-05-22 20:56:04 +00:00
2020-07-11 00:06:40 +00:00
Finally, a quick note about **Helpers**. I like to use classes with static methods for common behaviors that will be useful for many different engines, for example a `Color` class with a `HSVToRGB` conversion function. Be careful not to abuse helpers. If your helpers aren't static, that is usually a sign that the behavior belongs in an engine instead.