I know many of you are eagerly awaiting news about BombSquad 2.0, so I wanted to post an update on what I’m up to.

Back when I launched BombSquad 1.0, there was no net-play; it was local multiplayer only.  And in my opinion, having 6 or 8 players on a couch with controllers playing on a large TV remains the best way to play the game to this day.  However, the present reality is that the vast majority of players out there do not have access to this sort of setup; they are playing on mobile devices and net-play is their only realistic option for multiplayer.  And although BombSquad has supported net-play since version 1.4, it has always been a bit half-baked, lacking features such as matchmaking and not performing especially well in terms of lag and bandwidth.

With BombSquad 2.0 I want to change that.  I want to make net play work as smoothly as possible and want it to be just as fun as couch multiplayer (or at least as close as physically possible).  Reworking my net-play code to achieve this goal is going to be a major engineering effort, but I feel that now is the right time to do it.   It will provide a solid foundation on which I can build some really fun features in the future. (destructible terrain, cloud-based parties, matchmaking, PvP tournaments, etc.)

I have several other improvements planned for 2.0 beyond net-play, but I won’t get ahead of myself by mentioning them just yet.  I also can’t announce a specific release date for 2.0 other than to say I’m working as fast as I can.  And lastly I want to apologize once more to iOS & Steam users for making you wait this long for the game already, but I super-serial-pinkie-swear that I will launch on both platforms as soon as 2.0 is ready.

I’m breaking this process into several steps to keep it manageable. Below are some nitty-gritty tech details of my current plans in case anyone is interested.

• BombSquad 1.4.136:  This is the current release, containing my old ‘V1’ net-play code.  In net-code V1, all local player input events (button presses, joystick moves, etc.) are sent to the server which then runs them through a python game script to generate game events (jump, punch, spawn-bomb, etc) which are then sent out to each client to be run in their local game simulations. One major downside here is that seeing the results of a button press requires a complete round-trip to the server and back, which can often be several hundred milliseconds, making the game feel laggy on a less-than-perfect connection (which unfortunately is almost always the case when wifi/cellular is involved).  Another downside is that the local simulation is not designed to be deterministic and often diverges from the server’s, requiring bandwidth-intensive physics re-sync packets to be sent down to all clients constantly (if you see game objects ‘snap’ back in place in a net-game you are seeing a physics re-sync)
• BombSquad 1.4.137:  This release will contain significant internal cleanup and reorganization necessary for the upcoming improvements (and for maintaining my sanity), but should contain few, if any, outward facing changes.  This will act as a ‘stake in the ground’ to ensure existing functionality is not broken.  This should be ready soon.
• BombSquad 1.5: This release will contain revamped ‘V2’ net-play code.  In V2, clients will no longer run game simulations themselves.  Instead, the server will send out lightweight ‘motion streams’ of game objects that clients can use to display the game exactly as if it were being simulated locally.  This should eliminate the expensive physics re-sync packets which constitute most of the game’s current bandwidth, and also will eliminate the visual pops associated with that re-syncing. As an added bonus, the game should be less demanding on devices during net-play since there will be much less local simulating happening, leading to better battery life and performance.  Lag will remain an issue, however, as player input will still have to make a round-trip to the server and back before its results are seen, but it may be improved slightly due to the reduced bandwidth requirements.  This release will hopefully allow me to spin up more public multiplayer servers since I am primarily limited there by bandwidth costs.
• BombSquad 1.6: This release will contain ‘V3’ net-play code.  V3 will combine the lightweight streamed motion from V2 with the addition of client-prediction.  Client-prediction is a technique used by most modern action-oriented games to make gameplay feel responsive even on laggy connections.  It is the reason that your view rotates instantly when you move the mouse in a first-person-shooter, even though the server or other players may not see your player turning for a half a second.  It simply means that part of the game is being simulated immediately on your local device instead of waiting for the server to do it and send you the results. In BombSquad’s case it might mean that your own character gets simulated immediately locally while everything else is streamed from the server.  The tricky part will be combining the local simulation with the server’s motion-stream in a way that keeps everything looking reasonable visually.  For example: your local character simulation represents ‘now’ in game-time but the motion-stream from another player’s character could represent 300 milliseconds in the past (the time it takes their packets to reach you); so what happens when your character tries to pick up theirs?  This sort of interaction will be a tricky challenge and will require some experimentation.  The whole concept sort of short-circuits my brain like one of those trippy sci-fi time-travel-paradox movies.  Anyway I’ll try to post more nerdy info about this part it as I figure things out.  If all goes well, however, client prediction should allow net-play games to feel mostly indistinguishable from local ones in terms of responsiveness.  This in turn will unlock lots of good things such as the ability to run even single-player tournaments on my own servers without introducing lag so I can finally 100% prevent cheating.
• BombSquad 2.0:  After the big net-play revamp will come BombSquad 2.0. I have a list of features I hope to include (some of which are done already), but I don’t want to go into details just yet since it is still a way off and subject to change.  The main focus will be steering the game more towards competitive online multiplayer using the improved net-play system as a base.  This will also let me launch on iOS/Steam without being weighed down by an inefficient/substandard network architecture.  I’m super-excited about all of this, but I don’t want to get ahead of myself. First things first; time to fix net-play.

