Settings.ts 3.3 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455
  1. module Settings {
  2. var debug = console.debug;
  3. var debugEmpty = () => {};
  4. export var hardDebug = false;
  5. export var sayTurnTime = true;
  6. export function setDebug (isDebug : boolean) {
  7. if (isDebug) {
  8. console.debug = debug;
  9. } else {
  10. console.debug = debugEmpty;
  11. }
  12. }
  13. export function isDebug () {
  14. return console.debug == debug;
  15. }
  16. export function setHardDebug (isHardDebug : boolean) {
  17. hardDebug = isHardDebug;
  18. }
  19. }
  20. //Settings.setDebug(false);
  21. //Settings.sayTurnTime = true;
  22. /**
  23. * Future notes on Performance Issues:
  24. * - It doesn't really matter if most of the code is optimized or not. CPUs are fast.
  25. * - It *does* matter if code that is run frequently is sub-optimized.
  26. * --- Biggest place to look at is at Every Turn Rules, particularly AI: these will run for every action the player does for every single NPC in the game.
  27. * - This being a text game, we have up to 100ms before the player "feels" the game isn't instantaneous.
  28. * - Beyond that, we have until about 250ms before the player starts getting legit pissed. These are both per turn.
  29. *
  30. * Being that all other code will run once and that's the end of it, the only portion of the game that CAN bring performance issues will be the AI.
  31. * Each NPC added increases time spent by AI by around ((n + 1)/n). Each rule added does the same.
  32. * Since NPCs will be added and more and more rules will keep getting added, AT SOME POINT we'll have problems.
  33. * Stress testing with Pick Shinies and NPCs suggests that we can have about 200 NPCs and about 800 rules before problems, but the testing is not ideal:
  34. * - Pick Shinies increases in complexity with the amount of things in a room. So the test made this rule particularly nasty, since all NPCs were going and coming from the same rooms.
  35. * - In a real game situation, it's expected for rooms to rarely have more than 5 things/people in them and for NPCs to be disperse.
  36. * We should never reach our 250ms limit on powerful CPUs.
  37. *
  38. * Regardless, if performance ever becomes an issue:
  39. * - Optimize AI trees so that Conditions don't have to be checked. Cook each NPC's Rulebook so that all rules that aren't his aren't ever looked at. This is the simplest, no-loss improvement, but only offers improvements if the NPC * RULES number is big.
  40. * - If the number of Rules * NPCs is not the issue, then figure out which specific rules are being a problem and optimize them specifically. In general, expensive rules should also be rare. This solution might not always be available and might not get all that much result.
  41. * - Slow down AI for NPCs away from the player. Possibilities: if an NPC is more than 20 rooms away, it only gets one action every 4 turns, then 3, then 2... until it's close enough to act every turn.
  42. * - Simply skip AI for NPCs in different regions. i.e.: if the player is inside the Obelisk, don't even bother with NPCs in the forest.
  43. *
  44. *
  45. * We also do a lot of debugging.
  46. * While disabling console.debug offers a substantial performance gain (around 50%) and is available as an Option,
  47. * entirely commenting out console.debug calls gives us an additional 20% gain on top of that, for a total of around 60% performance gain.
  48. * Considering debugging is not really useful for players, this should always be kept in mind.
  49. */