Sharing Unity Code: The Journey

Introduction

At Space Ape we have a lot of shared code which we use across all of our projects. As of now, we have 57 shared code modules; these range from messaging systems, logging and our in-game console, to crowd rendering and asset processing, .

Why Share Code?

  • We don’t need to spend time reinventing the wheel.
  • We have the flexibility to take the shared modules we require.
  • We’re confident that this code comes with a suite of unit and integration tests.
  • We know it’s been proven in practical use across previous projects.
  • We are all familiar with the code, making project start-up times much faster.

Sharing code allows developers to focus more on the final product, in our case the games we create, because they spend less time worrying about low-level implementation details and non functional requirements.

The Journey

All of this shared code didn’t just happen overnight. We’ve tried and failed quite a few times with our release process, distribution and collaboration. As a result of failing and learning from these failures, we’re now able to easily share our code, and developers from various projects are all contributing to it.

The process is by no means perfect – we’re still working out the kinks – but it’s improved our workflow a lot, and maybe it will work for you too.

At the Beginning, there was only Ctrl+C, Ctrl+V

When Space Ape first started we were all focused on one project, so there was no need to share code. We were a start-up and our primary objective was to ship a product.

When the time came to start our second project, some of the code was copied over from the first project and we remove any project dependencies, but we had a code base to start with. Our first title was still being developed, bugs were being fixed, and features were being added.

Whilst all of this was happening the two code bases diverged quite a bit. If a bug was fixed in one of our games, there’s a good chance that fix didn’t make it into the other game – the same goes for features and improvements. As each project went on, the ‘shared’ code was modified to fit each project, and in the end sharing code between projects was more hassle than it’s worth.

Context of the Problem

Roll forward a few years. We now have a few established games, Samurai Siege, Rival Kingdoms, Transformers: Earth Wars and Fastlane, and we’ve entered into a partnership with Supercell.

Unsurprisingly, our company goals have changed a bit. We’re no longer a start-up in the true sense of the phrase. Our goal is to create a genre defining mobile hit, and in doing so we are moving away from our build and battle heritage.

We are branching out into many new genres, so we need to iterate quickly. We can’t predict that every new game idea will be a success. We need to try new things rapidly, and learn as quickly as possible.

Having a solid foundation of shared code would help us to iterate faster. In order to do this we would have to look at how we could share code between projects, with as little pain and slowdown as possible. When it comes to sharing code, the biggest obstacle is not writing the code itself, it’s the tooling and practices around releasing and distributing it.

Enter Git Submodules

Git Submodules are like a repository within a repository. You can continue to work on your code base and once you’ve finished a feature or fixed a bug, you can check it in. You just push your shared code up to one repository, and your project’s code to another.

This seemed ideal at first! We were already using Git across our studio so everyone was familiar with it. But we soon ran into problems.

As the source code is there for you to edit freely, teams would obviously change shared code, check it in and then when the other team pulled changes, their code wouldn’t compile! This sounds a little lazy and reckless, but this issue stems from the fact that there is no boundary between what is shared code and what isn’t. From a team’s point-of-view, they are just changing code in one big solution. The ideal solution here is to expose a simple yet well-defined API to the game teams.

So once this became an issue, each team decided to branch the shared modules off the master branch, and we were back to square one. Two diverging code paths, never merged together.

Further to this, we found that anyone who’s not a developer (artists, animators etc) can have quite a hard time using submodules. The tooling around submodules isn’t straight forward. Often we would update a submodule but someone wouldn’t pull changes for that submodule, so project and shared code would get out of sync.

Maven

Our server developers use Maven to manage and release packages. Maven is a tool developed for the Java ecosystem. When you are ready to release your project, Maven will take all of the information within a pom file and then package up your code so that it can be shared with others.

Because of all the features offered by Maven, and the fact that it’s not a native .Net tool chain, it often felt more complicated than it needed to be. Out of the box it comes with things like build life-cycle management. But at the end of the day all we were really interested in was dependency management, versioning and packaging; and that came with a lot of overhead. We ended up creating custom build steps to install our packages which made our build and release process even more complicated. As it wasn’t natively supported (or developed for) either Unity or .Net we felt that there must be a better solution.

Unity Packages

Because we are using Unity, the next technology that came to mind was Unity Packages, just like you see on the Asset Store. It was really easy to integrate. However, the whole release process and package storage was quite unregulated. There’s no real package versioning support and no dependency management. You also need additional tooling to uninstall a package as there’s no defined package structure, so we would have to clean up the old package before installing the new one.

Finally, Unity packages traditionally contained source code. We wanted to stop teams making changes to source code within these shared modules and improve compile times. This meant we needed to use Dynamic Link Libraries. DLL’s also allow us to easily develop shared code modules that depend on other modules, without having to make sure that the source code for the dependency was the correct version and compiled in the first place. Whats more using DLL’s would also lead us to faster compile times.

So we looked elsewhere, and found:

NuGet

If you’ve not come across Nuget before, it’s a package management system designed specifically for the .Net framework and it supports dependency management. There are currently over 110,000 packages on the public repository, some of which we were already using. However this repository is public, and a lot of our code isn’t for public release, so we couldn’t just go ahead and push our packages up to this public repository.

