CRYENGINE is always evolving and our last update built on the CRYENGINE 5.5 Preview with a raft of new features and fixes. Today we’re exploring what came in, and what’s coming next, by sitting down with some of the team working to push the power of CRYENGINE forward every day. This wide-ranging discussion includes how the team decides what to work on, improvements in C#, releasing the source code, the new VR Component, and the future of Schematyc and Flow Graph.

In this roundtable, we’re joined by Luis Lairet, Lead Software Engineer, C# Programmer Michael Bosschert, and Alexander Klinger, Junior Engine Programmer.

Thanks for joining us today! What’s your main focus at the moment?

Alex: At the moment I’m working on improving and fixing the 5.5 preview builds to get the best possible outcome for the final 5.5 release. I am also listening to feedback from the community regarding entities, components, and general usability in the preview builds with an eye on integrating feedback into future releases. My main focus for the next update will be the Entity System and Schematyc.

Michael: I’ve been focused on making it possible to use Visual Studio to work with C# in CRYENGINE. With Xamarin Studio no longer being developed, it was vital for us to have an alternative ready. Another big feature for this release was of course the C# assets in the Asset Browser. This should make it possible to quickly make new components on the fly, without having to restart the Sandbox.

Luis: On Sandbox we’re always looking at three pillars. First is polishing legacy systems so they can perform better, and make them less of a hassle to maintain and/or align better with our current framework. Secondly, we want to continue to drive the Asset System forward. Ever since it was released, the idea was to migrate every asset type to use this new system. While doing this we always try very hard to offer some sort of migration process. For example, with 5.5 we changed levels to use the Asset System, which meant we had to offer an upgrade path for levels created using 5.4. And now we’re looking at migrating Prefabs to the Asset System, and hopefully we can offer the same kind of nice upgrade path. We’ve also been working on collaboration tools in the form of a Perforce plug-in for Sandbox that will tie-in nicely with the Asset System.

Finally, we want to continue to improve the UX in Sandbox so we can have more generic tools that can be used to accomplish any specialized goal. This all comes together in our desire to build solid frameworks. You have this with the Asset System, and you have this with our Node Graph Framework. They are systems that are meant to be used by a lot of tools. Even our Asset Browser uses the Node Graph Framework to display a dependency graph for any given asset, and Schematyc and the Particle Editors are clearly using the Asset System. :)

How satisfying is it to have released the Sandbox Source Code?

Luis: It is immensely satisfying! It was always in our heads that we wanted our source code to be in the hands of as many people as possible. In this way you can have people all over the world toying with the editor, creating interesting plug-ins, and familiarizing themselves with what we’re building on

How does the team go about identifying areas of priority for an update?

Luis: Each team is in charge of identifying the set of goals they set out to achieve every sprint, and in the long term for every single release. We also have representatives from different teams weigh in to contribute on what the engine team should be helping with, be it internal developers, customer support, community requests, etc.

We’ve had the immense benefit of working with the Hunt team on helping that game become one more success story for Crytek. All the work we put into fixing some of the pitfalls their designers run into and improving their processes for creating the game is something everyone will be able to benefit from when using CRYENGINE.

Alex: There were a lot of different things to do for the last update and it is never easy to decide what we want to tackle and in which order. We also had the Hunt: Showdown Early Access release at the same time. As the game is being developed on the latest version of the engine, we made a lot of changes and improvements during that process. Most of those changes are now also in the 5.5 build and the entire CRYENGINE community benefits from that process. We also tackled a lot of the user feedback, for example, porting more legacy entities to components or adding VR related components to the engine.

The UX in CRYENGINE has taken yet another step forward. How important is this area for the team?

Luis: Well, to be honest it’s been going forward for as long as I can remember! Even looking back at 5.0, it was a monumental release. There were some issues, but there were a ton of positives too. In regards to Sandbox UX, you look back and it was a huge step in the right direction. We look at the people who have helped shaped the UX of Sandbox and they are incredibly talented and very passionate people. Actually, I’d like to give a special mention to our UX Designer, Falk Sonnabend and our previous designer, Aleksander Budzyński. They’ve put a huge amount of effort into making things more and more consistent and empowering users to work more efficiently. They’ve been working closely with our developers and internal game teams revising workflows and coming up with ideas on how to make things nicer and easier to use and understand.

Can you tell us a bit about the new VR Camera Component?

Alex: Before we implemented the VR Camera Component there was no plug and play way to immediately have a nice room scale VR camera in CRYENGINE. We saw that people kept having trouble with it or were asking questions directly to us regarding this. Those components now work as a strong entry point if you want to start making your own VR game. If you have a VR device which supports room scale, the VR Camera Component can also take care of that. We also added another VR component called VR Interaction, which allows you to pick up physicalized entities in the world with the VR controllers. This component is also a good start to show how you can work with the VR controllers in CRYENGINE.

What’s the process for updating legacy entities?

Alex: If you have a quick look at the entities available in the GameSDK, you can see that there are still plenty of entities. But our approach for new components is to keep them as “simple” and generic as possible. You should be able to make any game with those components, whether you want to make a FPS or an RTS. This is why we have to evaluate what we want to bring over from the legacy entities. But there are still some entities we want to port to components, like the snow entity or the trigger entities. If the community has ideas for components or really want to see a specific legacy entity from the GameSDK brought over, we’d love to hear that feedback and we’ll look into it.

