I know something about the rendering, so I am curious about PA. Does this game apply some techniques to speed up? such as culling, level of detail, proxy image? Or it just renders all planets and units? The culling is a techniques to reduce the number of objects which are sent to the graphics hardware. For example, if you are look at a planet in close distance. The units on other planets doesn't need to be rendered. Level of detail: When the model is too far from the camera, it can be replaced with fewer faces model or even just a icon. Proxy image: The game can render the planet and its units to a texture, and this texture can be used in the background when the planet is far from the camera. I am not developer, so I don't know how the game works. But I guess none of three techniques is used in PA. For culling, I feel no frame rate difference when I zoom in and zoom out. Usually, the frame rate should decrease when I zoom out. This happens on many FPS games, or even some RTS game such as company of hero. If player is seeing the close range, the frame rate can be higher. For level of detail, I guess that the models of the units are always rendered. When I want to assist a fabricator, I must click the unit. If I click the icon of the fabricator, it will be a miss. So I think this game uses the selection buffer to pick up the units. And the icons are not rendered into the selection buffer. Instead of rendering the icon only, PA uses a slower method to implement it. That is "Always render the units". Even if the icon is larger than the unit, the game is still rendering the unit model. And that's why I must click the fabricator exactly. If you have played the SC:FA, you know the units are not rendered when the camera is very high. Only the icons are shown, and these icons are able to be selected. For proxy image. I can see the command line and estimated building position on the planet which is floating in the background and far from my camera. So I think the while planet is always rendered in every frame, and there is no cache or proxy image to reduce this overhead. If I am wrong, please tell me. I will appreciate.
It uses many such tricks. If it were to not use such tricks the game would not work at all on most hardware.
Occlusion Culling, Frustum Culling, Level of Detail (multiple steps) are basic optimization steps that are definitely in the game. They also make use of tile-able textures for each biome. They do this in a way in not sure is the most optimized but it is the most dynamic, I know too little about this way of texturing so yeah. The most likely reason for the "select unit on unit itself instead of Icon" issue is that they just turn off the mesh renderer of said unit and keep the same "collider" it always uses on. The icon is purely a GUI thing with no colliders attached and thus you can't select a unit via the Icon.
Yep they would need to keep track of the stuff they render with the icons to do pixel perfect checks against it.
Nah if GUI is used as a button they use 2D collision planes. Every Icon/GUI/UI element in the game is a square in it's origins. It's the fact we see it round is because of the transparency in said files. The square Icon collider would be as big as the maximum width/height of the image. Which yes, means that you could miss-click because some parts of the collision are transparant. *Damn I need to brush up my technical english*
I think the icons of units are billboards. They are always on the top of screen and above all units and planets. It is obvious when two planets are about to collide. The icons of unis are above both planets, but some of them should be occluded by one planet.
The word "Billboard" in game development refers to objects always facing the camera. It does not matter if these objects are in 2D or 3D space. For instance you have a tree infront of you 5m away. it is 100% rendered (LoD1), when you walk backwards 30m away from the tree. It now has a mesh 75% of original polycount (LoD2). 60m away 50% polycount (LoD3). 90m away 25% polycount (LoD4). If the mesh is still visible at a distance of 100m+ the tree transfroms from a 3d mesh to a 2d plane which "billboards" or in other words always faces the camera. Another thing that almost always "billboards" are all particle effects. *Note numbers are arbitrary and for explanation only* Icons and GUI are Sprites. And also spites are very very light to render. For example if the Icon of the Dox is 10kb in size, the game only needs to load that icon once and than saves it into the games memory. When certain parameters are met the Icon will need to be rendered and at that point the game only needs to render it from memory. If you have 10 dox, which means 10 icons, then the amount of memory needed is still 10kb as the image is the same it's just rendered on other places. The only thing going on is rendering itself. - Forgive me for my god awful english explanation. Atleast it's good exersize lol. - Note this is how I've learned it and I don't know how or what Uber does and uses.
The unit icons are held in some form of texture generated dynamically from coherent. I was implying to consider that and work with it. In Ubermap I generate 2d arrays of booleans from the icon images once at startup. To check if a click hits an icon I convert the clicked position into local coordinates on those 2d arrays based on the position of the icons I render and their scaled size. If it's true it hit. That way there would be no need to further keep track of the rendered frame directly. Instead you just keep track of icon positions (PA has them anyway) and other transformation applied on the icons (scaling comes to mind) to convert the coordinates. The resulting behavior is pixel perfect within floating point rounding accuracy, which is easily "good enough". I'd say PA would need to do something similar. This would need to happen in native code though, the UI does not know the location of the icons you can see.
