Author Topic: Normalized Feature Stats?  (Read 2768 times)

0 Members and 1 Guest are viewing this topic.

March 27, 2016, 03:01:38 AM
Read 2768 times

AlbinoStoic

  • *
  • Information
  • Member
  • Posts: 89
  • aka The AngryAlbino
    • View Profile
    • AngryAlbino's YouTube
Hello!

I couldn't really figure out the normalized Innovation, Stability and Usability.  Are they normalized per feature in that a feature can give "Stability" and "Innovation", or are they normalized across in that "all Stability / Stability of feature = ?"  It's kind of confusing based on the Wiki description and testing.

E.G: A feature described as the following doesn't do as expected (severely negative stability, lots of innovation, some negative usability) [ I had all other features set to '1/1/1' to test. ]

Code: [Select]
    <Feature Forced="FALSE" Vital="FALSE">
      <Name>Overclocking</Name>
      ...
      <Innovation>12</Innovation>
      <Usability>6</Usability>
      <Stability>0</Stability>
    </Feature>

How would I design the numbers where '6' was the median value (1/2 the scale?)  Or is that even how it works?
« Last Edit: March 27, 2016, 03:05:04 AM by AlbinoStoic »

March 27, 2016, 03:59:40 AM
Reply #1

jdphenix

  • *
  • Information
  • Member
  • Posts: 19
    • View Profile
From what I have seen, the normalized values are the result of something like:

total = Innovation + Usability + Stability
NormalizedInnovation = Innovation / total
NormalizedUsability = Usability / total
NormalizedStability = Stability / total

So in your case, Innovation would be 12 / 18 or 0.666666, Usability would be 6 / 18 or 0.333333, and Stability would be 0.0 for that one feature.

As far as figuring out how it exactly contributes to the whole software type - I'm not entirely sure.

March 27, 2016, 04:21:41 AM
Reply #2

AlbinoStoic

  • *
  • Information
  • Member
  • Posts: 89
  • aka The AngryAlbino
    • View Profile
    • AngryAlbino's YouTube
So in your case, Innovation would be 12 / 18 or 0.666666, Usability would be 6 / 18 or 0.333333, and Stability would be 0.0 for that one feature.

Interesting... so whatever numbers you use are relative.  If I base each feature out of "30" for example (10-10-10 being a "No Effect"); should that work as long as I'm consistent across all the possible features in the software type?

Testing with something like that in mind has seemed to get me a lot closer to what I want, but to get a drastic change to stability I need to do '10-10-5' for normal features; '20-10-0' for overclocking, etc.

Can't seem to make a "All features => "High"" for later game, can only max around Medium/Medium/High
« Last Edit: March 27, 2016, 04:27:53 AM by AlbinoStoic »

March 27, 2016, 04:46:52 AM
Reply #3

jdphenix

  • *
  • Information
  • Member
  • Posts: 19
    • View Profile
Sure, but there's other factors in it. DevTime for example affects the programmer/artist balance of a project, but I'm not sure exactly how this works for innovation, usability, and stability.

With the programmer/artist balance, and three features:


    <Feature>
      <Name>Art Feature</Name>
      <Description></Description>
      <DevTime>1</DevTime>
      <Innovation>1</Innovation>
      <Usability>1</Usability>
      <Stability>1</Stability>
      <CodeArt>0</CodeArt>
    </Feature>
    <Feature>
      <Name>Time Consuming Art Feature</Name>
      <Description></Description>
      <DevTime>3</DevTime>
      <Innovation>1</Innovation>
      <Usability>1</Usability>
      <Stability>1</Stability>
      <CodeArt>0</CodeArt>
    </Feature>
    <Feature Forced="true">
      <Name>Base Feature</Name>
      <Description></Description>
      <DevTime>1</DevTime>
      <Innovation>1</Innovation>
      <Usability>1</Usability>
      <Stability>1</Stability>
      <CodeArt>1</CodeArt>
    </Feature>

picking Art Feature causes artists required be 50%, picking Time Consuming Art Feature makes it 75%, and pick both makes it 80%. That implies that for the programmer/artist balance, the calculation sums the product of DevTime and CodeArt totals for each feature.


Feature                          CodeArt       DevTime
Base Feature                     1             1
Art Feature                      0             1
Time Consuming Art Feature       0             3


