These last two weeks I’ve been hard at work on Blast Flocks!
A lot has been done in two weeks!
The very first thing was to reactivate and adapt the main mechanics of shooting and saving planes, to the multiplayer systems.
Mostly, the difficulties were about making sure that the destruction and saving effects (audio and graphic) happened on both server and client. The actual destruction of ships and the passing from one player to another, was rather straight-forward using the normal plane syncing system I implemented the previous week, with Castle’s network library.
Something that I think is interesting is that the bullets are not synchronized at all! I was conflicted about this, so I decided to test it, to have all the bullets created and updated without communication between server and clients.
The players’ cursors are synchronized at all time, and they have a ‘shooting_order’ boolean field that tells planes they should shoot, or not. So as long as that cursor synchronization is steady and the planes synchronization is close-enough, the bullets are very predictable for every client.
Quite a few tests were done since and the absence of bullet synchronization has not proved to be a problem at all! The result is seamless! Which means I can have as many bullets as I want without being afraid of overloading the network connections!
The next thing I worked on was a nicer interface for connecting to a server. (and also hosting a server) With the brand new addition of text fields to my existing menu system!
The text fields keep the focus after you click on them to let you write whatever you want. You can then click away or press enter or escape. Ctrl-V will also paste whatever you have stored in the clipboard into the active text field.
I also concocted this connection screen you can see in the gif above. So that even if the servers are broken or take forever to connect you, you will still be captivated!
I added a minimap! And a leaderboard! And later I added a crown on the minimap, for the leading player!
Player positions are defined by averaging all their planes’ positions. Both those positions and the leaderboard are calculated on client-side rather than shared from the server. That might change in the future as every client might not get the data for other clients whose planes are too far to be interacted with anyway, for the sake of network optimization.
And let’s talk about that, network optimization!
Here’s how Castle’s network library works:
- Server has a ‘share’ database they can write to.
- Each client has a ‘home’ database they can write to.
- Every client can read the server’s database and the server can read all client databases.
- Those databases are synchronized by sending difference updates between server and clients.
That is to say, if the fields ‘x’, ‘y’ and ‘z’ in server.share are 1,2 and 3, but then ‘x’ changes to 5, that change on ‘x’ is the only thing that will be sent to the clients when updating the database, the values for ‘y’ and ‘z’ will not be sent again.
So you can have things that are set on the init and the only time it will be sent to a client is on the very first update after that client connects. And then you can have more dynamic data that will get updated constantly.
Or you can have data that you update every once in a while, and those are the only times that they will take up network bandwidth.
The problem with Blast Flocks is that there are so many moving entities, and even if the bullets are not synchronized, the planes need to be.
But with sufficiently determinative behavior on the planes, maybe they don’t need to be synched every frame, maybe not even once per second, as long as we have the cursor data which tells the planes what to do. (shoot, boost, and target position)
Do you see where I’m going here? We do not need to sync up all the planes at all time, which would effectively clog the network bandwidth really fast. No, instead we can update every plane on a regular 1-to-5 second basis. Not all at the same time! Those updates can be differed and so we can just update one or two planes at a time, per player, every frame, to have a steady-but-limited stream of data going over the network!
And that’s how I got it to work just fine with literal hundreds of planes in the game! Yay!
Finally, those last few days I’ve been doing a lot of smaller tweaks and optimizations. I limited the usage of trigonometry functions on the ships’ update and draw methods. I made it so each player’s averaged flock position is stored in the player structure so that it needs to be calculated only once per frame.
I also changed the way text is drawn to have this neat chrome effect, and even got it to show two colors on the same text! Previously, the same text would be drawn about 15 times, with offset, to create outlines and shadow effects. Text drawing might be fast but doing it 15 time per string is still a bad idea. So instead now there’s one simple outline and then we use Love2D’s ‘clip’ function, which is actually named ‘setScissors’, to draw portions of the text with different colors. We still have to draw the same string a few times, but it’s a lot better than it was previously! And it’s more readable too!
On the non-optimization side, I made the player’s ships’ outlines glow to let you know that those planes are yours. Other players’ names are displayed on their flocks. The crown was added on the minimap. A restart button was added. And quite a few more tiny tweaks and reorganization of draw orders and other tiny details were taken care of!
And that leaves us with the coming week of work on Blast Flocks, which will be the last! There are quite a few things left to do, especially plane merging/upgrading, when you start having a lot of planes, and also non-player ships that roam the game area! Aside from that I’m sure we’ll have some more tweaks to take care of, the game’s title art needs some love, and the sound effects and music might too. We’ll see what I have time for!
Still, I’m very happy with the progress done and the current state of the game. This last week is going to be tight but I feel very confident that it will be manageable.
Prepare to play Blast Flocks next week!
I’ve been able to work a tiny bit on the Tetris, but I couldn’t finish it. I implemented both DAS and ARE. DAS is the input repetition when holding left or right, and ARE is an entry delay after a tetramino locks down onto the board.
With both these things done, only the main menu remains to be done. And maybe some sound effects. But that’s it!
I will finish it first thing in the week after Blast Flock is done.
Finally, I released a new batch of wallpapers generated with Sugar just yesterday! All my Patreon supporters can download them there!
Of course I want to thank all my Patreon supporters for their continued support! I’m starting to think of new ways to do things and new rewards for you kind people in 2019. This yearly Patreon overhaul will be much more reasonable this time. I will be running a Patreon poll about possible future content soon-ish! In the meantime, here are the names of all the 3$+ supporters:
☆Joseph White, ☆Spaceling, rotatetranslate, Anne Le Clech, Wojciech Rak, HJS, slono, Austin East, Zachary Cook, Jefff, Meru, Bitzawolf, Paul Nguyen, Christian Östman, Dan Rees-Jones, Reza Esmaili, Andreas Bretteville, Joel Jorgensen, Marty Kovach, Giles Graham, Flo Devaux, Cole Smith, Thomas Wright, HERVAN, berkfrei, Tim and Alexandra Swast, Jearl, Chris McCluskey, Sam Loeschen, Pat LaBine, Collin Caldwell, Andrew Reitano, Qristy Overton, Finn Ellis, Giovan, amy, Brent Werness, yunowadidis-musik, Max Cahill, hushcoil, Jacel the Thing, Gruber, Pierre B., Sean S. LeBlanc, Andrew Reist, vaporstack, Jakub Wasilewski
These two weeks were very busy but also very productive! I feel confident for the last week of work on Blast Flocks!
Have a great week everyone!