Lewis Yates
Game Programmer
Luna Playable Plugin (Unity Playworks)
Software Engineer
- Created and adapted diagnostics systems in Unity, NodeJS, and a C# console app.
- Created robust and sleek custom Unity editor windows.
- Found and fixed bugs in Playable export pipeline and Playable game engine.
Project Diagnostics
The Luna Playable plugin enabled developers to create playable advertisements (playables) within the Unity
engine itself. This meant studios no longer needed to outsource the development of ads and instead could
adapt the original game project to conform to ad network requirements.
Playable ad networks required playables to be a single html file, meaning we would need to use a transpiler to
convert from c# into a web friendly format, in our case, we used Bridge, a c# to JS transpiler.
Code diagnostics, a feature of the plugin, was built to better inform developers of issues coming from this
transpilation process.
Project diagnostics would take this a step further and include diagnostics for all stages of export. This
project went through many iterations to ensure we delivered a user friendly product that made creating
playables a smoother experience.
I led the development of this project, working closely with the engine and design teams.
The playable plugin has four core stages in the export pipeline:
- Collects all assets and prepares them for processing.
- All asset processing, including applying compression and creating font bitmaps.
- Transpiles c# project to JavaScript.
- Prepares the assets for the specific platform being built for, and bundles them into a zip file.
All stages run various different sub processes, each with specific errors that can be thrown, to ensure we
were collecting these errors in a meaningful way we created new error codes to encapsulate these issues. The
codes were sorted into the categories they originate from:
- 1000 - Asset export
- 2000 - Asset processing
- 3000 - Code transpilation
Going forward each known common error would have a custom log created in its place, these logs could be
created by anyone on the engine team. Any new errors would be logged as normal but tracked so if it became a
prevalent issue it could be fixed engine side, or a custom log could be created.
CS error codes would be logged as normal, but new LP codes were created for issues within our export process.
The individual logs were stored in a single JSON file, which held project and build related information. These JSON files were intended to not only be displayed in the project diagnostics tab, but also be sent to our systems to identify how common any given error is. We added various properties that allowed us to filter results to identify trends between projects This meant we had a better understanding of the places out user base was struggling, and allowed us to fine tune updates to improve their overall experience and speed up playable development
The tab was updated to be able to display the new log information in a way that made sense for
our new error codes, but also in a way that still made sense for CS error codes.
Each error was then sorted into a dropdown tab that best suited it.
Any unity project was able to be ran through the export pipeline, which meant projects that were not suited for playable export could cause thousands of errors to be thrown and logged to the diagnostics system, since this is a completely custom window, to mitigate any performance issues, I ensured only a handful of logs were drawn at a time.
Playable Health Check
Whilst the project diagnostics tab was intended to help developers better understand and debug issues in their playables, we conceptualized a new section to better highlight and give more information on the less critical issues present in a playable.
The health check tab featured four categories, each relating to the categories found in the project diagnostics tab. The core idea for this tab was to highlight the importance of the non-critical issues, whilst still preventing long builds if critical, playable breaking issues were present. Each category featured what we called a traffic light system, where the colour of the light would indicate the severity of the issue, and how much it would impact the playable.
| Color | Description |
|---|---|
|
Red
|
There are serious issues detected which could break the build, or the playable ad will be rejected by the ad network. |
|
Amber
|
There are non breaking runtime issues detected, fixing these will greatly improve performance of the playable, and will decrease the chance of the playable ad being rejected by the ad network. Or you are not using all of our features which is proven to increase playable ad metrics, such as higher CTR. We highly recommend fixing these issues. |
|
Green
|
There are no issues detected which could break, or have a negative impact on the playable ad. |
Pairing each category with a light meant we could directly tell developers how impactful issues in a category
can be to a playable with minimal information. depending on the category and severity of issues, we would
block the ability to build "Playground" builds since the playable would be guaranteed to not work correctly.
Each category in theory would block builds if a sufficient issue was present, however, We wanted to
ensure that we werent introducing more pain points for developers, so blocking issues were mostly limited
to critical core functionality issues.
Critical issues in other categories, such as Luna apis not being implemented, might flag the
category as critical, but will not block builds. This way, builds could be created and uploaded to playground
for general testing on different devices.
Luna Playables
Unity Developer
- Developed playable ads for names such as Rovio, King, Zynga, VooDoo and more.
- Aided in creation of template projects that are available on the community github page.
- Upskilled and helped colleagues learn how to use the playable plugin and create playables