PGD Home

P-155 “Phoenix” Engine Concept/Feasibility Study

by on Jan.07, 2015, under Concepts, On Game Development, Software and Games

I have been considering the pros and cons of creating my own games engine for some time now. Obviously, this is a massive undertaking. Creating a games engine from scratch would involve writing custom modules to handle rendering, physics, object and mesh importing, animation, sound, networking, lighting, shading, texturing, and a whole host of other features.

Creating an engine, along with creating an MMO game, are probably the two areas where developers fail most often when embarking on a new project. It is the reason I have never tried to create a complete 3d engine before now.

However, in recent years my work has become more complex and more specialised, and I have moved more into simulations and virtual worlds, and away from traditional games.
This has meant that traditional engines, such as my much loved T3D engine, have been not entirely suited to the tasks I have been asking them to perform.

One major problem that I have come across on several occasions, and which I mentioned in a recent post, is the fact that T3D, along with the vast majority of conventional games engines, uses 32-bit floats to store position information. This gives a limit of about 10,000 units of precision, after which “jittering” starts to occur, which is where imperfections in the math used to control the objects position cause the objects to appear to shake as they move.

Assuming 1 unit is 1 meter, that means the player can only travel 10,000 meters in any direction before encountering precision issues.
For the vast majority of games, this is more than enough room, however for driving games, flight sims, open world games, and especially, space games, this is not even close to enough. 64-bit floats would allow an area approximately the size of the solar system to be traversed without issue, which is much more reasonable for game with large worlds.

However, even 64-bit floats would prevent a true virtual universe. For that, you would need even bigger numbers. In C++, a “Big Number” library would be needed, since 64-bits is the largest number that can be represented as standard. This would be a major decision, since these transforms would be used everywhere, every time an object is placed or moved, every time a shot is fired, and the larger the number, the slower the game will run (Hence the reason why 32-bit numbers are normally used).

There are quite a few other “pros” with regards to writing my own engine. I would get full control over the code, I would be able to market it, sell it, and more importantly, I would be able to include only the features and libraries that I wanted. I could optimise and streamline the engine to do exactly what I need it to do.
I would also understand exactly how it works, I wouldn’t need to spend hours scrolling through pages of code trying to figure out how a particular feature was implemented or where to add a modification.

There are many cons too, namely, the time it would take to create something of this complexity, and the problem of ensuring the engine is reliable enough and tested well enough. Most engines have many users beta testing them for a lengthy period before the engine is released, I would likely have to go down that route too.

I have decided to begin a preliminary feasibility study of a 3D engine designed for very large open worlds. It will be optimised for persistent and massively multiplayer worlds, and should support procedural content, and seamless surface-to-space transitions (a player should be able to explore the surface of a planet,take off, fly to a distant world, and fly back again, without load zones or trickery of any kind).

I am tentatively calling it the “Phoenix” Engine.

I will not be committing to the use of this engine yet, this is, for now, just an experiment.


Comments are closed.

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!