One thing I’ve learned over the years while running a solo project like BombSquad is the importance of automation.  If I can write a script to save myself 5 minutes of time each day, that adds up fast.  When that’s multiplied by 10 or 20 things that need to get done every day it can mean the difference between actually making progress on the game vs. being mired down in daily busywork (or simply letting things fall out of date)

So on that note, I’ve been working to automate a few things and I thought it’d be useful to share:

1. Python API Docs.  A few years back I wrote a script to generate documentation for BombSquad’s Python API (for modding purposes, etc.). However this required me to manually run the script and copy results into a page here.  Hence, it fell out of date constantly.  I’ve now automated this process to run nightly on my latest code.  Wheee!
2. Change Log.  I’ve now got a single detailed change-log that lives with my source code and is used to automatically update the change-log page on this site and elsewhere (as well as release notes on app stores, etc).  This will hopefully result in fewer “bug fixes and polishing” app release notes, as well as providing a useful reference for modders.
3. Translation notices.  First off, a huge thanks to all the volunteers who have helped translate BombSquad to 27(!!!) languages.  The game would not be what it is without your help.  To this end, I’d love to make the translation process smoother for those who want to help out.  So as of BombSquad 1.4.133 you can now opt in under settings->advanced to be informed at launch if the language you are using contains new untranslated phrases.  Hopefully this will be useful!

Hi folks!,

Its been.. oh.. about 3 years, so I figure its time for a blog update.

If you’re wondering where I’ve been:  for the past few years I’ve been working with my good friends at Limbic, blowing stuff up as the resident vfx-guy and working on some fun games.  (Check out Zombie Gunship Revenant on iOS if you get a chance).  It was a great opportunity and I learned a number of good development practices from some really smart folks (wheee I can actually use git now!).  The downside, of course, was that it kept my time on BombSquad rather limited.  I’ve been able to make minor additions and fixes the past few years but I simply didn’t have the time to commit to major updates or platform releases or things of that nature.  (cough cough iOS cough).  Despite all this, however, I’m happy to say BombSquad has been doing quite well this whole time.  In fact, I’ve hit my highest ever daily player counts within the past few months.

So recently, after wrapping on some big projects at Limbic, I decided the time was right to bow out and hit the gas again on BombSquad.  Just as with Pixar, it was bittersweet to say goodbye, but I’ve learned over the years that I work best when I can just focus on one thing that I’m passionate about.  And so here I am, back on BombSquad.