Before we could make a start there was quite a bit of work involved in setting up a whole development and release process around Nuget, not to mention setting up our own Nuget package server and getting everything to work nicely with Unity. In my next blog post I’m going to take you through everything, from start to finish.

Mentoring – you might be doing it already

MCV4

MCV Women in Games Awards at Facebook May 11, 2018.

Do you remember all of your good teachers, both in- and outside of the classroom? The ones who inspired you, pushed you, believed in you, called you on your BS? I do, and they made all the difference.

Last week I was honoured to win the MCV Women in Games Award for Career Mentor of the Year. I didn’t have exposure to this industry when I was growing up, so I feel blessed to have the chance to be a part of it now. I think it’s up to all of us to make the opportunities available in this incredible industry accessible to those trying to follow in our footsteps, and apparent to those who may not have even considered it as an option.

award1

My boss and Space Ape mentor Mickey.

I’m proud to be part of a studio which takes that seriously. We set up our Varsity Program for students earlier this year, partnering with local universities to deliver lectures about disciplines in games. We livestreamed the lectures on Twitch, and had more than 16 thousand live views. One of the students I met through the program is now actually interviewing with us for a part time position over the summer, and we’re looking forward to next semester.

SpaceApe-Varisty_Masterclass_1080p_Unis

We partnered with UCL and the University of Greenwich to deliver six lectures.

VarsitySTUDENTS

Us and some of the students following a lecture at the University of Greenwich.

But even before our efforts for more outreach, we’ve been mentoring talent internally for years –

We hold Universities at lunchtime where we teach each other about different aspects of game development and the broader industry. To further build on our experience every Ape gets a yearly £1500 training budget, to spend however they see fit to develop their skill-set. We also hold monthly Ape Spaces, days dedicated to fostering creativity and brainstorming new game ideas as a company.

I wanted to take this chance to highlight just a few of our success stories within the company.

IMG_4595

George Yao is the PM for one of our upcoming titles, which grew out of an Ape Space game jam.

Graduating with a Finance degree back in 2010, George never thought he would have the opportunity to work in the games industry.

“It wasn’t a thought that ever crossed my mind even though I grew up loving and playing games,” he says.

George didn’t just love playing, he held the Number 1 world rank in Clash of Clans for seven consecutive months.

“At the time, I didn’t understand the potential impact from pro-gaming. For me, I just played a game that I enjoyed and due to my competitive nature, I strived to be the best. After retiring from Clash of Clans, Simon Hade (COO) contacted me from a start-up mobile games studio out in London.”

IMG_1303

George with a player from Team Secret, where he acts as Media Director.

IMG_0829

You can find out more about George’s journey and his involvement with esports @JorgeYao87

After consulting for Space Ape for a few months, he was interviewed and officially hired for a full-time position as a VIP community manager. Alongside his career at Space Ape, George now manages pro esports team, Team Secret. 

“Being a self-starter and having strong mentorship from management, I became a Live Operations Manager within six months and a product manager and owner within two years. Space Ape not only opened the doors but also fostered my career growth every step of the way.”

Screen Shot 2018-05-17 at 11.17.44

Vicki is the Vision Holder for one of our upcoming titles, also born out of an Ape Space game jam.

Vicki is a Lead Artist and Vision Holder for one of our new games. After she started as a 3D artist she was quickly exposed to game design, management, pitching and other areas of development.

“We are huge on our knowledge sharing culture, and with our density of talents Space Ape is a great place to learn and grow,” she says. “I’m always learning new things in the Universities we hold at lunch. I don’t think I would be as equipped to be a Lead Artist if I had gone anywhere else.”

Fire_Demon

Art from our first title Samurai Siege, and (above) art from our second game Rival Kingdoms.

Vicki found agency through working in a small team and set the artistic vision for one of our most promising new titles.

Image uploaded from iOS (1)

Johnathan went from Games Analyst to Game Lead in two years.

Johnathan began his career at Space Ape as a Games Analyst, keeping his finger on the pulse of trends in the market.

“What’s really impressed me about Space Ape is their willingness to give people the opportunity to prove themselves in new roles. The training budget also allowed me to get the resources I needed to develop my skills. There is a strong culture of promoting from within and it’s a true meritocracy.”

Fast-forward two years and he’s now the Product Owner of one of our most successful titles.

IMG_4611

Johnathan used his training budget to develop some of the skills required to become a PO.

“When I joined Space Ape having changed career, I never imagined I’d be running a game team just two years later! If you’re passionate and productive, they will make sure you get the opportunity to put your new skills into practise.”

I can think of a dozen other examples off the top of my head, from Alex and Ioannis who journeyed from QA to Product Owners, to Raul and Keedoong who started as CS agents and now head up entire departments in CS and Localisation.

From Pro-Gamer to Product Owner, George and his team are now getting ready to soft-launch his dream title, which was actually born out of an Ape Space game jam.

“As long as you have a long-term vision and the traits that embody the company culture, your goals will come to fruition,” he says.

VarsityDEB1

Fore more info or to get involved with our Varsity Program: varsity@spaceapegames.com

I’ve watched my colleagues grow into various roles and thrive. I feel incredibly lucky to work in an environment that allows for, and encourages that kind of growth. I’m personally excited about using the talent we’ve fostered in-house to reach, build and hopefully inspire the talent waiting to be tapped in the wider community.