It's Not That Hard

This may look like a daunting stack, but all you need to do is handle it one layer at a time

Rather than thinking of an engine as the monolith that games need in order to function, it is better thought of as a collection of small, achievable subsystems. The reason we find the need to state this is twofold: 1) starting this project, each programmer was intimidated by the prospect of developing a game engine and 2) while doing research for the project, the internet oozedan elitist attitude about those who've developed an engine. What we imagined being hard coming into the project was finding what system should be implemented first, and beyond that was figuring out how to develop and integrate each subsystem. The reason for our fear came from trying to learn about engine development in the past, which was to Google "how to develop a game engine" This isn't what you want to Google. As we've stated throughout our project, there are relatively few resources that speak of the engine development process and as a whole (isetta.io can be added to that list now!). Searching engine development just won't get you that far and often leaves you with more questions.

Like any big problem, game engine development can be deconstructed into manageable subsections. For us, the process revolved around understanding some base engine vocabulary and getting a high level understanding of what functionality our modules need to have, answering what features make an engine for us. From there, we were able to deconstruct a game into mechanics, mechanics into a list of engine features, and engine features into dependency chart. By having a sense of what your dependencies were, you should be able to select a system and start working on one that is near the bottom; don't be afraid about missing systems because you probably are, and you're probably also including systems that aren't needed. Your diagram, much like ours, will be wrong, and you will have to iterate on it as you develop. What we want you to know, and wish someone told us, was that you may feel your architecture is wrong or you aren't doing things right but there is almost never a right answer, just compromises. This applies beyond just planning and architecture to all decisions you make on your engine.

Sometimes they just won't look right, so you gotta toss it and try again

Researching engine development can still prove to be useful as you will get a sense of the vocabulary typically used with engines. Most of this vocabulary revolves around the programming and design patterns used in engines, as well as the different paradigms, like data-oriented vs. object-oriented. While it is certainly useful to understand this terminology, trying to implement the latest craze in engine development can be intimidating and frankly a bad idea. It's usually the latest thing because there are incredible nuances to it, and the industry is still working to understand it better. For us, sticking with something that was tried and true, as well as what we were more familiar and comfortable with, proved to be a better idea for our first engine. Something one of faculty members told us was, "you have a limited amount of innovation 'points' on a project; don't spend time trying to innovate on every aspect of a project, that will lead to overscoping."

While game engines aren't a searchable subject, its subsystems certainly are. Systems like graphics and rendering, physics simulation, file I/O, memory management, etc., aren't just game engine topics, they're software topics which have tutorials, examples, and well-documented knowledge. As one of our faculty members put it, "intelligent people have already captured the tech details of game engines and made them accessible for novices." Solving subsystems isn't a difficult process; it may take time to learn, but the implementation is something that can be iterated on. If your implementation isn't right (in either correctness, runtime performance, or memory performance), it can be fixed. The engine won't implode from a bad implementation.