Julian Banks

Contributions:
A solo project, all shown artwork and code is my own (Music and haiku sourced).

Context:
Originally a university project developed in SFML C++, I recreated the project in Unity C# due to familiarity for faster development. Then, when Unity introduced the runtime fee I recreated the game in Godot C#, which is what you see now. Refactoring the codebase each time based on what I learned from the previous iterations lead to smoother, more polished player movement.
The goal was to make fluid player movement that smoothly blends between different movement such as swinging, running, sliding, grappling, swimming, etc, within an interesting, dynamic world that the player can interact with.

Player state:
The player character uses a class state machine, inherited from a base PlayerState class, to determine how the player should move given the current context. This gives me the control to manage state changes based on the current state's possible transitions. Originally, the state machine used enums, though containing all the movement and transition logic within a single class was not scalable enough for the project.
I believe that the finely tuned transition requirements between states, along with the large number of different animation frames, squash and stretch, and momentum-based movement lead to smooth looking and feeling movement that I am very satisfied with.

Shaders:
Zen Grappling uses multiple shaders throughout to create more dynamic and interesting visuals.
The grass shader animates grass tiles back and forth to simulate wind, with an x offset based on world position so wind travels over time. The players collision box is drawn to a separate texture each frame with the opacity depending on speed and the colour depending on the sign of the horizontal velocity, which is also faded out each frame. This texture can then be used by the grass shader to know if it should be pushed down by the player, in what direction, and by what magnitude depending on how recently the player moved there and their speed.
There is also a tree shader that shows the players silhouette when behind it. The way this works is the players sprite (with skew, rotation, and scaling) is drawn to a separate texture, which is then passed into a tree leaves shader and each tree in the room checks if the players colour is in front of it. If so then change the colour to black to show the player silhouette. It was done this way as other things can overlap the player so if it was done on the player then silhouettes would be drawn in the grass.

NPC Movement:
For the fox NPC seen in the first video, the movement is based on my previous movements saved to a text file. It works by saving relevant data (such as position, sprite frame, scale, rotation etc) to a queue every set timeframe, and then interpolating between points each frame to recreate the movement.
This allows me to create more intricate, realistic movement for NPCs, such as a chase scene, and could also be used to recreate player movement for replays or ghosts in a time trial setting.
Initially i wanted to just record the inputs and the time of those inputs as then i could recreate movement with less filesize, but as Godot's physics engine is non-deterministic, meaning the same inputs do not always yield the same results, it was not reliable to do it that way. I can still reduce filesize by increasing the time gap between recordings at the expense of accuracy.

Contributions:
A solo project, all shown artwork and code is my own.

Context:
Originally a university project developed in Unreal C++, I recreated the project in Godot C#.

Powerup System:
The powerups use inheritance to reuse common functionality such as cooldowns and references to the tank using it within a BasePowerup class. Then when I want to add a new powerup I only have to create the unique features with the cooldown timer and functions for pressing and releasing the powerup button already handled.

Bomb Explosion Pooling:
One issue I ran into was that the game would hang for a frame when a bomb exploded, which was made worse when multiple bombs chained explosions. This was because I was duplicating the explosion texture so that the explosion shader didn't impact all instances within the scene, and then creating a new noise texture to ensure all the explosions looked unique. Doing this, especially creating the noise texture, caused the game to lag. The way I solved this was creating an explosion material pool. By creating a set number of explosion materials at the start, I could use a manager class to return unused materials and as explosions only lasted a short duration, they could be reused quickly. This stopped the need for generating new textures while still looking unique as they all are assigned a different noise texture from the start.

Juicy Walls:
For the walls, I created a pixel art texture in blockbench. Then, using an existing normalmap, I sampled colours and manually created a normalmap version from my original texture. This makes the wall look significantly more interesting, not just flat, paired with an out bounce easing and ascending sound effects for creating them, the satisfaction of using the wall powerup increased dramatically.

