Introduction
Delivery Dash: Da Nang is a local multiplayer game set in the town of Da Nang, Vietnam set during the COVID Pandemic during the year 2020. Each player is picking up and delivering orders around Da Nang while avoiding pedestrians, cars, road debris, and buildings in order to have the highest customer rating by the time the round is over.
Inspired by Crazy Taxi and real life situations in Vietnam, up to 4 split screen players can compete using rats as weapons, using their phone GPS, and strategically picking orders that are close to them to boost their score and harm their opponents.
Production Process
This project was conceived and pitched by the Project Lead Steven Solof (aka Stebs) who lives in Vietnam. The original prototype took place using JS/HTML but was recreated in Unity. Jeff Hanlon (aka Axphin) took the Art Lead using MagicaVoxel. Michael Fewkes (aka Misha) took charge as the Audio Lead. And I was brought in from the HomeTeam Outpost group as the Unity/Technical Lead.
As the project began, we were picking at small pieces of the project like adding generic buildings, generic bikes, generic nav meshes, a general map, etc. With some minor check ins with the team lead to see if we were on pace.
Once we started to feel out the chemistry of the team, our communication began to ramp up. As a result, much larger changes were being considered and implemented such as – core gameplay loops were created and fleshed out, then the code would be restructured by all 3 different people. A GPS system was created and tied to the order system. Then we would realize the map wasn’t working right in both the nav mesh, the poor frame rates, and restaurant and apartment location – that would mean the entire map was changed which meant every node in the GPS system needed to be moved, traffic patterns were recreated, restaurant and apartment order times were recalculated among other things.
The larger the project became, the more imperative it was to communicate the changes that were happening since all the systems were relying on each other. The key contributors on the project knew the others were doing what was best for the game so they were okay with other people touching their work so long as we communicated what we were changing.
A couple of examples were –
* I created the initial car and pedestrian traffic system. The map was changed and the system needed rework so Stebs took a shot at trying to fix it. He adjusted the cars and tried the pedestrians before passing it back to me and I finished the pedestrian system again.
* I started to create the multiplayer system through code, score, and split screen, Barış Köklü helped build the multiplayer input system, but since neither of us had 4 controllers, we relied on Stebs to test the 4 player system and provide us feedback.
* Brian Nielsen worked on the GPS system. I had meetings with him to connect the players to the system and to try to manipulate the system for our Enemy Delivery AI system.
About 2-3 weeks before the project was finished, we had about a dozen systems that were all ‘almost’ there. It didn’t feel like they would all come together and we started prioritizing what would and would not make it into the initial release.
During the last week, there were a flurry of changes of telling people what was changing, how long we would be in the scene, and commits at weird times in the day to try and avoid merge conflicts. But we did it!
Delivery Dash: Da Nang was released on time with a working 4 player system with GPS, traffic systems, enemy AI systems, and others. It was a whirlwind, but we made it through.
Challenges
Time Zones
With lots of people working on the project we were covering lots of time zones.
Stebs and I were exactly 12 hours apart for most of the project so when both of us wanted to work, we’d be contesting each other for being able to get in the game while trying to avoid merge conflicts.
Stebs was GMT +7, Baris (controller input system) +2 GMT, I’m GMT -6 (technical/Unity), Jeff was -8 GMT(art lead).
To avoid merge conflicts, we would mention in the Slack channel that we were jumping in to the scene so others wouldn’t lose their work.
Performance Problems
We were using MagicaVoxel for our art which gives it a low-poly/pixelated type of feeling.
What MagicaVoxel doesn’t do well is performance.
We were having what would be an under 10 vertices shape in Blender turn into 2.5 million verticies in MagicaVoxel repeated 50 times.
We also had the flooring, sidewalk, grass, and buildings all using MagicaVoxel. By replacing the 3d model with a texture, we were able to save 20 million vertices.
Different team members were running on different levels of hardware so we were painfully aware of when bugs, errors, or inefficient art were appearing. We had to spend a week bolstering our framerate from 1 frame per second to over 200 frames per second.
Christer Kaitila (aka McFunkyPants) helped us by creating Level of Detail (LOD) tools to help with occlusion of buildings, roads, traffic systems, pedestrians, and others. That tool help immensely in performance management.
It also didn’t help that my computer blue screened during the project and took nearly a week to fix before I could be up and running again.
Size of the Map
The original intention was to replicate the city of Da Nang down to the specific street with specific businesses, specific road marks, specific construction zones, etc.
We soon realized that was 1) out of our scope for a 4 month project and 2) not great for performance when you factor in art placement, pedestrian system, traffic system, and GPS waypoint systems
We opted instead to do a “Theme Park” version of the city where we capture the feel of the city with the various landmarks and people, but in a much smaller zone. That helped make certain areas feel more alive, large, and captured the vibe of the original game. Games like GTA, Burnout, and Red Dead Redemption utilize this tactic.
Multiplayer
A key piece to this game was the multiplayer aspect of it. The ability to have up to 4 players competing was cool, but it ran into logistical problems when the two people building the system (Baris and myself) couldn’t test it since we didn’t have the controllers. Instead we had to rely on Stebs (who had the controllers, but a lower performing computer) to give us feedback on what to change.
Bugs!
So many bugs. We had to spend a week in the middle and at the end of the project to fix problems we had been neglecting
It almost became a battle of – do we add this feature or go back and try to fix the bugs that had accumulated under the metaphorical rug we’ve been sweeping them under?
Feature List
We had lots of systems that all relied on each other –
* A driving system with 4 player support and split screen
* Connecting the player inputs to controllers to be able to play exclusively with the controller if the player desires.
* Character selection allowed for the player to choose from up to 4 different players
* An ordering system containing a pickup and drop off locations, a score system, this also worked with the GPS system.
* A GPS system using nodes all over the map to help determine where the player is and where their order destination is.
* A phone system that contained the ordering system, GPS system, score system, ranking system, and a review system.
* Enemy AI to give them orders, have them complete the orders, and have those scores feed to the GameManager.
* Both a traffic system for cars and pedestrians to give the world more life and use as an obstacle for the player(s).
* A Nav mesh system to help tell the player, enemies, cars, and pedestrians where they can or cannot go.
What Went Right
This was the largest project I had been on, both in ambition and team size.
With lots of people doing lots of cool things, the end product turned out much better than I or we could’ve alone. It was amazing to see everyone’s skills come together to pick up to fill the holes of another person’s weakness.
Weekly updates were critical. This gave a place for everyone to share the leadership during the meeting to explain what they did during the week and it allowed the other members of the team to fully understand what all was going on outside of their core competency.
Lessons Learned
This list is quite impressive since it was the largest team project I had been in. Lots of learning in play!
We had lots of systems at play
That also meant the systems relied on each other. If you changed one, you would need to check to make sure others didn’t break.
The help of Chris and Jonas were essential for some of the more complicated pieces of the puzzle. They are an excellent resource for getting unstuck.
We learned far too late in the project the power of Prefabs
Rather than informing the entire channel that we would like to work on the game, we could have said we were working a specific prefab (like the phone system, players, map, or GPS prefabs) which would have allowed others to be able to be in the scene working at the same time.
Newsflash: Multiplayer takes longer than 3 weeks to implement
Each player needs their own GPS system, ordering system, prefab system, line renderer, collision, score system, controller system and character customization.
It could have been easier to utilize in prefabs, buuuuuut, I didn’t do that. We kept changing items and I never knew when the player would be committed enough to prefab it so I didn’t do it… needless to say, that cost me a ton of extra work.
Some people had the skills to build the controller input system. Some had the skills to build the order system for the 4 players. Some had the extra controllers to test the input system and order system for 4 players. Lots of communication was needed to detail was what and wasn’t working especially since those 3 people spanned 12 hours of time zones.
Communication is key
This was the largest project I have been a part of, the most time zones I’ve covered of any project I’ve been in and the Most diverse skill set I’ve been involved in.
There was push back if things weren’t working right. Items would be reworked and tried again if things didn’t feel right (player feel, traffic system, order system). Having a strong enough relationship to trust your teammates and not be married to the first iteration saved a lot of frustration.
I would try to get updates from my teammates on weekly basis involving phrases such as – “These are my main priorities for the week, any changes” “Yes, add this, lower this priority” “Got it” to help determine my to do list, then following up by giving status reports through the week.
With all the people that were in the project working, it meant each time you jumped in, something had changed.
Detailed Github commit messages, messages in the group channel, and DM’s to different people, and letting people know when you touched another person’s system was essential to keeping everyone on the same page.
Summary
Studio: HomeTeamGameDev – Apollo
Title: Delivery Dash: Da Nang
Staff: 11
Budget: $0.
Total Play Time: 5 minute rounds
Development Time: 98 days (Dec 20,2020 – Mar 28,2021)
Release Date: March 28, 2021
Platforms: Itch.io
Software Used: Unity, MagicaVoxel
Game Link: https://hometeamgamedev.itch.io/delivery-dash-da-nang