On December 23, Star Citizen announced its 2.6 Alpha, with Star Marine (the FPS counterpart to Squadron 42, Star Citizen’s space-combat storyline), updates to Arena Commander, and a variety of other improvements and tweaks. The press release also stated that Star Citizen would shift from CryEngine to Amazon’s Lumberyard engine. The news, and its timing, set off a flurry of concern in the Star Citizen community. Most companies never announce good news practically on top of Christmas — you drop news on December 23 if you don’t want it picked up. Engine changes, meanwhile, usually mean a significant delay as assets and resources are ported from one engine to the other.
With Lumberyard, however, the situation is more complex. Lumberyard is heavily based on CryEngine, with additional technology integrated alongside it. Amazon has an FAQ that gives the specifics, but it looks as if most of the changes and additions Amazon has made boil down to feature improvements and new tools for building games as opposed to fundamental alterations to the game’s engine. This should speed the porting process, since we know Cloud Imperium Games (aka CIG, the developers of Star Citizen) has done a great deal of work to customize CryEngine in the first place. Now, Chris Roberts, the head of CIG and famed Wing Commander designer, has issued an update on the engine porting situation.
Lumberyard and StarEngine are both forks from exactly the SAME build of CryEngine.
We stopped taking new builds from Crytek towards the end of 2015. So did Amazon. Because of this the core of the engine that we use is the same one that Amazon use and the switch was painless (I think it took us a day or so of two engineers on the engine team). What runs Star Citizen and Squadron 42 is our heavily modified version of the engine which we have dubbed StarEngine, just now our foundation is Lumberyard not CryEngine. None of our work was thrown away or modified. We switched the like for like parts of the engine from CryEngine to Lumberyard. All of our bespoke work from 64 bit precision, new rendering and planet tech, Item / Entity 2.0, Local Physics Grids, Zone System, Object Containers and so on were unaffected and remain unique to Star Citizen.
Going forward we will utilize the features of Lumberyard that make sense for Star Citizen. We made this choice as Amazon’s and our focus is aligned in building massively online games that utilize the power of cloud computing to deliver a richer online experience than would be possible with an old fashioned single server architecture (which is what CryNetwork is).
Looking at Crytek’s roadmap and Amazon’s we determined that Amazon was investing in the areas we were most interested in. They are a massive company that is making serious investments into Lumberyard and AWS to support next generation online gaming. Crytek doesn’t have the resources to compete with this level of investment and have never been focused on the network or online aspects of the engine in the way we or Amazon are. Because of this combined with the fact we weren’t taking new builds of CryEngine we decided that Amazon would be the best partner going forward for the future of Star Citizen.
Star Citizen has been criticized before for its scope, the enormous difficulty of developing and launching the project, and the need to reshape CryEngine to do something it was never intended to accomplish. But based on what Roberts has laid out here, the shift to Lumberyard really shouldn’t be a problem. I’m still not certain CIG can pull Star Citizen into a shape that delivers everything the game promised, but I don’t think the Lumberyard shift is any reason to be concerned. If anything, it may help with later development stages if the superior tools and netcode outweigh the annoyance of moving whatever code needed to be moved (and if Roberts is being honest, it sounds like it will).