Putting the 'Last' in Blast Point

Putting the ‘Last’ in Blast Point

Determining how long an augmented reality game session should last using data driven game play.

The early design process & prior experiences

Blast Point was originally conceived as a prototype inspired by the global game jam in January of 2020, with the game jam theme of ‘repair’.  I didn’t originally plan on participating in the jam, however coincidence would say otherwise.  I was at the playground with my wife and kids, and generally spotting my 2 year old in fear of him falling off of the higher platforms.  That day i was wearing a ‘Dominations’ t-shirt which i won in a random business card drawing at an IGDA meeting a year or two earlier.  A woman approached me and asked why i was wearing that shirt, and after i explained the origin, she pointed to her husband across the playground with their kids and mentioned he was one of the producers on that game.  He and I chatted for a few minutes, exchanged information and a week or two later grabbed some lunch after which he mentioned Big Huge Games, the company that created Dominations, was hosting a location for the Global Game Jam, and that they had just opened up a few more spots for any additional latecomers.  I chatted with my wife about it, because participating in a jam meant she would be tackling the kids for the weekend.  She was on board, so i mentally prepared to hang out at Big Huge Games for the weekend cranking out a game. 

The theme of the game jam was announced as ‘Repair’.  I brainstormed some ideas with a few folks, but wasn’t really confident about what i had come up with.  The idea that I did jot down was an incremental style game where some sort of central object needed to be repaired, and then some kind of external protagonists would be sent in to repair the central object, competing to do so, resulting in more breaking and thus needing more repairs from additional external protagonists or resources.  This seemed like the beginning of a procedural or incremental game, but it wasn’t really something i wanted to commit to for a game jam, and continued to sketch.  

Some of my work in the previous year or two involved studying augmented reality development, and a few game prototypes i had developed in previous years did involve virtual assembly.  So i thought maybe combining these two concepts might be doable in the weekend, and since augmented reality would be involved, I would try and create some sort of physical object that could be virtually repaired.  At that point i committed to creating an AR mobile game that would be projected on a 3d printed object.  The game would be simple, and focus more on developing a better command of the medium rather than innovative game mechanics, so I went with the creation of a simple tower defense game where players needed to rebuild their tower in augmented reality when it broke from taking on too much damage. 

The challenges of designing in augmented reality: how long should a game in augmented reality last?

One of the major differentiators between an augmented reality game and a traditional video game is that a video game asks the player primarily for their time.  This assumes the typical scenario of a player playing a game on a console,computer, or phone, and thus there isn’t much physical movement involved.  An augmented reality game asks a player for their time and their space (much like virtual reality, but that isn’t the topic of this blog entry).  An augmented reality game will need to meet the demands of a mobile game that is somehow linked to the physical world, so in many ways needs to meet the physical demands of a table top game, but the computational demands of traditional video game.  Knowing these constraints, I began designing the AR table top game with the understanding that game sessions will need to be short both in favor of players holding their phones up for too long, but also because of the computational demands of mobile phone which at the time of this writing would still get pretty hot during a lengthy AR session (I was using a Samsung S8 for the test device).  Ergonomically, it was too physically awkward to constantly point at something in AR, and then press buttons as the player would then have to shift their phone around in their hand, avoid covering the camera on the back side of the phone, and then still find a comfortable way to play the game.  Therefore, the game was designed to be played in five to ten minute intervals and players would have three lives.  Players would then only need to point at their targets and the game would handle all of the logic of determining what it was pointing at, what the state of the game was, and what it should do based on the resulting condition.  

First, the bounds of the game needed to be established, and this was through the use of a tracking marker that was designed around the 3d printed object (the base of a turret).  Once the game detected the marker and spawned the top of the turret, players would point at incoming drones and the turret would auto-rotate to aim at and shoot those drones.  When the turret took on too much damage from the incoming drone attacks, the turret broke into several pieces and players would have to mentally switch into a puzzle mode of sorts and play a mini matching game to collect the pieces of the broken turret for reassembly.  By aligning the a puzzle piece on the players screen with the same puzzle piece corresponding with the broken turret on the field of play, the turret could be reconstructed.  Upon breaking a third time, the game was over and the players score would be added up in the traditional arcade way.