Portals:
Each object that can teleport using a portal has an ITeleportable interface with a function for teleporting when it hits a portal. This may sound like overkill; to begin with the portal handled teleporting of all objects that hit it, but this quickly became too large of a class due to the surprising number of unique ways I needed to handle teleporting. The player should be sent out the exiting teleporter with enough speed to not still be touching it even if holding the other direction; bullets velocity need to be flipped depending on the difference in portals directions; the growth ray means that some objects are too big to fit in the portal, and objects like the punch or grapple need to keep track of how far they have travelled even when travelling through multiple portals. The grapple has a stack of portals travelled through and calculates the distance based on all the portals travelled through, while also creating a new Line2D for each one to still render the rope at each point. That way when it retracts it can retract back through each portal rather than just returning to the player.
Portals attached to walls can be enlarged when a growth ray hits the wall, and any object travelling through different sized portals gets the scale difference applied to them. It ended up being quite a complicated system!

Contributions:
A solo project, all shown artwork and code is my own.

Context:
A personal project currently being developed in Godot C#. I have identified overscoping as one of my weaknesses as a developer. My goal is to turn this project into a small game with strict considerations for scope, to publish on Steam. For this, I can also reuse and extend systems I have already created such as the player movement and dialogue systems from Zen Grappling.

Dialogue System:
Each NPC with dialogue in the world has a DialogueSpeaker script that contains their speaker ID, sound effect, pitch, talk speed, and a reference to their sprite to animate them. They add themselves to the DialogueSpeaker group on start so that when a dialogue is triggered, it can find the relevant speaker by ID in the group.
Dialogue is stored in a text file, and each dialogue trigger has a serialized/exported reference to its dialogue file. This makes it easy to add new dialogue as I just have to create a new text file and object to trigger it, while allowing for different characters to behave differently while talking. The text files contain blocks of text with their speaker beforehand and the choices/next dialogue after, denoted by specific characters I wouldn't use in the dialogue, such as double colons (::). The game then goes line by line through the text file, passing the text to a speech bubble to be read until it hits an option or the end of dialogue.
The speech bubble loops over each character within the lines it gets passed and displays each character with a sound effect, delay, and pitch variation depending on the speaker.

Music System:
I was considering using royalty free music for the game given the shorter scope I'm giving myself. However, I wanted to make the music dynamic and fit the different areas of the game while still having similarities between the tracks. For this reason I have produced some music for the game (and more to come..) as well as creating a system for playing them. The music manager has functionality for creating and removing audio players to play different layers of the song at the same synced time, meaning that as the player progresses, layers of the music (with different instruments) can be added to give a sense of progression and keep the music from feeling too repetitive.
As it's a rage game, while the player falls, the music becomes more distorted as well :).

Contributions:
A solo project, all shown artwork and code is my own.

Context:
A personal project developed in Godot C#, inspired by the incremental genre and falling sand games, I wanted to combine the impressive visuals of falling sand with an incremental progression system. However, part of the enjoyment of incremental games is seeing the number scale exponentially bigger as you progress, which can quickly become an issue of performance with falling sand without careful optimisations. For that reason I decided to take this idea forward for my university honours project, which you can see the result of in Dronescape.


Falling sand:
There are two sprites in the scene, one for the structure and another one that starts empty for the falling sand. Clicking converts your click position into pixel coordinates and reduces saturation of the structure in a radius around the click position. Once the saturation of a pixel reaches zero, it is removed from the sprite and added to the sand sprite. All pixels in the sand sprite check if the pixel below is clear and moves down if so. If not, the pixel then checks diagonally down left or right and moves there instead, which causes the sand to pile into dunes.
During development I realised that the order of processing the sprite makes a big impact on the way the sand falls. Checking from bottom to top is important to avoid sand getting stuck on top of other falling sand, and horizontal order changes the outcome too. Alternating between left right checks and switching the order every process step made the sand fall most realistically.

Other elements in the sandbox have similar simple interactions, liquids check left or right instead of diagonally, gasses act the same but reversed vertically (and added random left/right for extra floatiness). These material types are stored as an enum within a particle struct also containing: density, lifetime, and temperature. The sprite is a 2D array of these particle structs.
I chose to hold the data for the particles in a struct rather than a class due to structs being a value type rather than reference, meaning it is contiguous in memory and looping over the grid of pixels becomes much more efficient due to less cache misses. I later learned that opting for a data oriented design approach would be even more efficient as storing all pixels individual characteristics (density, lifetime, etc) in separate arrays further reduces cache misses in parts of the code where only a few characteristics are read.

