Who This Book Is For?

This book is targeting the aspiring game developer who wants to make a 2D game. Royalty-free game assets for sound, music, textures, and sprites will be provided (all created by yours truly), thus allowing the book to focus on the programming and architecture components of game development without worrying about cranking out game assets.

What This Book Is Not

While we will review game types as it relates to what pairs well with MonoGame, this book will not go over game design principles, asset creation, or the game development life cycle. There are numerous resources available including entire books devoted to these individual components and are outside the scope of this book.

Reader Assumptions

While no game development experience is required, there is an expectation that you are a seasoned C# programmer. While MonoGame is easy to get started with due to the architecture and the simple design, the framework is written in C#. In addition, the project we will be iterating on throughout this book utilizes many core aspects of the C# programming language such as inheritance and reflection. If you find yourself reviewing the accompanied source code and are struggling, I suggest picking up C# Programming for Absolute Beginners also from Apress to close the gaps.

From a development machine standpoint, this book will review how to configure a MonoGame development environment on both macOS and Windows with Visual Studio. Linux can also be used as a development environment with Visual Studio Code; however, Windows will be the preferred environment for the scope of this book due to the tooling Visual Studio for Windows offers.

With all of the assets provided with this book in formats MonoGame’s pipeline can natively read (more on this feature in Chapter 5), no other tools are required. Experience with tools such as Photoshop, 3ds Max, and Audition will come in handy for your future development efforts even if it is simply a beginner skill level.

At the time of this writing, version 3.8 of MonoGame is the latest production version available, which was released on August 10, 2020. This version will be used for all code samples and snippets throughout this book. Versions 3.8.x or later may be available by the time you are reading this; however, based on the road map, samples should continue to work without issue.

What Is MonoGame

MonoGame at the highest level is a C# Framework that provides the developer a canvas to quickly create the game of their dreams. MonoGame is open source (Microsoft Public License) and royalty-free (over 1000 games have been published to various stores). While MonoGame does offer 3D support, the community by and large uses its powerful 2D support almost exclusively, and that will be the focus in this book (for 3D games the use of Unity or Unreal Engine is recommended). MonoGame’s source code is available on GitHub (https://github.com/MonoGame/MonoGame).

For PlayStation 4, Xbox One, and Nintendo Switch, it should be noted that additional developer agreements are required before publishing to the respective stores.

Given MonoGame’s underlying usage of C#, as new platforms become supported by C#, MonoGame should not be far behind.

Throughout the book, we will review any platform-specific considerations such as resolution and input methods (touch vs. keyboard, for instance). Fortunately, designing around a cross-platform game does not require much upfront effort with MonoGame.

One of the best features of MonoGame’s design is this simplicity, unlike other frameworks that have an extremely difficult learning curve to even get the first pixel rendered. Over the course of this book, we will extend this structure to support more complex scenarios and provide a rich expandable engine to not only build on with each chapter but also provide a framework to build your own game. In Chapter 3, we will deep dive into this architecture.

Seasoned developers at this point may be wondering what the relationship between MonoGame and Microsoft’s XNA framework is. At a high level, there isn’t a direct relationship. The underlying structure bulleted earlier is retained and the use of C# as the language is where the correlations end. MonoGame grew out of a desire from Jose Antonio Leal de Farias in 2009 to create XNA Touch. Similar to the effort on Mono Touch to bring Mono to iOS, the goal was to bring XNA to iOS. By that point, XNA was stagnating with the release of 4.0 in 2010 (which would be the last version released) and an official statement ending support in 2013. From there XNA Touch was renamed to MonoGame with support coming to Android, Mac, and Linux shortly thereafter. MonoGame eventually made it to GitHub and at the time of this writing has over 2200 forks with 267 contributors.

MonoGame Compared to Engines

MonoGame as mentioned is a pure framework. From the beginning of development, the goals of MonoGame were to create a flexible, simple, but powerful framework. The main design reason for this was to allow MonoGame to be used in a wide range of genres and game types as opposed to an engine that more often than not is tailored to a specific genre (generally the genre that the game driving the engine’s development was such as the Quake series).

An engine conversely like that of Unity, Unreal Engine, or id Tech, to name a few, provides an end-to-end engine and editor with all of the various components that make up a game engine such as rendering, physics, level editors, and content pipelines with integrations into modeling programs. Depending on the level of deviation from the engine’s core, there may be very little for an implementer to have to extend on their own. The engine approach allows a team of artists and designers a canvas ready to start implementing the game as opposed to waiting for the programmers to create the engine from scratch or build on top of a framework such as MonoGame. Learning curves and licensing fees of the aforementioned engines also should be taken into consideration.

If you’re reading this book, chances are you wish to dive a bit lower level with a quick learning curve – this book should achieve that.

Game Types Best Suited for MonoGame

As mentioned previously, MonoGame is best suited for 2D games. With the revival of classics from the 1980s and 1990s in addition to a return to simple but fun games like Castle Crashers, this isn’t a hindrance, if anything a benefit as the framework is set up for these game types.

MonoGame can be used in a wide range of game types; the following are a few examples of types that work best. In addition, for each game type, the pros and cons in comparison to the other types will be reviewed. When planning a game, weighing all of the pros/cons of a particular type should be a major part of your development efforts. For your first game after completion of this book, choosing an easier to implement game type is strongly suggested.

Vertical Shooters

