Your First MonoGame Project

In this tutorial, we’ll take a look at how to actually get your first game up and running with MonoGame using the MonoGame template.

Once we have our game up and running, we’ll take a look at the code that was included in the template to see what we’re working with. Hang on tight, because, in a few short minutes, you will have made your first game! (If you count a blue screen as a game, that is.)

Using the MonoGame Template

Start by opening Visual Studio. You should see a screen that looks like the image below:

Choose File > New Project from the menu, or use the keyboard shortcut Ctrl + Shift + N to begin creating a new project. This will open the New Solution dialog, shown below:

As outlined in the image above, you’ll want to select the MonoGame Windows Project template to get started. (We’ll talk about the other templates another time.)

To select this template, In the category tree on the left, select Visual C# > MonoGame. Note that if you failed to install the MonoGame correctly, you won’t see these MonoGame templates at all. (Go back and follow the instructions in the previous tutorial to get it set up.

This template is built on top of DirectX. (More precisely, SharpDX, which is built on top of DirectX.) There’s another Windows template alternative that runs on top of OpenGL. In theory, these should be functionally equivalent, though you will see some small differences in the rendering, with the DirectX version usually being a little nicer looking.

Because of the way MonoGame works, picking one template over another will not box you in permanently. For the most part, the code is the same, regardless of the template you choose or the final target of the game you’re developing. You’ll be able to create a “twin” project later on if and when you want to branch out to other platforms, so don’t worry about that at this point.

You’ll also want to give your project a name.

When all of that is done, press OK to finish the creation of your project.

After a couple of seconds of configuring your new MonoGame project, Visual Studio will open with your project ready to edit, and you’ll see your main source code file displayed, as shown below:

If you don’t see the source code file opened on the left side (as shown in the above image) open it up by clicking on Game1.cs in the Solution Explorer on the right side.

Running Your First Game

We’re going to ignore the code for a brief minute because this game is ready to roll right now! (You’ve already made your first game!)

To run your game, simply press F5. (This runs in debug mode. You can also press Ctrl + F5 to run without debugging. You can also find both of these options under the Debug menu.)

When you do this, you should see something that looks like this:

That’s it! Your first game is up and running! Congratulations, you’re now a game developer!

Understanding the Generated Code

It’s time to go back now and see what all of that source code did. I’m going to make the assumption that you already know how to program at least a little bit. If you don’t know what you’re doing with programming at all… that’s the place to start. And you’re in luck, because I have a whole pile of tutorials that will teach your how to program in C#!

So if you don’t know how to program at all (or just want to get a quick refresher on C#) go take a detour over there and come back here when you’re done.

The code that your project contains is spread out across two files. One has not been opened, but it’s called Program.cs. That file contains what will be the main entry point to your game. It starts up a new instance of your game and makes it run. It is pretty rare that you’d ever want to edit that.

The second file, called Game1.cs is what we’re going to spend most of our time on. (You should probably rename it and the class inside it to something else at some point, because “Game1” is way too generic to be meaningful.)

We’ll start at the top of that file and work our way down.

Using Directives

The first block you’ll see is this:

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;

namespace MyFirstGame
{

All of this is just your ordinary C# stuff. I discuss this kind of thing in more depth in my Hello World tutorial so if you’re unfamiliar with it, go look there.

The Game1 Class

The next thing you’ll see is this:

public class Game1 : Game
{

This is the beginning of the Game1 class. You can see that it [inherits]https://rbwhitaker.com/tutorials/c-sharp/inheritance/ from the Game class, which provides all of the core functionality that all games should have. So your game (which has the name Game1 right now) is a special type of Game.

This one little line means a lot. Because your game is a special type of Game, you get all of the abilities that were already defined in the Game class. In many ways, that’s the magic of MonoGame, because now you don’t need to build your whole game from scratch. You’ve got an intelligent starting point to make any game that you want.

Instance Variables

The next thing you’ll see are a couple of instance variables:

GraphicsDeviceManager graphics;
SpriteBatch spriteBatch;

We’ll learn how to use both of these as we go, but in short, the first one is your link to the graphics device (which lets you set various settings for how things should be drawn, etc.) and the second one is a tool that we’ll use when we want to draw sprites (a fancy game development word for image) to the screen. (No, we won’t just be limited to 2D, if that’s what you’re wondering. But even 3D games will use 2D stuff in their user interfaces.)

The Constructor

The next thing on our list is the constructor:

public Game1 ()
{
	graphics = new GraphicsDeviceManager (this);
	Content.RootDirectory = "Content";
}

This is a pretty typical constructor. (Again, if you don’t know what a constructor is, you’ll probably want to jump over to the C# tutorials and start there. This sets up the graphics device manager and content manager (something we’ll talk more about in the next tutorial) and makes our game be full screen (or not, since we changed it).

Initialize Method

Up next is the Initialize method:

/// <summary>
/// Allows the game to perform any initialization it needs to before starting to run.
/// This is where it can query for any required services and load any non-graphic
/// related content.  Calling base.Initialize will enumerate through any components
/// and initialize them as well.
/// </summary>
protected override void Initialize ()
{
	// TODO: Add your initialization logic here
	base.Initialize ();
}

This method is called shortly after the constructor is, before the game loop starts to run. It allows you to do one-time initialization for your game.

The LoadContent Method

The LoadContent method is the next thing in the code:

/// <summary>
/// LoadContent will be called once per game and is the place to load
/// all of your content.
/// </summary>
protected override void LoadContent ()
{
	// Create a new SpriteBatch, which can be used to draw textures.
	spriteBatch = new SpriteBatch (GraphicsDevice);

	//TODO: use this.Content to load your game content here
}

This is the place where you can load content (art assets like 3D models, textures, fonts, and music) for your game. It’s worth pointing out that you’ll actually be able to load content anywhere you want. You don’t necessarily need to do it here, nor do you have to do it all at once. But for smaller games, or while you’re getting started, this is the perfect place to do so. We’ll be talking about loading content in more detail in the next tutorial.

Again, this will be called once, sometime after the constructor and Initialize method have been called before the game loop really starts running.

The Update Method

Now we’re really getting into the meat of our game. The Update method is next:

/// <summary>
/// Allows the game to run logic such as updating the world,
/// checking for collisions, gathering input, and playing audio.
/// </summary>
/// <param name="gameTime">Provides a snapshot of timing values.</param>
protected override void Update(GameTime gameTime)
{
	if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed || Keyboard.GetState().IsKeyDown(Keys.Escape))
		Exit();

	// TODO: Add your update logic here

	base.Update(gameTime);
}

While your game is running, this will get called periodically and frequently. By default, this is configured to run 30 times per second, but we’ll see how you can change all of this in another tutorial.

This is the place to put all of your code for updating your game. Like the comment before the method states, this is where you update objects in your game world, handle user input, do collision detection, start audio playing, etc.

Much of what we do going forward will happen in here (or in a different method or class that was called from here).

The Draw Method

The last thing on our list is the Draw method:

/// <summary>
/// This is called when the game should draw itself.
/// </summary>
/// <param name="gameTime">Provides a snapshot of timing values.</param>
protected override void Draw(GameTime gameTime)
{
	GraphicsDevice.Clear(Color.CornflowerBlue);

	// TODO: Add your drawing code here

	base.Draw(gameTime);
}

Like the Update method, this is drawn 30 times per second by default, but it, too, is configurable. There doesn’t need to be an equal number of Update and Draw method calls. You can’t count on that. And for that reason, you really want to separate code that draws from code that updates.