So picking all three gives 1 CodeArt / 5 DevTime = 0.2, or 20%. There are some inconsistencies that aren't explained by this, for example the balance gets off if the DevTime total for all the features picked is < 1, or if you toss in negative DevTime.

I have figured out that the features balance work similarly, with the same kind of uncertainly / odd behavior.

March 27, 2016, 05:40:20 AM
Reply #4

AlbinoStoic

  • *
  • Information
  • Member
  • Posts: 89
  • aka The AngryAlbino
    • View Profile
    • AngryAlbino's YouTube
Sure, but there's other factors in it. DevTime for example affects the programmer/artist balance of a project, but I'm not sure exactly how this works for innovation, usability, and stability.

...

I have figured out that the features balance work similarly, with the same kind of uncertainly / odd behavior.

Very very interesting.  So balance still needs a little bit of work to be complete (as is expected with Alpha of course); as it's not quite straight-forward yet.  It works great though so far using these guidelines, I'm able to figure some balance out of it that way.

Using bigger numbers when a product has more features seems to help make the changes more drastic.

March 27, 2016, 07:56:10 PM
Reply #5

jdphenix

  • *
  • Information
  • Member
  • Posts: 19
    • View Profile
Alright, I think I've got this about down.

Feature balance is definitely calculated by summing the product of each feature's DevTime and the feature's respective values. The game doesn't handle the following cases in an expected manner:

* DevTime < 0 for the entire product, I've ended up with Artists Required = 400% displayed in game for example.
* DevTime = 0 for the entire product, makes all the labels display Very Low.

For example, if I create a feature set that ends up with a normalized stability of -0.33, usability and innovation of 0.66, the game prints out descriptions "Very High", "Low", and "Low" respectively. I've yet to figure out how the values picked are displayed with negative DevTime or other weirdness. I would make sure that a feature set never could produce those

I calculated the values here: https://docs.google.com/spreadsheets/d/1bjqDvE-VuX1YqIMMBzFFai1M-8q5_4VV4pPYZfTSSsY/edit?usp=sharing
Note the labels for "Very Low", "Low", etc. don't exactly match up with what shows up in-game, but are close.

Neither of these cases show up with the base game because nothing subtracts from DevTime. (The time scale on software categories is almost assuredly a scalar, so this issue wouldn't ever come up with timescale unless timescale < 0). 

-------------

Aside:
One use case I thought of for reducing DevTime was a base feature like this:

    <Feature>
      <Name>Rush</Name>
      <Description>It compiles! SHIP IT!</Description>
      <DevTime>-4</DevTime>
      <Innovation>0</Innovation>
      <Usability>0</Usability>
      <Stability>2</Stability>
      <CodeArt>1</CodeArt>
    </Feature>

Note that the stability value is still positive, because if it was negative it would actually increase stability.
« Last Edit: March 27, 2016, 07:57:43 PM by jdphenix »

March 27, 2016, 10:40:50 PM
Reply #6

AlbinoStoic

  • *
  • Information
  • Member
  • Posts: 89
  • aka The AngryAlbino
    • View Profile
    • AngryAlbino's YouTube
Alright, I think I've got this about down.

...

I calculated the values here: https://docs.google.com/spreadsheets/d/1bjqDvE-VuX1YqIMMBzFFai1M-8q5_4VV4pPYZfTSSsY/edit?usp=sharing
Note the labels for "Very Low", "Low", etc. don't exactly match up with what shows up in-game, but are close.

...

Note that the stability value is still positive, because if it was negative it would actually increase stability.

Very very interesting.  I haven't been able to make features detract from overall stability as drastically as I'd wish to, unless I use unrealistically large numbers for some features (which has other side-effects, such as increasing the price of the product dramatically; without costing any more to license the product, which is a bit of a problem in my use case.)

I wanted Overclocking as a Motherboard feature to reduce the stability dramatically of the Computer it was built in to, and I could only do this by using numbers such as '100-10-0' for the stats of "Overclocking".  It needed to know that normalized, stability was extremely low.  Thus; including it brings your Motherboard from "Medium" stability down to "Very Low" without QA, or "Low" with QA.  Adding "Watercooling" or higher increases stability back to "Medium".  This took a lot more guess and check than I would have hoped for.

I want products (CPU, Motherboard, Graphics Card, etc.) to cost a lot of money to License, when you're selling a prefab "Computer".