CRYENGINE is the cumulative effort of a wide range of people working together at Crytek. We’re always focussed on evolving the engine and service, and improving it for everyone who uses it. Today, we’re talking with David Kaye about upcoming Linux support, how the community helped with the GitHub release, and the importance of automation.

David Kaye is Lead System Engineer at Crytek, and has been working here for over three years. He works on our build system and joins us today to tell us a bit more about himself and his role.

Hi David! Thanks for joining us. How did you end up joining Crytek?

Hi! Honestly? I applied because I met the job requirements and I thought it would be fun. I applied as a Junior Programmer but was offered a position as a regular Build Engineer, and I’ve worked my way up since then. Before I came to Crytek I was working for a small company in the Oil and Gas industry, but I wanted to work in an industry with which I had a greater personal connection, and that I could talk about with my friends. I’m from Britain, but I was also excited to move to Germany.

What is your main focus at the moment?

My main focus at the moment is improving workflows for our developers. One way we’ve done this is by implementing a code review/test compilation workflow using Helix Swarm, which moves multiple pre-submission steps into one. In parallel to this, I am also working on porting the resource compiler to Linux.

What’s the most satisfying moment working with CRYENGINE at Crytek?

Releasing CRYENGINE on GitHub. It was the culmination of months of work on WAF, the engine code itself, and our internal build system. It replaced a legacy delivery pipeline that modified code and created .zip files for distribution.

The CRYENGINE community was very involved in the GitHub release. How did that involvement help you?

The help from the community was invaluable. It dramatically increased the number of combinations and permutations that we were able to cover. As a result of this we were able to address a number of issues prior to the announcement, for instance, the initial compilation and how to distribute SDKs, which made the entire process much smoother for the rest of the community. We really value the community getting involved in our projects wherever possible. It helps us directly and helps everyone who uses the engine.

What does it take to do your job well?

A desire to abstract away all manual tasks into scripts, where they can be tested, debugged, and shared with colleagues. I’ve joked that my aim is to automate myself out of a job, but despite ever-increasing levels of automation, it looks like I’m unlikely to succeed for quite a while. :)

Patience, a willingness to read documentation, and a desire to make people’s lives easier are also important. Much of my work comes from talking to developers about what they find frustrating about current workflows, and trying to find ways to automate/remove those elements. It’s not always possible, but we make things work wherever we can, and developers will often volunteer to help us test new workflows and tools.

Have you got any tips or tricks you’d like to share which you’ve learned along your journey?

Automate it! Whatever it is you are thinking of setting up, automate it! If you want to run static analysis, generate documentation, create builds or do anything like that, remove all humans from the process. Meat-based memory forgets to do things, does them inconsistently, and isn’t conveniently accessible to colleagues. Also, set up a Jenkins server, even if you only have one machine. If you don’t have a spare machine…find one! It takes the burden away from you, and lets things “just happen” while you work on things that Jenkins can’t.

What does a regular day at work look like for you?

The first thing is to check the status of the builds. We get notified of any failures, so the first thing to do is fix anything that has broken, or find a workaround to make sure that the team has a build available for testing and working on. The productivity cost of a failed build is very high.

After this, I look at what tasks I have left to complete in this development sprint (we have adopted an Agile approach to engine development), and start working on the highest priority item. When we are planning each sprint, I make sure there is a mix of fixes, features, and maintenance, so that we can maintain a stable pace of feature development without incurring long-term technical debt.

For instance, over the last week or two, I have been updating Jenkins’ pipeline scripts to allow developers to create a set of binaries for QA to test. They can do this when creating a code review by including “#savemebatman” as part of the change description.

What feature are you most looking forward to coming to CRYENGINE next?

I’m looking forward to rolling out improved cross-platform support. It’s a subject that’s important to me and I’ve already been working behind the scenes to bring the resource compiler to Linux as part of this process.

I will also be happy if we can roll out some more CMake improvements. There are many good features, but I think we can still make the experience a little smoother. It’s always rewarding to make a change that simplifies somebody’s workflow.

What trends do you see coming down the line in your discipline?

Continuous builds and storing binaries in a version control system. Not for the history, but to allow rapid turnaround of code submission -> testable build, using a pre-existing client.

Have you got any tips for anyone aspiring to work in your field?

I would recommend gaining at least a basic understanding of C++, so that you can recognise the change from which a compilation error likely originated.

Alongside this, a good knowledge of a scripting language makes possible the rapid development of tools and pipelines to support your team. Since requirements can change quickly, using a language with a fast turnaround time will help you rise to the occasion. Python is particularly suitable for this due to its expressive and cross-platform nature.

Finally, a strong understanding of the Perforce and Git version control systems. They are quite different, but both are widely used and you would be well served by familiarity with them.

Thanks David!

Watch this space for more profiles of the people working everyday to make CRYENGINE the best it can be. We hope you enjoyed this piece, and we look forward to your feedback on the forums, Facebook, and Twitter.