2014-12-30

Planning Aether3D Rewrite For 2015

In 2015 spring I'll rewrite my engine again.

It's that time again, the moment when I look at my engine, started in 2013, and an accumulated list of architecture improvements that are easier to put into a completely new engine instead of shoehorning them into the current engine. I know that rewriting is a thing you should never do, but I am quite satisfied with the current engine and can take many things into the new engine. Refactoring could get my current engine into the right direction, but some of the things I want are just too big for current architecture.

Rationale:

Static linkage/getting rid of virtual methods


My current engine's whole API is exposed as virtual methods, but I want to use them only where it really makes sense. Static linkage also makes configuration easier, not having to worry about DLL's location or format.

Singletons/global state


Current engine has some, but I want none.

Entity-Component System


I want to compose game objects by combining components like in Unity. Separation of Concerns FTW.

Memory labeling/profiling


I want to have a breakdown of memory used by a game, asset by asset. That means custom allocators, which will come handy because...

Minimizing dynamic allocation


I want to have a data-oriented cache-friendly design. When I create a texture, I want to get an index into a texture pool that was allocated on startup. I will analyze my main loop and minimize dynamic allocations. I will also check cache-misses.

API inside a namespace


My current engine's public API doesn't use namespaces, so collisions are possible. Not so in my next engine.

More const-correct design


While my current engine is mostly const-correct, more objects and state could be made immutable, making reasoning about program's behaviour easier.

Compute shaders aren't exposed


My current engine uses them internally for light culling, but I want to give the power to you, the user.

Post-Processing Effects can be pulled out


Separation of Concerns, baby. Unity has them as a separate package, I want to have them out of engine core, too.

AZDO


Maybe not full-on, but definitely something to strive for.

Updated Renderer APIs


Exact versions can vary, but I aim for OpenGL 4.5, GLES 3.1, D3D11.1 and Metal. Need to figure out something for OS X, maybe 4.1.

Editor


Many open-source engines have editors that contain basic usability problems that are easy to fix. I have been prototyping a custom scene editor using Qt 5 for several months and believe I can make an editor that's not painful to use. The editor will be in sync with the engine and support new features as soon as they are implemented. It is by no means necessary to use the editor, the engine works without it, too.

GitHub


The whole building of the new engine will happen on GitHub, right from the start. It gives the engine discoverability and easier management of issues/documentation/wiki etc.

Dogfooding

I want to have a real use-case for every feature I add to the engine. A simple game, a demo, whatever, just something real, released stuff.

Schedule


I will do research until GDC 2015 (March 2-6) and a few weeks after that I plan to make the first commit to GitHub.

2014-12-07

Software Development Terms

Here's a quick description of random software development terms. Most developers probably know them but someone could find something new.

Broken Windows Theory
If there is a low-quality part of a codebase, people maintaining the codebase tend to produce more low-quality code.

Technical Debt
Taking shortcuts by making intentionally suboptimal design or implementation decisions. Not always bad, not all debt have to be paid.

Dogfooding
Using your own unfinished product in day-to-day work while developing it.

Code Smell
Doing something that could lead to problems.

Heisenbug
A bug that doesn't repro when debugging.

Cargo-Cult
Applying a method that works in one context in a different context without knowing why it worked in the original context.