Pox Statistics

Discussion in 'General Discussion' started by Imba, Mar 10, 2014.

  1. Imba

    Imba The King of Potatoes

    Okay, so an idea I've been toying with for some time is a deep statistical analysis program for Pox Nora. I've already been able to implement certain features of this program on my own system, while others continue to elude me just because of the technical sophistication of the game, having no interface in which to build this program and having to find a way to communicate with the client from scratch. Details below.

    Pox Statistics

    One of the key aspects of becoming better at Pox Nora is knowing why you lost a game. I think that an automatic in-game analysis would be beneficial in this regard. Ideally, the program would run alongside the main client and collect it's information with virtually no input from the user, so that you can focus on playing.

    This post will be compiled into three parts:

    0) Real-Time Statistics
    1) Visual Data
    2) Automatic Calculations

    This is a list of statistics I think would be useful, and is by no means a comprehensive list of everything I plan to include. One of the reasons for this post, besides feedback, is to get input from you guys as to what you'd like to see.



    Real-Time Statistics

    PLAYER/MATCH Statistics
    The program should provide w/l ratios against a specific player, a comparison of two individual players' respective w/l ratios for each

    faction, and w/l ratios for individual maps. In addition, the program should record useful peripheral information in the form of the following

    key items:

    1) Separate w/l statistics for EACH faction.
    2) Average game length by faction and map.

    GAME-DEPENDENT Statistics
    Game-Dependent Statistics is my term for all statistics that do not fall within "meta-statistics" such as w/l ratios and faction records. This
    is the heart of the program. Since this category is potentially so large and encompasses so much material, I've decided to break up the specification
    into lists.

    Universal GDS
    -Total nora in play // This is also the basis of Nora in play per turn
    -Total nora lost // This is also the basis of Nora lost per turn

    -Total champs played // This is also the basis of avg Champs in play per turn, and substraction finds relics & spells

    -Total champs lost // This is also the basis of avg Champs killed per turn

    -Total champs killed // This is also the basis of avg Champs killed per turn

    Champ GDS

    // It has been decided not to include statistics that can be easily found through other sources, such as avg nora cost, as most players are aware of this data when building battlegroups

    -Average adjusted champ cost // Program should weigh each champ against the amount of nora it forces the other player to lose (such as through kills, contests, etc.) to calculate an adjusted nora cost, and is a measure of how well a player uses his resources
    -Average counter efficiency // Program should compare opponents' deploys to determine how well each counters the other. Algorithm to be determined later.
    -Basic and Advanced Abilities // Program should record each champ's basic stats (such as hp/def/dmg) as well as upgrades, to be used for two purposes. These purposes include: Calculations (see section 2), and Area of Influence - Area of Influence is a concept I've been toying around with and deserves its own post, may or may not include


    Spell GDS
    -Average Hit (AOE) // If a spell involves an Area of Effect component, the program should record how many champs are affected as a byproduct of the spell.
    -Average adjusted cost // Same as for champs. I can see this statistic being less meaningful for decks that are reliant on passive spells. Discretion on the part of the user is encouraged in this case




    I suspect users will be more impressed by the program's ability to provide a visual component to the statistics they will find in record.
    The program should break this up into two tasks, In-App Visual Data and On-Web Visual Data. This section will begin with the discussion
    of those two concepts and end with an exact specification of what visual data is needed.


    IN-APP VISUAL DATA
    Program should provide a secondary form in which the data compiled from previous games can be seen on-screen in the app. Preferentially this secondary
    function will be chosen at start-up so that we can break up the task of the program (either record a match or view a previous one). This will help to
    maximize screen real-estate.

    ON-WEB VISUAL DATA
    If the user so desires, he should also be allowed to submit these .txt files to an online application that will undoubtedly be able to provide a much
    nicer, more uniform UI. The difference is purely aesthetic.


    VISUAL DATA SPECIFICATIONS


    The program should generate graphs instead of flat text whenever possible. This is to facilitate quick analysis. I would prefer to use an existing
    library to accomplish this feat, and am hesitant to use the Swing API as it is Java dependent and wouldn't work well with the web-app. The user should
    have his choice of which type of graph to view each statistic in. The graphs themselves can be static after generation, with the option to add more dynamice
    elements later.


    A good example of what I'm going for here is www.ggtracker.com, a nearly 100% replica
    of what I want to do on the visual end.


    Automatic Calculations

    ~I'm not sure if this part of the program will be tolerated or not, but I'd like to see
    something like what I have listed below implemented. In my own tests I was able to get most of the information from memory neccessary for this stuff.

    ATK CALCULATIONS
    When prompted, the program should calculate the damage output of one champion on another, taking into account all spells and abilities currently in effect, and
    informing the user when an ability/spell that would positively or negatively impact the outcome of an ATK is present.

    For instance, the user would be presented with a list of champs currently deployed. From that list, he choses his attacking. Another list is automatically populated showing potential targets. When the user preses 'Go', the program will run an internal simulation of the attack, printing results along with relevant factors.

     
    Kampel likes this.
  2. Imba

    Imba The King of Potatoes

    Bumping this for those who did not get a chance to see.
     
  3. KTCAOP

    KTCAOP I need me some PIE!

    A lot of text that sounds somewhat interesting. If you get something with a screenshot so we could visually see what you are trying to add, I think it would be an interesting add-on.
     
  4. BurnPyro

    BurnPyro Forum Royalty

    RIP Skill
     

Share This Page