By: Simon Steele, Game Programming ’21
During the Fall semester of my junior year, I worked at Ironbelly studios. Ironbelly was first founded by Ryan Wiancko in 2009. At the start, Ironbelly was mainly focused on trying to make three-dimensional art assets for both indie and AAA developers. With the number of assets that they created, Ironbelly decided to move over to publish their art assets onto the Unity and Unreal asset stores. Over time, the number of Ironbelly’s clients increased, drawing more and more opportunities. Today, the studio stands with almost 60 people working all around the world, 4 of which are at the main office in Montreal. Though Ironbelly has mostly focused on helping clients over the years, there have been a couple of games that they have decided to take head-on. The first standalone game they worked on is a game called Hold Your Own. Also known as HYO, Hold Your Own is a survival game where you explore islands and gather materials to aid you on your journey. Within the game, enemies such as bears, wolves, and even raiders help to keep you on your toes. Even though HYO is still being developed by its original publisher, Ironbelly still helps a lot with fixing bugs and adding new features to the game. After some time, Ironbelly would also get some time with working on another survival game known as Fractured Veil. Ever since the original developers decided to opt-out, this has become Ironbelly’s only standalone game that they develop by themselves. Unlike many other survival games, Fractured Veil has an emphasis on its multiplayer systems, making sure that players work together to survive in the world.
At my time at Ironbelly, I worked on a multitude of projects, all of which involved different types of skills, some of which I have never had to use before. When I first arrived, I was primarily assigned to work on updating the weapons packs for both Unity and Unreal. In general, these weapons packs were art asset packs. However, to show off how each weapon pack works, Ironbelly developers created a demo scene where you controlled a first-person controller and was able to control the guns by shooting them at targets placed around the scene. Since the Unity packs had not been updated since 2015, I had to make sure that both the demo scene and pre-existing assets would properly integrate with the new Unity version After some time of polishing each Unity pack, I started to move over to working on the Unreal weapons packs. Since they were QA’ed in the past year, the amount of work with Unreal packs mostly involved tweaking level of detail (LOD) groups, readjusting sights, and folder organization. During my time working with the packs, I would sometimes also be called over to complete tasks for client projects. These projects would only take about a week or so to complete yet would be a lot more strenuous than my regular tasks. For example on one week, my mentor wanted me to work on a Virtual Reality game that was from a potential client. My job was to find potential bugs with the code and then eventually document them in a report that I sent to my mentor. During this project, I would have to go through complex, unorganized systems that I could barely understand, and find the source of the issue. Though these tasks were fairly challenging, I found that I had learned a lot from the experience.
While doing many of these tasks, I managed to learn new technical skills and experience that I never would have gotten from my regular classes. For example, I learned how LOD (level of detail) groups worked, and how they can be used to optimize games. I managed to create Unity’s standard asset first-person controller from scratch, which in turn, helped me understand how helpful using input axes can be to optimize games in Unity. When learning how to fix animations and particle systems, I managed to fully understand how to use Unity’s particle system and also how to fully animate 3D objects in-game with Unity/Unreal. When helping to debug client’s projects, I learned how networking works in Unreal and how to use inputs for VR within Unreal. Even though I did learn a lot of technical skills during my internship, I do believe that the hard skills that I learned from working in a corporate environment are the skills that are going to help me in the future.
The first thing that I learned from working at my internship is how to work independently. Because I had to work alone when updating the weapons packs, I found many problems that I would have to fix myself. During this, I found that looking up documentation on Unity/Unreal to be extremely helpful to find solid and simple solutions to problems. For example, when working on the Unity packs, I found a glitch with the game that specific particles from particle systems would not properly convert over to new versions of Unity. I went through the old Unity documentation to see what kinds of components the system was using and found what I was looking for. There was a simple script that I could attach to the legacy particle systems that would seemingly integrate them in. I eventually plugged everything in and the whole thing worked like a charm. During debugging, however, I did find that some bugs were too project-specific to be answered online so I eventually would have to find the answer myself. I had never really had the opportunity to read someone else’s code before, at least not a code sample that was greater than 500 lines long, so going into this, I was in uncharted territory. After talking with other coders who had previously worked on the project or simply just looking at the comments within the code, I could decipher what the program was trying to accomplish and work from there and get straight to debugging. During this time, I found that some of these issues in the code would involve me to truly understand how the code works because nearly all of the bugs I found with the code had to do with either my interpretation of the code being incorrect or something being wrong about the fundamentals of how the code worked. This understanding came into its own when I was working on the Unity weapons packs and found a bug where the gun could shoot you forward. To find the solution to this, I needed to see how the code registered hits. Eventually, after going through each script, I found where that piece of code was and then backtracked through the program to find where the bug was coming from.
The final thing that I learned from working with Ironbelly was how to communicate and update teammates on what I am doing and what do I need from them. During most of the time that I worked at Ironbelly, I constantly needed to communicate with many different people that all had different skills and knowledge about the subject at hand. At the start, I found this to be rather difficult because not everyone knew what I was talking about when trying to describe an issue that I was having or trying to give an update on what I changed about a project. Over time, I learned that I needed to look at communicating with a net neutral mindset, I needed to assume that whoever I was talking to did not have the same knowledge on the issue that I have. This means that whenever I try to explain an issue or a feature, I start from base one of explaining what the feature/issue is and how I am attempting to work on the task and then start going into the down and dirty on what I did. Of course depending on the person I was talking with, I would try to change around how far I needed to explain what I was doing but I always tried to make sure that the base was still there and I always tried to make sure that I talked about all of the processes that I have done already to get there. In the end, I found this approach to be beneficial to the listener since I was always describing what I did to get there, so they could get the full picture of my thought process so not only would I not be wasting their time, but it would also show that I put some thought into it before talking to them. For example, when we eventually got to uploading the Unity packs to the asset store, I tried to articulate as much as possible to the marketing director what I had changed about the packs so it was clear what we had changed so we could put the update on the asset store. I even tried this when describing a bug. When trying to open an old project Ironbelly had worked, I had a significant trouble. I eventually reached out to some of the former developers on discord to give them a full description of the problem and the steps that I took to get there and low and behold, I found out that I was using the wrong version of the Unreal engine. Even when updating my mentor on what I was doing, I was trying to give them constant updates on what I was doing so my mentor knew how much work I had left on a given task.