Optimisations:
The first optimisation was to keep a list of active pixels to iterate over rather than checking the whole image, removing pixels from the list when they had nowhere to move and readding the ones above when removing pixels. Next, I learned how Noita handles their falling sand and used spatial partitioning to break the image down into smaller chunks to only process chunks that have pixels in them. This allows me to keep a rect that covers all the pixels per chunk and iterate over the rects instead, which is more efficient as having a single list can become incredibly large and not cache friendly when the pixels are not ordered by position. This also allowed me to parallelise the simulation as parallelising each pixel would not be efficient due to pixels having race conditions checking and moving into neighbouring cells. Chunks can be parallelised in four passes so that no adjacent chunks are being processed at the same time, though this does require either a second buffer or a simple bool to check if a pixel has already been updated this process step as pixels can move into other chunks and get processed twice.

Contributions:
A solo project, all shown artwork and code is my own.

Context:
A personal project developed in Unity C# and published on the Play Store (now delisted). My first game developed not following a specific tutorial, prior to University. It gave me a good insight into different aspects of game development, the artwork, music, localisation, setting up a store page, and actually releasing a finished game.

Reflections:
As it was my first game, there are lots I would have done differently if I were to do it over. Firstly, the scope of the project was very large for a first game. When I started development, I went in with the intention of seeing how far I could get without a specific tutorial; I was sure that I wouldn't be able to create certain aspects... and then I did. This gave me the confidence to dive head first into things to figure them out when I'm unsure, something I still follow to this day (see Dronescape). Though, having much more experience now, I am better able to plan in advance to better manage my time.

Penguin Voyage also taught me the importance of developing tools. Each level in the game (of which there are more than 100) was painstakingly designed, tweaked, and tested by hand. In hindsight, it would have been so much quicker to design a tool to automatically test and balance enemy levels. Again, a plan helps.

Though, one of the hardest lessons I learned from Penguin Voyage was that, much like the crew of penguins within the game, you can't do it alone. Game development is collaborative; the best ideas often come from iteration, bouncing ideas off of one another in a team, and getting feedback from players. Getting feedback for the games I have put so much time and effort into can be intimidating, but the gamejams I have since had the privilage of being a part of have taught me that it can be the most rewarding too. Even for solo-developed games, having the faults of your ideas being exposed is essential, being open to ideas changing and evolving is part of making a great game even if it can be difficult at times. Since Penguin Voyage, I have spent a lot more time getting feedback from players and developing games alongside my peers at university, and it has deepened my appreciation for game development and great games a whole lot.
Penguin Voyage will always hold a special significance as my first game.

Penguins:
Penguin data that needs to persist across play sessions is stored in a class with their instances also having an ISavable interface, which is called for each object within the scene when the game needs to save or load. This allows for the game to call save on all objects that require it at once.

Each penguin has a profession, represented as an Enum and used multiple times throughout the game.
Penguins in battle inherit from a base PenguinAttack script with functionality for the specific professions in their derived classes. A dictionary with the profession enum as the key is used to instantiate the correct penguin type during battle.
The profession enum is also used in the main menu and in cutscenes to get the value of what sprite the penguin should have, so that the players' penguins appear in the cutscenes. This is possible as the cutscenes use Unity's animation system rather than being videos.

Contributions:
Developed in a team of seven, I was responsible for the cooking simulation, the individual actions (chopping, marinating, skewering, frying, serving) as well as the ordering of the tasks and hint system. We used a package for splitting the mesh while chopping.

Context:
A university project developed in Unity with C#. We were assigned a games company as a client who gave us a prompt to build the game around. Communicating with the client, testers during playtests, and our lecturers to refine the game based on feedback.

