Zwift

During my time at Sumo Digital as a Placement Programmer, I worked as a tools programmer on Zwift, implementing new features for the level editor. Day-to-day responsibilities included stand-up meetings, working through Jira tickets and occasional collaboration if required by the feature implementation. I would also attend bi-weekly meetings for new requests and sprint planning. New requests meetings were to review ideas for new features made by users of the editor, and for me to provide feedback on feasibility and time estimates.

Tools Programming

One of the tools that I created was the visual markers for the timing arches. It enabled users to visualize predefined start and end points at a distance along the road according to where an arch was placed.

At the outset, adding visual locators at a distance out from timing arches located throughout the game seemed relatively feasible, it quickly escalated and became a lot more complex. The reason for this is that it required modifying the rendering of roads so that the visual markers would always appear on top. The main problem was creating transparency, as this essentially meant that two roads would need to be rendered. The road that the player rides on and the coloured road with slight transparency on top.

As I started down the path of modifying the road rendering system, I soon found this to be the case, and as the implementation was growing larger, it also became harder to get help from seniors since they would have to spend a great deal of time catching up on what I had already done.

Further, as the road on top copied the original road rendering method, it was looping through all the tessellation points on the road, and then only rendering a particular segment. Coupled with the fact that it would never have a texture applied, this meant that the tessellation points should have been reduced, to better optimize the render method. These were all issues that could have been identified had I initially contacted a member of the Zwift team that was familiar with this system.



Additionally, the implementation also required a system to allow the user to drag and move the light towers along the road, and have the coloured road react accordingly. This created an issue with looped roads, especially at the seam where the road connects.

Considering all this, I think the best solution for this would have been to identify feasibility before assigning this ticket and providing a list of people that were familiar with the affected systems. Consequently, however, this system took a lot longer to implement than it probably should have, even though it was relatively complex.

I learned a lot about taking general responsibility and time management from this ticket, but outside of this feature, all other situations regarding engine additions and bug fixes were completed according to the story points that were set at the start of each sprint.

I was also responsible for implementing the terrain editor which allowed developers to easily swap out textures at each terrain level, rather than having to manually modify XML files to achieve the same effect.

Gameplay Programming

During my time as a Gameplay Programmer, I got to learn NoesisGUI, a multi-platform XAML-based UI framework. NoesisGUI supports data binding meaning it can interact with data using MVVM patterns ensuring a clean separation of logic from UI.

IoCpp was required to implement the framework, which inverts the flow of control meaning that the game could receive the flow of control from the NoesisGUI framework allowing for real-time UI modifications.

UI Programming

As a UI Programmer, I worked on converting the editor menus to ImGUI. This was another technology that I got to learn, and more than that, I got involved in the process of removing old rendering code, decoupling the logic, and integrating ImGUI.

I found that generally after a menu conversion the class would no longer have a need to inherit functionality from various UI classes and instead could sit as a standalone implementation with just a header inclusion from the ImGUI library.

Consequently, this required a lot less code, and would typically reduce the amount in any given file by around 40%. After several menu conversions, and getting more accustomed to the library, I found better ways of doing things and would often reduce the line count by an even greater amount.

Feel free to drop a comment below.