Programming Work

Main Learnings (so far)

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

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.

Resources.Load()

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.

Continue reading…

Game Developer at eargym

Overview

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.

Continue reading…

‘The Best Days’

Play the game here! https://m-ansley.itch.io/the-best-days

Shortened Walkthrough: https://youtu.be/OyVhGWbF-2k

Overview

The Best Days is a game about student life and mental upkeep. It’s about pushing forward through the days and nights while attempting to stay healthy and sane. It’s a game about the invisible hours spent toiling away in a room without company. These are, in short, the best days of your life. 

Ultimately, however, it’s a game about anxiety, depression, isolation, time pressure, and boredom, but it’s also one about perseverance and routine in the face of them. It’s been created in response to: A) the idealisation of student life (particularly by nostalgic adults), and B) the over-reliance on ‘black dog’ imagery (or other embodiments) in depicting depression. Instead, this game focuses primarily on the experience of depression and anxiety (in terms of sensations), in the context of mundane student life. It uses a Unity first-person perspective setup with a custom mood, anxiety, and time manager to adjust time on cue and increment post-processing and audio effects depending on the player character’s mental state.

Low mood and creeping anxiety

High anxiety increases the volume of a heartbeat effect while incrementing a vignette (designed to represent the kind of pessimistic ‘tunnel-vision’ stress can cause), while low mood desaturates the colours and increases the volume of a breathing sound effect (designed to simulate and represent the general loss of energy, vibrancy, and warmth, along with exhaustion/fatigue, I associate with depressive episodes). These are based entirely off personal experiences and sensations rather than qualitative research.

High anxiety (with thumping heartbeat)

The game is, in a sense, a juggling act between anxiety and depression (essentially masquerading under the word ‘Mood’), but it ultimately hopes to illustrate ideas of time- and self-management. While the impending exam within the game is figured as somewhat of a doomsday (and ‘time’ is figured as a sort of antagonistic force), there is life and warmth beyond it. My many post-its and notes-to-self during my undergrad told me to keep at it, but that there would also be a time when I could enjoy the sun on my skin again.

*****

Work Digest

Programming:

  • Implemented raycasting to allow for user interactions with objects in the room (switches, record player, TV, etc).
  • Created a custom time and mood manager class to control time within the game as well as the player’s ‘mood’ and ‘anxiety’ levels (with a public multiplier variable to be influenced by activities, the date, etc.).
  • Developed incremental post-processing and sound effects. These increase in relation to the player’s mood and anxiety levels beyond a certain threshold (and towards a minimum and maximum level respectively): a tunneling vignette effect and heartbeat for stress; a
  • Set up and created user-triggered camera animations for first-person cutscenes/transitions.
  • Developed a custom ‘audio fade’ class which works with Unity’s audio-mixers to gradually lower the volume of groups of audio sources.

Design:

  • Designed the piece as a simulation game, designed to create and recreate some student life experiences: time relentlessly passing, low and high mood, high and low anxiety (exam stress), working, procrastinating, unwinding (via meditation or during walks). Developed a custom mood, anxiety, and time manager to enable most of these.
  • Designed and developed the bedroom, lake, and ending exam environments. Implemented environmental details for narrative purposes, authenticity, and to promote player curiosity. Implemented lighting and post-processing for atmospheric purposes.
  • Rapidly developed custom models using Unity’s ProBuilder package. These include (but are not limited to): the bed, desk, lamp, drawers and cabinets, books, TV, games console, record player, laundry basket, and drying rack.
  • Created a variety of interactive objects to make the space feel more homely, as well as to provide the player with some fitting procrastination material (in-keeping with the ‘student life’ theme and setting).

Additional Screenshots

*****

This game is one of several stories I’ve been meaning to tell. I’m starting to see a lot of my games as a ‘coming to terms’ with parts of my personal history. I get to work on it, package it up, and then simply move on to the next project. While I don’t believe depression and anxiety can be quite so easily packaged up and ‘dealt with’, I do hope this project can be a sort of send-off to my undergraduate days. This depiction of student life is fairly mundane and hopefully understated, but that’s so much of what it was and is for me. We just work away and hope for the future.

[P.S. I’m working on a full post-mortem for this game which should go into the development process in a bit more depth. Keep your eyes peeled if you’re interested! ;)]

‘The Network’

Relax. Enjoy the party.

Play the game here! https://m-ansley.itch.io/the-network

Full walkthrough: https://youtu.be/zQ4AkoQ3oC4

Summary

‘The Network’ is an interactive narrative game about the collapse of a friend group and a power-struggle in spite of it. It’s about seething resentments, rumour, and people exploiting private incidents for personal gain. It’s a game about seeing where people stand on the matter or, alternatively, just talking about what matters to them. It’s a jumble of a couple friend groups I’ve been a part of — the drama that destroyed one and the social hierarchy of another — projected onto a slightly surreal prom after-party. It’s also a game which hopes to reflect on the coming and going of people in our lives. A lot of it comes from a conversation I had towards the end of prom night: standing out on a terrace and overlooking a lake as someone told me how we’d all meet up after tonight, and knowing, as sure as anything, that we’d never see each other again.

Work Digest

Design:

  • Designed the piece as a surreal dialogue exploration game about the the death of a friend group, exploring themes of social loss, breakdown, and cynicism.
  • Made extensive use of YarnSpinner for the project, allowing me to plot out elaborate conversations with multiple potential paths (with the player largely deciding the focus and tone of the conversations).
  • Designed the game’s aesthetics, spotlights, and set specifically with theater in mind: the ‘players’ on the stage each getting their turn in the limelight, delivering social ‘performances’. (Intended to bring out ideas in drama, showmanship and artifice, as well as to create a certain surrealism).
  • Created the game’s symbolic ending sequence, designed to be a kind of ‘afterlife’ for the player’s character and the elusive head of the group Lauren. Made use of an intentionally abrupt blink-of-the-eye transition between the activity of the party and the tranquility/reflectiveness of the terrace scene.

Programming

  • Implemented YarnSpinner and made extensive edits to the UI script; namely, creating a custom text-parser which uses in-text colons and the Split() method, along with a switch statement, to identify the character talking and then to apply certain effects accordingly (different coloured fonts, display name immediately rather than type it character by character, and different speech sounds).
  • Created several Yarn variables to keep track of player choices across the game (e.g. the tone previous conversation were ended on), to be used in the game’s ending.
  • Implemented a minimalist raycasting and camera animation system to allow the player to select desired characters and move towards them.

***

Continue reading…

‘Piece by Piece’ (Global Game Jam)

Play the game here! https://m-ansley.itch.io/piece-by-piece

Full Walkthrough: https://twitter.com/i/status/1224064219773132801

Experience Digest:

Overview

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.

Work

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.