Results 11 to 20 of 44
Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast
  1. #11
    Maybe the word arbitrary isn't so good to use in gaming since everything developed and the values placed on the developed assets are always arbitrary lol.

    However in terms of balance the difference between assets shouldn't be arbitrary once the boundaries and limits of the entire game are set. e.g. defining the boundary of maximum speed any player can go when a full 100% investment of CPU is put into parts that give speed for example. Maybe 100% is too much since that gives no room to invest in health so you're already dead before you begin. A maximum CPU investment in health or speed can be no more than 99% and no less than 1%

    So a 99% CPU investment in speed should be the fastest a player can ever go in the game. Leaving them just 1% of their CPU to invest in health parts.

    Algorithms to set this balance should be on the backend developer end, us players shouldn't be seeing any of that, all we need to know are the stats of the parts we're using. The stats of the parts shouldn't change, what is displayed in the inventory should be the stone set stat.

    Maybe something like after creating an asset, a dev arbitrarily sets the values of "part type", CPU cost, and part size of their asset. Then if the asset is a armour piece for example the algorithm outputs a mass value and a health value that the part should have applied to it based on the part size, cpu cost and function in the game compared to other parts.

    Ex.1: So if it's a big piece armour that cost a lot of CPU, it's not going to get a huge mass but it will have a lot of health.

    Ex.2: If it's a big piece of armour that cost not as much CPU, it's going to get a lot of mass and more health then the first example. The idea is to automatically trade speed for health via mass.

    You can make a million different parts all with different stats but every advantage gained in 1 stat will come at a direct and correlative compromise to it's counter. I could probably put together simple formula in a spreadsheet that when i put some basic data like size and CPU cost i get an output of relative stats where speed and health are in direct correlation instead of arbitrary.

  2. #12
    Thank you for expanding upon your thoughts. It sounds pretty cool.

    So - if I understood you correctly - quite aside from how a player builds a bot you would like to also have players invest CPU towards a 'purpose' - whether it be toughness or weight or anything else for as far as the total 'category' profile is concerned.

    The one thing that slightly concerns me about that, if I understood you correctly, is that this could mitigate the building element by its very nature - since CPU would be invested towards boosting traits of that which is built in.

    Furthermore, one couldn't look at a block and say 'OK I know the traits of that block' by sight alone - since again, the player-assigned CPU could very from one bot to another such as to make knowledge of the baseline meaningless.

    Even if I am understanding you correctly though - I'm certain that there is room for improvement and I would encourage you to develop the idea further and dedicate a thread to it - and I'll be happy to take a closer look at it.

    For the moment though. I just have this sheet.

  3. #13
    Updated to Version 1.22 - and now have two sheets for FreeJam's stats - one current - and one 'mostly' (pending info on minimum fire-rate) reflective of FreeJam's update to come.

  4. #14
    Updated to version 1.25

    Every older version since December 2018 is in there - but I'd like to draw FreeJam and players' attention to the current 'Revamp' proposal sheets.

    The highlights in brief:

    - A modified roboranking balance
    - A complete rebalancing of existing parts
    - New chassis parts
    - New movement parts
    - New weapon parts
    - New modules
    - New balance mechanics (elaborated on in commentary sheet).

    This revamp is loosely but surely based upon FreeJam's current balance and so is current.

    I would appreciate feedback as always.

  5. #15
    new parts are almost always welcome ^-^

  6. #16
    May I ask what is EP A, B ,C?

  7. #17
    ElectoPlates in the current version have been divided between tiers and each tier has an 'A', 'B' and 'C' variant (I don't get into sides and consider left and right to be the same).

  8. #18
    The problem with the 100% to be spent on health/speed/etc is that there is always going to be disparities with builds - eg you build a small, fast, bot.. and then stick teslas on it and prove to be an annoyingly hard to hit bot killer win-machine.

    You could set weapons damage as part of this system, but again, you'd end up with small fast bots that do mega damage. Not fun.

    just go back to the old ways, damage is smaller and blocks absorb damage. No "big bang" weapons and things will get better.

  9. #19
    I'll save it in the Google Drive
    for future comparisons.

  10. #20
    Build disparities are to be expected. It is in part a building game after all and not all builds are created equal. Where Robocraft currently goes wrong is that it courts inconsistencies that shift the balance of power towards a disparity-based-meta.

    T5 weapons as we know them are a prime example of the kinds of parts that contribute to such a disparity-fueled meta.

    However we are moving further and further away from discussing Robocraft as it could be.