One thing that a lot of "hobby engines" ignore is the toolchain / the real-world workflows of each individual user.
An engine needs to be user-friendly for all of it's clients, which includes:
* gameplay programmers
^ most hobby engines focus on this area
* AI programmers
* animation programmers
* graphics programmers
* network programmers
^ most hobby engines hard-code some solutions to these areas, instead of making flexible/extensible systems.
* level designers
^ most hobby engines have a terrible tool for this.
* 3D artists
* texture artists
* lighting artists
* UI artists
* effects artists
* animators
* musicians/composers
* sound engineers
^ most hobby engines completely ignore these clients!
The "hard part" is knowing how all of these people will be doing their jobs, and creating a workflow that keeps them happy and fits well with your engine.
Building the engine first often results in shitty workflows
-- Undetstand the toolchain first, then build and engine to match.
I personally wouldn't think of that being fully true. Most hobby engines are probably just about the same level as an indie project with an inhouse engine. You probably don't have a large enough team to build custom tools for all of that. So you typically build for what you know is the most likely.
Currently... I have a few plans.
A. TCP connect Blender to the game engine. Probably going to be a pain to do. Maybe not. If not, then life is good.
B. Separate tool chain. Reuse as much as possible. Level editor may use Sony's ASF if the documentation is a little better. Or may do it from scratch. Animations, and Models are custom fitted for the engine, and a plugin has been made for blender. Engine only uses Ogg and Thea for sound and video. Everything else? Formats already exist. Tools can be what ever you want.
Right now... I think the hardest part is trying to find a game framework system that works. My goal was to make it where entities can be split into tasks so they can be updated asynchronously with a scripting language. And allow it to be easily modified.
I thought about using an entity component system. But I quickly threw it out when I realized how limiting it actually was. And also setup is more tedious than people give it credit.
Adding new systems means you need to make some way to update it in the game. A number of systems will be created with only one or two things actually using it. It's not a one thing tackles all system.
I eventually decided to trade for GameObject-Component. With a specialty object for Level scripts. When the gameobject is created, it takes from a predefined archetype from file, creates it and registers what needs to be updated every pass. And what waits for event callbacks. It works great! Now came to finding a way to thread it!
I've thrown out code for this so often, and have a spiral filled with plans of attack. I origionally wanted as much of the engine in lua as possible. But then I realized that depending on the complexity of the game you are designing, it won't work well. Not to mention full Lua makes threading ridiculously difficult.
So... I threw out about 5,000 lines of code in one instance, another 1400 in another.
Now I'm looking into other options. Such as spawn a thread with a lua state attached to it, and treat Lua as script only. Swap to Angel Script. Etc.
I don't really have the resources, or the know how to do what big-daddy engines can do. I read through some of their code for ideas. But some of the sheer complexity makes it difficult to map out exactly what they are doing.
It's grown so frustrating, that I just might game logic single threaded.
Rendering. Resource Loading. Audio? All easy compare to the framework.