I’m super excited to get this ball rolling again, though it’ll take a little time.  I’m currently in the process of dusting everything off, making some sorely needed optimizations so my busy servers don’t bankrupt me (good problem to have!), getting some anti-hacker measures in place (seriously guys; play fair or get banned), and indulging in a little fun making new characters/maps.   Soon, however, I’ll be making announcements about my bigger plans.  (And before you all swamp me with the same question:  yes, iOS is one of them.)

-Eric

I wanted to ramble a bit on this topic since it has been (and continues to be) quite a learning-experience for me. Perhaps this will be useful for other developers to hear.

Last year, in preparation for releasing BombSquad on Google Play, I switched the game from paid to free on all platforms. This is something I had long been planning on doing once the pieces were in place (in-game store, tournaments, etc.), so it seemed like a good time to take the plunge.

As developers, we all hear about how F2P is the future, and admittedly everyone’s mouth waters a bit when they read SuperCell’s latest earnings report, but from my perspective there were several less-obvious incentives to going free as well. One of these was exposure. Being a solo dev with no marketing department, I liked the idea of eliminating the barrier-to-entry for new players. I’d rather someone try my game and not pay for it than not try it at all due to it’s price tag; especially as it becomes harder and harder to stand out in the crowd. I also liked the idea of potentially being able to support myself by adding to the game over time instead of being forced to abandon it once the rate of new users slowed. I started writing BombSquad 10 years ago as a hobby and still love adding to it, so anything that lets me continue doing that (while also continuing to buy groceries) is good by me.

Of course going free is a little scary as well. There is the potential to torpedo player goodwill with over-aggressive monetization, pay-to-win mechanics, or excessive pay-walls. There is also the other end of the spectrum where the game gives players little reason to spend, in which case your game won’t make money regardless of how popular or well-received it is.

But free doesn’t have to mean evil.  It can work well, and I wanted to try it. So I did.

It’s now been a bit over 6 months since I flipped the switch to free, and in this time I’ve learned just how tricky it can be to find a comfy spot in the center of those two extremes. I’ve also gotten inch by inch closer to said comfy spot. If I were to go back in time a year to give my past-self advice, this would be it:

• Keep in mind that free-to-play is a *lot* of work, especially adapting an existing game not explicitly designed for it. If you are a solo developer or a small team and you just want to focus on gameplay, carefully consider whether the extra time wiring up IAPs, balancing economies, and incentivizing players to purchase is worth the extra effort vs. simply releasing a paid game.
• Give yourself plenty of time for tuning purchases. Don’t slap a few unlockables in a week or two before release and expect amazing things. Consider a lengthy soft-launch.
• Incentivized ads are worth looking into, and provide a safety net in case your IAPs are ineffective.
• Play F2P games. This seems obvious, but I am guilty of not doing this nearly enough before I switched BombSquad over. I knew all the F2P concepts ‘on paper’ but until recently I feel like I had not played enough to really ‘get’ them. A recent Boom Beach binge worked wonders for this. The best games don’t kick you in the face; they’re fun without purchasing but just a *bit* more so if you do.  If I were starting over converting BombSquad to free today I would definitely rethink a few things.
• Lastly, get down and dirty with analytics. When I am balancing a game I tend to do it more by ‘feel’ than by numbers, but when it comes to virtual currencies and economies it really helps to crunch the data. On this topic, I’d like to give a shout out to the folks at Google who are going to be rolling out their new Player Analytics features in the developer console in the next few days which makes a lot of this easier for mere mortals like myself. I’ve been fortunate to get to work with them in recent months as they’ve been putting it together, and it’s been quite helpful in identifying and correcting shortcomings in my in-game economy. As a particular example, their sources & sinks report showed that most players were easily earning more tickets in the game than they were able to spend, meaning few had any incentive to purchase ticket-packs. Adjusting my numbers to bring these two back in line had a substantial positive effect on my revenue and put the game on much more sound financial ground.  So if you’ve got a game on Google Play, integrate Play game services and give Player Analytics a whirl.  Yay for buying groceries!