12/31-1/14: Preproduction Technologies

Over my Christmas break, I’ve been doing pre production research for the studio, figuring out new technologies and determining if they’re applicable to the studio. Here are the results of my research:

Unity Test Runner

One of the major challenges during the development of Dreamwillow was the presence of Regression Bugs. Regression bugs occur during the middle of development and break systems that were previously working. Dealing with these kinds of bugs took up a significant amount of development time that could have been used to implement other features. As a result, I began to look into technology that can eliminate these types of bugs.

Fortunately, Unity offers Unity Test Runner, an interface to create and administer Unit Tests fairly quickly. For instance, say we had an XP system in our game where a UnityEvent is called every time the character levels up. We can create a unit test to check if this event is being triggered. The test passes if the event is triggered and it fails if the event isn’t triggered.

Why does this system help save time? Suppose someone changed the code to accidently prevent the event from being called. As a result, vital game functions, such as scripts that display a “leveled up“ screen, were broken. Simply pressing a few buttons would show that the UnityEvent was broken, thus taking a few minutes instead of an hour to fix.

However, there are a few downsides to using Unity Test Runner:

  • Unity Test Runner is complex to set up, due to the assembly files and .dll files involved.

  • These tests can only tell you if the code is broken, not if the code is working, so this doesn’t eliminate bug testing.

  • Requires a large investment in the short-term, making prototypes and early builds much harder to set up.

For all these downsides, I estimated that we would end up saving a lot of time by reducing regression bugs.

Game Foundations

One of the technologies I was asked to research about for the studio is “Game Foundations”, a Unity preview package. It’s purpose is to implement the systems that can take developers time, including inventory, stats systems, currency managers, and save systems. It allows developers the ability to focus on creating unique aspects of their game, rather than the general systems that many games think. Our producer thought it could be useful, so I looked into it.

As I began working with Game Foundations, I realized that this system poses inherent risk if we choose to use this. There are several things that can’t be done with the Game Foundations, such as Item Descriptions and adding enums (and other data types) to items. If we needed those functionalities from the system, we would have to implement it ourselves using their framework, which can be very difficult. Attempting to work with a system you don’t understand can be significantly more challenging than simply writing that system from scratch. As a result, I made the recommendation to not use Game Foundations.

Save System

The ability to save your game has transformed the way games are developed. Whil

Previous
Previous

1/28-2/16: Concepting and Prototyping