Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

PCU values that may need reevaluation

Discussion in 'Suggestions and Feedback' started by Burstar, Jul 4, 2018.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. Burstar Apprentice Engineer

    Messages:
    461
    I personally like the PCU concept. I think it solves many problems in MP, but I have noticed though that some of the numbers don't line up with expectations.

    A Large Grid Conveyor Junction costs 20, whereas a junction with storage (Small Container) costs only 10.

    Cockpits and seats cost 15, while the remote control block 25.

    Antennas cost double that of beacons, but it feels like they do more than double the work.

    Small Grid Gatling Guns 80, Gatling Turrets 225 vs.
    Large Grid Rocket Launcher 825, Missile Turret 275
     
  2. Isaax Trainee Engineer

    Messages:
    11
    this is balancing, which i believe is the next big update to come after the MP one.

    I agree, the numbers do seem a little off
     
  3. Malware Master Engineer

    Messages:
    9,719
    It's quite logical that the remote control costs more than the cockpit and seats, as it has the autopilot feature.
    (seats are technically cockpits)
     
  4. Burstar Apprentice Engineer

    Messages:
    461
    Seats have player charging, and cargo, while cockpits also have conveyor connections to consider. RC's do not.
    (Seats are technically similar to cockpits, but different).
     
  5. Malware Master Engineer

    Messages:
    9,719
    @Burstar Hehe. No, I mean literally technically, as what they are in code.

    The control stations, cockpits and passenger seats are all just variants of Cockpit (the MyCockpit class). They don't have their own distinct code. The cryopod derives from this class to create MyCryoChamber to add on top of this code.

    All of these are MyShipController derivations. Remote control derives directly from that, and is technically not a cockpit but something different.

    Player charging isn't performance intensive at all. Conveyor connection is an issue yes, but not constantly. Not all cockpits have conveyor connections either. Active collision avoidance though? Obviously has an active hit.
     
  6. Burstar Apprentice Engineer

    Messages:
    461
    This is my point. Generalizations have clearly been made which do not make sense to players when they look at the particulars of a specific block. This is why they MAY need reevaluation.

    The player does not care that one block is the same class as another. They care that the passenger seat, which does much less than a fighter cockpit, costs the same. Things need to make sense to the user, especially in regards to rules and limitations. Something I think many coders forget because they are focused on their particular issues.

    While we're talking about PCU, there's something I'm wondering if it will help free up more for the user. The idea of upgrade modules. A refinery costs 4 less PCU than a fully upgraded refinery, which does MUCH more work. I feel like this could apply to other blocks that have a high cost. For example: Gyros. Instead of placing 10 at 50 a piece, one or two with equivalent upgrades to do the same work might cost 108 instead of 500.
     
    • Agree Agree x 1
    • Disagree Disagree x 1
  7. Malware Master Engineer

    Messages:
    9,719
    I don't disagree that there may be some reevaluations needed, I never said I did. I just stated that it made sense that the remote - which have a collision avoiding autopilot - is more expensive in PCU than the regular cockpits which do not. But the PCU is all about the code and what it does. It has nothing to do with what players "feel", or what "makes sense" to players, but the impact they actually have as measured. From what I've been told, they set up a bunch of blocks and measured their impact on the world, and decided upon a PCU value based on that. Now, since all cockpit variants share the same code, they will have the same impact - so they get the same value. If you think the values need to make sense to the user, you've not understood what they're for. They need to "make sense" to the computer they're running on, so to speak, not the users.

    I'd be all for more upgrade modules.
     
    • Like Like x 1
    • Agree Agree x 1
  8. Burstar Apprentice Engineer

    Messages:
    461
    Based on the numbers they've posted, there are either flaws in their testing procedure, or in the way the code is run in the first place. I agree that RC's having an autopilot does make their case distinct from the other cockpits, but if a passenger seat is as expensive as a fighter cockpit there is something wrong.

    Spoken like a coder. :p

    They need to make sense to both.
     
    • Disagree Disagree x 2
  9. Calaban Junior Engineer

    Messages:
    932
    I can see how a passenger seat=cockpit processing-wise... as it plants a space engineer to a grid, who can access the inventory and Kontrol panels, control turrets, even remote control the ship- or any other ship connected through antennas, plus gets to travel with on any jumps. while he may not have access to a toolbar like in a cockpit, he absolutely gets to use the remote controls' toolbars.

    So its much more than just sitting in a chair. Its all the interactions and "channels" associated with what we can do when in the chair- that makes it so "expensive" PCU wise.
     
    • Disagree Disagree x 1
  10. Malware Master Engineer

    Messages:
    9,719
    Oh, it's not perfect, that's for sure, but the difference between those two is just the model, same as with all the other variants. That's it. The rest is the same. It may look like the one is more complicated and expensive than the other, but... that's an illusion. they might not necessarily be.

    Yes. One that happens to be professionally trained in user experience as part of his day job. I do know a thing or two about both sides. If a piece of code takes time, it takes time. Doesn't matter whether a player thinks that "makes sense" or not. It will still affect performance the same way, and a PCU value is representing that: The actual performance impact of a block. Making sense or not, it's still slowing down the game all the same.

    They really don't. If a PCU value is artificially lowered to suit a player's expectation, they'll get a higher performance impact than they expect.

    This is simply about mathematical facts. This is the way it is. You may agree or disagree as much as you want, but that won't change the facts. Oh, I'm sure there will be adjustments, and yeah, I wouldn't be surprised if the seat value is decreased, but that all depends on the code behind it.
     
    • Agree Agree x 1
  11. Burstar Apprentice Engineer

    Messages:
    461
    It is a sad state in the world when mathematical facts don't make sense to people.

    This isn't about wild guessing about appearances. This is about being exactly the same except for one or two things not being done by one. This means one MUST BE less costly than the other. MUST BE. You do not get something for nothing. Ever.

    If they are identical in computational demand than it is a problem with their design. The coding is such that all the possible features of the class are being considered every time, all the time, regardless of which features a block actually uses. This is bad coding. At the very least, logic to stop processing of information that does not apply to the block should be in place. At best, they should not even be the same class.

    I'm not saying artificially lower costs. I'm saying it is evidence of a problem. Fix. It.
     
    • Disagree Disagree x 1
    • Funny Funny x 1
  12. Malware Master Engineer

    Messages:
    9,719
    Hehe. Ok, fine. I give up.
     
    • Late Late x 1
  13. sioxernic Senior Engineer

    Messages:
    2,535
    Yeah, there is coding in place to make sure they wont be using code it wont be using, but problem is, it might also not be a good idea to remove a large part of the code.

    Conveying is something that is possible on ALL functional block types as an example. This is something that makes like no sense to completely remove and create a different inheritable class and up the complexity of the code simply to save a slight bit of CPU. That is not evidence of a problem, it is simplification of code, and can be evidence of good coding as well.

    Coding a game is always a game between simplifying the code (You avoid a lot of bugs with simpler code), coding quickly and building the most efficient thing possible.

    If we went by "all games always have to take the best CPU wise route, all games would be written in Assembly, but I am quite sure I don't want to wait 25 years for an assembly built game.

    The only "modern" game I can think of that was built entirely in assembly is Rollercoaster Tycoon.
     
  14. Burstar Apprentice Engineer

    Messages:
    461
    Except in this discussion, saving CPU/PCU is the goal. CPU for overall user experience, PCU for overall user satisfaction.

    In the specific case of chair vs. cockpit saving 2 PCU by having 5 programmers faceroll keyboards for 4 years obviously is impractical. In the general case of overall design, having ALL functional blocks check conveyance just to make the coders life easier in the short term would be a poor decision.

    I think what we're looking at is chickens coming home to roost.
     
  15. sioxernic Senior Engineer

    Messages:
    2,535
    And/or keeping code simpler to avoid bugs. The thing is, the majority of functional blocks can have conveyors, which also means modders can add conveyors to the majority of blocks. I think the exception is the door? Which is annoying a modder I know.
     
Thread Status:
This last post in this thread was made more than 31 days old.