My main contribution to the project was the development of the combat system. To facillitate this sytem, I developed an extensible 'action sequencer' (with great assistance from a similar system in Pox Nora) to act in concert with the combat architecture, allowing each individual action and their subsequent reactions to be handled by care of the sequencer. Additionally, I was in charge of the inventory system and its accompanying UI, which fit rather nicely into my 'wheelhouse' of combat expertise. I was also principally in charge of submitting builds and publishing the final version of the game to Steam (as well as integrating all the bells and whistles that Steam had to offer: Steam achievements, Steam trading cards, Steam API calls, depot setup, DLC setup). Post-release, I was also in charge of integrating the game with the PS4 and its publishing pipeline (Hello FQA!) and revising the game to be PS4 compliant (creating and triggering PS4 trophies, converting all UI and controls to account for the PS4 scheme, creating/packaging builds). Lastly, I was in charge of integrating the Unity build process with a system called Jenkins — an automation tool connected to our version control (SVN) — in order to build and publish the game to Steam with one simple command.
The Process:
We began this game, my colleagues and I, as a trio of junior programmers. Responsibilities were divied between the three of us, and out of the game's two central mechanics (dialogue sequences and combat sequences) I elected to tackle the combat system. As a group, we also decided to try our hand at Strange IoC as a design paradigm for the game (a form of dependency injection for Unity). Strange required that we adhere to an overarching MVC format as well, so I got a taste of two different design approaches as my introduction to professional programming. For our purposes, Strange was serviceable and I adapted to it quickly, but I'm not 100$ sure we got the most out of dependency injection at the time (considering that we still experienced our fair share of architectural problems as the project progressed). Of course, there's the very real possibility that we weren't making the most out of the system, being as green as we were. NBC Universal became involved towards the middle section of development, where the game took on the shape and universe of The Huntsman movies, but for as much applomb as the partnership brought to the game, there were now challenges to face that hadn't existed before. Partnering with NBC meant agreeing to a fixed release date, so when we lost our third programmer late in development, the ramifications were clear: we simply did not have the option to negoiate for more time. The proverbial curtain was set to rise, whether we were ready or not. It was an enormous amount of work, but I'm proud to report that we were able to split the responsibilities and get the game out on time.
Takeaway:
The takeaway here was immense. There were a lot of unique challenges that presented themselves throughout the course of this game's development but I firmly believe that I rose to address each and every one those challenges. Personally, learning how to write sustaniable, 'future-proof' code was likely my largest achievement here: learning how to tackle a problem from all angles with consideration for the project's directory. Is this a system that is likely to change? We of course want to avoid over-engineering whenever possible, but I also quietly discovered the importance of making small — perhaps out-of-my-way — adjustments to code that I was writing if it meant that I could avoid a headache later down the line. I don't think I had this kind of foresight working on solo projects; I had the mentality that 'if something works today, then that's good enough for now'. This project was the first of so many things for me: working on a team of people, developing a significant system from start to finish, getting accostomed to version control (and the occasional woes of losing work to a conflict, or a hasty update), and shouldering more responsibility than I had (perhaps initially) thought I was capable of doing. I'm not ashamed to admit that I made a lot of mistakes and had my fair share of stumblings along the way, but I can contextualize those mistakes now as 'all part of the process'.
Spacewars: Interstellar Empires
Unity | PC, Mac
Supplementary Role | 3 Year Timeline
Key Responsibilities:
I served more of a supplementary role in the development of Spacewars. By the time I joined the team, pre-production was already underway and much of the game's systems and mechanics had already begun to take shape. My role was to assist wherever necessary, so a lot of my work was placed towards integrating UI comps, combat QA, developing tools for the creation of galaxy maps and sectors, as well as keeping an eager eye out for bugs. Unity's 4.6 UI overhaul was still pretty fresh by the time I got to the project, so constructing 'adaptive' UI — something that doesn't break under a variety of resolutions and aspect ratios — was paramount here.
The Process:
For the most part, the team adhered to Unity's natural pattern: allowing gameobjects and prefabs to speak for themselves and for components to modify their behaviour in a modular way. I tried my best to keep UI and their respective classes as object-oriented as possible, and to craft behaviours in such a way that a parent class could remain abstract. I'm thankful that I got a bit network programming under my belt as well. Client/Server interaction is a bit of a dance, I think, and it took a decent amount of time to grow fully accostomed to it (as well as, tangentially, Unity's method of interacting with web APIs through REST). It's not a terribly complex interaction, in the case of Spacewars at least (it's a lot of: 'network sends a google protocol message, which we grab, interpret, and construct a client message that we can understand, at which point a handler interacts with the message and proceeds accordingly') but it's an important interaction all the while. Spacewars, it should be mentioned, was always more of a living, breathing entity than perhaps one of our more standard projects: rules were constantly being added or removed, features would come and go. The more you could plan for the future, and the flexibility of the project, even as far as simply fixing bugs, the more pleased I found myself when I had to return to the project.
Takeaway:
My contributions were never as large or as significant as they were in The Huntsman or in the VR Project, but I was happy to assist where I could. Spacewars would also unofficially mark the beginning of a role for myself at Desert Owl: the 'Jack of all Trades'. For my part, I was eager to play a versatile role and 'wear a lot of different hats'. After all, if it meant expanding my skillset and learning new things then I was all for it. I was never affixed to Spacewars or Pox Nora for too long (maybe only a couple of months at a time) so much of my work here was about examining the entire problem and making quiet but impactful revisions. I didn't understand this initially, but I think I have a better appreciation of it now: interacting with other people's code and being mindful of your actions and edits is arguably just as important as being the one to write them. The combat system in this game is immense — there are a lot of rules and lot of mechanics — so retaining the functionality of everything (keeping the place as tidy as you came in!) while still addressing the issue was pivotal to maintaining forward momentum.
Project Golem
Unreal 4 | PC
Lead Role | 4 Month Timeline
Key Responsibilities:
After a grace period, I found myself at home within the weapon system and I was principally in charge of creating an architecture to handle the unique variety of weapons our Mech might wield (energy beams, bullets, and lobbed projectiles). This also meant configuring the system to handle any animations affixed to the gun (if there were any), its corresponding projectile (if applicable) and all of the effects and sounds associated with that weapon as a whole. Design and development were pretty rapid, so making sure to construct a system that a would account for flexibility, and a healthy portion of new ideas, was important. Later, I was in charge of implementing the Hangar UI as well as the Mech UI; we elected to take on a retro-inspired aethetic — something akin to the Nostromo from Aliens — so the UI needed to exist in world-space, something the player could see / hear / interact with.
The Process:
We partnered with a third-party publisher this time around to produce a virtual reality 'experience' — a shorter game you might encounter at an arcade — and we were glad to make the connection. From the pitch document to the concept art, it was clear that this game was going to stand out (which was awesome). But admittedly, the conditions were a little daunting: the game needed to be developed in Unreal 4 (an engine I was completely new to), it would need to play out entirely in VR (a format that none of us had worked in before), and it would need to be finished in 4 months. A timeline was constructed to fit something of this projection, but the milestones would be tight. The team consisted of two programmers (me, and my boss) and two artists. I won't speak for the others, but I was feeling pretty apprehensive about the sheer amount of new and unknown elements at play here. Would I be able to learn Unreal in time? Am I going to be able to make contributions? Would I pull everyone back? I'm happy to report that I rose to meet this new challenge. Unreal has its own set of quirks to contend with, not to mention tackling the added dimension of VR, but I think I was more than capable of tackling this new 'beast'.
Takeaway:
I am so pleased that I got to experience Unreal 4, what felt like a missing page in my overall repetoire. It also meant getting a chance to re-familiarize myself with C++ as well, which was a useful takeaway. This too had its own associated hurdles: the tight timeline, the new engine, working with the Vive headset; by no means was this an easy timeline to complete. I'm thankful that the team was so dedicated and supportive; Unreal took some getting used to, but at the very least it was a team experience. I'm also quite pleased with how effectively we were able to prototype the game. Each system I was behind, the weapon system especially, I designed to be flexible and iterative. We were changing and developing new weapons up until the final two weeks or so, discovering play mechanics that felt good and fun, and I think that was only possible because we knew how to prepare for it.
Pox Nora
Unity | PC, Mac, PS4
Supplementary Role | 2 Year Timeline
Key Responsibilities:
My role in Pox Nora was to aid in the PS4 integration, implement new Unity UI screens, and to bugfix like crazy.
The Process:
From the get-go, this project was a tall order. This would be a Unity port of the Java client of Pox Nora, a now 10 year old game with just as many years of content, bug fixes, and features to go along with it. Porting Pox Nora to a Unity client allowed us to give the UI a well deserved face-lift and the ability to exist on a variety of platforms. The magnitude of this task had to do with the compilation and translation of ten year's worth of Java code to C# — by no means a simple task. My job was to support the established team, to put out fires as they arose, and to get the Unity version compliant with the PS4 (something I was quite familiar with at that point).
Takeaway:
The challenge that Pox Nora posed to us programmers was the sheer vastness of the game's history and collective work that has been put into it. As a project, Pox Nora easily dwarfs Spacewars in size and scope, simply due to the fact that there are twice, or three times as many scripts attached to it and running at any one time. If I hadn't already learned the importance of being 'code mindful', and watching where I stepped (or at the very least, examining everything a change might enact before changing it), then I learned it here. The codebase here was encyclopedic — obviously functional and well-thought out — but certainly intimidating. The key takeaway here was learning how to approach a problem (a very large, scary problem that touches many systems) and diffuse it to its smallest parts. Even Goliath can be conquered.
PERSONAL
About Me
Hey there! My name is (William) Thomas Scott, I grew up in Flagstaff, AZ and I currently reside in Tucson, AZ. I attended Middlebury College in Vermont, where I received a joint bachelor's in Computer Science and Theatre (with an emphasis in playwriting). I've been in the industry now for 2.5 years and I think I'm ready for the next step in my career. Oh! And thank you for checkig out the website, I made it myself ~
