STORE COMMUNITY ABOUT SUPPORT
Login Store Community Support
View desktop website
© Valve Corporation. All rights reserved. All trademarks are property of their respective owners in the US and other countries.
Note: This Early Access game is not complete and may or may not change further. If you are not excited to play this game in its current state, then you should wait to see if the game progresses further in development. Learn more
This week I have been focused on making the performance optimizations from last week actually work in the context of the game! When you fundamentally change how the MAV's are put together, you run into some strange issues.
Most likely the funniest issue was me not accounting for rotation of the part you attach to the legs. Since I am a causal MAV builder, I slap a cockpit on the legs and call it a day. However, the more advanced builders ran into a funny bug that would flip the whole top of the MAV around! You can see it in action here.
The next biggest issue, was the turrets.
In MAV, turrets are MAVs, but just with some special rules. They have a set of legs [that can't move] a cockpit, and the same types of weapons as you. Only now, there is a bunch of code expecting them to be cut in half. This was a much trickier problem to solve, as I had to make some design choices on how I wanted to handle the code branching between the turrets and normal MAVs, as I try to minimize the amount of hard forks in the code as much as possible. After some extensive testing, I believe I have found a solution that allows them to still share a code base with a normal MAV, but with a minor number of code forks to handle the none split nature of them.
With these updates, I have also put out some new snapshot builds! What is a snapshot build? It is a quick build designed to address a few specific issues [mostly when dealing with multplayer] that allows people to play the build before it goes live to everyone. This helps me do hot fixes very quickly for a smaller number of players without the risk of sending the build to the entire player base. If this is something you want to participate in, just go here: http://bombdogstudios.com/forums/topic/enabling-snapshot-builds/
Also, with these snapshots I have started hosting 'Official Bombdog Servers'. These are 4 multiplayer servers setup on a dedicated box. 2 siege and 2 arena games, with and without AI bots. The goal is to always have a server available and I hope these servers help fill in any gaps. The community has been doing a great job of running servers and I am hoping these servers just help provide some extra flavor. Since the servers are fairly powerful, I have set the AI servers to have a reasonable AI count, 6 in arena and 8 in siege.
Also, in the latest snapshot I have adjusted some of the server admin commands. After a relentless assault by SergeDavid, I have changed the admin cmd syntax from 'cmd/' to just '/'.
I have also added these new commands:
'/endround' Instantly ends the round and calculates the winner. Good for siege matches where both teams are stripped or out of ammo but nobody wants to wait out the timer.
'/switchteam [PlayerName] [TeamNumber]' Force switches a players team during the team setup phase. Can be used on the AI as well. Usage would look like this: /switchteam RoboMAV-AI0 4.
'/reboot' Sometimes the server gets into a state that a hard reset is the best course of action. This command will close down the current server and restart it using the same settings that it originally launched with. Very helpful for people running headless servers on remote machines as well. Works with a machine hosting multiple MAV servers as well.
That is all for this week! I will be hoping on and playing through out the next week as I compile my list for the next big update. I hope to see you in game!
Performance is a hell of a thing. Chasing it is as close to being addicted to drugs as I can imagine. Your always chasing that last tiny bit of it and it has you doing more and more crazy things with ever diminishing returns. Here is how I spent 96 hours chasing my last high.
MAVs are expensive. MAVs on screen are VERY expensive. But worse, they are expensive just existing in the level. How expensive? Well, in my baseline test, 12 MAVs ate up 60 milliseconds of CPU time, not including the actual drawing of them on the screen. Considering I am looking to be at 16 milliseconds for the whole game, this was a problem.
Time to dig in.
It’s easy to say MAVs are expensive. Just spawn a bunch and watch what happens. I needed to know WHY are they expensive. Time to fire up the profiler! I jumped into 12 man games and watched as the profiler gobbled up all the data and drew all it’s pretty charts. I compared multiple plays on multiple levels, with different MAV makeups. This allowed me to eliminate specific MAV design issues or issues unique to a level. After a few hours I was able to create a hit list of the top offenders.
MovementCode – 12 ms
AnimationUpdates – 23 ms
AimingCorrectors – 8 ms
AttachmentCorrectors – 1 ms
Ground Alignment – 1 ms
These top 5 offenders are worth 45 ms of CPU time alone!
This is what this stage looks like
I created test levels with just legs walking in circles. I added spinning parts to them. I tested having the parts attached in a nested hierarchy versus a flat one. I tested just about every possible thing I could thing of. The more testing I did, the more apparent the looming problem was.
Unity hates how I build MAVs.
There was no getting around it. Unity fundamentally did not work with how I was assembling a MAV together. The most basic building block of the game and I had somehow done it the ‘Wrong’ way. Great. Time to throw in the towel and rewrite the whole game. I mean right?
Or, to quote Matt Damon, “It’s time to science the shit out of this”.
Or more so the scientific method. I spawned in a MAV and manually rearranged it, or tweaked a value, or twiddled a switch, logged the change in performance, then collected the data. I did this for exactly 148 different tests. I was chasing performance and I had to find it. And find it I did, in the most unusual of places.
Off with it’s head:
In my data logging I found several key points. Unity hates having a physics object attached to an animated object. Even worse if it’s a dynamic physics object. Unity also hates deep hierarchies. It seems Unity was written with less than 10 levels of nested objects in mind. Unity even more so hates rigidbodies being children of other rigidbodies. I was doing all of these things and unity hated me. In one test, I happen to remove the entire top half of the MAV as I was moving things and I noticed a MASSIVE increase in performance. So that is what I did. I chopped the MAV’s in half.
Chopping things in half is super fun, but for the game to actually work, we kind of need that top half back. I tried many different ways of doing this, the result of one can be seen below, but ended up having to go with a solution that was not as performance friendly as some of them, but actually provided the same game experience currently in MAV.
After fixing up some code that assumed your MAV was all 1 item, I had my results. What used to take 45 ms, was now taking a smooth 16 ms! A more than 50% decrease in CPU time!
MovementCode – From 12 ms to 3 ms
AnimationUpdates – From 23 ms to 6 ms
AimingCorrectors – From 8 ms to 0 ms!
AttachmentCorrectors – From 1 ms to 7 ms [Lots more correcting now]
Ground Alignment – From 1 ms to .5 ms
I have predictions that I can even reduce that more! It’s possible that with a more extensive rework I could save another 5-8 ms. This will need to be done for the eventual goal, but it’s time for me to move on to other problems for now!
You can use this widget-maker to generate a bit of HTML that can be embedded in your website to easily allow customers to purchase this game on Steam.
Enter up to 375 characters to add a description to your widget:
Copy and paste the HTML below into your website to make the above widget appear
Sign in to add your own tags to this product.