Knuckle Cracker Wiki

User Tools

Site Tools

Trace:
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
Next revisionBoth sides next revision
cw4:frequently_asked_questions [2020/07/11 10:27] – Karsten75cw4:frequently_asked_questions [2020/08/11 10:42] – added BFS search Karsten75
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. 
Line 12: Line 12:
 **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:**   * Why can packets no longer travel via units?
 +  * Why can I no longer use units to connect between towers as in CW3?     
 +\\
 +**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:**  **Q:** 
cw4/frequently_asked_questions.txt · Last modified: 2021/01/09 18:02 by Sanian

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki