3. Need for Speed - Endgame optimization limitations

Need for Speed - Endgame optimization limitations


  • "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.