How did the team go about deciding which areas of C# to expand in the last update?

Michael: First of all we looked at the feedback from the community. Visual Studio support was a big request. We’re also constantly looking at how it feels to work with C# while we’re working on the sample projects, like Sydewinder, or the templates. Whenever something feels too complicated or is not intuitive, we look for a way to fix it.

Users can now create C# assets directly in the asset browser. Can you tell us more about this feature?

Michael: C# is extremely effective for rapid prototyping, so we looked at how we can capitalize on this with CRYENGINE. One of the bottlenecks we identified is that users would constantly need to restart the Sandbox whenever the code had changed. So we started experimenting with reloading all the managed plugins of a project so you don’t have to close the Sandbox anymore. With the addition of the Asset Browser, we saw a chance to add C# assets to that as well, which means that you have more time to focus on your game in the Sandbox instead of managing the C# solution in a different application.

Why did you choose to implement debugging in Visual Studio with the new extension?

Michael: CRYENGINE uses Mono to run the C# code, instead of .NET, which is the default in Visual Studio. But Visual Studio can’t debug Mono without a little help, so to make it possible to debug Mono with Visual Studio we needed a new debugger that is compatible with Mono. We give the C# projects a specific project type, and have the extension use a different debugger when it detects it.

We chose Visual Studio because we already use this internally for most parts of the engine, and we received a lot of requests from the community to support it. So, making the decision to support debugging in Visual Studio was a very easy one. Our first step with the extension is to allow you to start an instance of the game launcher, Sandbox or the server and attach the debugger to it. In the future we want to expand this so we can attach to an already running instance of the CRYENGINE, and to handle recompiled code from the Sandbox.

How do users go about installing the Visual Studio Extension?

Michael: Installing the extension is very easy. All you need to do is run the extension which is included in the engine folder. The exact details on how to install it can be found in the documentation about C# programming.

How important is expanding C# to the team?

Michael: Expanding the C# interface is a slow but continuous process. In many ways, we are still designing and tweaking the C# implementation, making sure it’s stable and functional. To ensure this process goes well we’re not rushing to expose everything. To solve this partially, we have the CryEngine.Common and the CryEngine.Core assembly. The CryEngine.Common assembly is generated by SWIG based on the C++ CryCommon code. This results in a very C++-like library which is a bit unwieldy to work with in C#. The CryEngine.Core assembly is hand-made by our developers and is written to be more like C# instead of C++. This includes proper usage of abstract classes and interfaces, descriptions for methods and objects, properties, and events. The CryEngine.Core assembly doesn’t expose everything yet, so far, because it needs to be added manually. The CryEngine.Common assembly, however, already exposes the CryCommon interface, but can be very confusing to work with because of its different workflow. But the more C# stabilizes, the more work can be put into expanding the interface so it will offer the same functionality as C++.

What future updates are planned for C#?

Michael: We’re experimenting with having a tighter integration with Schematyc. For example, marking properties and methods to be used in Schematyc with a single attribute. We’re also looking into integrating C# code samples into the new tech docs. That way if you look up a method in the documentation we can also show an example of how to use that method.

How do you see the future of Schematyc and Flow Graph within CRYENGINE?

Alex: I see Schematyc as a really powerful tool. In combination with the new Component System; utilizing C++ and C#, it will make creating games in CRYENGINE a lot easier and quicker. Of course, we recognize that right now we aren’t there yet, but we keep working on it and improving it with the intention of making it a production-proven system. It will take time until it is completely ready, although you can already see the potential it has right now through our numerous explorations within the shipped versions of 5.5 and Hunt: Showdown.

To note, we will still have Flow Graph in the engine for some time; however, it can’t really keep up with the new changes we are making in the engine. At their core Schematyc and Flow Graph are just designed differently and have different requirements. For example, you can’t really create a custom entity in Flow Graph and adjust it to your needs by adding new components, state machines, variables, and so on. So taking this into account we are looking at the best ways to not only manage the designer creation of these elements but also monitoring how we send and receive data.

Naturally with the updated workflows, we in the dev team see that in the future users will gravitate towards Schematyc by default and Flow Graph will continue to be deprecated. The expected course of this journey will be the extension of components that remove the need for any legacy entities, alongside the shifting of common utilities inside of Flow Graph to make the connection of entities a more streamlined process.

For now it should be stated though that Flow Graph as a level visual scripting tool and in combination with entities exposed traditionally can and has shipped AAA games within the engine. The deprecation of Flow Graph will take time as it is the lifeline of interaction within the toolset, a convenient way to create that interaction in your level and solidify the game loops that define the uniqueness of your project.

Which tool improvements do you think will make the biggest impact for users?

Luis: All of them together have a huge impact! And having source control integrated with something as cool as our Asset Browser/Asset System is awesome and something we’ve wanted to do for a while. Moving Prefabs to the Asset System is something that also has a big impact. Even small things we do that aren’t that noticeable, like refactoring some of the legacy systems to make them easier to maintain, is great. If we can reduce the amount of bugs and make tools more maintainable, everyone wins :)

Thanks guys!

We hoped you enjoyed this round-table straight from the studio. Community feedback in shaping updates is really important, so we’d love to hear your thoughts, feedback and comments on Facebook, Twitter and our forum or in the comments section below. Additionally, we will try something new and have a Live AMA in Discord next week so stay tuned for updates!

- Your CRYENGINE Team