Keeping the engine design as simple as possible allows rapid experimentation, which is the key to future proof technology. We will identify a few key areas where complex designs are necessary for maximum performance. In all other areas we will go for the simplest design possible. This includes:
We will document our design decisions publicly, post news about the development and encourage others to participate. If people know about, discuss and copy our techniques, that will add value to, rather than detract value from our engine.
Run time data will be kept in flat, simple data structures. We will avoid complex object hierarchies, subclassing and virtual calls. Such tools may simplify the design in the short run, but in the long run we believe them to be counter productive. They belong in the high-level interfacing part of the engine, not in the low-level data structures.
When operating only with (nearly) raw data, it is easy to repack it for maximum efficiency, and to create efficient algorithms that operate on it. This optimizes memory performance (which is often the bottleneck in modern CPUs). It also allows quick DMA-transfers to co-processors, GPUs, etc to parallelize the processing.
Multi-core systems are the future. All bulk workloads in the engine should be run through a job system which provides data parallelism for an arbitrary number of CPU cores or co-processors (i.e. SPU). Data will be laid out and algorithms designed so that pointer chasing and job interdependencies are kept to a minimum.
To create great games you need a work flow that allows you to iterate fast over the content. Content, in our mind, is everything from the low-level configuration of the engine (rendering layers, post-processors, memory layout, etc) to high-level art assets, such as textures. The engine will be completely configurable through data files, and support hot-reloading of content as far as possible.
