Developing a Geospatial AR Game for Niantic’s Beyond Reality Developer Contest (Postmortem)

Baron Chan
15 min readJul 18, 2020

Inception

“Want to join a competition and make a game? It’s a $1 million dollars prize pool!” — asked Timothi when we met up when he came back to Singapore for a visit during his term break in March 2019.

Without giving much thought, I agreed. What I did not expect was a wild ride over the subsequent seven months, where we had the privilege of being one of the few people in the world to develop a game using Niantic’s proprietary technologies.

Niantic Beyond Reality Developer Contest

Within a span of a week, we had roped in three more people into the group, bringing our total count to five Timothi, Chin Liang, Chin Jieh, Ivan, and myself. Honestly, I didn’t think we would even get past the selection phase — we were all fresh graduates with no “real” game development experience, only developing small games for local game jams and competitions.

Still, we tried anyway. Ideation was terribly difficult — the competition needed participants to create a game that utilized Niantic’s platform, consisting of geospatial & alternate-reality (AR) tools, amongst other things. We wanted to make a game that would appeal to us, yet remained novel enough to appeal to Niantic’s judges.

Planning the direction of the game

The contest was open to all globally, and contestants had to submit a proposal. Niantic would select ten proposals, upon which the selected teams would spend the next few months completing the game prototype. The game had to have an augmented reality (AR) component, and also utilize Niantic’s tools (geolocation, AR library).

At that point in time, Niantic had three flagship games — Pokemon GO, Wizards Unite, and Ingress. We felt that these games were not achieving their full potential due to their over simplistic combat gameplay. As big fans of Monster Hunter, we wanted a game that had a higher bar of mastery involved. We also wanted players to experience deep gameplay by allowing them to customize the way they played. We threw lots of ideas around — from pet-raising games to chat applications.

Cover image of our pitch

Ultimately, we settled on a game that had players pilot mechs that fought giant kaijus; something like Monster Hunter in a Pacific Rim setting. Players would travel around the real world killing Kymeras — giant monsters mostly made of rocks. They could also use lasers to destroy ore nodes for materials. Through materials from these activities, players could craft better equipment for their mechs, allowing them to defeat Kymeras more easily.

To our great surprise, we were part of the ten groups that were shortlisted for the competition. They flew three of us down to San Francisco for a bootcamp, which I deeply regretted not going as they went through lots of server-side code that I had to struggle to figure out myself.

Timothi, Ivan, Chin Jieh flying to SF for the bootcamp

Decisions & Tradeoffs

Truly, the devil is in the details. There were lots of design and technical challenges we had to face, and tradeoffs made.

“Should we have combat in augmented reality?”

We knew Niantic was huge on augmented reality from their evident obsession with it in Pokemon GO (playing with buddy Pokemons in AR) and Wizards Unite (portkeys teleport players to the Harry Potter world). Having combat, which is our core gameplay, in AR would definitely score well with the judges.

Niantic’s real-world multipler AR demo

However, we wanted positioning to matter in combat — players needed to dodge attacks by the monsters. Having combat in AR would mean that players would literally have to move around quickly, all while focusing on the gameplay. This would pose danger to the players as they might potentially walk into walls or furniture while being engrossed in fast-paced combat. We could have reduced the gameplay complexity (no aiming) and speed (monsters would move/attack much slower), but we felt that this would go against the principles of a high-octane combat gameplay we envisioned for the game.

Our first prototype for the pitch

Furthermore, having combat in AR would bring problems. The game would have higher device requirements as AR is quite resource-intensive, and having fast-paced combat would mean the device would need to have insane internals to support it. The device’s battery would also drain really quickly.

In the end, we decided that earning brownie points on having combat in AR was not worth the tradeoffs, and scrapped the idea.

“How Do We Incorporate AR Into the Game?”

With combat in AR out of the question, we had to rack our brains on this. Having some AR gameplay was one of the requirements that Niantic set out. As the AR proof-of-concept was required in the second milestone, we scrambled to figure something out within two weeks.

