Inspiration
DayZ was one of my favorite games when I was much younger. Back then, it was still only a mod for a game called Arma, and had not been ported to its own independent game. Through the years, the independent game has been slowly shifting into a position where the player base could develop their own ideas and implement them into the game. When I was asked to lead the development of an entire DayZ server, I couldn’t refuse.
Development
I was responsible for the entire SDLC of this project. This included operations such as gathering design and feature requirements from the client, developing thorough use cases and test cases, and fairly distributing each stage’s workload to all team members. Distributing the workload was particularly difficult, because that meant I had to fully understand each task and figure out the best way to assign all tasks, while also taking into account the innumerable considerations, such as team member skill levels, team member subject familiarity, task priority, etc. Due to the longevity and complexity of this project, I will only be able to give a brief rundown of the more interesting parts.
Enfusion Engine
The first mountain to climb was to learn about the game-engine, the language used to develop, and the development environment. DayZ was created on the Enfusion Engine, and the corresponding language was dubbed Enscript. The learning curve for the language, Enscript, was abated, given that it is very similar to C#/Java and has many familiar characteristics such as garbage collection (strong and weak references), object-oriented (classes and inheritances), etc. The development environment was entirely restricted to DayZ proprietary tools. This also meant that we were restricted to running the server on Windows operating systems. In the end, we decided to run the server on a Google Cloud Platform VM running Windows Server 2016.
The most difficult part about working with Enfusion was that it does not provide a multiplayer client synchronization, thus we had to build entire systems using RPC with very little client authority. From a security standpoint, this is ideal, but through the eyes of us developers, it made the project much more complex and more laborious.
Party System
DayZ does not have a way to create a party by default, and since I only played the game when I played with friends, I saw this as something desperately lacking from the game. Thus we decided to build our own custom party system where you could invite friends and see them on the map as well as in the 3D world around you, along with stats and details such as distance, health, etc. On top of these functionalities, we wanted a way to more easily communicate combat situations, so we also developed a 2D/3D pinging system, loosely inspired by Apex Legends’ pinging system, where we can use a simple shortcut key to show friends exactly where you are looking. Each ping can be seen from each players' perspective and also on each party member’s map.
Here's the server’s opening trailer which briefly previews a few of the many features and systems we implemented, but it also very briefly highlights the aforementioned party/ping system.
Community Tools
The server development community is still relatively new, thus it is extremely underdeveloped. So on top of the in-game systems we built, I saw the need to build necessary and extremely useful server tools, as well as contribute to the existing frameworks that are used in the majority of servers. I built the majority of tools in Python, due to Python’s ease of use and production speed, with the plan in mind to port any tools that require more performance to another language such as C++. These tools included Discord bots that interfaced with server statistics, efficiently automated mod updating, etc.
For instance, one tool I made was a command-line interface tool used to modify Trader configurations. Trader mod is one of the most commonly used mods in DayZ, where players can enter a safe-zone and trade items for in-game currency, or vice versa, with NPCs and other players. However, this mod has no easy way to configure traders or even simple sanity checks such as ensuring that no items can be sold for more than they are bought for or that all of the same items have the same listing prices across all traders. So I decided to create a python-based CLI that takes care of all these sanity checks behind the scenes, as well as allowing users to quickly modify the trader configurations with features such as an item lookup, modification of an items across all menus and traders, and even saving and loading configuration presets. If interested, here’s the public version I released on GitHub.
Miscellaneous
There is so much more that we worked on such as custom modeling and animation for characters, items, weapons, buildings, and vehicles. Or a travelling trader that spawns at one of many random locations every server restart. Each of these feats required a unique solution that took time and meticulous thought to get right, and I wish I documented more of this development process so that I could share it here.
What I learned
I enjoyed learning how to develop on the Enfusion engine using Enscript and was able to hone my Python skills while compensating for the limitations of Enfusion. Furthermore, I learned many techniques to develop within an RPC model and I will carry this knowledge onto new projects and endeavors. Beyond technical, I practiced developing in a UX-centric way, where everything we implemented must be thought of from the player’s perspective. I learned how to manage and lead a team. Moreover, I learned how difficult it is to manage and lead a team. My struggles might have stemmed from my desire to be hands on with almost every facet of development. But nonetheless, I gained a new respect for project managers and those who take on the responsibility of a leadership role. In the end, within my many mistakes, were countless lessons that only strengthened me as a developer.