Ok, I realized the server-stats stuff in my previous post was a lot to digest and would probably be a lot more useful with an example. So I made one.

This little tutorial shows how to keep a permanent tally of kills by everyone that joins your server and display the top ones in a webpage.

edit: I moved this to its own permanent full-width page since the source code shows up much better there:

BombSquad Server Stats Example

I’m hard at work ripping things apart for the 1.5 update I mentioned in my last post, but in the meantime I wanted to mention some fun new stuff in the smaller 1.4.139 update that just went out: account IDs and server stats buttons.

Account IDs

Some server modders have started to log persistent stats for players on their servers, which I think is AWESOME (stuff like total kills, win/loss percentage, etc).  I think this is a good way to differentiate custom servers and give people a reason to come back to custom servers instead of just playing on default ones.

The only issue here is that I haven’t provided server modders with a good way to identify player accounts consistently in order to store stats for them.  People have been using things like account-display-strings for this purpose (‘Android0301031‘, ‘MyGooglePlayGamesName‘, etc).  While this works, it has a number of problems.  For one, it is possible to link multiple logins together in one account, and this display string will change depending on the login the player is using, even though they are technically all the same account.  Another issue is that some platforms allow changing the displayed name for an account, which would cause the server to lose your previous progress in this case.  Lastly, login names are not guaranteed to be unique, and it would be not be hard for someone to impersonate another player by using their login name.

So in 1.4.139 I’ve provided a better solution for server modders: a bs.Player object now has a get_account_id() method.  This call will return a unique account-id string for any player that will remain consistent no matter which of their linked logins they are using or what their display-names are.  As an added bonus, the game does verification with the bombsquad master-server to ensure a player’s account-id is legit, so it should not be possible to spoof another player.  (Note that the get_account_id() method may return None if the game has not yet been able to verify a player’s identity or if they are not signed in; the server mod should handle this case by ignoring their stats, attempting to fetch their id again later, or simply kicking them from the game).

Server Stat Buttons

The second fun bit of this update is server-stats buttons.  Being able to store player stats consistently is great, but its not terribly useful if nobody can see them.  To help solve this, I’ve added the option in the 1.4.139 dedicated server builds to specify a stats URL for your server which will show up in the server browser as a stats button next to your server name.

If you set up an html page to show your server’s custom stats, (Today’s top kills, etc.), you can use this button to provide a link to it.  Furthermore, if your URL contains ${ACCOUNT}, it will replaced with the account-id of the currently-signed-in account.  This way your server can show stats tailored specifically for the current account.

At the time of this writing, I’ve set up the “FFA US West 1” server with a sample page to show how this all works.  Feel free to locate it in the list and click its stats button.  You should see something like this:

This server specified the following string in its config.py:

config['statsURL'] = 'http://bombsquadgame.com/testserverstats?a=${ACCOUNT}'

When we click on it in the game, our account-id gets substituted into that address, and a browser window is opened to a URL such as this:

http://bombsquadgame.com/testserverstats?a=pb-JjBJIRpSVktDWltH

Then, as you can see in the results, our stats server can make a call to bombsquadgame.com/accountquery to fetch information about that account.  (a display string for it in this case).   I can expand this call to include other account information, so please let me know if there’s anything else you’d like access to.

Anyway, that’s about it.  I’m looking forward to seeing some interesting stats pages!   (though please note that I will curate the list and hide any stats buttons that are hijacked for any purpose other than server stats).

Also a special shout out to Panagiotis Giannoulis, who I worked with to get this system up and running.  Check out his Godfather servers if you get a chance (with nice stats pages coming soon).

Cheers!

 

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.