We wanted the AR gameplay to be safe. By making it (mostly) stationary, players would have minimal chances of injuring themselves (or worse, getting into accidents). We still wanted player positioning to matter, and make players move (without walking) to play the game. Lastly, we wanted the gameplay to feel “tangible”. This meant that the game should closely mimic an activity we could do in real life.

Timothi hacked together this AR minigame in a day!

After hours of long discussion, we settled on a minigame where the players would excavate materials from rocks. This would be very similar to excavation toys that are commonly sold for kids, where they had to dig fossils out of clay. This tied really closely to our principles, and was really promising when we pictured it in our head. Timothi did an impressive feat and hacked a prototype up, which we tried when we met up for a discussion the day after. It definitely cemented our decision towards this minigame.

“How Do We Make the Overworld Fun?”

The Overworld is where the player appears when not in combat. It is the map where the player appears, and the player’s position on it is directly affected by the player’s position in real life. We wanted to encourage players to travel around and explore the world and interact with other players.

First, we decided on an “epic” quest system. Players would have to go to a few points on the map before finally arriving at the final spot, where it culminated in a final boss battle with other players. This satisfied the exploration side as players would be made to go to different places to complete the quest. It also satisfied the social aspect, as players would team up to fight the boss monster, which would be difficult to defeat alone.

Early stages of multiplayer rooms

Players could also fire flares, a signal for help, when faced with a monster too difficult to take on alone. This flare would be visible to all players near it, allowing them to join the fight. This would foster a greater sense of interaction.

Early prototype of the overworld

We also had the concept of “hubs”, where players would congregate, and hopefully interact with each other. However, this was hard to implement as we needed reasons for players to go to them. In the end, we included a leaderboard on each hub, which displayed the top “contributors” to the hub. Players would be able to contribute by killing nearby monsters or completing quests from it.

We wanted to implement player shops, where players could set up stores on physical locations to sell their materials. However, we decided that this would take too long to implement and scrapped the idea.

We also wanted to implement the concept of biomes, where the ore nodes and monsters that spawned within some specific areas would be unique. Although we managed to implement it in the end, we did not have a good way to differentiate biomes visually, so it felt like the effort was wasted. Furthermore, we didn’t have different ore nodes and monsters to spawn, so the effects of the biome were lackluster and mostly unnoticed.

What We Achieved

Most of our team members worked on this game in addition to our day commitments. The fact that we actually came up with a working prototype at the end of the day was quite a feat. The best part of it was that we loved what we made, and were extremely proud of it!

Showcase video

Combat

We managed to implement an actual multiplayer combat gameplay. Players could strafe around the monster while firing their weapons — the weapons had to be aimed similarly to many mobile shooters games.

Combat — using the minigun and aiming for the face

Enemy monsters had specific weak body parts like the face, rewarding players by inflicting more damage if they could aim for them. Some body parts even broke off when enough damage was inflicted, giving players more rewards and incentive to do so.

Combat — using the shotgun for close-range damage

Players can move around the monster by strafing left and right, and are able to avoid enemy attacks by doing quick dodges. The monsters had slow, hard hitting moves that would be telegraphed, allowing skilled players to survive longer by having good positioning and reflexes to dodge them. When fighting the monster with other players, good players would be able to hold the monster’s “aggro” while the other players could aim for its weak spots and pile on the damage.

Combat — using the homing missile

One of my favorite things about the combat was the “juice” it had. Using screen shakes, sound, explosions and haptic vibrations, we were able to make combat feel really engaging. Hitting the enemy with bullets felt really great when you could feel the impact it created from the sounds, explosions, and ultimately breaking the body part. Being able to dodge the monster’s big, telegraphed attack at the last second also gave a great sense of satisfaction. It felt like we did justice to Monster Hunter, which we drew a lot of our inspiration and direction from.

Augmented Reality Minigame

