3. Need for Speed - Endgame optimization limitations

Need for Speed - Endgame optimization limitations


  • Dear Dissi,

    Gaining direct access to setIntent is something I have been hoping for as well. It doesn't seem like it would be too difficult to accomplish. All necessary verifications should already be performed on the processor side anyways. Access to the spatial registers would also be very welcome, but I'm not sure how easy that would be to implement.

    However, I strongly disagree with differentiating the base CPU cost of any core action such as move or harvest. The standard 0.2 CPU cost for any set intent is a good standard and I think it should remain that way. The trick would then be to restructure your creeps/processes so that they need to perform fewer actions. For example:
    - make 50 part harvesters which only need to harvest 1/10th the time an optimized harvester
    - make 50 part haulers even for nearby containers so that they need to move less often

    I have always envisioned that the "endgame" is a shift in strategy where the focus is less on resource/spawn efficiency and instead heavily focusing on CPU efficiency. I agree that we should not be penalized by client side checks which are intended to assist the user. However requesting that the core game mechanics be changed so that players do not need to make radical adjustments after GCL 28 doesn't feel right.

    As far as I can tell, It should be possible to run an efficient AI with 45 rooms without having to make radical strategy adjustments as the ones mentioned earlier. With extreme strategies that number could be pushed to 60-80 although I have not made any math on how profitable such strategies might be.

    If anything, move() should cost more since it is one of the most expensive functions to process server-side.

    Kind regards,
    Atavus

  • Culture 

    atavus:

    - make 50 part harvesters which only need to harvest 1/10th the time an optimized harvester
    - make 50 part haulers even for nearby containers so that they need to move less often

    I tried this, it's not more CPU friendly. The 50 part harvesters is just waste energy as well. You energy income per CPU won't rise if you try this, feel free to try though!

     

    atavus:

    However requesting that the core game mechanics be changed so that players do not need to make radical adjustments after GCL 28 doesn't feel right.

    I think you misinterpreted what I wanted, I'm opening a dialogue here for more lategame variation in tactics. As you can read I've pretty much exhausted any normal way of optimizing my scripts. Obviously less creeps = less CPU.

     

    I'm looking for way we can improve the late-game, and am challenging the community to come up with ideas.

  • Culture

    To be fair there already is a difference between some intent setting functions. For instance, running a reaction a lab is closer to 0.35 cpu than it is to 0.20 cpu.


  • Ok, let's switch it around and do some math.

    Let's assume an inefficient scenario where each source has:
    - harvester 1 carry : 6 work : 3 move => 800 energy
    - carrier 32 carry : 16 move => 3200 energy

    Mind you this assumes an average distance to a source of 80 units which is pretty extreme. It assumes all your sources need a carrier.

    If you double the size of your harvesters and you spawn 2 carriers instead of 1, then in an ideal scenario you are dropping your CPU cost to half. 1 carrier is always waiting and the harvester only harvests half the time.

    This means that you can use the extra CPU to mine another source. So you pay 4000 extra energy to gain the use of one more source which will produce 15000 - 8000 over the lifetime of a creep.  Assuming an energy overhead for the necessary infrastructure of 4000, that's still 3k energy profit. More importantly, the scenario here presented is pretty inefficient.

    50 part creeps are probably unprofitable, but somewhere in between a standard 10 part harvester and a 50 part harvester is a good balance between CPU and energy profit.

    Technically a room which has access to 6 sources in total is already a very profitable room. If you would shift away from SK rooms (the extra minerals are no longer important), I can see reaching 45 rooms as a reasonable expectation.


  • "I'm looking for way we can improve the late-game, and am challenging the community to come up with ideas." ~ Dissi

    Let me just be mean here for a second.

    So, you are challenging the community to come up with ideas which will exclusively benefit the 7 strongest players in the game?

    Shouldn't it be the case that these 7 players collaborate and experiment with different tactics and then share their results with the rest of the community?

    Shouldn't it be that the best players help lift the whole community to a new level of gameplay?

    😛

  • Culture 

    atavus:

    If you double the size of your harvesters and you spawn 2 carriers instead of 1, then in an ideal scenario you are dropping your CPU cost to half. 1 carrier is always waiting and the harvester only harvests half the time.

    No, you pay 4k energy to have extra idling creeps which might overlap actions while walking, costing more CPU, reaching your limit faster due to burst issues ( can be mitigated ). 

    It's also not what the discussion is about.

    I'm trying to aim the discussion more towards the CPU limitations we currently have due to how the game is programmed. I run ~960 creeps + buildings simultaneously with little overhead, the CPU costs are just too high. This can become 1500 creeps of which 440 are idle on a wimp, it's not the issue I'm trying to discuss here.

     

     

  • Culture 

    atavus:

    So, you are challenging the community to come up with ideas which will exclusively benefit the 7 strongest players in the game?

     

    No, you can benefit from the same changes.


  • Ok, let's try a different angle. Let's focus exclusively on harvesters.

    Let's assume:
    - 20 RCL8 rooms
    - average CPU cost per room with remote mining (SK or otherwise) of 10
    - average income per room of 1.5m per 24h
    - average creep cost per room of 750k
    - total harvesters 165
    - average harvester cost 850

    Let's suppose you double the size of your harvesters:
    - extra cost per room ~7k
    - extra cost empire wide ~140k
    - CPU gain 33 (harvesting only half the time)

    So I'm spending 140k energy to get an extra 2m+ of energy (more rooms) for the exact same CPU.

    I think the math is pretty clear. Even assuming that the benefit is not 0.2 per creep (it really should be). Even assuming a benefit of only 0.06 CPU per creep from the double size. That still gives you one extra room and at least 500k energy profit.

    I get the feeling there's definitely room for optimization at GCL >30.

  • Culture 

    atavus:

    I think the math is pretty clear. Even assuming that the benefit is not 0.2 per creep (it really should be). Even assuming a benefit of only 0.06 CPU per creep from the double size. That still gives you one extra room and at least 500k energy profit.

     

    I'm not saying you're wrong, the problem is that it's not what the discussion is about


  • Sorry, I must have misunderstood. I thought the challenge was how you could push the limits after hitting GCL 30.

    What I was trying to suggest was that there is no need to discuss about changing the core game mechanics until we have players which have exceeded GCL 45.

    On that note, I would still very much appreciate getting access to setIntent. Pretty please @Artem?

  • SUN

    From my point of view (and ... YMMV of course) : empowering the player with more efficient tools at the cost of more "danger" seems all good : eg, giving us access to lower level, unsafe APIs for the sake of performance (and at the cost of cpu penalty if you misuse) seems a good idea to me.

    However I don't see the point in  reducing the fixed cpu cost of any thing , you'll just hit that same wall, just a little bit later right ?

  • SUN

    and ... from my own experiments, even though my efficiency is miles away from yours dissi, it seems i was able to reduce cpu footprint of energy harvesters by having one harvester run both sources in a room (eg, bigger, moving between the two sources) when the sources are close enough.


  • I would love access to the FIND registers and the intents.set object! Also, as an alternative to reducing move cost, perhaps there could be a reduced cost for creeps doing multiple actions? Something like the first action costs .2, then any subsequent actions only cost .1. I feel like this could alleviate a lot of cpu for creeps that move + some action(s) on the same tick. This is based off my assumption that some portion of that .2 constant is accounting for updates to the creep itself, which could be combined when it's doing multiple actions.


  • I'd love to have more options to write efficient code.

    Ideally they should come with trade-offs such as direct access to intents idea (lower cpu cost, more challenging to use right) with a penalty for getting it wrong (higher constant cost if conflicts do arise)

     

    As a new player this opinion may not hold much weight, but I'm going to disagree with the notion that raising GCL once past 28 has currently not enough benefits or that the 7 top players who did achieve this should be catered to specifically. First, being high ranked is a status thing. Second, the increased room limit past it does have (some) benefits. It can be used to own an earlier reserved room without fullly developing it, which means:

    1. no reservers are needed (smallish cpu saving)
    2. reduces the dropoff distance for remote sources using a lone termina (smallish cpu saving)
    3. an extra source-keeper-free minerals (smallish cpu saving, also makes balancing minerals easier)

    Instead of investing time in changing or developing things that benefit a few players, I'd be happier with progress on general improvements that benefit everyone equally (or give everyone reason to rewrite their codebase, such as the visual thing)

    On how to stay engaged once hitting the ceiling: I don't have any ideas. I suspect this is a problem that can not be solved using game mechanics, every MMO has it in some way. No matter what improvements for the players past 28 are added, at some point they'll hit a new ceiling. Even if the restrictions on GCL and cpu were to be entirely removed it'd get boring after a while (infinite growth at a linear rate)

    I hope that the power creeps, other future enhancements and the excellent user community are enough reasons to stay engaged for now 🙂


  • Relatively new player chiming in here, but I have 25+ years programming experience.

    I've found it to be really funny that ultimately this game boils down to trying to optimize JavaScript code for CPU usage.  JavaScript has to be one of the worst languages ever invented when it comes to CPU optimizations.  The entire benefit of using JavaScript is its asynchronous nature (which we the players are not really able to take advantage of without costing ourselves more CPU) and its amazing efficiency at performing I/O (which again, is useless to we the players).

    TL;DR JavaScript is a horrible language for us to be using, if CPU optimization is the end goal of our code.

    I'd love to be able to submit C++ code, pay for the compile costs via my bucket, and then see it run at 2x or 3x more CPU efficient than the JavaScript code will ever be capable of running.

    Sure JavaScript is a fun language.  It's easy for people to learn.  It is not at all CPU efficient, and if the game really boils down to CPU efficiency being the highest priority, then ultimately JavaScript is the wrong language to be using.

    WTB C++ compatibility!  🙂

  • SUN

    @Xist qualities of the language here are not really that important, we're all using the same, so the field is level 🙂

     

    The winner is the one that finds more efficient ways through his code design decisions


  • @Finndibaen I totally understand and agree that the playing field is level if everyone uses JavaScript.

    I only meant to suggest that, since the cost of running the servers is almost purely based on how much CPU/RAM is used, and thus the game devs wish for us to make the most CPU efficient code possible, then allowing us to use a language which is significantly more CPU efficient than JavaScript would likely go a long way to reduce their expenses.

    I'm sure this is no small amount of work for them as they are very heavily invested in JavaScript.  However it's something for them to consider if indeed they do want to save probably-significant money without the consequences of simplifying/reducing the game that we all enjoy playing.