

Road de Versaille
A cute match 3 browser game depicting your journey to Versailles. Collect the right tiles to follow the map, collect the wrong ones and you'll get lost. Your car battery is broken though, so make sure your speed never hits 0 otherwise it's game over.
I was both UI artist and producer for this project.
Click here to play

The Journey
(The development one, not the road trip to Versaille)
‘Road de Versailles’ was my first time acting as producer and it truly opened my eyes to how much work goes into game design from all the disciplines. Up until this point, I had stayed firmly within my realm of art and UI design and was hesitant to step outside of it until I was functionally shoved into the deep end of the pool. That said, I like to think that I learnt to swim fairly quickly. Within half the allocated development time, we had functionally finished the game despite my ensuring that all members of the team had reasonable hours and were sharing the workload in a healthy manner.
02
UI Design
UI Buttons were in the form of badges and pins, with the pause button as a sticky note. Menu backgrounds and the playable area were done in the style of corkboards. The overall design was meant to mimic scrapbooks, remnants of a trip that had already happened that you could idyllically reminisce upon with the completion screen having a collection of post cards made by artists on the team as a final send off to the player.

Post-Mortem
aka undigging my own grave
It was a little strange, trying to balance the team's workload as I am self-aware enough to admit that I can get sucked into productivity spirals very easily and often overwork myself. As such I was deeply worried that, despite being assuaged by the team, I was overworking them. Nonetheless, I’m glad that the game came out so well especially since the most important thing for me about making ‘Road de Versailles’ was ensuring that all members of the development team had the opportunity to either learn something new about the development pipeline and/or had the chance to showcase their specialisms.
As the project progressed, I learnt about the difficulties and concessions different specialists have to make to make sure that the game worked. For example, we wanted to create a speedometer system, as seen in the game, and as an artist I always would just focus on backgrounds and art assets and making sure the parallax in the background ran smoothly. As producer, however, I had to be the point of communication for the coders and the designers. The designers wanted to implement more difficulty to the game (slightly contradicting the whimsical game we were aiming for) and, while the coders could do it, I had to balance timing and other juicing aspects for the game. "Was the time spent on the speedometer system worth it, or would it be better spent elsewhere?" Not only that but I had to constantly remind the designers of the dilemma’s that came with scope creep.
Further, communication was something I had to be extremely careful about, given the project was done during Covid lockdown, so keeping track of my team was hard. To make sure that we were on top of things I implemented two meetings in the day. The first was at 11am to make sure everyone knew what they were doing for the day, having specifically chosen that time so that everyone had a chance to set up and didn’t have to rush to get ready. The second meeting was done at around 5pm, at the end of the standard workday, this was done to check in on the progress of the day and to see if the workload needed to be redistributed, if there were any sudden issues that needed to be taken care of urgently, if there were any things that needed to be done across disciplinary fields, etc.
With this fairly rudimentary system, and despite my own lacking experience in a producer’s role, I’m proud to say that we succeeded and made an outstanding game.