Hi, I’m Aurora

I’m extremely honoured to announce that Overshadowed won the award for Best Game in the Game Design Methodologies subject at the UTS Tech Fest Games Showcase.

Overshadowed is a puzzle game about a cat who has split from it’s shadow. The cats are controlled simultaneously, with the same set of controls, but they interact with mechanics differently — for example, the shadow cat can walk through glass, but it disappears when a light shines on it.

The highlights of the night, for me, were discussing the inner workings of Overshadowed. Of note, one child who spent around 40 minutes beating the game, and found more bugs than all other players did over the course of night (I suspect he has a bright future as a QA tester).

A particular highlight was meeting Naresh Hirani, on whom I unloaded a truly vast amount of information with great enthusiasm (a photo of which exists; it looks like I was about wallop the him).

I must give thanks to Riot Games for their (in my utterly unbiased opinion) excellent judging, and MSI Australia for their vast stash of gaming mice, two of which were bestowed upon me as a prize.

I have learned a lot through developing this project. A non-exhaustive list of these lessons are:

• Puzzle Design. This wasn’t a discipline I had particularly experimented with before. There are many things I learned from this — some of which I will discuss in later points — but an aspect which I struggled to accept was that I had to stop trying to show off to players. I’m writing particularly about the final puzzle of Level 3, which makes clever use of the glass mechanic, elevation, and blocks disrupting light flow. While these are all conceptually interesting ideas, users were consistently confused, and really struggled with this puzzle. What I should have done is rework it from the concept up, but I was so pleased with it that I just kept tweaking it, and ultimately, users never really got it.
• Art Style. Effectively all of the (3D) art assets in this game are store-bought. I am very proud of the way we integrated them together, to form a cohesive and relatively unique visual identity. Ultimately, this was guided by the artistic vision we had — calm, minimal, similar to Monument Valley. This effect is achieved by two main things: shaders, and lighting. We performed colour-space quantisation on the full frame, which reduced the number of colours and helped create the minimal effect. The sky shader with stars both highlighted the minimalism of the level design, and provided a visual bridge between the hand-drawn style of the trailer, and the minimal 3D style of the game.
• User Testing. This is by far the most important learning of this project. User testing is incredibly vital and there is no amount that is “too much”. There are countless things we changed as a result of user testing, the most important of which was the control scheme. Overshadowed is an isometric game, so choosing a control scheme presented a challenge. In testing, users chose screen-space coordinate controls and world-space coordinate controls at an approximately 50/50 rate. Ultimately, I created a system to automatically assign a control scheme to users based on their first second of inputs (unfortunately, by the time I had implemented it, I had run out of time to user test). It was a mixed success — it certainly helped some users, while choosing the wrong control scheme for others. Realistically, I think a better solution would be to explicitly prompt the user, but I (once again) got distracted trying to be clever, at the cost of the game. This project truly drummed the importance of user testing in my head, a mindset I have taken forward into my other projects.

To play or read more about Overshadowed, go to auroraechoes.dev/posts/overshadowed.

All em dashes in this post were ethically sourced. No LLMs were used in the creation of these, nor any other punctuation marks.

I’m pleased to release my portfolio website, auroraechoes.dev. It’s still a little rough around the edges, but over the coming days, I will add more of my games, and generally improve it.

I created Overshadowed (along with Harlen Postill, Alexander Maturan and Gordon Huang) for a Game Design course at university. I was primarily responsible for gameplay programming, as well as designing Level 3.

Overshadowed was featured at the UTS Student Games Showcase and won Best Game from Game Design Methodologies.

Technologies Used

Lessons

• Puzzle Design. This wasn’t a discipline I had particularly experimented with before. There are countless things I learned from this — some of which I will discuss in later points — but an aspect which I struggled to accept was that I had to stop trying to show off to players. I’m writing particularly about the final puzzle of Level 3, which makes clever use of the glass mechanic, elevation, and blocks disrupting light flow. While these are all conceptually interesting ideas, users were consistently confused, and really struggled with this puzzle. What I should have done is rework it from the concept up, but I was so pleased with it that I just kept tweaking it, and ultimately, users never really got it.
• Art Style. Effectively all of the (3D) art assets in this game are store-bought. I am very proud of the way we integrated them together, to form a cohesive and relatively unique visual identity. Ultimately, this was guided by the artistic vision we had — calm, minimal, similar to Monument Valley. This effect is achieved by two main things: shaders, and lighting. We performed colour-space quantisation on the full frame, which reduced the number of colours and helped create the minimal effect. The sky shader with stars both highlighted the minimalism of the level design, and provided a visual bridge between the hand-drawn style of the trailer, and the minimal 3D style of the game.
• User Testing. This is by far the most important learning of this project. User testing is incredibly vital and there is no amount that is “too much”. There are countless things we changed as a result of user testing, the most important of which was the control scheme. Overshadowed is an isometric game, so choosing a control scheme presented a challenge. In testing, users chose screen-space coordinate controls and world-space coordinate controls at an approximately 50/50 rate. Ultimately, I created a system to automatically assign a control scheme to users based on their first second of inputs (unfortunately, by the time I had implemented it, I had run out of time to user test). It was a mixed success — it certainly helped some users, while choosing the wrong control scheme for others. Realistically, I think a better solution would be to explicitly prompt the user, but I (once again) got distracted trying to be clever, at the cost of the game. This project truly drummed the importance of user testing in my head, a mindset I have taken forward into my other projects.

