Diving Head-first into Engine Development

Back in high school I used to play with a little obscure engine named Sphere. It was this little RPG engine that was simple, yet also deceptively complex. 

It featured a full-fledged map system, sound, networking, file management. And at the same time it also gave you direct control over the rendering workflow. 

The only downside were it's performance, and the age of the JavaScript engine that it uses. You're stuck with SpiderMonkey 1.8.5, or JavaScript 1.5 which is almost alien compared to modern JS. 

Rather than developing games on it, aside from maybe 3d pong- I focused more on seeing just how far I could push it. I spent two years learning how to write a 3d rasterizer from scratch; from just drawing points which represent vertices of a cub, to generating entire voxel landscapes (albeit while taking eons to do so.) 

A Screenshot of Candle, my first graphics engine. This was taken during a lighting test where I was mapping colors to coordinates. This was all done on the CPU.

Now, I could use still use this; the code is available. But with it's age and the fact the fact it last received an update in 2008, it's probably time to move on. 

I could go on about the successors that have replaced this engine, and my failures in trying to move away from sphere to other engines, but I think I've rambled on long enough. 

So, I want to make a game; I have an idea that I think could work for once. But to make it work I think it's time I dive into engine development. To that end we'll be going with C. Not C++, or C#, but just plain-old C.

So, where do we start?

 The first thing any game needs is graphics, so we'll start with that. I've got a little test setup I've written for sphere, so we'll use that as our reference for implementation. 

Each step in development, will be marked by a milestone. 

1. Vertex rendering 
2. Render Surfaces (aka frame-buffers, we'll get to why we need this in the future) 
3. Wire-frames 
4. Image blitting 
5. Transform-blitting 
6. Audio 
7. Engine extensibility 

These are the goalposts I need to reach, and they're deceptively simple. I already have have the first goalpost met, and the matching JS-level API implemented. Even despite how inefficiently my demo is written, BoVinE is considerably faster than Sphere when we use the same JS code. The only differences between my implementation, and Sphere is that two drawcalls have to be called with the bovine engine prefix.

So performance. Sphere can manage to render a 5x5x5 voxel map, while BoVinE can manage 10x10x10 -- If I don't mind 5 FPS, then even 20x20x20 is feasible. 

Now, I know what you're thinking, performance sucks. And that's okay at this point. What matters right now is getting things to work first and then we can focus on performance. Well, almost. 

Duktape, the JavaScript engine I'm using at the moment, is slow. It's absolutely tiny (SO CUTE!), but it's slow. I mean, that's not unexpected, the engine is meant to be embedded in places where space and resources are constrained. It's not meant to maximize the performance of a giant gaming beast of a computer, it's meant to run almost anywhere. 

With how wildly different the difficulty curve can be between JavaScript engines, I need to make the switch now while the API methods are miniscule in number. If I put this off now, I'm looking at major headaches down the road; so I'll do it now while I know I can stomach the change.

 I think that's all I have for now, in the meantime I wish you all the best of luck out there, wherever you may be in life.