I might be doing some work on the Pauline pace program in the coming months, so I'm creating this thread for people to talk things such as features that should be added to it, bugs and issues with the existing version, or other suggestions for improvement.
In this poll you can select which features you would be most interested in seeing. A more detailed explanation of the features are below. Note that the options marked "probably feasible" and "maybe feasible" are not guaranteed to work out. You can select 5 options (I would have allowed more, but this poll works a little differently than I thought it would and I don't think I can change it anymore). Note that all that matters is the relative difference between votes that each gets, so checking all of them (if it were allowed) would be equivalent to checking none of them. I don't guarantee that I will work on whatever gets the most votes, I'm basically just using this poll to get an idea of where the most interest lies. Feel free to suggestion other options not on the poll in this thread.
There are a few things I plan on working on no matter what, and will put as higher priority than any of the features in the poll, and so they are not included in the poll:
- I will add a mode in which you can manually enter scores as you complete levels. This will allow arcade players to use Pauline. It will likely involve just having to enter 4 digits representing your score after every screen.
- I understand that Pauline still doesn't work properly for some people. I want it to work for everyone so I plan improving the robustness of the OCR by training the OCR engine to recognize specifically the numbers in DK.
Here is a more detailed description of each option in the list.
Voice RecognitionThis was suggested by some people as an improved method of score input than manually typing the scores. This will likely involve saying some command followed by saying your score after each screen, and also after deaths. I think current voice recognition is robust enough for this to work out, but there is still some risk. Note that I will definitely support manual keyboard score entry so you should select this option if you think voice recognition is a worthwhile improvement over entering 4 digits after every screen.
Automation for ArcadeI've had some ideas on how to get pace tracking working automatically for arcade just like it does on mame. One example would be having the user manually set a region where the score is located along with maybe another small region for recognizing which board is being played, and then see if it can read the score and recognize the board. Probably the main challenge would be reading the score since the numbers might not be totally clear like they are in mame. Maybe with image pre-processing and/or training the OCR engine I can get it to consistently read the score correctly, but maybe not.
Dumping StatsThis would be the capability of dumping a stats file after a game containing information like the date and time of the game, final score, the score on every board, averages, paces, etc. The information would be very similar to that in the DK Data Library of Memorable Games thread (it would actually greatly speed up the process of collecting those stats for mame games by simply running Pauline while an inp plays in fast-forward). In the future I could even add stuff like an ability to query archived stats files for aggregate data over long periods of time, such as querying for a rivet average over all games in the past month.
Fullscreen ModeSome people really don't like playing in windowed mode, so I could support running Pauline with a game in fullscreen mode. Running this way would make Pauline no longer visible, but I assume you would still be able to stream Pauline's window. If I was to do this I would probably just add support to track games in arbitrary screen regions rather than just the current window that is in focus.
Improved Pace AlgorithmThe current pace algorithm uses essentially the equation pace = start_score + level_average*17 (although it's a little more complex than that). One problem with this is that you can't get a pace until you reach level 6, and pace at that point could be extremely inaccurate if the level 5 score wasn't reflective of what you normally score. Another problem is that if in game A a player is on the same level as in game B and has the same number of spare men but has a higher score in game A, then the pace in game A should be higher at that point in time than in game B since the player in game A is clearly ahead, but the naive pace equation doesn't guarantee this (i.e., 130k start + 58k level 5 will result in a significantly lower pace than 120k start + 60k level 5, even though in the first game the player is 8k ahead). I have an algorithm in mind that fixes this and also allows for a pace to be shown before level 6.
Graphical User InterfaceThis is pretty self-explanatory, instead of the interface being just a resized terminal window I could make an actual GUI with menus and such.