game design

• core idea

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

  • during one of our team brainstorming sessions, we conceptualized an on-rails delivery game. 

  • from this initial concept, we created a core loop of picking up packages, movement, and delivering those packages. think something like Crazy Taxi (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 intensity, map design, and satisfying movement.

  • after understanding more 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 level. as a team, we ideated a cityscape with several distinct districts. 

• as development progressed, the level scale kept increasing until it eventually became the largest map in Vancouver Film School history.

• 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 maps prioritizing believability/setting first with gameplay becoming secondary. however, i found the flow of these maps much too linear, lacking meaningful choice. 

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

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

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

• 3D blockout

  • due to the large map scale, i quickly realized i would require some help to pull it off. luckily, our project manager had scope available and helped create 1/3 districts. 

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

• delivery routes

  • designing effective delivery routes was the most important element of my role. making sure routes felt smooth, had meaningful choices, connected to other routes, and directed players correctly was my biggest challenge. 

  • the design process i used to create routes was:

    • placing the goals (delivery points) across the map 

    • creating paths between them, supporting the map flow design

    • placing package pickup locations

  • my intention with package pickups was to ensure players naturally collect them on their routes.

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

• combo/score system

  • another of my responsibilities was designing/balancing the score system; although, other team members also worked on this feature. 

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

  • this system added depth, but also increased the challenge of level design as i now had to design around combos. because score is given through grinding, airtime, and deliveries, all routes now needed enough of these elements to keep combos alive. 

  • a challenge i faced here was making all routes feel unique/interesting while having the same gameplay elements.

  • to solve this, i created a memorable moment/landmark on each route. (ex. grinding on powerlines vs grinding on a skytrain railway. although these are the same mechanic, the presentation keeps them fresh)

• tutorial

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

  • to do this, i started the player in a linear, sectioned-off part of the map. this area lets players experiment with movement at their own pace. then to progress, the player is indirectly forced to use all the game features. 

  • my belief is that showcasing the features in a linear order like this helped introduce players to their goal and the tools available to them in a digestible form without removing 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, i hosted multiple playtests every week. the playtest process included:

  • watching players playtest 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 all the notes and organize them into another form, this way i could simplify them for easier review by the team.

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

set dressing

• another of my responsibilities was set dressing/making a living world by placing props, interactibles, moving elements, vfx, etc.

new things i learnt!

level design pipeline

• the biggest thing i learned working on ShredEx is a proper pipeline for creating a level. 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 ive 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 presented by Vancouver Film School's level design instructor!

​

post mortem

• although i am very proud of ShredEx, there are a few things i felt were lacking and have used them as learning lessons going forward. 

• one of my responsibilities i believe i failed at is the opening cinematic/trailer. i'd never done cinematic video editing before and it ended up being left until last minute, only giving time for a single pass. i learnt to always leave time for multiple passes, 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 better, trying to make this concept work. here i learned that being married to a specific idea when feedback says it doesn't work, is generally a waste of time.

• i believe the map also suffered from its 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 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.

• i learnt to not be afraid of starting fresh! 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 it. as a result, core map elements ended up flawed, requiring make-shift solutions. from this i learnt to experiment more with quick iterations early-on, switching between 2D ideation and 3D gameplay often.