Best practices for starting a project

Hello all,

I’ve been messing around with monogame for a while now, and I’ve decided to start my first big project in it. However, I can’t figure out how to start. I want to make a ‘game engine’ first, which I can reuse in all future games i make. It would essentially just lay out the architecture, physics, animations etc and manage everything low level so that making a game on top of it would be easier. I’ve found that it is incredibly daunting for a beginner to start a project since every idea i’ve had has faced some serious backlash on some forum post somewhere, with someone saying how it is terrible and you shouldn’t do it. So, I just need someone to describe to me an architecture and project layout that just works, without telling me what not to do.

Initially, i wanted to use the built in GameComponent classes and interfaces, but there is a massive debate on this and it seems that the general consensus is that you shouldn’t use these. This is just one example of how a beginner can get easily confused with starting a project.

Note: Please don’t answer with something like ‘Personal Preference’, as I am not experienced enough to have any preference, I just need something that works and doesn’t suck that I can learn with, and then perhaps once i am more experienced i can tailor this to my preference.

Thanks everyone

Like you said, you don’t yet have enough experience. My advice is to join some game jams and create monolithic code bases. For new projects you can reuse some code by copying it over. Over time you’ll learn what code is useful in many projects and you can extract that into your engine code.

This is what I have done with my own projects. It all starts being part of my big codebase. Here are some of my libraries that I’d consider my engine code. They allow me to create new games pretty fast.

4 Likes

Hey,

Are you experienced in programming? It makes a whole world of difference whether you are already an experienced developer in any domain just transitioning to game development, or you’re also want to learn programming through this project. If the latter, then I’d say don’t do it, writing your own game engine to learn programming is a very bad way, try with small projects like Tetris or breakout clones for coding practice, but even those will probably not give you enough experience to succeed. But if you already know programming very well, then your plan could be a logical next step, if you’re dedicated enough. You didn’t specify if you’re working in 2D or 3D, but I’ll try to share my experiences.
Like with any other thing, there is no silver bullet for game development either, but there are things that most games share, like collision detection, scenes, physics, etc.
Don’t start to implement the engine, you’ll most probably fail. Start implementing a game, similar to what you’d like to develop and write your engine through that. Once you’ve achieved a small bit of behavior successfully, think about how you can generalize that code and extract it for reuse, into the engine (as a superclass, utility, component, or any other thing). You will probably need to move your object on the screen, right? Write the piece of code that moves your object around, then extract it as a component or superclass, or whatever, and reuse it for other objects. You’ll need to collisions, right? Write a collision detector to detect collisions between 2 specific objects on your screen, even by directly referencing each other. If it works, again, think about how you could generalize it to apply to any number of objects. Same with textures: try to apply texture one test object, then extract the piece, etc. This could give a nice, organic way to develop your engine while constantly feeling successful by seeing your work improving. Eventually, as you develop your game and engine, you’ll realize that some decisions you have made weren’t so great, so you’ll have refactor, you’ll also probably notice that whatever worked on a small scale is very slow on a large scale (for lots of objects, etc), you’ll optimize and refactor again. Don’t be afraid of this, your first implementation will probably not be greatest for everything, but that’s how you learn and improve.
I know you don’t want “Personal Preference”, but there is no blueprint of developing an engine, no one will be able to give you a step-by-step guide to develop what you need. What you can find, however, are an insane amount of samples, demos, tutorials, full game’s with source code, and everything else you need for your yourney. Check how other people have implemented what you need, incorporate it into your game, then extract it to your engine.
I have some materials about the topic.

Project setup for cross-platform development for MonoGame, this give a short intro of how you can separate the engine from the actual game project:

This was my bachelor’s thesis on 2D game engine development:

And here is my open source, basic, immature 2D engine with source code and a sample platformer game. This has changed quite a lot since I wrote my thesis, but the basics are mostly the same:

There are definitely better and more mature engines out there that you can use as example (https://github.com/Martenfur/Monofoxe, Monogame Extended, etc.) so mine is just one sample.
Go your own way, make your own mistakes, and if you’re stuck, ask the community.

Good luck!

1 Like

Wow, this is brilliant!

Developing an engine in tandem with a project is a brilliant idea. In terms of programming experience, I am pretty experienced in c# at this point, but inexperienced in terms of Monogame.
Thanks for a great response

1 Like

Happy to help, let us know how it goes!

@Lajbert Thank you for the great answer! Just wondering when to use Shared Project (as far as I understand it is included (as source) to each project and therefore allows use of #compiler_preprocessor_directives) VS .Net Standard Library (that is individually compiled (I’m guessing as a dll but I’m more of a C/C++ developer so im not sure) and therefore cant use #defines_os_specifics since it is compiled separately).

I’ve been using this: Sharing Code Overview - Xamarin | Microsoft Learn as a reference but I see you used both (one for engine code and one for game (platform-neutral) code) is platform neutral code better as a library?

Hey!

Unfortunately, I decided that I have to move away from MonoGame (at least temporarily), but I’ll try to answer. It’s been a while since I made that decision about my design, but if I recall correctly, the reason was that you can’t embed multiple NetStandard libraries into each other. If you only have 2 projects (engine + game code), then it’s simple, but if I remember correctly, you can’t have multiple nested NetStandard libraries. I had 3 levels of nesting:
Engine → Game Logic → Platform-specific code
Therefore I’ve decided to use both SharedProject and Netstandard, so I can nest 3 levels of code into my project.
Yes, there is definitely a drawback of shared library, you can’t use #macros, which is not very convenient, but you can use public static boolean fields to replace macros with if statements in your shared project. This may not be the most elegant thing ever, but it works, and allowed me to use the project structure I’ve sketched up.

Good luck!