At the conclusion of the game jam that weekend, I was pretty happy with what I created, and also wondered if there was any commercial viability for this sort of game.  Augmented reality gaming is still the wild west of gaming to an extent, and hardware is still improving to handle augmented reality programs.  Not long after the jam ended, the game jam bug had bitten, and i wanted to polish the game a bit more and explore the development potential.  For example, just in the process of coming up with a name for the game, I thought of several more board variants that i could build including a pirate ship blasting cannons at tentacles, or a variant of the another piece of IP i’ve been developing called Flutter Bombs where a butterfly could be sitting on a tree stump dropping nectar bombs on spiders emerging from below.  I also wondered what the multiplayer potential of the game would be in either a vs or coop style.  

Metaphorical friction plays a pretty big role in AR (not as much as VR, but enough to have an impact), and so in the process of studying market potential I understood that asking a player to download a tracking marker and then 3d print the base of the game board was way too much to ask.  Previous surveys i had conducted already showed that there was an extremely low rate of people using 3d printers.  This meant i needed to develop the game in a way that could also take advantage of ARKit and ARCore’s ability to detect surfaces which would allow players to play a session of Blast Point on any surface rather than a physical game board / image tracker.  So, a mult-modal game that supported either surface or marker tracking, in conjunction with modular code that created an easy way to rapidly iterate with different board designs and themes for a ‘Blast Point’ helped shape the development of the game. 

Beyond developing the framework for the game constraints, the gameplay itself needed a lot of work so the game was more than just ‘whack-a-mole meets puzzles’ in augmented reality.  Because there was a central avatar engaging various enemies, the concept of leveling up and upgrades fit the nature of the game.  This opened up a new can of worms, and in order to easily build tools to shape and tune this sort of gameplay, enter the world of curves and data tables.

Data driven design challenges: Curves and Data Tables

Leveling up is driven by an exponential curve.  The closer the player gets to level 30 (which is the highest level a player can achieve at the time of this writing) the more experience points are required to reach the next level.  This helps reinforce the concept of progression in early stages of the game, but also eases the player into the higher levels of the game by teaching them how enemies change at various milestones or increments.  By the time they reach the max level, they understand which kind of enemies can spawn and the various stats associated therewith, which brings us to our data tables.

The data tables in Blast Point consisted of a few basic stats, which were intentionally kept fairly simple, because even a few different stats can synergize to create vastly different gameplay scenarios.  Health determined how much damage an enemy could take before dying.  Attack speed indicated how often the enemy would attack.  Damage was how much damage the enemy would attempt to deal to the player either through a melee attack or projectile, move speed was how fast the enemy approached the game board, and last but not least, experience and score were the statistic based rewards given to the player upon defeat.

This data table was the heart that drove gameplay and could dramatically shape the outcome of a Blast Point game session.  Increasing health of enemies as players level up their game boards was a delicate process to make sure the enemies didn’t become bullet sponges.  Tuning their damage output was also difficult because I had to accommodate for which different combinations of enemy might be on the board, what would be overkill, and what would give the player a fighting chance of survival.  Attack speed was also a fairly critical element and was tuned heavily with base damage to assurer enemies weren’t attacking to quickly with too much damage.  Additionally, all of these stats had to be considered at various stages of a players advancement through the game with upgrade choices.  Did the player choose an offensive upgrade path to start? Did the player choose a defensive upgrade path to start?  How the player experienced the game throughout the leveling process would essentially differ from the end game condition where a player would finally have all upgrades equipped.  The way these stats were tuned throughout gameplay testing also went hand in hand with how long the desired gameplay session would last, or at least was intended to last from a design perspective and which could be significantly altered with a slight modification of any of these stats.  

The Power of Random: What role does random choice play in Blast Point