Hints and Guidance:
We wanted the cooking to be exploratory and not hold the players hand too much, From the first playtest a lot of the enjoyment came from figuring out how to cook the meal on your own.. and if you wanted to chop the carrot into a million pieces you could do that too (because that happened a lot).
While there were limitations, you couldn't 'lose' cooking. The risk of having it more open to exploration is that the player may not understand what to do, which can quickly lead to frustrations and understanding may vary with players' previous cooking experience. To ease this, there were a number of small changes and additions made, one such being the silhouettes of objects when holding an item to show where it would go if you clicked with it, what it could interact with. This was done by duplicating the object's visual components when it was picked up, with a translucent shader applied to the clone and then positioned based on a raycast from the cursor position, depending on what it hit and what was interactable by the current object. The clone was then destroyed when the player interacts with the item.

Another addition was the hint lights that shone on where the player should interact next to progress the cooking and was based on what current tasks had been completed as well as what the player was currently holding. This required careful tweaking from watching playtesters to ensure it wasn't too delayed or too pestering.

One final addition to make it easier was making all the objects in the scene easily movable without breaking the logic of the tasks, to allow for designers to adjust the cooking layout easily based on game flow and what logically makes sense next to each other.

Polish:
Another thing we learned from the playtests is that the players found chopping the ingredients super satisfying and we wanted to lean further into it; combat would be the tension and cooking is the release. No lose condition, relaxing music, player can play at their own pace. To further this goal I implemented a number of small elements of polish to improve player experience.
The first is the animation of moving the ingredients to their own plate after chopping as before they would just teleport there all at once. I changed that to be an animation teleporting one after another in a coroutine with a short pop sound, random velocity and above the plate so that you could see it fall. This leaned further into the many players who liked chopping the ingredients really small as the animation would play longer and be more over the top for the number of ingredients being added.
Skewering the ingredients felt flat and uninteresting, for this I added screen shake whenever the player skewered. I also made the skewer animation draw back quickly and accelerate, exaggerating the aggressiveness of the movement really helped give weight to the players click, you could feel the skewer being thrusted down. There is also a 'skewer buffer' implemented so if the player clicks towards the end of the previous animation it stores the input for a short duration and still performs the next skewer, to avoid the frustration of clicking slightly too early and nothing happening. Furthermore, I added a shadow below the skewer that animated when it's hovered over an ingredient via raycast, which helped reduce the frustrations of missing an ingredient.
Another small thing we couldn't have known without playtesters is that the freedom would also inspire players to do things we hadn't expected, like chopping the tablet that had the cooking instructions on it. To play into this and avoid players expecting something and not being rewarded for it, I added a glitchy animation with a sound effect to chopping the tablet. It was a small thing most players had no idea about, but seeing the reactions of the players who did find it made it all worth it.

Contributions:
Developed in a team of three programmers, I was responsible for creation of the tracks (including obstacles, itemboxes, boostpads etc), as well as all models (besides from the police car model), player steering animations, race results screen, and implementing sound effects + music.

Context:
A university project developed on PS5 devkits using Abertay's in-house engine Skateboard (Entity component system C++).

Lighting and Models:
Though not a programming specific issue, one of the big limitations of the engine is that it only supported one light. This was a pretty big issue as it meant that even with a directional light, more than half of the game would be in complete darkness. To get around this issue, I created all the models with the limitation in mind. Firstly, we used a directional light pointing straight down to illuminate the ground and top faces of the models. Then I created the models with slanted vertical surfaces so that they were always facing at least slightly upwards, causing them to be illuminated. This is why the walls are slightly slanted and the characters are slightly cone shaped, though not that noticeably.

Track Generation:
Tracks are generated using a 2D array representing track tiles that are looped over and instantiated into the world. Track tiles contain lists of the objects within them, such as boostpads, itemboxes, and obstacles like trees. They also contain any colliders like offroad, pits, and walls. This allowed us to quickly create tiles that we could reuse for a variety of track layouts, easily enough that another developer could also help make layouts. Finally, tracks also contained a theme enum so that the tiles could be instantiated with different textures depending on theme, allowing for unique looking tracks while using the same system for generating them. This system also made it easy for the programmer responsible for AI and race logic to implement invisible checkpoints on each road tile for counting when a racer had completed a lap.