How We Write Code

Author's note: Back in the early days of Velan Studios, we tried to articulate a philosophy that would guide the code we were going to write. The result was this document.

Author's note 2: Since the time this document was written back in 2017 and now, our technical strategy has evolved. These days most of our work is done using in-house technology. Viper has grown from an early prototype that could render single triangles each representing a player, to the tech behind a number of shipping games. And most importantly, Viper continues to change to meet the needs of our games.

Attributes we value in our code and our approach to technology:

1. We want our code to be Changeable.
2. We want to always be Learning.
3. We want to take Ownership.

Changeable Code

Changeable code is rooted in the idea that no code we write will be perfect, nor do we want it to be (because perfection is context-specific and the context is always changing). Code should be written assuming it will be added to, subtracted from, modified, and deleted.

This does not mean we just write poor quality code as fast as possible. Writing changeable code requires good judgement, clean architecture, and constant attention.

• Changeable code looks like other changeable code and follows common patterns.
• Changeable code is appropriately complex and solves actual problems. In other words, a good ratio of essential to accidental complexity.
• Changeable code names things well.
• Changeable code is written in an environment that balances costs and benefits of mandatory process and policy.
• Changeable code is well tested, giving us the confidence to change.
• Changeable code minimizes dependencies.
• Changeable code aims to be accessible to all Velan programmers, no artificial boundaries or overreliance on domain expertise.

Learning

Our studio values the unconventional and the curious. Both require constant learning.

• When we think about the systems we write, we look outside our studio and our field.
• We revisit fundamentals of the systems we use.
• We stay current.
• We seek feedback.

Ownership

Write enough code, and some code can be neglected. Accumulating hacks and workarounds, passed between programmers, the clarity of its original purpose lost, the code has become ownerless. It is not enough that code is changeable, we must actually change it. We believe this derives from a sense of ownership.

The concept of ownership applies to external code we use as well. In order to feel comfortable using some external code we must:

1. In most cases, have the expertise to write code we are using (but perhaps not the time.) This leads us to the second point.
2. Understand the code we are using. Often this understanding comes from having the expertise. Regardless, if we are to use an external piece of code, we must understand it.
3. Take responsibility for making it better. All code has to change.

Viper

We have a two-pronged technology strategy:

1. Start with Unreal Engine 4. Among full-featured, modern game engines, we believe that UE4 is most changeable out-of-the-box.
2. Over time create a collection of internal technologies we call Viper. Viper technology is standalone from UE4.

We believe this approach gives us the best opportunity to create systems that align with our values, and to make the kind of games we want to make.