Another curve that was important to the design of Blast Point was the weighted enemy spawn curve.  New enemy types would spawn every five levels giving each board six different enemy types to interact with.  As new enemy types were available, there wasn’t an equal distribution for spawning.  Instead, I used a curve to drive probability of spawn type.  For example, early in the game’s development, I used a simple exponential curve for spawning, with an equation similar to the experience point progression.  This worked well for leveling but did not work well for end game conditions.  Players had a higher probability of facing against lower level enemies, and the high level enemies that would spawn would be tougher or hit harder or last longer.  As mentioned earlier this worked well to add variance to player enemies while leveling, but it did not work well at the end of the game when too many lower level enemies were spawning.  I changed the curve to more of an S-curve and this seemed to work well for spawn weighting.  At the game’s end there were more high level engagements with enemies, but with enough variance to create some easy kills or more strategic kills with lower level targeted player choices.  This also meant that higher level enemies weren’t necessarily designed to be the hardest to kill, but they did offer some more challenging mechanics that a player had to consider when choosing between multiple targets. 

Beyond the weighted random factor of enemy type spawning, another random factor that was introduced into the game was the spawned pickup.  There were three types of pickups, and for each type of pickup, there were two tiers of said pickup.  A player could aim their crosshair at any of these pickups, and after filling up a meter for that pickup, the pickup would be collected and the player would be rewarded with either experience points, health points, or a score bonus.  The reason for the second tier of these rewards was to add a bigger gamble to the pickup game.  Because the second tier of pickups offered significantly more of a reward than the first tier (and were spawned only after level 10), they did take longer to collect by asking the player to point at them for extended period of time and which subsequently would leave the player’s game board vulnerable to attack in the interest of a gambled bonus.  This meant that sometimes players would need to ignore the pickup, and just wait for the next one to spawn that they had a higher desire for, or maybe collect the pickup if by chance it spawned during a time when the player had just cleared a few enemies leaving some room for a bonus engagement.

Upgrades

The six different upgrades a player could add to their board were designed around three being offensive and three being defensive.  The first offensive upgrade was an area of effect (AoE) periodic damage upgrade.  The second offensive upgrade was a way to amplify damage.  In most cases it meant doubling the damage dealt by the tower’s attack method, but in the case of the Moon Base game board it was a faster attack speed.  A faster attack speed was ok, because most enemies had some sort of ‘knockback’ animation that would delay their own attack, but Moon Base enemies did not, which meant a faster attack speed would not be over powered.  The third offensive upgrade was a pet to accompany the player because first, pet’s are awesome, and second, it added a nice element of variance that a player could rely on when employing their own strategy on a game board. 

The first defensive upgrade was a heavy armor of some sort that halved all incoming damage.  The second defensive upgrade was movement impairing effect.  A movement impairing effect on enemies offered players a significant combat advantage because enemies would only attack when within their attack range.  The slower they took to get in range, the closer a player would be to be in position of counter-attacking the incoming enemy (which was heavily dependent on gameboard turn speed).  The third defensive upgrade was an attack delay effect that halved enemy attack speed, again, giving players a massive advantage in counter-attacking their incoming enemies and knowing that if they were hit by one, they have a little more flexibility in choosing whether or not to counter attack based on their current position of the threat weighed against how far they have have to rotate their tower to fight back.  

Because upgrades were working in ‘halves’, either with damage mitigation, amplification, or movement losses, this meant that high level enemies hit pretty hard or fast (or both in some cases).  This also meant that timing was everything in a game of Blast Point, and that each board had a specific design or ‘key strategy’ so to speak that give players the most amount of time to earn points on each board before their inevitable tower collapse which was to occur somewhere between 5 and 10 minutes of a gameplay session.  

Spoiler alert: how the board priorities were designed

MoonBase - This was the first board developed that was part of the prototype, and because it was the first board, it was a pretty straightforward board design.  As the player progresses with this board, the enemies have more health, but ultimately do the same rate of damage.  The unique element in this board is that enemies have no knockback, and the enemies that shoot projectiles should usually be prioritized because there is more isolated damage being incurred from these enemies.  

Flutter Bombs - This game board encourages the player to kill low level enemies as a priority.  While the spiders do have knockback, it’s not very long, and only buys a little time.  In this case, low level enemies hit slow and hard, and high level enemies hit much lighter, but much faster.  The biggest challenge with this board is probably the grind from level 1 to 10, but once the player is equipped with at least two upgrades, the board gets significantly easier, as long as they focus on taking out the lowest level spiders first.

