Hey everyone it’s time for your weekly update. Due to the holiday here in the U.S. last week was a short one for myself. I spent a good chunk of it writing new GPU benchmarking code and then using it on the UI path rendering. Running in debug mode with unoptimized shaders the initial results are what I hoped they would be – 500 to 750 fps with a GTX 1080 at a 1080p resolution for simple full screen shapes. This should translate to at least 200 fps on moderate hardware though I still need to see how many shapes can be drawn before performance begins to significantly degrade. At the high-end of 4k resolution I get around 200 fps. This is approaching the performance danger zone given that it’s only a simple scene being rendered with a GTX 1080 however it’s unlikely anyone will be running the game at 4k without a seriously powerful GPU anyhow. Lastly our algorithm scales extremely well for shapes that don’t cover a lot of pixels so since our UI won’t actually take up a lot of screen space even at 4k we should see decent frame rates in practice. Another benefit of the new UI code is that we can decouple its render rate from that of the game. What this means is we can render the UI at 60 fps whereas the rest of the game could be running at 120 fps so that UI rendering has a minimal impact on the smoothness of the game itself. Finally, in the case of extremely low-end hardware, we could render the UI at quarter or even half resolution and composite it into the final picture. I also found two bugs while doing the benchmarking, one is already fixed, and I’m currently working on resolving what is hopefully the final bug before I move on to more exciting things.
A pre-rendered shot of land base repair infrastructure
Flavien spent the majority of his week working on improving the threading of our game update logic. As we’ve mentioned before this will be an incremental process but he’s nearly finished with the most significant step. Once completed he’ll get back to resolving our last remaining major technical hurdle – the server-side planetary collision detection we described in a previous update. After that the focus will be on releasing the next patch and returning to gameplay iteration.
The art team continues its work on a number of large projects. This includes the final geometry and materials for the land base, the material pass for space station pieces, and the final geometry pass for the destroyer. It’s probably going to be at least 2 months before all of that is wrapped up but once we release the next patch we’ll try to get as much of that content into the game as possible. Lastly, we’ve been receiving reports over the previous few weeks that some people are experiencing problems with Facebook login. We haven’t changed anything on our end with Facebook in months, maybe years, so my assumption is that something changed on Facebook’s side. As soon as I finish fixing this last UI bug I’ll do another polish pass on our website and backend infrastructure and for those of you experiencing problems we appreciate your patience. That’s all for this week, until next time!
Wild idea - since drawing the UI directly affects the gameplay quality of the players: why not use this as a balancing tool? If someone blows an EMP bomb near my ship my UI would render at 10fps instead, or 2 fps. It would be much harder to track a moving target without the reticle keeping up. So whenever a big fight starts the “crowd-control” elements of the fight would start limiting the UI on some players and increasing framerate a bit during hectic fights.
Say i’m on a cruiser doing my cruisery things - if an enemy blows up my comm array my UI fps for targetting and target locking would go down to 1 fps, making it harder for me to do anything until my repair bots (or another player) fix it. With a performance improvement to boot,
What do you mean by crowd-control elements?
It sounds like you’re talking about some mechanism for keeping big fights going smoothly like EVE’s time dilation.
Such issues are generally server-side - ie the server struggling to keep track of all the weapons fire and double checking collision detection.
Ah I see! Thanks.
It’s an interesting idea but maybe if the only effect was a UI FPS drop, it could be confusing to players. “Is my PC struggling or have I been EMPed?”
It’s gonna work the other way around - i see that you might have lower FPS but still 60fps on the UI, if you get CCed the UI fps will drop but the game fps will remain the same. Planetside 2 does this - if you get EMP’d the UI… i’ll just how you:
With regards to EMPs (since it’s been brought up), I’d rather see them completely disable small ships and partially disable large ships. With a tightly concentrated battle, a well placed EMP detonation could be really effective at scattering forces, because of the Newtonian movement in the game. Everyone would fly off on their own vectors, trying to power back up. They’d also be (briefly) sitting ducks for anyone outside the blast radius.
I would certainly have it affect everyone though - meaning both teams within the blast radius - or it would be too overpowered. Possibly even disabling the person who fired it too, to prevent abuse, and making it a tactical, team-oriented decision. That person could have a quicker restart time than their victims though as they were “prepared” for the EMP.
@frag971 Those are definitely some interesting ideas and I think once we get the Alpha out there’s some interesting stuff we can play around with in the spirit of what you’ve proposed.
Keith said the UI and the game could have separate FPS caps, but that doesn’t mean their FPSs are entirely unrelated. Unless they are rendered on separate hardware an increase in one is going to result in a decrease in the other, and vice versa.
If you have low FPS (<60) in the game because of your hardware, then it makes sense to reduce the UI framerate so more GPU time can be spent on the game rather than the UI.
If your GPU is your bottleneck, if you get EMPed and your UI framerate is cut to 1 FPS, you’re naturally going to see a slight increase in game FPS as more GPU time is available for rendering the game.
I love the thought of ships being disabled and continuing on their ballistic trajectory until the pilot can power it back up and regain control.
If there are mechanical controls enabling the pilot to continue controlling the thrusters despite all electronics being knocked out, then it’s conceivable that your could loose the HUD but maintain control.
Looking forward to trying out these various ideas!
Let’s say that I’m playing on my computer and, according to the game’s design, end up getting 50FPS for the 3D stuff and 20FPS for the 2D stuff. The theory would be that everyone gets 20FPS for the 2D stuff because we’re going to mess with it for gameplay purposes.
Along comes the guy who drops that EMP. Everyone within range gets dropped to 5FPS HUDs. It doesn’t matter if they’re getting 200FPS or 60FPS for the rendering of the 3D environment because the frame rate of the HUD has become a gameplay issue. So it must naturally be throttled and uniform for everyone.
Yes, the 3D rate could rise when the 2D rendering is slowed, but it doesn’t have to. I’d argue that it shouldn’t, so that the player gets a more uniform experience out of the game. I find stuff like that distracting.
So anyway, I’m jumping in here to observe that the HUD display rate would become a gameplay issue if @frag971’s suggestion was implemented.
I don’t love the idea of being the guy in the ship that got disabled. Being in a disabled ship is not why I got into the game. An EMP should impair, but not disable a ship. The Planetside 2 guys understood that. Their weapon exists to temporarily disable systems on the player’s character, not completely prevent it from operating.
Don’t blind the pilot. Don’t take away his ability to maneuver. Those are severe breaks in gameplay. Temporarily remove one aspect of his capabilities and leave it at that. Per Planetside, drop a ship’s shields and short range sensors. That seems perfectly matched to what an EMP does. I’d leave the HUD up, but without any short range information on it. Or just some random information. Force the players to temporarily rely on their Mk I Eyeball to maintain situational awareness.
As a game developer I’d never intentionally reduce FPS for gameplay reasons. It would just look like poor performance and gamers are extraordinarily sensitive to such things.
I don’t love the idea of being the guy in the ship that got blown up. Being blown up is not why I got into the game. However, if there was no jeopardy it’d be a very different game.
As with all things, it’d have to be balanced. I don’t think anyone would suggest disabling a ship for long, leaving the player twiddling their thumbs.
There could also be options to invest in EMP shielding, reducing or eliminating the effects (and providing a surprise for the one who thought everyone was knocked out)!
Yes, it would be stressful being completely disabled, but real danger is the key to making a challenging, successful game.
i’m only talking about using a reduction in the GUI fps during a fight to INCREASE game fps slightly. I don’t see the UI taking more than 1 game fps penalty. You’re all worrying about the wrong things. Read carefully what i write.
EDIT: And whether or not our ships can be disabled with an EMP comes down to game design and balance, not UI. i was merely giving an example of a situation where you could use design and tech together.
This is not an issue of jeopardy. It is an issue of players being unable to play the game.
The very essence of a twitch game is fast action, so I really don’t see forcing a pause on a player in the middle of combat as a good idea. It flies in the face of the very gameplay that the players are after.
If I was implementing such a thing, I’d do something like trade shields on ships. If I have 100 points of shields, then I can do The EMP Thing. It drops my shields for N seconds (with a nice graphical effect) and also drops 200 points of shields of everyone within 100*M meters of me for N/2 seconds. It’s a shield bomb. If shields were sectional, you might find smaller ships converging on a section of a larger ship to work to bring down that particular section.
If my shields are only at half - 50 points - then I can only trigger a 50 point shield bomb. So it’s worth it to light up an incoming enemy ship’s shield if you’re worried about him trying that tactic. Of course, any ship that throws away its shield is that much closer to being destroyed, so it’s a tactic that would require some thinking. If there are EMP torpedoes or bombs, they better be very large and/or very expensive and/or very transient because they need to be balanced against conventional weapons that work to bring down shields.
Given that we’re all worrying about the wrong things, perhaps you should review what you write for how it will be read by others
As for fooling with the 2D vs 3D leave that to the players to balance. They’ll know what works best on their rig and they’ll know what they place emphasis on. This is pretty standard UI quality configuration stuff, just with a separate section for update rates on HUDs and so forth.
PVP action of any kind usually has pace to it. How the gameplay mechanics balance it is something that can be tested and discussed over the coming months.
But I don’t see why sudden pauses would be bad for this game, forcing people to regain control and think about the fight. It’s also possible there might be a rebooting mechanic to stop people getting bored!
So, as a player, I would like this! We’ll see what happens
I’d rather have a faster UI than game visuals if there’s really a choice here. Personal preference. I’d rather still be able to aim and hit things with the targeting icons in a competitive multiplayer shooter in a situation with low fps and poor performance.
Maybe move that whole issue over to the game’s option menu, if at all possible? Have separate settings for the visuals and UI in terms of FPS caps and such?
Most people probably don’t understand the difference between various types of anti-aliasing (MSAA, SSAA, FXAA, etc) and yet many AAA games with mass audiences allow the user to choose between them in their settings.
As long as there are sensible Low, Medium, High and Ultra presets, I think giving users the option to tweak everything is a good thing.
