User Tools

Site Tools


cw4:frequently_asked_questions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
cw4:frequently_asked_questions [2020/07/09 17:20] – added more of forum questions Karsten75cw4:frequently_asked_questions [2021/01/09 18:02] (current) – [Units] deleted empty Q: and A: lines Sanian
Line 4: Line 4:
 **Q:** Is the game frame-locked? What frame reate is it designed to operate at?  **Q:** Is the game frame-locked? What frame reate is it designed to operate at? 
 \\ \\
-**A:** The game is frame locked and whether it meets it's intended frame rate is a function of available processor and graphics resources. Internally, CPU-intensive tasks such as the Creeper Simulation is intended to run at 30 cycles per second. These tasks are also, where feasible, multi-threaded to take advantage of multiple processor cores. Display, the UI and rendering is frame-locked to the internal cycles at a 2x multiplier, thus yielding **60FPS** for the player. Should game performance degrade to to CPU intensive maps, then the player will experience a corresponding drop. +**A:** The game is frame locked and whether it meets it's intended frame rate is a function of available processor and graphics resources. Internally, CPU-intensive tasks such as the Creeper Simulation is intended to run at 30 cycles per second. These tasks are also, where feasible, multi-threaded to take advantage of multiple processor cores. Display, the UI and rendering is frame-locked to the internal cycles at a 2x multiplier, thus yielding **60FPS** for the player. Should game performance degrade due to to CPU intensive maps, then the player will experience a corresponding drop. 
  
 It is possible to have the simulation engine run at 2x and 4X speed, but this will not be reflected in the externally-observed FPS rate.  It is possible to have the simulation engine run at 2x and 4X speed, but this will not be reflected in the externally-observed FPS rate. 
  
-**Q:** the  core game engine operates at 30 FPS (ideally, given sufficient processor resources) but the visual portion of the game is rendered at 60 FPS. How does that work?+**Q:** The  core game engine operates at 30 FPS (ideally, given sufficient processor resources) but the visual portion of the game is rendered at 60 FPS. How does that work?
  
 **A:** Map panning, zooming, animation effects, and general other visual concerns looks smoother at 60fps.  For instance, when you scroll the mouse wheel and zoom, the game animates the camera movement rather than snapping to new zoom levels.  That animation looks better at 60fps. It also give an opportunity to do some things on the even frames and some on the odd.  So things like shoving all of the creeper geometry changes to the GPU happen on the 'off' frames.  Of course Unity still renders the creeper geometry every frame (which is at 60 fps ideally) so lighting and shadows and all of that happen at 60. **A:** Map panning, zooming, animation effects, and general other visual concerns looks smoother at 60fps.  For instance, when you scroll the mouse wheel and zoom, the game animates the camera movement rather than snapping to new zoom levels.  That animation looks better at 60fps. It also give an opportunity to do some things on the even frames and some on the odd.  So things like shoving all of the creeper geometry changes to the GPU happen on the 'off' frames.  Of course Unity still renders the creeper geometry every frame (which is at 60 fps ideally) so lighting and shadows and all of that happen at 60.
  
  
-**Q:** +**Q:**   * Why can packets no longer travel via units? 
 +  * Why can I no longer use units to connect between towers as in CW3?     
 \\ \\
-**A:** +**A:** For pathfinding efficiency. 
 + 
 +Pathfinding uses A* (and caching).  There's a lot going on in the game, though, so pathfinding is just one straw on the camels back. So every little bit of efficiency here and there adds up.  Removing terminal nodes from the graph (units) reduces the graph complexity  by a lot (in most cases). It also produces a game play that I prefer (so it's a win win).  Note that the graph changes frequently when people move 50 units at a time and there might be 100 packets per frame being emitted (from different sources to different destinations). So eliminating moving units from the graph makes that worse case scenario more efficient 
 + 
 +To determine connectivity of any unit to the rift lab, a BFS (Breadth First Search) exploration of connected nodes is performed every frame. There are game rules based on knowing that... like the towers providing power.  Since that happens anyway, the game keeps track of the distances when running BFS and then use that to determine the best route from the lab to a unit.  As for the factory, a similar search is performed. The reason is because the one factory needs to receive and send to numerous destinations. The sources (deposits, etc) need to know if they are connected to the lab.  So similar issue.  Note there are some other optimizations in place. The BFS for the lab and the factory run in parallel each frame in their own threads.  Some other cases exist where a packet needs to go places (like a pod). In cases where connectivity knowledge is needed, all units know if they were crawled in the BFS by the lab and the factory. So two thing are connected if they share a common connection. And of course A* is still there in the case of an arbitrary A to B routing need on the graph. 
 + 
 +Note that these graph searches are performed every frame, are resource-intensive and area multi-tasked. This is also one of the primary reasons why non-network units (such as weapons) are not considered for packet routing in CW4.  
 + 
 +**Q:**  Describe the ""Hold" objective. 
 +\\ 
 +**A:** The Hold/survive objective will keep counting time so long as you hold the minimum number of bases (in this case 1, since there is only 1 on the map).  The objective time is the minimum time, so you get the Hold objective when you reach that time. You can keep running the time up as long as you want... or can. Now in this mission, you can hold the mission as long as you care to once it is stable.  One of the reasons I wanted to see your plays on this mission is I wanted to establish what seemed like an adequately long time to take over this type of map. What I'd like to do in other similar missions (in the full game) is add  Creeper++ but with a really long initial time.   After that, the map will more and more aggressive.  Most people will have bugged out by then because most people will have one or more objectives already.  For those that want to get the longest possible Hold time, that's when the challenge would begin.  That's the idea anyway.  For this map I think I'll  make a setting on the Hold objective that says the min time is also the 'max' time. As in the Hold objective doesn't keep counting up past the specified time.  That's the simpler scenario for maps that don't want to have some sort of ramp-up-to-eventual-destruction mechanic. 
 + 
 +===== Units =====
  