Shipwrecked - The tentacles in shipwrecked hit slow and extremely hard, however, they have a significantly longer knockback time, and thus it makes more sense to keep pinging each tentacle with a volley of cannon fire as opposed to focus on killing each one at a time.  Especially when timed well with the electrified anchor proc, a player can actually survive pretty long with several high level tentacles on the board, as long as they keep that round-robin cannon volley going. 

Pond - This board has a fairly linear progression much like Moon Base in terms of enemy health gains and damage gains, but the enemies that are wielding water blades need to be primary targets.  These enemies attack much faster.  However, the water drops in Pond do suffer from knockback, so if a player’s pet engages an enemy with a water blade, the player can let the pet do it’s thing while moving on to another primary target or collecting a pickup for more health, xp, or score. 

Dragon’s Throne - For this board, I designed it in a way where mid-range enemies needed to be the primary targets.  Mages hit extremely hard, but they also die in one or two shots.  Once a player has a pet dragonling active on the board, they can actually rely heavily on their pet, and focus on constantly maintaining a position that allows them to rotate as quickly as possible toward any sign of a mage appearing.  This means even ignoring the lower level archers at times and just let the flame wings proc, while waiting patiently facing an open lane in case a mage appears.  

Monetization Strategies

Making Blast Point a commercial product meant understanding the pain points of augmented reality, and limitations therein.  Because this was a mobile game, and an augmented reality game (which honestly go hand in hand anyhow), I felt the game had to be free to play to reduce any and all obstacles where possible to make the accessible to players interested in augmented reality.  However, i do believe that developers should be paid for their work and contributions to the gaming community, and so I wanted to find a way to monetize the game that would be fair.  I eventually settled on the concept that players can play as much as they want, but if they want to upgrade their board, they will need to pay a one time fee to unlock access to upgrades (and which would be inclusive of all five boards).  I thought this would be fair enough to allow players to get a feel for the game, and as they leveled their boards, if some day they decided to take the plunge, they could use those hard earned skill points at any time by committing to the one time in-app purchase.  

In Conclusion and Next Steps

Bringing Blast Point to market was an enjoyable process that was rooted in a global game jam and a chance running-into at a playground with a producer at a local game development studio which i have always admired (i tried numerous times to get a job at Big Huge Games way back in the late 90’s and early 2000’s).  I put a lot of time into playing their games when i was younger, so being able to build a prototype in their studio for a game jam was a very heartfelt experience.  At the conclusion of the jam, and when i continued to build the game at home post-jam, I also enjoyed diving into the world of data driven gameplay from a very simplistic standpoint.  I have been an intermittent World of Warcrafter since Burning Crusade, and appreciate the time and effort that goes into gameplay balancing a world that’s driven heavily by statistics.  I also learned how minor changes in a stat can have a huge difference in gameplay, and at various stages in a player’s journey through leveling up.  

Production-wise, I would love to integrate more features into Blast Point, but this will depend heavily on its commercial performance in its current single player state.  Multiplayer could be a lot of fun in augmented reality using a playmat tracking image to link each player into the same augmented world.  Additionally, there is a great monetization opportunity with playmats and tracking images.  In that same vein, as object detection technology gets better with each model of phone that comes out, the original concept of building a game on top of a figuring becomes extremely viable.  At that point, the game could theoretically be free, and only the figurines would be purchased depending on the target audience.  I looked at a lot of these different financial models, and even spoke with several manufacturers to discuss CNC vs injection moulding for 3d game boards.  So as this core gameplay loop continues to evolve as it currently stands, I hope to either crowdfund multiplayer Blast Point game boards, and maybe build a few more game themes into the platform.  From an in-game monetization perspective, there are ample opportunities to equip boards with custom cosmetic features, or even down the road, increase the level cap with more upgrade availability. 

If you made it this far, thanks for reading and feel free to reach out with any comments, criticisms, questions, or to say hi!