All em dashes in this post were ethically sourced. No LLMs were used in the creation of these, nor any other punctuation marks.

Stuff It, We Snowball was made in 28 hours for the 2025 Tech Fest / Riot Games Game Jam, in which it won the theme for “most intuitive game”. The theme for the jam was “enlarge”.

It was such a success that I am currently developing it as a mobile game for iOS and Android.

Technologies Used

Lessons

• Physics Isn’t The Enemy (With Much Tweaking). I’ve previously had painful experiences with game engine physics (which, who hasn’t?), so I was relatively worried about making Snowball feel good — bearing in mind that the physics is the core mechanic, so if it wasn’t fun, the game wouldn’t work. I’m ultimately extremely proud of how Snowball feels to play, which is as a result of a vast number of tiny physics tweaks (which I am only barely restraining myself from discussing in detail). Of the 28 hour jam, easily 2 or 3 hours in total were spent just rolling down the hill and tweaking values. User testing with my long-suffering family was extremely helpful in this regard, too.
• Perspective Is Everything. A problem I ran into while developing Snowball was that it didn’t feel like you were rolling down a hill. Even when the slope was pointed downwards so steeply that all that one could see of the skybox was the brown ground colour, the game didn’t feel downhill — it felt as though the ball was moving across a flat plane, propelled forward by some unknown force. The solution to this was provided by Mr Luke Ledwich of Riot Games, who diagnosed the problem as a lack of vertical references. Game obstacles, at the time, were perpendicular to the slope, as opposed to being directly vertical. Changing this made a world of difference to the game feel, and taught me that — much like other forms of game design — simply being physically accurate is rarely an objective to strive for; rather, I needed to explicitly demonstrate aspects of my world that I want players to notice.
• Simpler and Polished is Better. This is a lesson I first began to learn with The Hacking Minigame, however I think I applied it here to great success. Having a simple game which was quick to implement left me free with plenty of time to polish — particularly, the aforementioned physics tweaking (along with other related values) was, to my mind, crucial to Snowball.
• Sleep Isn’t Actually That Important. Exhaustion is temporary. Winning is forever.

All em dashes in this post were ethically sourced. No LLMs were used in the creation of these, nor any other punctuation marks.

The Hacking Minigame was made for the Playmakers March Game Jam, in which it came 5th. The theme for the jam was “Restart”.

Technologies Used

Lessons

• Game Design Scope. In previous game jams, my approach has been “what’s the most ambitious thing I think I can make within the time limit”. In contrast key success of The Hacking Minigame is it’s conceptual simplicity. Technically, the game is made up entirely of UI nodes. I had a basic implementation working within an hour of the game jam beginning. I’ve heard the adage that a game jam game should have one idea, and one hook (in this case, Cyberpunk 2077’s hacking minigame, but with multiple varying objectives), but I had never particularly applied it. However, I think that is a good framework for game jams.
• Idea vs Execution. The quality of the idea is questionable, as I will discuss in the next point. However, I was surprised by the degree to which execution enhanced a somewhat conceptually flawed experience. The game’s constrained scope allowed me a lot of time to polish and refine the experience, adding elements like shaders, sounds, and the intro sequence. Users valued the level of polish to a degree which I found unexpected; it’s hard when programming games to view them from the user’s perspective. In future, I should focus more on polish.
• User Investment Must Be Earned. Unlike me, users found the game difficult to get into. The elements I found satisfying — meticulously planning sequences to achieve the goal — users didn’t enjoy, because it required them to invest valuable brain power, investment that I had yet to earn. This meant a lot of users bounced off, or worse, selected options at random until they died. The game wasn’t overly hard, but it was overly tedious, and despite trying to mitigate this with the game doing all the maths calculations, it was ultimately too much. In a game jam context, less taxing is better, because user investment in your game is low.

All em dashes in this post were ethically sourced. No LLMs were used in the creation of these, nor any other punctuation marks.