Best approach to learning Monogame?

Hello, this is my first post on the forum but I have been a reader for a bit. I am, or have been beginning the process of learning Mongame. I am an experienced programmer which is why I decided on Monogame over something like Unity. Anyways, I don’t want to bore you.

I have at multiple times in the past started some game development. Where I personally always got hung up is the with the artwork. I done a little bit of pixel art with Aseprite but let’s be real, I am a programmer, I am not an artist. I’ve been caught in an endless cycle of…

  1. Start game development.
  2. Focus on artwork.
  3. Lose focus of game development after frustration with said artwork.
  4. See step 1.

So my question to the forum is this. How do you personally go about prototyping a game? What I am really into is making the engine. I am at the stage now where I am just moving shapes like a square or a circle around the screen and treating that as my “sprite” if you will. If I get to a point where the underlying game logic is behaving correctly I can at that point in time add some artwork. Is this a backwards way of thinking? A concern I have is while I am moving a square around the screen, it is not doing it in the same way it would move an animation around a screen.

Any thoughts or suggestions on what some other people new to Monogame, but not necessarily a development process would take? Shapes or sprites?

I feel like my past experiences are exactly as you have described yours. I come up with some fun idea and get really excited about programming the engine or the AI, but then I come face to face with the artwork, menus, etc. and just lose interest.

I think starting with the logic and worrying about the artwork later is a fine approach, and that’s the one I’m taking now. I created a few decals of different types and exported a single model from blender to make sure my rendering pipeline works correctly, but I have and plenty of code to generate levels and to send spells flying, while my player just runs around as a lamppost.

But I guess to answer your question, I would recommend creating one piece of artwork, however crude and simple, in the format that you expect your final artwork to be, just so that you know from the start that the entire process works.

1 Like

I wouldn’t worry to much about artwork first, Just look at roblox and minecraft.

Even the skybox looks like it was just tossed in and guy was like eh oh seams… ah thats good :smiley:.
I have no idea how retro graphics got so popular but the kids love it.

1 Like

Alright…be warned…this is my super long essay on how to approach a gamedev project, large or small. It comes from my experience playing games, following development of games…and…well…coding one. I’ll have a far-less-long-winded TL;DR at the end, don’t worry.

The super-long-winded essay that took me almost an hour to write

Typically you want to come up with a base foundation and idea for your game. What are the rules? How hard do you want the game be for an average player? Will there be a story? (don’t write the story at this stage, just decide whether you want one or not.) etc. Once you get the base idea, write it down. Write all the ideas you have for the game down…no matter what they are. At this point you’re basically writing a game design document. This is where you start to define exactly how the game will work…how it’s played, etc. Then you have something to refer to when you want to add new features down the line. (So you don’t start accidentally losing focus on what your game’s all about).

Once you’re near satisfied with all your ideas, share the doc around with friends. Get feedback from them and adjust based on their feedback. At this point you do NOT want to let negative criticism get to you personally (I’ve fallen into that trap. Not fun.), because negative feedback will help make your game better for more players.

Decide based on the feedback you get what features should stay, what needs adjustment, and what needs removal. For example, if you’re making a first-person shooter and you decide wall running is a good idea and everyone else says that’ll completely break the game…you probably wanna think twice about adding it. (Heh, that’s a nice Call of Duty burn right there.)

After that stage, it’s time to start coding. Do not focus on artwork. Focus on functionality. It doesn’t matter if your buildings are simple cubes/rectangular prism meshes. It doesn’t matter if all your UI text is in Microsoft Sans Serif or Comic Sans. Just make your game playable. This is what a tech demo or prototype is. Doesn’t exactly look good, but it shows off the core gameplay. That’s what you want. It’s a lot easier to approach when you just focus on core gameplay. At this stage it is okay to use low-poly meshes, ugly textures, royalty free music/SFX, etc. These are temporary assets and you’re just using them to convey certain things to the player. If they know it’s an early prototype, temp assets won’t be a point of criticism.

Send that prototype out to a group of people for testing. (Hell, go ahead and slap it on as a prototype and slap that link in Showcase on here so we can all try it out :P). Much like the original idea for your game, you want to get feedback on this prototype build. Is it playable? Is it too hard? Are things unfair? etc. Take this feedback into consideration and adjust and refine your game as necessary. Then, you can release this new prototype build and repeat the process until you stop getting negative feedback and people start to really like playing your game.

This is what I’m doing with Peacenet Weekly Releases. Weekly protptype builds with early demos of different gameplay mechanics and each build improves on the last one based on feedback from here and on our own Community Site.

Once you’ve finished refining your prototype builds, now you can start focus on things like artwork, the storyline, etc. Start replacing your temp assets with better, higher-quality ones. But, do note, this is the Alpha development stage. It’s okay if things are still crusty around the edges. The Alpha stage is when your final game really starts to take shape. Look at Minecraft for example. Its early prototypes started out with Notch’s core ideas being implemented - being able to build, being able to destroy. Alpha was when a lot of the rest of the gameplay was implemented, world generation was refined, etc.

Just keep on collecting feedback on your alpha builds and refining them as well. You’ll want to keep doing this for every development stage.

Then once you’re satisfied, move to beta. This is where you start to really worry about your artwork and fixing as many issues with your game as possible. Most of your gameplay mechanics are in by now, you want to focus on patching things up as much as possible. The more stable your beta builds get, the closer you get to RC. Though, if players really want a new feature, this is still the perfect time to add it - because it’s okay if it’s a little buggy at the start. Later builds will fix it up. Beta is also a good time to start thinking about advertising and marketing your game to get as many players as possible.