We achieved our goal of making a safe yet engaging minigame where the player had to play in augmented reality. Holding the phone as a laser gun, the player would fire lasers by holding their finger on the screen. There would be a piece of rock in front of the player, where they had to chip chunks off it using the laser until they removed enough chunks off to reveal a jewel in the middle, allowing them to extract it.

AR minigame — destroying chunks around the jewel
AR minigame — revealing more of the jewel as you destroy chunks

Players have to be careful when aiming the laser — hitting the jewel with it would degrade the jewel, lowering its quality. At the end of the minigame, the player’s performance will be graded according to the time taken and how much damage was inflicted onto the jewel. For optimal scoring, players have to complete the extraction quickly, yet not be too hasty about it and damage the jewel with the laser.

Thankfully, despite this portion being somewhat neglected and rushed, we managed to achieve quite a novel gameplay we have yet to see other augmented reality games implement. In fact, we may even try to recreate this minigame (with a twist) in future game jams!

Overworld Exploration

Our team wanted to create a map where it invoked a sense of mystery, as if players were thrown into an uncharted planet and had to survive on. We implemented an overworld with an outlandish color scheme, clouded by lots of fog-of-war, making it difficult to see far into the horizon. While this made navigating the real world more difficult, we ultimately achieved our goal. Looking at the overworld did feel like we were thrown into an alien world with giant monsters lurking near.

Mining ore nodes for resources
Flare system to request backup from nearby players

We managed to implement most of the features we wanted for the overworld — giant lurking monsters, ore nodes, hubs, and flares. We also implemented the epic quest system, which saw players moving about in the real world to reach subsequent quest points.

Item System

Players are able to get items from defeating monsters, mining ore nodes and visiting hubs. Using these items, players can craft and upgrade different weapons. We implemented a few different weapon types like the minigun and shotgun, which greatly influence the way players fight monsters in the combat minigame, giving players more choices in their playstyle.

Working crafting system

Items are also persisted across sessions in the player’s online accounts, so they can retain their hard work from previous gameplay!

Tutorial

As we were to have minimal interactions with the judges while they tried the game, we needed to have a robust tutorial to guide them through. We eventually implemented a full-fledged tutorial system for both the overworld, AR minigame, and combat. From the moment players log into a new account, they will be brought through every single feature we implemented — how to walk mine ore nodes, start combat with monsters, aiming for the monster’s weak spots, crafting, eventually culminating with them defeating the boss monster and completing an epic quest.

We were glad to have done this, despite it being time-consuming to implement. By having a tutorial that showcased every feature, we made sure that the judges would experience all of them without leaving any out. From developing the tutorial, we also had better clarity of the flow and understanding of the game, allowing us to refine it further, and cut some redundant features out.

What We Could’ve Done Better

Lackluster Models

We spent quite a lot of time coming up with the concept art of the main mech and monster in the game, and paid someone to model them. Eventually, the models turned out quite lacklustre. There are quite a few possibilities for this. Maybe we weren’t experienced enough to come up with good concepts. Maybe we didn’t express our ideas to the modeller well enough. Maybe we gave the modeller too short a time frame. Maybe we could’ve paid more for a better modeller.

Mech model

Thinking back, we would rather have bought and used assets found online. Although they wouldn’t be exactly original, they might’ve made the game look much better.

Neglected AR Minigame

Remember when we mentioned that we rushed out the AR minigame prototype? It stayed in the hacky state for a long time. After submitting the AR prototype for the milestone, we channeled our attention elsewhere — there were just too many things to do! We only really got back to polishing the AR minigame a few weeks prior to the competition finals. We were even making huge changes to it on the 18 hour flight from Singapore to San Francisco!

Laggy prototype where chunks disappeared suddenly

Eventually, we managed to solve quite a bit of problems. The crazy frame rate drops were less noticeable, the visual feedback from destroying chunks and damaging the jewel was more obvious, and even hacked a tutorial into it.

However, we feel that this was a huge wasted potential as Niantic really loved AR. While this minigame was decent and somewhat fun, we could’ve scored much better if we made this minigame excel.

