game design

• core idea

  • this project was our final project at Vancouver Film School with about 6 months of dev time. 

  • during an early brainstorming session, we conceptualized an on-rails delivery game. 

  • from this initial concept, we created a core loop of picking up packages, movement, and delivery. think something like Crazy Taxi (which was a big reference point for us)

• reference gathering

  • now with a vision, we researched reference games, taking inspiration from games such as Crazy Taxi, Bomb Rush Cyberfunk, and Jet Set Radio! we aimed to replicate their skill-expression, map design, and satisfying movement.

  • after understanding some genre standards, we implemented secondary features such as grinding, boost, a score system, and ramps.

• documentation

  • I was responsible for a large portion of the documentation including the GDD and LDD, specifying features as a reference for the team.

level design

• my main responsibility on ShredEx was to design and create the open-world. as a team, we thought the environment should be a city with several distinct districts. 

• as development progressed, the level scale increased until it eventually became the largest playable-space map in Vancouver Film School history (at the time of development).

• 2D layout

  • i often found the quickest way of making drastic map flow changes was with 2D layout iteration. this allowed me to ideate freely without committing much time.

  • in my layout process, i initially created layouts prioritizing believability/immersion first with gameplay coming secondary. however, i found the flow of these maps much too linear, lacking interesting choice or skill-expression. 

  • to fix this i started fresh, now focused on movement flow and gameplay first.

  • with mentors help, i discovered that a "hub-and-spoke" map design would be effective for our intended flow. using a central hub that branches out into districts with a long outer-route circling the entire map perimeter ensured there was always a route forward for players, with no dead ends. 

  • to balance the paths, I placed a majority of delivery dropoff spots inside districts, forcing players to stray from safer "highway" routes and improvise their navigation. 

• 3D blockout

  • due to the large map scale, i quickly realized i would require some more man-power to finish it in time. luckily, our project manager had scope available and helped create one of our three districts. 

  • using Unreal's sublevel system in tandem with source control, we were able to save a lot of time by simultaneously working on map sections together. 

• delivery routes

  • designing delivery routes was the most important part of my role. making sure routes felt smooth, had meaningful choices, connected to other routes, and communicated to players efficiently. these all were my biggest challenges. 

  • the main design process i used to create routes was:

    • placing the goals (delivery points) across the map 

    • creating paths between them, supporting the map's intended flow design

    • then finally, placing package pickup locations in convienent spots.

  • my intention with package pickup locations was to ensure players naturally collect packages while on their routes, not needing to go too far out of their way to collect them, as I wanted the focus to be on the delivery aspect.

    • to do this, i placed a majority of packages surrounding delivery dropoff locations, making players likely to pickup new packages after successful deliveries.

• combo/score system

  • another of my responsibilities was designing and balancing the score system. 

  • the intention of this system was to give active performance feedback to players and to give a highscore, adding replayability and competition. 

  • this system added more depth to our movement, but also unpredictably increased the challenge of level design. i now had to re-design the map around combos. because score is given through grinding, airtime, and deliveries, all routes now needed enough of these elements to keep combos alive while flowing from route to route. 

    • a challenge i faced here was making routes feel unique/interesting while also needing to rely on a small number of gameplay elements.

    • to solve this issue, i tried to create a memorable moment or landmark on each route. (ex. grinding on powerlines on one route vs grinding on a skytrain railway on another. although these are the same mechanic, the new presentation and flow kept them fresh)

• tutorial

  • although we had many systems to communicate, we wanted to get players right into the action and feel it out for themselves; so, we decided on an indirect tutorial. 

  • to create this, i started the player in a more linear, sectioned-off part of the map, to act kind of like an intro level. this area lets players experiment with the movement at their own pace. then when they wish to progress, the player is indirectly forced to use all the game features before they are sent out into the open-world. 

    • my belief is that showcasing the features in a linear order like this helped introduce players to their goals and all the tools available to them in a digestible form without removing any of their agency.

playtesting

• playtesting was a crucial part of ShredEx's development, helping us with direction, balance, and overall player enjoyment.

• to ensure we received constant feedback on our work, i hosted multiple playtests every week. this playtest process included:

  • watching players and taking notes in a developer document i created. on this document was a map of the level, developer observations, playtester feedback, and the build name. these sheets proved useful for organizing feedback. by the end i had around 50 filled out documents.

  • after playtests, i had players fill out a short feedback form. this forms main intention was finding who fit within our target audience so we could prioritize our feedback accordingly.

  • i would then take the notes and organize them into another form for easier review by the team.

• additionally, we held developer playtests for 30+ minutes every morning to play the latest build together. here we could give feedback to each other, find bugs, and see overall progress. any dev notes were put into a form for further review.

set dressing

• the last of my responsibilities was set dressing the world by placing props, interactibles, moving elements, vfx, etc.

• this was fairly easy work as I could reference our mood board of city environments; however, because of the scale of our world, setdressing took me much longer than I had anticipated. especially considering each prop was hand-placed and we didn't really have any modular tools.

new things i learnt!

level design pipeline

• the biggest thing i learned working on ShredEx is a proper industry-standard pipeline for creating large-scale, open-world levels. i learnt the relationship, strengths, and importance of 2D layouts, blockouts, and playtesting.

​

flow-focused/open-world design

• with racing and platforming being so important to ShredEx, a majority of my focus was surrounding player flow and the open-world design. i learned quite a lot about how to effectively use navigation, landmarks, negative space, meaningful choice, and many other level design tools.

​

Unreal Engine 5

• ShredEx was built in Unreal Engine 5, meaning i got to learn the ins-and-outs of the engine and many of its useful tools such as sublevels, splines, procedural generation systems, and visual scripting.

takeaways/post-mortem!

ShredEx is the biggest game project i'd worked on so far and i very much enjoyed working on it with such a great team! 

​

as a result of my work, i ended up winning the "best in level design" award which is presented by Vancouver Film School's level design instructor to only one student per graduating class!

​

post mortem:

although i am very proud of ShredEx, there are a few things i have used as learning lessons going forward:

• one of my responsibilities i believe i failed at is the opening cinematic/trailer. i'd never done video editing before let alone for a game cinematic and it ended up being left until last minute, only giving me time for a single pass. i learnt to always leave time for multiple passes on everything, especially on tasks i dont have experience with.

• an element of map design that suffered was the verticality. i wanted to experiment with height (ex. a crane in the industrial yard). however, this proved difficult to telegraph to players. i spent a lot of development time, that could've been used making the map more polished, trying to make this concept of verticality work. here i learned that being married to a specific idea when feedback says it isn't working, can be a sign to move on. Giving myself a deadline for proving new concepts out is something I will be doing going forward.

• i believe the map also suffered in some parts from its large scope. as development progressed, the characters speed kept increasing, resulting in the map needing to get bigger to keep up. this meant each area got less iteration passes because i had to design such a large area. i believe if we instead slowed movement down to account for our scope, we couldve had a smaller, more polished map. from this i have learned to prioritize polish and iteration over scope.

• due to the pipeline i was following (creating a detailed 2D layout, then blocking it out) i often felt by the time i had blocked out my map, i had already spent too much time on it to scrap anything. as a result, some core map elements ended up flawed, requiring make-shift solutions later-on. from this i learnt to start small and experiment more with quick iterations/ideation early-on, switching between 2D ideation and 3D gameplay often.