Once you get to RC, kick it into high gear with patching, bugfixing, performance optimization, etc. RC stands for “Release Candidate”, effectively meaning “This build could very well become the final release.” So every single RC build needs to feel more and more like the final release.

Once you’ve exhausted basically all the issues on your bug tracker, you’ve got a final release. Celebrate with fanfare…because you just saw all your hard work come to fruition.

You have two choices at this stage… you can either start iteratively improving your game until you’re out of ideas and keep your game active as long as possible, or you can sit back, relax, get another idea for a game, and start this entire process all over again until you’ve released two awesome games.


  1. Come up with the base idea.
  2. Write it down.
  3. Write all your ideas down.
  4. Get feedback on your ideas.
  5. Refine your ideas based on feedback.
  6. Go back to step 4 until you’re satisfied.
  7. Code up a prototype.
  8. Release said prototype, get feedback, refine it
  9. Repeat step 7 and 8 until satisfied.
  10. Now do it for the alpha stage, while improving your artwork, storyline, etc
  11. Now do it for beta, while getting as many people on board as possible.
  12. Now start hammering down on those pesky bugs and performance issues for your RC builds.
  13. You’ve just released a full game.
  14. Go back to step 1 if you come up with another idea for a game. Or keep improving your current one. Or do both! :slight_smile:

I always find myself going through cycles… I am energetic and code like crazy… and burn myself out. During that recovery period, I do artwork. I get sick of making artwork and want to code again… repeat. As a software engineer, I program all day at work and sometimes the last thing I want to do is come home and do more programming, that is another period were I shift to making art. I’ve also found that game art evolves as the game dev goes on, so don’t waste all your time perfecting it from the beginning.

When I don’t have sprites ready, I just use blocks, circles or something like that.

Reminds me of the lead developer of a previous project I worked on. He worked as an early childhood educator by day and a programmer by night. Actually he made a video when he handed the project over to us. The video went over the last features in the game he worked on, then explained that he was hand-picking new devs to take over based on a contest. Toward the end he explained how his usual daily routine was always “Wake up, eat, code the game, work as an ECE, come home, code the game, sleep, repeat the next day”. This lead to him stepping down and never programming ever again.

That is an example of why you should always take breaks when you start to feel burned out.

Fun fact: This game became open-source a few months later, then all the devs lost interest (except me) and left, then I took over for a few years as lead, built a new team along the way, stopped development of the game due to even me losing interest in it, then I took the code and ported it to MonoGame and it then became what it is today - The Peacenet. And the team became what we’re known as now, Watercolor Games. So, I guess something came out of him getting burned out? I still talk to him every now and then today and we keep up on each others’ projects. We’re good friends :stuck_out_tongue:

Hey thanks for the response and dedicating an hour (maybe more) to doing so ;). I have yet to do something as formal as writing a game doc as I am still learning the ins and outs of monogame. Once I settle on an idea I believe I will put some of your suggestions to practice as I know for experience, it’s easy for a software project to spiral out of control if you don’t have a clear vision documented somewhere along the way. My end goal is a top down 2d game, something like Stardew Valley / Zelda. Hopefully I don’t get burnt out on it and can get something to a point where I can come back and show some progress to the community.

This is a problem that I have encountered in multiple projects I have started outside of work, not only game development. I spend all day developing or programming, the last thing I want to do when I get home is do it some more… for free. I figure if I pick away at it for an hour or two a day for awhile that I will get comfortable enough with the framework that I can eventually sit down for 4 or 5 hours a day and actually make some real progress on it. For now the responses I have gotten have inspired me to stick with blocks and circles, at least until I am comfortable enough with Monogame and game development in general.

There is a lot to learn for someone new to game development. Learning about how animation works. Frames. Vectors (thought school was the last time I’d bump into programming Vectors). The list goes on and on of things that even though I am an experienced programmer… I have never bumped into until I started looking into making a game.

Short answer SpriteBatch make stuff move draw stuff.

After you had a little fun and start to get comfortable.

Start off with a bunch of very small how to’s.
Not for others but for you as a reference make them small put em in a folder.

If you feel like you don’t know were to go from were you are.

Then goto reading.
Googling the fundamental keywords will lead you to a endless chain of information.

Timing and latentcy.
Vector math matrix maths
Scrolling Velocity and Position Vector Normalization.
Orientation matrices, world view projection, scale,
Monogames Matrix methods and how they are used for the above.
CreateWorld CreateLookAt SpriteBatch.
In 2 or 3 dimensions, Rotations vs Orientations in 2 or 3 dimensions.
The 2d and 3d spaces, model world view clip screen…
Vertices Triangles Indices Models
Texture’s vs images how the gpu interacts with the cpu.
Pixel shaders. 2d and or 3d
Rasterization.MipMapping Antialiasing Multisampling TextureFiltering.
Monogames BasicEffect, Lighting Ambient Diffuse Specular.
Custom effects z buffering homogenous coordinates.
There are tons of well known and commonly termed effects that help to do things.
You will see many post about them they are all related to pixel shaders ect.

The list can go on for technical stuff.
Then there is all the other stuff.
I think there is information overload now days.

Id say pick what sounds interesting to you pick a simple thing.

Look it up and try to apply it,
You will end up looking up the other stuff to go with it as you go.
One step at a time.

1 Like