Make your first game now with .NET and MonoGame
TL;DR
MonoGame is still a serious path for .NET game development — Chris Gomez frames it as XNA’s true spiritual successor, with the same Microsoft.Xna namespaces and a track record that includes Bastion and Stardew Valley.
You can get from
dotnet newto a running game in minutes — Chris uses themgdesktopgltemplate, runsdotnet run, and gets the classic XNA-style cornflower blue starter window before adding a clown sprite and drawing it at(100,100).The heart of the demo is the classic game loop: initialize, load content, update, draw — Chris explains MonoGame’s four key methods and uses them to load textures, apply gravity, update velocity with frame-time, and render 2D sprites at 30–60 FPS.
MonoGame’s content pipeline does a lot of heavy lifting without hiding the code-first experience — in VS Code, the MonoGame extension lets him import PNGs, WAVs, and sprite fonts, then build assets through the content editor while still keeping everything close to plain C#.
A simple physics toy becomes a game once collision and feedback show up — the clown first just falls, then bounces off the floor, later collides with a trampoline using rectangle intersection and trig-based bounce angles, and finally gets sound effects, scoring, balloons, and animation.
Chris’s pitch is really about approachability for C# developers — compared with Unity or Godot, he argues MonoGame keeps you in a familiar code-first environment, making it a gentler first step into game dev while still supporting 3D, shaders, and cross-platform targets like Windows, Linux, Mac, iOS, and Android.
The Breakdown
XNA nostalgia, and why MonoGame matters now
Chris Gomez opens with a full-circle story: 11-time MVP, got his start teaching line-of-business developers with XNA, and now he’s back showing modern .NET devs how to make games. He explains MonoGame as the “spiritual successor” to XNA — not just inspired by it, but intentionally namespace-compatible — and grounds that with real examples like Bastion and Stardew Valley.
From templates to cornflower blue in one command
He quickly moves from history to action: install MonoGame templates, use dotnet new mgdesktopgl, and run the project. The payoff is the instantly recognizable cornflower blue startup screen, which he jokes is sacred XNA lore, and it sets the tone: this is meant to feel friendly, fast, and familiar to C# developers.
The four methods that make a game
Inside Game1, Chris gives the essential mental model: constructor aside, game dev starts with Initialize, LoadContent, Update, and Draw. He explains the loop in plain terms — update the world, draw the world, repeat — and lands the point that this is just code, not magic, which is exactly why MonoGame is approachable.
First sprite on screen, with a quick detour into content importers
Using the VS Code MonoGame extension, he imports a clown PNG through the content editor and loads it with Content.Load<Texture2D>("clown"). There’s a nice side conversation here: Stacy asks whether custom importers could enforce texture best practices like power-of-two sizing, and Chris doesn’t bluff — he says he’s not sure about exception behavior, but loves the idea and points people back to the docs.
Gravity, debugging, and the classic “why isn’t it moving?” moment
The clown appears, then Chris adds position and velocity vectors, applies gravity, and wires movement into Update using elapsed game time for frame-rate independence. He hits a totally human snag — the clown doesn’t fall because he forgot to use the updated position in Draw — catches it live, fixes it, and then shows VS Code debugging with breakpoints and variable inspection.
Why MonoGame over Unity or Godot for a first game
Frank and Stacy push on the bigger question: why start here? Chris’s answer is clear: Unity and Godot are great, but MonoGame lets .NET developers stay in a code-first environment instead of also learning scenes, editors, and engine conventions on day one. He also makes sure not to undersell it — MonoGame supports 2D, 3D, shaders, and cross-platform shipping.
Turning a falling clown into a toy that plays itself
The demo gets much more fun once he adds a homemade Sprite class, viewport size checks, floor bouncing, an 800x600 window, and eventually a trampoline sprite. Then comes input via keyboard and gamepad APIs, rectangle-based collision, and a trig formula that makes the bounce angle steeper near the edges and straighter near the center — suddenly it feels like Circus Atari by way of reverse Breakout.
Sound, animation, scoring, and the finished Circus Pop build
In the final stretch, Chris adds a WAV bounce sound, shows how sprite fonts work through a simple XML description, and reveals the fuller game: balloons to pop, score rendering, light animation on the clown and background, and optional music through MediaPlayer. His closing line is the real thesis of the episode: if you’re already a C# developer, you’re closer to being a game developer than you think.