Welcome Guest, Not a member yet?
Why not sign up today and start posting on our forums. |
Sector Siege needs improvement
|
Yay, new stations! The 2 big ones are excellent! They really give you the capability to put the bigger baystations up front, and use the bigger gunstations to provide a more powerful static defense.
The First Contact is cute, but way overpriced/under-statted. For 1600 you get a 3 big gun, 2 PD with 1400 hull, 500 or 700 shield. For 1800 you get 8 PD, which is approximately the same overall firepower, but 600/600 hull/shield? And with much fewer marines. I don't mind keeping the price the same, but crank up the hull to like 2000/1000 making it easy to snipe but extremely hard to kill. That seems fitting with the original game. :-)
Curious are you using models or sprites? I would have figured you went with sprites because of the ed nature of the game. Also if you are using ed models how many levels of detail have you built into the game. Even a moderate application of lods could significantly lower the needed render calls. I wish I still had a PC because adding LODs to higher poly models was my thing when I could mod Armada2.
It's all sprites. They're not the main problem regarding performance though, it's the logic needed to run those units and turrets.
Odd ai behavior usually doesn't put that kind of strain on the processor. I wonder why
Well, could always be something in the code. However, I have checked with a profiler tool and optimized the game a lot. I've used many tricks to do this, and all of it happens when the units are hidden from the player.
A single unit affects multiple things. Even a single fighter has to be taken into account regarding fog of war, updating it regularly. The unit has to scan for nearby units and mark them as visible or not compared to itself. The fighter also has to periodically scan for nearby units and find a target. A movement trajectory has to be calculated and the fighter has to follow this. A single turret needs to periodically scan for nearby units and find a target. If a big ship unit has 10 turrets it means merely this one unit already has 10 turrets looping through all enemy units, and doing calculations to find a target. Smooth rotation of turrets and fighters seem to take a bit too. And there are a lot of turrets and fighters. All of this means there is a lot of looping through objects and calculations going on. Adding more units immediately means the lists grow for units and turrets. I stay clear from doing scanning and calculations every frame of course, and from doing all calculations for all units on the same frame. I use a lot of other tricks to make the game perform a lot better.
Starfox, if you want an idea of any limitations present, try doing a 2x2 scirmish mode. It does tend to tax the device and you can see where the limits start showing up.
(11-17-2017, 02:27 PM)AdmiralGeezer Wrote: Well, could always be something in the code. However, I have checked with a profiler tool and optimized the game a lot. I've used many tricks to do this, and all of it happens when the units are hidden from the player. I hear what your saying. I just can't help but feel something is off because they beauty of sprites is how resource lite they are and these kind of calculations are bread and butter stuff for a cpu. For the numbers we are talking they shouldn't even put a dent in a quad core or octi core processor like my phone has every. The game just shouldn't be able to lag the processor. There just shouldn't be enough going on. I mean look at some of the mods 4 games like Empire at War or Sins of a Solar Empire. They use high poly 3d models with 3d turrets and hav similar tracking with 10 times the assets before lag becomes an issue. Its got to be a software problem with the engine but for the life of me I don't know where to look. What's the res on your textures? Loding them might help some especially if you are running really high res like 4096 or higher and file type might also be a factor as some formats are significantly larger than others for the same resolution.
Those are solely PC games if I'm not mistaken. There is a huge difference between PC devices and mid-range mobile devices. Sprites are nowhere near that size, units are made up of 1-6 sprite pieces varying in size. Closer to something like 100x100 in size. But again, rendering is not the issue Although if one chooses the wrong way to implement fog of war on mobile, that will be it for some devices. It will simply kill performance. This varies a lot across different brands and devices too.
It sounds like the fog is the part that's dragging down performance. Would having the option to remove fog improve profomance, say as a game option? Also it sounds like android doesn't handle things nearly as well as pc's do. Maybe this is something you should pass on to Google and see if they have any ideas.
Please disable the fog if it’s dragging the performance down, you can add random incursions that appear anyway, it’s not like we know every detail of what the enemy can portal to us or events that create portals if we get within distance of their bases.
Also is it possible to change the gun scanning, make the ship or building scan, then adjust for the distance difference for the turrets, this is far less calls. So the building scans, notices an enemy is X distance which means the building can see, it then sends this info to the turrets that say this distance - distance of turret compared to the middle of the building, then it simply says yes or no as to whether it can now fire at the enemy. This is easily possible and would allow for more ships and buildings especially if the fog is removed. To explain more, you should be using simple X Y coordinates for scanning anyway, so the distance of the turret compared to its parent is simply a set of numbers on this scale. The enemy distance is also a set on this scale. It’s a simple test of comparing the distance to the building, then adding or minus the turret distance on this scale to the building, and comparing it to the turrets range, some simple maths would tell you that it’s within range or not, now just set a bool that says it’s in range or not, if in range allow firing, this just calls the same thing you use for firing now. With regards to how the building itself scans, just set a perimeter around it, so say 2000 range circumference, it simply scans this circle and nothing else, it has no need to scan anything else. Really feels like your over optimising at some points and missing things at other points. |
Users browsing this thread: |
14 Guest(s) |