Scarlet Sprite Games
This project, created in a team of 8, was created as a student-led brief with Rockstar as our client. As Catalyst games, we've spent 4 months developing this project - working closely with our client. It was showcased as one of only 8 projects during Abertay Offer Holder Day.
​
In a team of 3 programmers, the project had few innate technical challenges; aside from the rhythm minigame and a large dialogue system, most systems were simple.
​
My core responsibilities on the project were UI functionality and implementing dialogue.
Dialogue System
The dialogue system was one of the most technically challenging parts of the project. That's because after considering multiple solutions, we settled on a solution that could support long, non-linear dialogue.
The dialogue also had to be easy to trigger from various sources; event triggers, boss progression and various scripts. All while being easy to use by our writers, and ensuring the written dialogue would not be lost between various versions.
The graph editor itself was created by a groupmate, following a tutorial series.
I integrated the data created by the editor into the game, as well as extended it to handle character sprites and names. I've also implemented handling branching dialogue.
.png)
A major setback was learning that the experimental graph-view namespace we were using was not yet build compatible. As a result,
I had to separate the dialogue editor functionality; no graph view derived functionality and utilities could be accessed at runtime.
Furthermore, though instantiating scriptable objects was possible, retrieval of data from them was not. I implemented a twin-save method; to/from Scriptable Objects and .Json files.
Admittedly not a clean solution, it allowed us to continue using the graph view and not regress to my placeholder linear system
UI implementation
UI implementation required a fair bit of fine-tuning and iterating, despite its simple appearance. With frequent changes from client feedback, fine-tuned art assets and evolving gameplay flow, it was constantly evolving.
​
Switching between various screens and pop-ups, while ensuring proper layering order and toggling many elements at once took a fair bit of bug-fixing.
​
As I was ahead of my backlog on multiple occasions, I've been permitted to add a handful of interface effects for a greater sense of polish.
While the development of the project took place between February and May 2023, ideation started in September 22 and building the team started in March 2022.
​
One of our main goals was to make a game which all of us would be interested in. Using a questionaire, we figured out everyone's dealbrakers and slowly but surely homed in on a genre that everyone would be comfortable making.
Pre-Production
A
B
C
Initially, the combat system was much more complex: we all liked the idea of a buff-steal mechanic, where after killing a given enemy, player would receive a specific temporary power-up. I've broken up the sub-systems required for implementation.
​
As pre-production continued, we realised we did not have the resources for fully animating many minor enemies. The idea was scrapped in favour of bossfights with single enemies, greatly simplifying the system.
Some of my early system ideation. I was a big proponent of using ranged combat rather than melee early on, but after some revisions the team settled on melee combat.
Teamworking solutions
I was responsible for GitHub administration for the project for 3 programmers and 2 designers. Though I handled art implementation for most of the project, that was done outside of GitHub for stability's sake.
​
I used a weekly cycle, as opposed to bi-weekly sprints of the rest of the team. Every week, everyone would pull from a weekly core branch (IE. week 7), and implement features needed on their weekly branch (IE. Mick_w7). Once ready, I'd handle merging branches; merging into mine (IE. Dave_w7 >> Mick_w7), and checking they are stable. If stable, they are merged into the main weekly branch (Mick_w7 >> week7). At the start of each week, a new main branch is created, everyone creates their individual branch from it and the last weeks branch is kept untouched as a stable backup. This method ensures continuous check-ins and that everyone has a reasonably up-to-date version of the game that they add features on top of, reducing conflict errors and overwriting new versions with old versions.
Before Jira was set up, I broke up the features needed by the game into a roadmap, so we could prioritise and divide tasks from day 1 of production.
Despite initial skepticism of my peers, I did maintain a high output throughout, the project, only slowing down during spring break.
Prototyping
Since the wireframe of UI was implemented early, a lot of time was left for bugfixing.
Week 14
During week 7, I was ahead of the backlog so I could address client request of full controller support. I’m pleased with the result, particularly as I’ve never tackled controller input before.
Week 1
Week 7
If interacted with “normally”, the UI flow would be smooth. However, by simultaneously using multiple toggles, undesired effects were prevalent.
Polish & Fine-tuning
Thanks to establishing the game concept early and great pace of progress of the
programming team, we had a fair bit of time for adding minor improvements to animations, effects, UI, dialogue combat and VFX. While small on their own, they compound into gameplay which is more satisfying and professional.
I found a way to greatly reduce file-size. The original design made shallow copies of each node's children, and unintentionally recursively their children. By changing it to a hash value reference, children data could be retrieved just as fast, while file size was reduced 7-fold.
