Practices for navigating uncertainty in software design

Question

Background:

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.

Issue:

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??????

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.