It's Not That Hard
Rather than thinking of an engine as the monolith that games need to function, it is better said to be 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 the internet oozes an elitist attitude about those who've developed an engine. What we pictured to be hard coming into the project was finding what system should be the first designed/implemented, figuring out where to start, 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 an 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 will leave you with questions.
Like any big problem, engine development can be deconstructed into manageable systems. For us, the process revolved around understanding some base engine vocabulary and a high level understanding of what functionality modules have, answering what features make an engine. 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 are you will be able to select a system and start working on one that is near the bottom; don't be afraid that you are missing systems because you probably are, you are probably are also including systems that aren't needed. Your diagram, much like our was, 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 you architecture is wrong or you aren't doing things right but there isn't a right answer, just compromises. This applies beyond just planning and architecture but to all decisions you make on your engine.
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. It is typically the latest thing because there are nuances to it and the professionals are 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 has said is, 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, the subsystems of the architecture are easily searchable. Systems like graphics, physics, file I/O, memory, etc. aren't just game engine topics, they are software topics which have tutorials, examples, and well-documented knowledge on. 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, however the implementation is something that can be iterated on. If your implementation isn't right (in either correctness, performance, memory) it can be fixed. The engine won't implode from a bad implementation.
The subsystems are the puzzle pieces and the integration of the engine is like the picture of the completed puzzle. It takes some work to find a certain piece of the puzzle, but is doable; however without the picture it is difficult to assemble the puzzle at all.