“What If We Won” Mindset

Whenever we thought of a feature or implemented one, we were very cautious about making it scalable and appealing to the masses. In hindsight, this was a very damaging mentality to have.

Whenever we made tradeoffs for a problem that never existed, we sacrificed many things that would’ve appealed to the judges.

Overthinking the systems

One great example was the fact that we wanted to make the AR gameplay safe. In the competition, the judges would have been playing the game in safe, empty spaces. This would not have been a problem at all!

Given the choice, we would have made many decisions differently. We would steer the game towards more of a short experimental one. It might not be easily marketable or appealing to the masses, but would definitely find a niche, making it interesting.

The Drifting Problem

This one is on me. One big regret I had was not testing more edge cases while developing the gameplay. I was in charge of implementing the interaction between the client and server, and part of that was spawning the in-game objects at correct real-world locations. Throughout development, I was testing the game mostly while stationary on my laptop.

Footprints which players had to track for epic quests

During the actual judging day, most of the judges started walking to their next quest spot while still in combat with the tutorial monster! While this shouldn’t have been possible if they were playing on their own (you wouldn’t be able to see the next quest spot while in combat), the judges started following the other judges who completed their combat early.

This made many in-game objects drift from where they were supposed to be in the real world, causing some judges to be unable to activate the final boss fights and join the teams to fight the boss together. This probably caused them to have quite a bad impression on the game.

Missing Niantic’s Core Values

Niantic’s three core values are exploration, exercise, and real-world social interaction. This was made known to us very early on, and they constantly emphasized on them.

During our ideation and development of our game, we did pay attention to these core values, constantly using them as a beacon to pull us back on track. However after seeing what the top three teams did, we felt that we did not do enough on this front. There were many places where we chose to sacrifice on these core values, most evidently on the decision to have combat not in AR.

We were too engrossed in making a game we wanted to play, instead of making a game that would win the competition. Thinking back, we might have done many things differently to gear the game towards the core values. Ultimately though, we have no regrets — making a game we would play was the greatest prize in itself.

Conclusion

Disappointingly, we did not achieve a top three placing for the contest. We were one of the two teams who did receive an honorable mention, which lifted our spirits a little. After much discussion within the team, we decided not to continue the project. While we did love what we made and saw the potential in the game, we were mostly not willing to take the risk to work on this full-time, which we deemed necessary for it to succeed.

While working on this project with the team, I had to also deal with my full-time job as a software engineer. Coming back from work where I spent the whole day staring at code, I had to muster quite a lot of discipline to carry on coding the backend systems for the game. However, I felt that this whole experience was incredibly worth it. The peak of the experience was the opportunity to fly to San Francisco for the competition finals — the first time I’ve ever been to the USA! It was really eye-opening to see the offices that the developers of Pokemon GO (which I’m a big fan of), and the city itself.

Posing with the trophy with John Hanke

Most of all, it was great fun creating a game from scratch within such a short timeline with an awesome team. Despite being inexperienced, we hacked out a great prototype which impressed quite a few judges. While we did not get into the top three spots, achieving 4th/5th place out of so many teams which applied was quite a feat — we didn’t even expect to get shortlisted from our project proposals in the first place!

This project renewed my passion for developing games. While I’m still not going to make the jump to the game industry, I hope to find the motivation to finish another game and release it soon.

The team with Kellee & Ronak

Special shoutout to Ivan, Timothi, Chin Jieh, and Chin Liang. You guys were great teammates, and I had a blast of a time with you guys at San Francisco!

Thanks to Kelvin, who played an instrumental role in getting the team together.

Also a huge thanks to the Niantic representatives — Kellee Santiago and Ronak Shah, who saw us through the entire journey. Not forgetting the Niantic engineers who helped us resolve issues and made fixes.

p.s Niantic has since started its Creator Program, where AR Creators who wish to collaborate with Niantic can apply to work with them.

--

--