Outer Colony’s Game Engine

OC’s simulation and AI systems impose very large processing demands that are not common in most games. The reason that OC can run such a computationally complex system is because of its unique, custom built engine. The core of OC’s engine is a fundamentally multithreaded processing framework, built on Java’s concurrency package.

Processing

OC will use all available cores to keep the world running smoothly.

Summary

  • OC uses a custom built, entirely in-house game engine that was designed for one purpose: maximum computational throughput.
  • To process everything going on in a world, OC is running mountains and mountains of calculations all the time. Changing weather conditions, millions of plants and grasses growing, creatures and humans doing all sorts of things – this requires a different kind of computational power than what’s needed by most other games.
  • The most practical way to satisfy these special requirements was to build a specialized engine entirely from the ground up.
  • For really technical readers, OC is built using only Java. I develop and test on Windows (OC’s core target platform), but it should run on Linux and Mac with minimal effort. I’m not sure if these platforms will be supported at launch, because they do impose additional testing requirements, but the possibility is there.

Engine Details

Much as I’d love to write an immensely technical article on OC’s engine, I can’t spare the time to at the moment, so I’ll keep this piece at a high level.

People who have been following the project for years might be wondering, “Why change so much of the technical architecture? Specifically, if OC’s gameplay mechanics are going to be adjusted, why not stick with Unity for coding the new client / server application?” Again, the best answer here is very long and involved, but in short, it’s not because of any deficiency with Unity. Unity is an amazing platform that saves huge amounts of time and effort in developing games. The issue is that OC is a strange beast, and has less to do with Unity and more to do with accommodating its strangeness.

Most games don’t have to perform calculations for leaves falling off trees in the autumn. Most games don’t have to calculate changing wind velocities in sandstorms.  Most games aren’t growing hundreds of thousands of changing plants all the time. Most games aren’t dynamically generating plans to accomplish goals through vast problem spaces…for many thousands of creatures and people at once. I won’t keep listing examples, but it could go on and on. OC is doing a lot of strange things in real time and background calculations that most games just don’t have to do. Commercial game engines are built to support more conventional game processing structures, where game logic is often negligible and graphics are the big demand.

OC’s strangeness makes it sorta’ the opposite of the norm, so it’s not particularly well suited to development in conventional game engines. It absolutely demands multithreaded processing capabilities, and most game engines are fundamentally single threaded. Without getting really technical, multithreading can be a headache, and if most games don’t need it, then they certainly don’t want to deal with its complexity. Since it’s rarely if ever needed by most games, fundamentally multithreaded, commercial engines are, to my knowledge, very uncommon.

Furthermore, because of all the processing that OC needs to do, I really needed to exercise a fine degree of control over every aspect of the processing framework. It’s just easier for me to build the entire thing myself than to try to rely too heavily on outside libraries. By building the whole thing myself, I have an intimate, deep knowledge of the system at its core, and this was essential for all the technical design work of the simulation and AI subsystems.

Finally, the graphical component of OC’s engine helps facilitate the gameplay. The whole thing is written in-house, which means I’m now responsible for frame rendering, animations, sprite management, and all kinds of other things that were handled by Unity before. The benefit of this approach, though, is that I now know every of every detail of the system.

The tile-centric graphics are also much less of a headache from a multi-layered architecture sort of standpoint. 3D models, their file formats, importing them, getting their animations to play right – it’s a giant set of headaches that are only resolved by specialized knowledge. You can’t code your way out of those problems. You have to monkey around with your game engine, your modeling software, and all of the associated plugins, and I spent a lot of time fidgeting about to get things to work the way I wanted them to.

In OC’s new rendering system, it’s all just bytes. The world view (and everything in OC) is built from scratch, on pure JavaFX. I figure out RGBA values everywhere, jam them onto a GraphicsContext object, and that’s that. Is it a lot more code for me to write? Yes, absolutely. I needed to write my own code for animating characters, for rendering weather effects, for day / night shading, and tons of other things. But it’s all code, and it’s not monkeying around with utilities and applications in a long, complicated artwork pipeline.

If something doesn’t work in the current architecture, then there’s a problem with the code, and I can figure that out and fix it pretty quickly. If something didn’t work in the previous architecture, I’d be left scrounging about on the AutoDesk forums, the Unity forums, emailing other members of the team, and experimenting with program options haphazardly until something worked. In both cases, you can eventually get things to work the way you want, it’s just quicker and easier for me to solve problems myself in code than to learn a million and one details of how to use someone else’s applications.

And for any software project, time is a very finite resource. That’s a large part of what the technical changes have been about. The new engine satisfies OC’s unique processing needs, simplifies the overall architecture by giving me fine-tuned control over everything, and facilitates faster development. For me, on this particular project, that’s why a simple, pure Java system built around its concurrency framework is the best fit.

Posted in Uncategorized