This is not a comprehensive list of what is needed for a game engine nor a final list. Some of these elements can be considered as placeholders until a final decision, although those decisions should be sooner than later. An example is physics -- the final version of the engine may use bullet or physx or a custom solution, but the basic placeholder should be just functional enough.
It should also be complete enough that those working on the game mechanic end of things can being prototyping using the engine.
For the sake of workflow each item should probably be split into individual issues on github's issue tracker.
I am assuming an entity-component-system architecture. One advantage is the ease of adding placeholder systems and components to have a functioning game environment while the final, well thought out systems and components are cooking.
- Base entity component system (ecs). -- This is the super general system of creating entities, registering components, the system controller, and the system class other systems will inherit
- Base render system. -- Non fixed function differed pipeline that can display simple mesh, texture, lights. Camera stays at 0,0,0 and world is transformed around camera (this will solve some scale issues later)
- Basic asset loading -- loading meshes, textures, and shaders from desired or placeholder format into internal desired placeholder format
- Basic math -- Vectors, matrixes, points
- Scene management -- I'm not sure what this should be. This is the limit of my experience with it.
- Basic client and server networking -- Client and server are able to send basic messages. Protobufs or similar can be used for now. (Small aside -- I've read cases of ecs systems that had a universal binary and code base for client and server. Launching as client, server, or both was just a matter of which systems are activated.)
- Basic audio support
- Lua script layer -- Should work with the ecs system so it doesn't matter if a system or component is written in c++ or lua
- Basic UI layer -- Implement berkelium or some other html/css ui system (lets take advantage of our web developers)
- Basic celestial modeling -- If a dynamic universe then basic modeling of planet motion and position
- Basic plugin system -- Some naive way to load external code in c++ or lua for rapid prototyping of ideas using the engine.
- Basic API -- There will need to be a lot of discussion about sandboxing for client security later. While APIs should be stable and thoughtful there is also danger in spending too much time planning it when it will probably change some down the road as the game coders use it.
- Basic Newtonian physics system -- Mostly as placeholder. Could use Bullet or some other premade solution just to get the ball rolling while the final physics system is being developed
- Basic collision detection -- Naive sphere based collisions is a decent placeholder. See above on using bullet.
- Basic voxels -- A basic voxel system. Maybe use a "dumb" visualization system such as blocks JUST for prototyping.
- Basic DCPU api -- An abstraction layer for creating, destroying, tracking, and checking dcpus.
Hopefully this would be enough to create a static ship players can walk around in a single or multiplayer context.