| Main > Main Forum |
| HI-SCORE: worldwide sharing & public competitions (easy way) |
| << < (12/22) > >> |
| torino:
--- Quote from: cotmm68030 on June 09, 2011, 11:01:22 pm ---Mame only writes the .hi on exit. 9:00 user a starts a game and loads game.hi with a top score of 100. 9:01 user b starts a game and loads game.hi with a top score of 100. 9:10 user a scores 500 and exits the game, writing a new game.hi 9:15 user b's mame is unaware of the new game.hi and scores 300. 9:16 user b also scores 400 and exits. Mame Overwrites game.hi with the table containing user b's two scores 9:20 user c starts a game and never sees user a's score. --- End quote --- That's actually true, I was wrong, I am sorry, and thank you. It seems I didn't properly test it the fist time around when it appeared MAME is already merging files at the right time, but it actually never loads the file again before writing a score, it reads only once at the start, or restart, and it writes only once when the game exits, as you said. So, unfortunately, this is kind of problem that requires MAME patching, or alternatively some external solution via front-end. I would solve this problem by making special MAME build, which would later become necessary anyway. GAME STARTS: read .hi file after which MAME keeps it in memory as usual, until... GAME ENDS: just before it's time to enter initials MAME reads .hi file again, which is the most recent update at this time and the file now gets locked for others, then MAME replaces scores in game memory and when you enter initials the game itself could merge your new score, as it normally does, but this time with the most recent ones, and finally then our MAME build should save to web-folder and unlock the file before continuing with emulation. The solution is simply to always READ just before WRITE and have the file unavailable for others in the mean time. That's how we could "sync" without proper server, and this way score "merging" could hopefully stay a part of the game itself. Though if we want to expand those built-in game scoreboards we would end up using external parsing and merging anyway, and this means the final system would need HiToText employed either on client or server side. That's quite a bit to think about. Thanks again. |
| newmanfamilyvlogs:
--- Quote from: torino on June 10, 2011, 01:54:51 am ---GAME ENDS: just before it's time to enter initials MAME reads .hi file again, which is the most recent update at this time and the file now gets locked for others, then MAME replaces scores in game memory and when you enter initials the game itself could merge your new score, as it normally does, but this time with the most recent ones, and finally then our MAME build should save to web-folder and unlock the file before continuing with emulation. The solution is simply to always READ just before WRITE and have the file unavailable for others in the mean time. That's how we could "sync" without proper server, and this way score "merging" could hopefully stay a part of the game itself. Though if we want to expand those built-in game scoreboards we would end up using external parsing and merging anyway, and this means the final system would need HiToText employed either on client or server side. That's quite a bit to think about. Thanks again. --- End quote --- MAME has no concept of when it's time to enter initials. What you're proposing is going to be a build of mame with a watchdog function monitoring the location in the emulated games ram where the the .hi is copied from and constantly checking that versus some external server for merger/updates. Any update to that ram that happens outside of the normal time it's updated (during the end-game sequence of whatever your emulated games is) will have to happen BEFORE the player would be entering initials, otherwise the emulated game would not be able to rank the new score correctly (or reject it as a low score). Then the question becomes does the emulated game draw it's 'top score' constantly referencing the same location in ram as where the .hi is copied from? From a fixed system with low ram, this would seem to be the more frugal way to do it, but if it doesn't you can't do anything about it without altering the ROM on a per-game basis. No one wants to play a system where the "High Score" you're trying to beat occasionally ends up to no longer be the high score by the time you beat it. The fact that you missed such a simple file writing scheduling conflict doesn't speak well to your ability to actually make this work. This is not some new glorious concept, it's been possible for this to work in a controlled environment (where you manage the file writing issue with people rather than hardware) ever since .hi files were introduced. I though about the logistics of doing this on a home private network where multiple MAME machines existed several years ago. But, as many people have pointed out, no one seems to care about this working on as large a scale as this forum, much less the entire internet. |
| leapinlew:
--- Quote from: cotmm68030 on June 10, 2011, 05:42:14 am ---The fact that you missed such a simple file writing scheduling conflict doesn't speak well to your ability to actually make this work. This is not some new glorious concept, it's been possible for this to work in a controlled environment (where you manage the file writing issue with people rather than hardware) ever since .hi files were introduced. I though about the logistics of doing this on a home private network where multiple MAME machines existed several years ago. But, as many people have pointed out, no one seems to care about this working on as large a scale as this forum, much less the entire internet. --- End quote --- I couldn't agree more. Whats further frustrating is his inability to see other obvious roadblocks. Now he's suggesting a custom compiled version of Mame which I pointed out as a solution 5 days ago. :lol I guess there is a small interest to see if this works, as it seems to crop up from time to time, but the effort to pull this off isn't worth the reward. A ton of coding and engineering just so you can have a larger pool of peoples initials. |
| newmanfamilyvlogs:
Like I said, if you REALLY want to do this, the ideal solution is to not modify MAME. Most ideally it should be rather transparent to users like the proposed shared drive via WebDAV.. But for the back-end.... You could probably manage to use something similar to an SVN system to collect .hi files. Your shared .hi file is not the only singular file; it's presented on a per-client basis. When the back-end detects a write to the WebDAV share, use the .hi parsing engine from projects like HitoText to parse the scores into a database and then dynamically re-build the .hi with the current hi-scores, and write that back to the WebDAV. Doing it this way would allow you to 'bracket' the scores on a per-user basis so that high scores are more meaningful to the individual players.... I suck at Donkey Kong. It took me three weeks of trying every morning to get past the first damn level. I was thrilled to get a score higher than the default high score. I think it's wonderful that players can get such high scores in the game but honestly I don't care. What I MIGHT care about is comparing my hi-score to everyone with a score that's less than 2X my accounts current best (Or some other multiplier based as a function of the total number of high scores available on a particular game). Since we're writing parsed scores to a database on the back end, then I can compare scores being generated by my user account to others and have a custom .hi generated for me with scores of other individuals of a similar playing (and thus scoring) ability. What this system does NOT provide is the ability for scores to be dynamically updated IN-GAME. You have to modify mame to do that.. but again if we're generating scores dynamically to begin with then you could make it optional on your user account to have the file updated every n-intervals and have a modified mame build that re-reads and re-patches ram at that given interval. I don't think most people care, but maybe some do. Either way with a properly designed back end it should accommodate both methods of updating. I'm sure there are flaws in this system, and scenarios I've not though about. I think it's an interesting technical proposal but I don't have terribly much interest in doing it myself, nor would I be interested in participating. Either way I don't believe you can run such a system reliably on freely available services, thus being able to pay to provide the service becomes an issue, and as small as the community is, and even smaller those interested in a such a system, I just don't see it happening. |
| leapinlew:
--- Quote from: torino on June 10, 2011, 01:54:51 am ---I would solve this problem by making special MAME build --- End quote --- Do it already... |
| Navigation |
| Message Index |
| Next page |
| Previous page |