Introducing ng engine

Published on 2018-03-11.

ng is the engine I’m building to support my OGAM development efforts in 2018. The name “ng” is a working title and has little personal significance. There’s a major advantage to short names when using them in code, especially when using C.

I wrote about my decision to write my own engine here. There are many build vs. reuse arguments; I didn’t make that kind of evaluation this time.

My personal goals for the project are to achieve proficiency in the following areas:

• 2D and 3D graphics engine architecture.

• Mathematics for 2D and 3D graphics.

• User interface architecture.

• SDL and OpenGL APIs.

My technical goals for the project are as follows:

• Absolute control. The program designer will be in complete control of the event loop. The programmer will use ng, rather than ng using the programmer’s code.

• Excellent tooling, with a strong focus on debug facilities and tools to solve problems and protect against regressions as they arise.

• Top-notch Python scripting support. Since ng is currently being written in pure Python, this is a given.

Notably absent from the list:

• General purpose feature completeness. This is a toy and educational project with a scope as such. To say a “feature” is done in this project does not require “feature completeness”.

• Absolute performance. There are no absolute performance requirements. Performance issues will be addressed if and when they surface in use.

So far, specific feature requirements have been unplanned and driven by need of OGAM requirements. Since I have OGAM features planned through the end of April, I could conceivably create a two-month roadmap, and might do that in a future post.

See you in a few days, when we’ll examine weekly progress on both ng and the OGAM March 2018 entry.