So I'm trying to create my first game engine for learning purposes. After looking up a few articles I was able to design the beginning portions of my engine to at least get me going. My design so far involves have my own "Framework" layer for which all other, higher level subsystems (graphics, input, audio, etc.) will use. This will help with code portability as well as give me the ability to change my underlying implementation code without having to change my entire code base (only my framework code). This structure has provided enough of a mental framework to get me going. However, after coding a few things and getting a triangle up on screen and moving via keyboard input I'm finding it difficult to decide how to structure my different subsystems (graphics, input, audio, etc.) further. I want to have a design in place to allow for communication between subsystems with as little coupling between systems as possible.


My main issue is that I'm finding it difficult to architect my engine further since I don't really know where I need to go next. I would imagine this is a typical issue for any developer who is developing something new or unfamiliar. For example, I don't really know what kinds of functions I'm going to need or who will use those functions for my graphics system. Will individual objects be responsible for drawing themselves? Does the Window handle drawing graphics? With previous experience, I would have a better idea of these things and I could design my software accordingly but at this point I have none.

My Question:

My question is what are some thought processes or development practices that help you try and architect code for which you are unsure of where you need to go next? I understand this can be a big topic so I'm just looking more for quick tips to get me thinking about different possible techniques. I already have a few ideas below but wanted to get more thoughts from the community as well.

My Thoughts on Some Possible Solutions:

  1. Draw some diagrams to get an idea of how things will hash out: After coming up with a design idea draw a few class diagrams with their interactions mapped out. These diagrams could help you spot possible limitations in your design idea quickly and without any code. However, you might need to create a lot of diagrams before limitations with you idea become apparent

  2. Just begin experimenting with your idea in your code: With a versioning system you can just branch your code base and start experimenting with your idea. This will help give you immediate feedback with the limitations in your design as any code duplication or compilation issues will be immediately apparent after implementing. However, this will require more time and can be harder to see the bigger picture and ramifications of your design approach.

  3. Fallback to established design patterns: Just figure out the main problems your system needs to solve and apply a corresponding design pattern to fix it. There are plenty of tried and tested design patterns that have helped solve issues for decades. You can just default to these patterns when you don't really know where to go and have them drive your design forward. Issues here are that there are so many different patterns out there for different problems that it can be hard to decide exactly which one will best solve your problem. Also, defaulting to a design pattern could drive your system architecture in a direction you don't particular want to go, but won't notice it until later on in the process.

  4. Any other thoughts??????

  • How much working code have you written? Dec 29, 2016 at 1:53
  • Not a whole lot. I'd say about 500-600 lines or so. I feel this makes it more important that I have some solid plan in place since I'm creating the foundation code for the rest of my engine.
    – Jason
    Dec 29, 2016 at 2:01

1 Answer 1


You don't architect your "framework".

You can use many different techniques to determine what it is you want your game to do. Then you just start doing it. As you go along you make decisions on if a method (or unit of logic) belongs in the framework or not.

For example, you shouldn't be trying to figure out save file formats, until you actually have a save function. Then you can look at your datatypes and see what you have. Do you just need to store strings, then a text file with strings in it may work. Are you trying to store binary data, then some kind of marshaling/encoding library should be used.

Leave the class diagrams and UML planning to small segments if at all. You don't need to re-invent the wheel. Every language that I can think of has some kind of "save this blob of data to the hard disk".

Point is, your at the start of your game. You know you want it to be full screen. So write the methods that open a window in full screen mode. Then you know you want to display a intro video. So write some methods to display an intro video. Next you want a "start screen", so write some methods to display a start screen.

Then pause. take a look at what you wrote. Are there some classes that could be cleaned up. Are there some methods that could be refactored. Ok, refactor away.

Next, you know you want the menu to go "bloop" when you go to the next option so write the bloop code. Don't worry to much about rather "bloop" needs to use your "framework's" sound method. Just make the thing go bloop. Later, refactor, and notice that "bloop" and "swoosh" are very close, and they could be merged into a makeSound method.

Finally, don't be afraid to use libraries. For example, go ahead and use blink video player for your intro video. It beats having to write it all from scratch. Take a look a Unity or similar offerings.

If your trying to make the next Unity, then build a game, and extract your engine from it.

  • 4
    +1: Spot on. Developers that try to write frameworks to support future features end up with a bad framework and no features. Write features in whatever the mood strikes you. Refactor aggressively to keep it DRY, and never ever ever create a circular dependency. The framework you are dreaming of will almost magically fall out of the bottom of your call chains. Dec 29, 2016 at 2:28
  • Thank you very much for this answer. It really resonated with how I want to write software (I guess sometimes people just need external validation for their ideas to make sure they're not crazy lol). I guess I was just worried that not planning too far ahead into the future would result in a large, buggy mess.
    – Jason
    Dec 29, 2016 at 2:38
  • 4
    +1. Someone ones told me, before writing resuable software, one should write useable software first. Before writing a game engine, one should write one - no, several - games first.
    – Doc Brown
    Dec 29, 2016 at 6:40
  • Very well put. I guess we all try and find any shortcuts we can to create things as quickly as we can. In the case of software, I guess nothing can really beat experience
    – Jason
    Dec 29, 2016 at 14:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.