My primary responsibility in this project was to design and build a map environment for our player-controlled robot to drive in and deliver orders. I focused on creating an authentic representation of part of the Oregon State University campus, while making adjustments to fit the gameplay.

• Reference-Based Design:
  • Since the map was based on a real-world location, I always had a reference for placing various detailed objects such as foliage, buildings, walls, and street lamps.
  • This made the level design process different from typical projects, as much of the layout was already planned based on the existing campus environment.
• Object Omission for Gameplay:
  • There were many obstacles, such as trash cans and signs, that made it difficult for the robot to maneuver. I needed to determine which objects to omit to enhance gameplay.
  • To provide the player with more space to drive and avoid pedestrians, I added these types of objects sparingly, as well as reducing the amount of pedestrians.

One challenge I encountered while designing the level was determining how to handle the boundaries of the map. I tried several approaches:

• Fog (Inspired by Silent Hill):
  • Approach: I initially tried adding fog around the edges of the map.
  • Result: While it somewhat worked, it negatively impacted performance and didn't make sense within the narrative.
• Buildings with Walls and Doors:
  • Approach: I placed buildings with walls and doors at the boundaries.
  • Result: This compromised the goal of creating a realistic campus and looked unappealing, with flat buildings acting as barriers.
• Dirt Land Perimeter with Fence:
  • Approach: I added a large perimeter of dirt land around the map with a fence to block the player.
  • Result: This solution effectively stopped the player while maintaining a realistic appearance, as if that part of the campus was under construction or yet to be built. Performance was also unaffected due to static batching in Unity.

You can see the overall finished map design above, with the implemented approach I went with (dirt and fence perimeter).

I am not primarily an artist and this was my first time 3D modeling on a larger scale, so I had to start by researching lots of tips and techniques. I found that artists often taken reference photos and since my goal was to recreate parts of our university campus, I started by capturing over a hundred images with my phone. Not only were these helpful for modeling, but they ended up being useful as textures later on (after modifications). I used Blender to model streets, buildings, and sidewalks, before applying seamless textures I created from my images inside Quixel Mixer and an online synthesis tool.

The first thing I did for the UI was creating a mockup on paper for what I thought it should look like. Then after some thought, the challenge was to design a user interface that remained simple yet informative for the expo audience, many of whom had little gaming experience.

• Considerations:
  • Some players may want to drive around without paying attention to objectives.
  • Some players may want to speedrun to get the best time and need ample information to do so.
  • Some players may be unfamiliar with gaming and confused with too much pop-ups on the screen.
• Takeaways:
  • Base my design on the Rule of Three, and keep information on the edges and corners of the screen.
  • Avoid using the middle of the screen, using the tutorial for any information not needed at all times (ex: reset robot button).
  • Remove unnecessary elements, like the speedometer, which don't contribute to decision-making for players.

The next step in iterating on my designs was to invite playtesters to find any problems with the game, especially if related to clarity.

• Feedback Received:
  • The game felt too slow and it took too long to get anywhere.
  • The objective was sometimes unclear to the user.
  • It was very difficult to see where cars and sometimes pedestrians were coming from, especially from certain directions (ex: directly behind the player).
• Changes Made:
  • Added a boost ability to increase game speed.
  • Modified the compass to instead display a direct arrow pointing to the objective.
  • Introduced buttons to change camera views quickly and allow the player to see hazards easily.

This game project was very involved, but it was very rewarding in the end, especially when showing it to family and peers. Working as a group of four students with other classes and jobs, we had little time to communicate and work effectively as a team. This was easily the hardest part for me, but I think our goal of developing a fun and short game was successful in the end.

In terms of technical knowledge, I significantly improved my skills with Blender, particularly in modeling, texturing, UV editing, and exporting. I now understand how to synthesize textures in different applications and edit them in Quixel Mixer. Also, learning about seamless textures, tiling, and techniques like adding noise and random rotations has helped minimize repetitive patterns on my created surfaces. In Unity, I learned about using mesh colliders on imported objects and their interactions with rigid bodies based on topology. I improved my programming skills in C#, became better at testing features that need to be balanced (partly through conducting playtests), and learned how to do lighting.

Overall, I think there are a lot of necessary improvements for this project if it were to be revisited in the future. With our time crunch and poor communication habits, the final version of the game has several large bugs and poor performance. Features added towards the end did not have enough time to be properly tested, the map has a couple of collision issues, and the difficulty was harder than intended. With more time, better planning, and an in-sync team, I would love to implement a larger map, a better physics system, fix bugs, balance more appropriately, and adjust scenes for better performance.