In a nutshell, my experience is broad covering multiple industries, roles and projects including bespoke mobile marketing applications, large AAA packaged console games and live social games with millions of daily users.
I love to fix, improve, tweak and create ‘stuff’ with ‘stuff’ being really broad. This has included fixing 3D printers, setting up PCs for new starters, refining controls and player feel, installing CI servers, etc. Basically anything to keep the team/project/studio moving forward, filling in the gaps in roles and taking on new challenges.
Going forward, I’m looking for new opportunities to take on non-trivial problems and creating new experiences for users. If you have a role that sounds like it could be a fit, drop me a line!
Harry Potter: Order of the Phoenix was my first job in the industry as a one of the Level Integrator leaning towards the technical side more than design.
My main role was to implement a lot of the meta-game features and design that encouraged the player to explore the world of Hogwarts in exchange for rewards such as video interviews with the cast and the concept images.
All the logic for the game object unique interactions and reactions were controlled through C++ ‘scripts’ which sounds unusual and had it’s fair share of pros and cons during development.
This project is where probably learned the most about programming in a large scale project as I was pretty lucky being in a team of veterans game developers where they encouraged us to ask questions and willing to answer in detail.
They taught me about the advantages of using component based architecture, importance of CI, multi-platform development and the importance on good tools and workflows. With me just coming out of University, this was a fantastic opportunity to learn as much as I could from everyone and their experiences.
During the latter half of the project, I started to be given more programmer orientated tasks as my lead knew that was the direction I wanted to be heading towards. I worked on extending the scripting logic API and providing programmer support for the rest of Integration team as the majority were from a design background which reduced the burden and disruptions on the main game development team.
Harry Potter: Half Blood Prince was my second title and was the start of my career as a gameplay programmer as was given the task of prototyping and implementing the Potions mini game. This was a huge responsibility as it was one of the three core game mechanics in Half Blood Prince that would be used repeatedly throughout the game.
This is where I really learned the importance fast prototyping and how it was more important to prove something worked then it was to do it ‘right’. For every new idea that came up for potions, I quickly cobbled a working version under guidance from my lead to see how well it worked.
Everything from the core mechanic, layout and camera angle were reworked multiple times, the Wii controls alone had 7 or 8 different versions before it went through focus testing with our target audience to see which worked best and more importantly why. The mini game incrementally improved throughout development through ‘baby steps’ and become one of the most polished features in the game.
From the GamesRader Wii Review: "Let's start with potions, as it's the Big New Thing in Half-Blood Prince. It's brilliant. ... Not having ever made a potion we can't judge how accurate it all is, but the gestures are spot-on and fun to perform - it's a truly great mini game."
One of the larger unexpected problems that cropped up late in development was running out memory for assets due to the sheer number of unique ingredients and recipes needed for potions and had to come up with a solution without any major system rewrite.
Seeing that the head and body memory slots were not used during potions, I organised the data each set of ingredients for a recipe to occupy one or two of these slots since only one recipe would only be loaded at any one time. This meant that only a small change to the initialisation stage of potions was needed to cater for the load.
Need for Speed: Shift was a bit of a departure from my previous gameplay orientated roles as I was asked to be a frontend programmer using a Flash based library on an existing engine.
As it was an old codebase and toolset, there were not many developers at the company that knew exactly how the pipeline worked to export the game data into the game beyond the fact that there were a bunch of batch files that ran the command line tools.
Through some trail and error and the use of tools like Process Explorer and WinMerge, we managed to work out which batch files to use for different sets of data and also added some extra error reporting in the scripts.
As the frontend still had all the graphics from an old game, I stripped all the screens down to their barebones ready for the artist to add new graphics and animations at a later stage.
The livery select and editing screens were my main contributions to the game dealing with logic, presentation, saving and loading to memory card and UMD, including dealing with the TRCs associated with files on external media.
My main role on this project was working on prototyping a two player version of an existing mini game on the Wii and changing the controls so it can be played with just the Wiimote as the game was focused on co-operative play. This didn’t take too long to get to a solid workable version and move onto tool support for the integrators and art outsourcers.
As the outsourcers were external, we had to be careful on what data they had access to reduce the risk of a game leak but still be able to test their work in-game. An external Perforce server was created for them to use that was a mirror of ours without any of the level data except for a blue room sandbox that I created.
Within this sandbox was the same lighting and effects setup as the rest of the levels and also access to a set of debugging tools that I implemented that allowed the user to play any animation on a selected model and also scrub through the frames to look possible possible problems with the exported data.
Other side work also included adding some features into the existing development tools with requests from the development team such as being able to build the game data and launch the game in one click and managing to speeding up Wii image build times after talking with a few other developers.
There were some rumours that it didn’t take as long on Windows 7 an given it was something that was easy to try, I ran some benchmarks with our existing setup on Windows XP against Windows 7. There was a 30%-50% reduction (!) simply from an OS change and after some research, this was due to the improved file caching in Windows 7.
Unfortunately, this project was cancelled during production and the team moved onto Create.
EA Create was my last game at EA and during that time, I was a support engineer for the team taking on tasks that were outstanding but didn't fit in any of the other developers specialised areas and focused my attention to keeping the team moving forward.
My main task was on monitoring and maintaining the daily code and data builds, dealing with any build issues that occur which were usually memory related. This meant that I was also maintaining investigating our memory usage in game which became more important as we moved from a level based streaming system to a dynamic loading on-demand per object system which I assisted another developer in integrating into the game.
I partnered with IT to have PCs ready for newcomers from the moment they arrive via creating a base image for the PCs which had the majority of tools installed. Once I was given the new PC, I would update the tools via our in-house auto-installer that I maintained and built the latest version of the game on all platforms.
A new starter could now start working on the game within 30 mins compared a day that it used to take waiting for everything to install and download.
WMS Gaming was my first job outside of the game industry and since worked on two video slot machine themes, Commanding Officer and Periscope Pays which was based on the Battleships IP from Hasbro. Initially, there were meant to be two programmers on the project (one per theme) but as another project was overrunning, I ended up being the main programmer on both themes and developing in parallel. Thankfully, both shared a common base code which helped reduce the workload.
Each theme had their own unique set of bonus features that are available to the player to trigger. As there isn't much depth to the games compared to console games, there is a heavy focus on the player experience such as how everything is presented and fed back to the player. As the Producer and Designer were at the head office in Chicago, we were constantly sending builds up for review and getting feedback during the early stages to ensure that we had the experience and game flow correct early on.
A lot of focus and testing is placed on the strict technical requirements that states and countries have for these games which centre around accuracy, reliability and accountability. Common test cases being able to return to the same state if the machine is power cycled and being able to look at the games history if a dispute is raised from the player.
During this time, I also developed two small tools to help with my largest time sink during bug fixing which was anything to do translated assets.
It was incredibly difficult to compare translated assets with each other and whether they were missing or not so Locale Detective was born. The tool allowed me to quickly scan and search assets in the data folder and see at a glance if a translated asset was missing or named incorrectly which saved me hours during the late phases of both games. The full readme can be found here.
My second tool, GobbledyGook used Google Translate to loosely translate English text into the languages WMS supported so that artists can have a rough sense on how much room was needed for text on UI components in an effort to reduce the number of bugs due to text not fitting. The full readme can be found here.
Another point of frustration was the amount of manual work needed by the developer to send a build to the head office for review which required a clean code base on the developers machine, testing locally in the studio on device and then sending the build to the remote servers. This whole process could easily take up half a day, especially if the request for build came in the middle of task as it took some time to clean up the code to get into a playable state.
A couple of spare PCs and some lunchtimes later, I installed and maintained the first company's continuous integration server using Jenkins which performed static code analysis, build and deployed nightly builds of all active projects to the test devices in the studio. I also added a job that allowed anyone to send or retrieve a build from and to any office build server.
I joined Happy Finish to further widen my experience and knowledge in related interactive media industries. It was a much more client facing role than expected with frequent meetings (in person and over phone) providing progress updates and clarifying briefs/requests to further understand what their vision of the product.
The department's main aim was to create unique experiences using hardware like the Oculus Rift, Leap Motion and Kinect, pairing it with the CG work that is created in-house to create highly polished applications.
This included the Bazooka Budz Augmented Reality mobile app which I took ownership mid project and carried it through to release on both the Apple and Google Play Stores. Another was Happy Interactions which I oversaw as technical lead evaluating and experimenting with various hardware looking at what could be used pending the environment of the application.
We also experimented with ideas on what could be possible and creating proof of concept prototypes including a virtual showroom that the user could walk around using the Oculus Rift and the Kinect.
The interactive department was still relatively new and I was able to bring my industry experience to the team, mentoring the junior programmers, providing further feedback for usability within the apps, driving development processes and adapting them for a production driven company.
This was a challenge as the workflows that were in place and the managers were used to a linear schedule of production rather than a typical software iterative development cycle which made quotes difficult to calculate up front. Over time, I learned more about the process of the how the sales teams pitched ideas to prospective clients which helped frame my estimations in the correct context and highlight potential issues and/or provide further creative input to the pitches.