Popularized by Capcom’s 1942 and enhanced into the 1990s as graphics and gameplay advancements were made, vertical shooters can range from more science-fiction ala Major Stryker or more grounded like that of Raptor. As mentioned earlier in this chapter, for this book we will be building a vertical shooter from the ground up; a screenshot of the game from Chapter 4 is depicted in Figure 1-1.

There are some advantages and disadvantages to developing vertical shooters:

Pros

• Easy to dive into.

• Controls are basic.

• Graphics are easy to implement.

• Level generation and tooling is simple.

• AI is easy to implement.

Cons

• Tired genre

  • Need to generate some unique gameplay to differentiate from Raptor and other well-known vertical shooters.

Horizontal Shooters

Made popular by games like Einhander in the 1990s, similar to a vertical shooter, but affords more variety in the gameplay. A great MonoGame example of this is Pumpkin Games’ Paladin in Figure 1-2.

There are some advantages and disadvantages to developing horizontal shooters:

Pros

• Easy to dive into.

• Controls are basic.

• Level generation and tooling is simple.

• AI is easy to implement.

Cons

• Graphics fidelity in this genre is required to be high due to competition.

• Tired genre

  • Need to generate some unique gameplay to differentiate from other games.

Side Scrollers

Side scrollers are a genre that took off in the late 1980s and continues to this day, offering a wide range of adventure and action games from the horizontal perspective. MonoGame’s native support for sprites and hardware-accelerated 2D graphics have made this an easy choice to develop for.

Krome Studios’ Tasmanian Tiger 4 is a great example of fluid animation and fast action using MonoGame as shown in Figure 1-3.

There are some advantages and disadvantages to developing side scrollers:

Pros

• Diverse Gameplay is achievable.

Cons

• Graphics can be tricky to implement depending on the gameplay.

• AI can also be tricky depending on the gameplay.

• Tooling can also be cumbersome to develop for.

Role Playing

Made popular by the Final Fantasy series on Super Nintendo, the 2D isometric view has been used ever since for 2D role-playing games. A popular example of this game type with MonoGame is ConcernedApe’s Stardew Valley as shown in Figure 1-4.

Pros

• Diverse Gameplay is achievable.

• AI can be easy to implement (depending on the level of NPC interactions).

Cons

• Graphics handling of the tiles and sprites can be cumbersome.

• Tooling can also be cumbersome to develop for.

Puzzle

Puzzle games especially on mobile given the popularity of Angry Birds and Bejeweled among others in recent years coupled with MonoGame’s ease of use are a perfect fit. An example of this game type using MonoGame is Endi Milojkoski’s Raining Blobs as shown in Figure 1-5.

Pros

• Diverse Gameplay is achievable.

• Graphics can be easy to implement.

• AI can be easy to implement.

• Tooling can also be easy to implement.

Cons

• Achieving a unique and/or fun gameplay in the crowded market can be extremely challenging.

Strategy

Strategy games commonly range between turn-based, real-time, and strategy/role-playing game hybrids. While much more complex to design and implement, they can provide a unique experience for gamers. Reason Generator Inc’s Wayward Terran Frontier is a good example of utilizing MonoGame to its fullest in Figure 1-6.

Pros

• Diverse Gameplay is achievable.

Cons

• Graphics can be tricky to implement depending on the gameplay.

• AI can also be tricky depending on the gameplay.

• Tooling can also be cumbersome to develop for.

Organization of This Book

As stated at the start of this chapter, this book breaks down each of the topics into manageable and isolated chapters. The following is an overview of the book and the topics we will cover:

Chapter 2 details how to get your development environment setup from start to finish for the remainder of the book. By the end of the chapter, you will be able to run a blank MonoGame project. Both macOS and Windows setup will be covered in detail. Linux will be discussed, but not recommended going forward for the rest of the book.

Chapter 3 deep dives into the MonoGame architecture including going into detail about 2D graphics, the game timer, and input. This chapter should not be overlooked even if you have done game development in the past as it will offer a deep insight into how MonoGame’s architecture is set up.

Chapter 4 starts the deep dive into creating an architecture that we will be building off of for the remainder of the book. As with Chapter 3, this chapter should not be skipped as the objects, managers, and Game class changes will be described in detail.

Chapter 5 goes into detail of how the Asset pipeline works in MonoGame. In addition, integration with the ContentManager into the Game States will also be detailed. At the end of the chapter, we will render our first sprite.

Chapter 6 covers the handling of input with both a keyboard and mouse. In addition, platform-specific considerations will be reviewed to handle gamepad and touch screen input.

Chapter 7 goes into how to add audio to our architecture and add audio triggers to our event system. In addition, supporting background music layers will also be discussed.

Chapter 8 deep dives into how to integrate particles into our architecture to handle the bullet fire from both our player object and setup for future enemy objects.

Chapter 9 reviews various methods of collision detection used in games. For our project, we will use box collision and integrate it into our architecture to handle not only player object collisions but also projectile collisions.

Chapter 10 adds animations into our architecture and reviews approaches used throughout the industry. At the end of the chapter, animations of objects are added to the game.

Chapter 11 reviews the importance of level design and goes into detail of how to add level loading to our game engine.

Code Samples

Code samples starting with Chapter 3 will be referenced throughout each section. Outside of the code samples, there is also an Assets archive that contains all of the music, sound effects, sprites, and graphics used throughout the book.

Summary

In this chapter, you learned what MonoGame is exactly and the differences between MonoGame and game engines. In addition, you learned about game types that lend themselves to MonoGame and the book’s chapter structure.

Up next is setting up your development environment to begin your MonoGame development.