I’ve had to pick up a fair bit in order to keep up with the needs of my current team, and while these learnings might be obvious to more experienced programmers some of them have been significant milestones in the learning process for me.
ScriptableObjects have become invaluable for the work I’ve needed to do, namely in that they allow me to create templates for objects we want variations of in our projects. For instance, rather than creating dedicated scenes to contain the audio and visuals assets we might need for different locations, we can simply set up and load in the location-specific elements from a scriptable object (backgrounds, colours, text, audio, etc.). These save a lot of time, but I also hope they create some more transparency in the work I do for my teammates. I walk them through on how to create these objects in the asset menu, the values which need to go in, and I try to give the objects headers, tooltips, and sliders to make them more accessible to non-programmers. Another benefit of these is that they allow us to uniformly make additions to our games. Let’s say every location now needs a unique UI image in a given spot on the screen: all we need to do is add a sprite variable to the scriptable object script, add these images in to the instances via the inspector, and then tell the main scene to read from the template and load in that image after a null check.
The main problem I started running into with our projects was increasingly long load times, particularly into and out of the scene selection. I specifically noticed this in one of the games I worked on a couple months ago, where I was using scriptable objects to store the structure and assets for each of four stories. These were all located in the scene selection, and one of them would follow the player into the main scene to give them the illusion of opening up a dedicated scene for the story they’d picked. This was all well and good until I found loading the scene selection crashed my phone. Too much was technically being loaded in at a given time — all of the audio and visuals assets for all four stories. After doing a couple searches, I came across the ‘Resources.Load()’ function, which would allow us to store assets (including custom ScriptableObjects) in a Resources folder for us to then draw on via a file path. By switching us over to a system which uses this function, the scene selection would then only need to store file path references and only ever need to load in one story at a time. This drastically sped up performance in the games while enabling us to continue using the scriptable objects system we had for creating and loading levels/locations.
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.
A couple weeks ago I took part in the Global Game Jam. While we hadn’t initially intended to, three coursemates and myself ended up forming a team to address the jam’s fairly open theme of ‘repair’. It turned out to be one of the most positive, constructive work environments I’ve ever been a part of. To summarise it, the jam consisted of a lot of collaborative design, democratic decisions, and a great understanding of each other’s abilities and strengths. I don’t doubt life in the industry, particularly the AAA industry, is a lot more hierarchical than this, but it honestly gave me a glimmer of what small-scale game development could be like.
We had a relaxed couple of hours of ideation on the first day, putting out ideas and loose thoughts around the jam’s theme, and thinking through some game ideas more specifically. I thought it was a bit of a silly suggestion, but I shared an idea of a little game where the player controls a robotic character that falls apart as the game progresses, needing to repair himself with sometimes makeshift prostheses. The avatar would most likely reach a familiar character at the end of the game, but having changed so much that the character can no longer recognise him. It has its problems, namely the sheer number of assets we’d need our artist to create if we were working in a 2D environment (and the potentially fiddly programming on the various components that fall off the avatar), but it does ask a pretty focused and hopefully evocative question: To what extent are we the same person after the self-repair we conduct? It’s essentially the Ship of Theseus thought-experiment turned into a platformer. The team seemed surprisingly on board with the idea, but in all honesty I wasn’t. Aside from the practical problems I thought we might have, I repeatedly voiced that I’d much rather us try to make something beautiful rather than quirky. Yes, quirky is often the word we might use to describe game jam games, particularly some of the most successful ones, but our team consisted of designers from a course that urges us to create meaningful experiences. To tell stories, to evoke emotions.
I urged us to take a step back, perhaps aim at something functionally simpler but more meaningful. I suspected this particular theme was really resonating with some of us, and that we might have a particular story to tell. After speaking to her, it sounded like Martha had a set of ideas about emotional repair drawn from personal experience. She explained the kind of story she had, and it sounded beautiful. My only concern was that we didn’t risk rushing this or ruining what she had to tell; it can be quite painful to put so much of yourself into something that doesn’t turn out well. We developed this idea, thinking of how we might root it in something tangible. We ended up settling with a single, personally-significant object the player repairs while working through a kind of emotional repair. Furthermore, we decided the object would be significant not so much because of the function it served or who owned it, but because of its emotional value after a particular incident (its connection, in this case, with one of the last arguments a brother and sister had with each other).
As such, ‘Piece by Piece’ is a game about trying to restore something from the past and come to terms with loss. It’s about emotional self-repair mapped onto an act of physical repair. The game often gets misread for being a puzzle game when in actuality its a narrative one. There are not piece rotation mechanics and there are only seven pieces in total. It’s a short, meditative piece that urges the player to slow down, take in a story, and reflect.
It felt a little strange and arbitrary at the end of the piece to give ourselves certain titles for the credits. Certainly, we all did the things we described in the credits, but as you might notice there’s no lead ‘designer’. We have UI design and environmental design as specific branches (the latter being one of my roles), but this really was a piece of collaborative, democratic design.
To get practical, my main work was in getting the raycasting system to work for the drag mechanic. This allowed us to move the pieces across a surface rather than relative to the screen, meaning we had greater freedom to position the player camera (rather than strictly top-down). I also implemented the audio manager to integrate our sound designer’s music and royalty-free sound effects into the game (a satisfying ‘click’ being really important to us in terms of game feel for this piece). I also helped our main programmer implement a tried and tested dialogue system into our game, essentially the Brackeys Dialogue Manager with some variations of our own. The project manager and I often have our disagreements over timing — she prefers fast, I prefer ‘steady’ — and to me scrolling dialogue text seriously needs the kinds of pauses we find in human speech. I insisted this would be easy to implement — we just needed to create a couple if statements that check for the pieces of punctuation in question before creating a longer delay within the for loop (for printing out the character array).
With these additions, we were in a much better position to think about the overall feel, pace, and presentation of our piece — what feedback does the player get when they do this? How much time should we give them to read something? Additionally, after we went away on one of the evenings I continued work on the project to implement a little touch I really felt people would appreciate. I just wanted it so after the player clicks on the lamp and makes the title disappear the camera would lean in to begin their work. It’s a little touch, and fairly simple to implement using the Unity Animator and couple scripts, but for me it just gives the player this brief establishing shot, if only to tell them that a world exists around them (and that this repair is actually situated somewhere). I also felt tangibility and a degree of embodiment would be really beneficial to our piece (our act of repair being so tactile/physical), and this it would make the game feel a bit more dynamic and three-dimensional. Admittedly, it also worked as a compromise — I wanted a more detailed surrounding environment but at the same time appreciated we didn’t want a ‘cluttered’ look. Sure, we’d use lighting to tell the player what’s important, but this would allow us to show that there’s more in the scene than what the player strictly needs.
Earlier in the project, I sketched and proposed several environments to the rest of the team, including a study, kitchen, living room, and dining room. The kitchen or dining room might have allowed us to have an ever-present empty chair in the background, while the living room might give us a sense of warmth and home. But ultimately, we all settled on the study, creating this sense of the player-character having actively decided to take time out of their day to commit to this task. It’s a place for focus and a degree of intimacy with the object in question. The aforementioned animation would work to complement this sense of focus or study — the object as artifact — and the team were very pleased with the end result of this effect.
On a similar note, I also spent my time making a few decorative objects to have at our disposal — pencils, scrunched paper, glue, a pencil pot, a cork board. I also made the desk-lamp and switch, wired/coded them up, and made extensive use of freepbr textures throughout the project (freepbr.com). We were going for something fairly minimalist, but it still felt important to ensure the objects that were in our scene had a consistent style and build to them.
Lastly, I made the thumbnail/cover art, description, and submission page. My emphasis for this project was on thinking as much as I could about presentation and feel, both via the tools in the Unity Editor and via C# scripts. Our game was well within scope, meaning we did what we could to create something consistent and complete for the player to enjoy.