-==== Units ==== 
 === Cannon === === Cannon ===
  
-**Q:** Why do Cannons not shoot at the top of waves/visible creeper and instead aim at the terrain. \\ +**Q:** Why do Cannons not shoot at the top of waves/visible creeper and instead aim at the terrain. \\  **A:** Cannons fire in a straight Line-of-Sight (Los) from the barrel to the terrain, limited by distance. There's no artificial rule about not being able to shoot higher. It just has to be able to 'see' the terrain it is firing at. So it can shoot up at a higher ledge, but it can't shoot at a terrain cell that is inland on higher terrain (since there is not line of sight to that cell)
-**A:** Cannons fire in a straight Line-of-Sight (Los) from the barrel to the terrain, limited by distance. There's no artificial rule about not being able to shoot higher. It just has to be able to 'see' the terrain it is firing at. So it can shoot up at a higher ledge, but it can't shoot at a terrain cell that is inland on higher terrain (since there is not line of sight to that cell)+
  
 From a game play perspective, firing part of the way up (into  a wave, or at the top of a wave) has two impacts; It can miss more than you realize (because the creeper gets lowered before the shell arrives), and it's more computationally intense to calculate how high to shoot (or to try to predict what the height should be at some point in the future). From a game play perspective, firing part of the way up (into  a wave, or at the top of a wave) has two impacts; It can miss more than you realize (because the creeper gets lowered before the shell arrives), and it's more computationally intense to calculate how high to shoot (or to try to predict what the height should be at some point in the future).
Line 29: Line 40:
 And the final reason... it works to shoot at the terrain. It's effective and the gameplay is fun. And the final reason... it works to shoot at the terrain. It's effective and the gameplay is fun.
  
-From a lore perspective the cannon shell detonates on contact with the terrain. +From a lore perspective the cannon shell detonates on contact with the terrain. 
 + 
 +**Q:** How do target acquisition work for cannons (and sprayers)? \\  **A:** Cannons in CW4 don't have have any other rule than "line of sight and max range" So if there is a slope or a ledge, a cannon will shoot up at it.  Normally, a cannon barrel sits just slightly lower than "1" off of the terrain it is sitting on.  So it can't see on top of adjacent terrain that is 1 level higher than it is. It can see the edge, though.  Nearby hills might have edges that hold creeper and the cannons can shoot at them. The old rules in CW3 were based not on LOS but on higher or lower.  In CW3, it's just straight line LOS.  Note that it is the map vertices that are evaluated. 
 + 
 +The reason cannons can't just shoot at all lower terrain in range is... they'd be shooting through the terrain. 
 + 
 +=== Mortar === 
 + 
 +**Q:** How do target acquisition work for mortars?  \\  **A:**  Mortars use a simplified parabolic calculation for line of sight.  It's simplified to a triangle. So it's two straight LOS calculations. For every point in range they check for LOS to a midpoint (at a height) and from the midpoint to the target. 
  
-**Q:** \\ +===== Terrain ===== 
-**A:** \\ +===== Creeper/Wave Mechanics =====
-==== Terrain ==== +
-==== Creeper/Wave Mechanics ====+
  
 ===== Pre-release FAQs ===== ===== Pre-release FAQs =====
cw4/frequently_asked_questions.1594329654.txt.gz · Last modified: 2020/07/09 17:20 by Karsten75