Background
Movies like Hunger Games and Battle Royale along with video games like Fortnite and Player Unknown's Battlegrounds have created a completely brand new form of entertainment - the Battle Royale. This genre pits several players against each other in a contest of survival, combat, and exploration where only one single person can win.
We wanted to create our own Battle Royale - but we've played enough games at home during this past year. And so we decided to put a unique spin on the genre by creating Battle Locale - the world's first Battle Royale game that takes place in the real world, the perfect game for when the pandemic inevitably comes to an end.
What is Battle Locale?
Battle Locale is an exciting, competitive battle royale game that takes users on an adventure throughout their neighborhoods to see who can be the best.
1. Users compete against each other in groups of 10 players to see who can survive the longest in an ever-shrinking arena that is set at real-life locations.
2. Users can travel to landmarks to learn new spells that can be used to fight other players or restore health points.
3. Users can attack other players by getting within rangeof them. When a player's health points drop to zero, they are out of the game.
4. Once there is only one player left, that player is declared the winner of Battle Locale!
Planning
Creating a real-time, multiplayer, and location-based video game in the span of a single weekend is a challenging task. We managed to do it with very careful planning, coordination, and communication (Despite the fact that we were in a virtual environment). Here are some decisions that we made during our planning process.
The most impactful decision, without a doubt, was that we decided to make Battle Locale a web-based application, a stark contrast from other "real-world" games such as Pokemon Go and Ingress. We all strongly believe that web is the future and so we wanted to take advantage some of the latest (albeit experimental) technologies such as WebGL, Sensor APIs, and PWAs (Progressive Web Applications). This decision allowed Battle Locale to be cross-platform and easily accessible, available on Android, iOS, and even open-source mobile operating systems.
We also initiated our planning process by writing all of our documentation, before we even wrote a line of code. We began the hackathon in a multiple hour-long meeting discussing details such as Features, Post-MVP Features, Tech Stack, Database Design, API Routes, and Game Cycle. Feel free to check out our design documentation in detail at the link below.
https://docs.google.com/document/d/1LYjNriGGqOkz0QsmV3vTgRTj7eaYWuk3e7q00j1zROU/edit?usp=sharing
UI / UX
Our UI / UX Designer utilized Figma in order to create Low Fidelity, High Fidelity, and Final prototypes. He carefully designed our application's features, user interface, and user experience with careful consideration for the user journey. Our user interface also had to be designed in both 2D and 3D because we wanted our front end to take advantage of Three.js and WebGL.
Our design was split into flows because there are so many actions available to users
Front End
Our front end is built on a base stack of React, SASS, JavaScript, HTML, and CSS. We utilized Ant Design as an additional component library to help us quickly put together user interfaces. For the 3D aspect, we utilized Three.js to leverage WebGL to overlay 3D models on top of a map generated by MapBox GL. We utilize each device's internal GPS sensor, with web sensor APIs to track the location of the player character. Finally, we used Fetch API to send requests to our backend server. The information was then connected to all of the React components using Redux, Hooks, and other React technologies.
WebGL and Three.js allowed us to bring in beautiful 3D models
Back End
Our backend was built on Node.js and Firebase. We created three schemas in order to house all of our necessary data - a User schema, a GameStats schema, and a SpellTomes schema. We then developed algorithms for spawning in spell tomes at random locations and checking for when users are within proximity of other users or landmarks. Finally, the back-end team created a total of 15 routes to make all of the data accessible to the frontend.
We utilized a wide variety of technologies in order to develop our full-stack game
Challenges We Ran Into
For this project, we ran into some issues creating viable efficient algorithms for detecting player proximity to landmarks and other players. Due to the requirements of our application, we had to make sure that we provided as fast of a response as possible to ensure that it remained a real-time competitive game. The vast scale of this project and the limited time we had made it very difficult to optimize.
On the client-side, the biggest challenge was importing 3D models (GLTF files) from SketchFab into Three.js. Turns out, there's a bug in the latest version of Three.js, which ended up halting our progress continually for nearly 12 hours 😭. Additionally, overlaying the 3D models on the MapBoxGL map was difficult. Scaling had to be done to account for converting between latitude / longitude and feet, repeatedly.
We struggled with deciding the features we wanted for our project (initially it wasn't even going to be a Battle Royale game but rather a Defend Your Base Game!), deciding what types of data we needed to store in our database and deciding what routes we needed revealed to the frontend. With the time constraints placed upon us, we had to make many quick, often last-minute decisions on which features needed to be sacrificed. A lot of routes ended up, unfortunately, being unused and a lot of features ended up being cut to prioritize other ones. The chaos and hecticness of having such a big project was a huge challenge but also ended up being a wonderful learning experience!
What We Learned
Our team is comprised of a mix of seasoned and relatively new hackers.
The newer hackers were able to improve on previous skills and knowledge learned from class while also grasping new experience in technologies that weren't used previously. The more veteran hackers were able to guide the newer hackers in a way that strengthened their own understanding, and they were also able to gain some fresh perspectives through collaboration and constant communication with the rest of the team.
This way, we as a team became more comfortable working with new technologies and deepening our understanding of more advanced features and algorithms.
What's Next
We had a lot of fun coming up with and exploring this idea of a real-time Battle Royale game taking place in real-life locations. We have so many features we want to add! New game modes, events, player cosmetic items, additional spells, additional kinds of landmarks, an improved battle system (one that can use the upcoming experimental gyroscope and accelerometer APIs for motion control!), a story line, increased responsiveness, increased performance, - the possibilities are endless!
With Battle Locale, we aim to create a game that's enjoyable and accessible to everyone, while also promoting physical well-being and activity. We hope that with Battle Locale, we can assure that no matter where people are, they can easily find others to play fun games with and bond over an exciting competition.
Log in or sign up for Devpost to join the conversation.