Justin Lo

Timber Introduction

Timber was my first experience using the Godot Engine, my first experience programming with Lua, and my first time collaborating in a research team. I joined this project interested in learning more about Cloud and Backend Web Development for games. This led me to learn a lot more about .NET development in C#, cloud deployment, and Lua in the process. 

Struggles:
I struggled to adjust to the change from software development to research in my first semester, where I was not used to the open-ended approach of research. In software development, there are binary goals and outcomes. But in research, you don’t know if the feature you wanted to implement was feasible. Many times the path I picked was an dead-end and I had to abandon weeks of progress after consulting with my team.

Things I want to do in the future:
I want to learn how to create better benchmarking systems for the changes that I made, as it was never taught to me and I wasn’t sure how precisely impactful my changes were to the game engine in it’s entirety. 

Cloud Storage &
Data Serialization

I was interested in optimizing our cloud storage system, which contained data (images, maps, user scripting) for the games made by our users. All of the assets are pulled from our Amazon S3 bucket and then built dynamically. Therefore, it is in our best interest to keep our files as small as possible. 

Most of our data are C# data structures stored as JSON files in the cloud, which are then built into our engine using NewtonSoft. This led me to experiment with binary serialization methods as an alterantive to decrease uploading and downloading time.

  • I bench-marked three serialization libraries built off Google’s Protocol Buffers: Protobufs, Cap’n Proto, and Flatbuffers. For our small file sizes, they performed similarly against each other, but have 50% smaller file sizes compared to their JSON counterparts. 

  • I wasn’t able to benchmark the serialization speed difference NewtonSoft and Google Protobufs, which is something I am curious about

A problem arose when I tried to serialize Lua code our users programmed, as Lua support is not officially supported by any of these libraries. I had to test and scour Github for custom module support for Lua, many of which are now broken due to outdated dependencies and lack of maintenance. The Lua modules I tried for Cap’n Proto and Flatbuffers all didn’t work, and it was only after weeks of trial & error I found an Lua module for Google Protobufs that we baked into our custom Godot build which worked. 

Lua Integration Layer

We embedded Lua as a scripting language for our users in Godot, which required an creating intermediary script that translates user written Lua code into C#. Our old implementation was parsing Lua code into JSON and then feeding it into a C# script which translated it for our engine (this was done using Threads). This also needed to be serialized in binary using Google Protobuf, and which I did and replaced NewtonSoft.

  • I learnt how to read and write Lua scripts, as well as how to serialize and de-serialize objects using Google Protobufs

I also re-vamped our old data structures with my team and to create a more robust way to hold character and map data, which was part of my job in serializing objects with Google Protobufs.