Back in August last year I took part in a 1 month internship for a small games studio based in London, primarily as one of two game designers. After I finished my degree at Goldsmiths, I was offered a three month contract with eargym followed by a subsequent one. In that time, my role has shifted over from design to development, and I’m currently working as the games team’s main programmer and one of its main Unity developers.
I’ve primarily been responsible for setting up and managing our GitHub repositories to allow for remote collaboration, designing and writing our games’ main logic and feedback scripts, implementing audio and visual assets, creating custom data types to store information (structs, scriptable objects, etc.), setting up saving systems, rapidly developing and testing mechanics through WebGL prototypes, integrating analytics, and porting our games to native Android and iOS apps.
If we face a design problem or concern, I do my best to generate solutions for us to consider — weighing up the costs and benefits — and thinking about what’s feasible in the time we have and what’s appropriate for the game as a whole. We organise discussions, particularly on some of the more troubling questions we’re faced with, and I take notes and feedback to them with my thoughts on how I might approach implementing what we want.
Another underlying but substantial part of my role within the team is in seeing how I can minimize the manual, time-consuming work our team needs to do by designing and implementing programmatical solutions. I need to do what I can to anticipate the difficulties our game’s current setup will cause the team, and review how I can best mitigate these from an earlier stage. If I can see that a particular feature will need a lot of manual setting-up and would be time-consuming and error-prone to adjust, I do what I can to implement some code that’ll let us make those kinds of adjustments in bulk everywhere we need (and ideally only need to specified in one place). And as far as possible, I try to design systems which non-programmers on the team can tweak and edit in the inspector to get the results and game feel they want.
While I wasn’t initially sure I’d enjoy it, I found planning, structuring, and documenting my code quite satisfying. I particularly like thinking about how we might organise and offload code to dedicated game objects, creating, for instance, a ‘FeedbackController’, ‘GameLogic’, and ‘PersistentData’ objects to store and run parts of the game’s code (although I appreciate this can create a lot of dependencies, which I’ll return to at a later date). I’ve also enjoyed putting into practice some of what I’ve learnt from advanced programming: structs, arrays, lists, loops, switch statements, custom return type functions, etc. I also do my best to follow some of the practices I was taught, namely to never repeat yourself in your code, and to create functions which handle a specific thing you need to achieve and nothing else (for example, a single, dedicated function for moving a specified GameObject from one position to another over a length of time).
This has been and continues to be an incredible learning experience for me, and getting to work for a company that sincerely believes in the good that games and technology can do for the world makes this all the more a pleasure. For the sake of confidentiality I shan’t go into the specifics of the games I’ve worked on with them, but you can read more about the company’s mission statement, the team, and its games up on their website.