Jump to content
IGNORED

High Score idea


Thomas Jentzsch

Recommended Posts

Some games track the current high score of a session. That way you only have to write it down once per session. 

 

So I wonder how complicated would it be to load the current high score of a game and variation from the HSC? Either for the player or overall.

Link to comment
Share on other sites

1 hour ago, Thomas Jentzsch said:

Some games track the current high score of a session. That way you only have to write it down once per session. 

I have discussed this with @Dionoid last year for Amoeba Jump which is sending a lot of scores.

But I think it is the best approach to send every score, this way you can have more than 1 top submission in a session. It would be very frustrating for a user if his attempt would be high enough for the second place in the high score board, but it is not send, because he had done the first place in his previous run.

 

0879616914b050444dd9ad8f49127324ce467bfb

 

 

1 hour ago, Thomas Jentzsch said:

So I wonder how complicated would it be to load the current high score of a game and variation from the HSC? Either for the player or overall.

this is possible.

 

The HSC backend is prepared for sending the top 9 and the placement of your current submission in the response. Currently this is not used and tested, because it would need (much) more work and modifications to the ROMs to display this high score table response.

 

If you want to try it I would be very happy to help you.

 

 

 

  • Like 1
Link to comment
Share on other sites

45 minutes ago, Al_Nafuur said:

I have discussed this with @Dionoid last year for Amoeba Jump which is sending a lot of scores.

But I think it is the best approach to send every score, this way you can have more than 1 top submission in a session. It would be very frustrating for a user if his attempt would be high enough for the second place in the high score board, but it is not send, because he had done the first place in his previous run.

Understood.

45 minutes ago, Al_Nafuur said:

The HSC backend is prepared for sending the top 9 and the placement of your current submission in the response. Currently this is not used and tested, because it would need (much) more work and modifications to the ROMs to display this high score table response.

If the game already tracks the high score, processing the top score would be easy. I doubt there is much need for 9 scores though. But player's own high score score would be interesting too.

 

I already contacted you via PM.

Edited by Thomas Jentzsch
Link to comment
Share on other sites

14 hours ago, Al_Nafuur said:

I have discussed this with @Dionoid last year for Amoeba Jump which is sending a lot of scores.

But I think it is the best approach to send every score, this way you can have more than 1 top submission in a session. It would be very frustrating for a user if his attempt would be high enough for the second place in the high score board, but it is not send, because he had done the first place in his previous run.

Another question which results from this: How do I transfer scores in multi player games? I suppose I cannot transfer two or more scores rapidly by simply repeating the transfer loop, right? Is the protocol prepared for this case, e.g. by transferring a special continue value instead of the game ID?

Edited by Thomas Jentzsch
Link to comment
Share on other sites

17 hours ago, Thomas Jentzsch said:

If the game already tracks the high score, processing the top score would be easy. I doubt there is much need for 9 scores though. But player's own high score score would be interesting too.

I don't understand which scores you mean by "already tracks". Local scores from the ROM session or the scores in the online database?

 

17 hours ago, Thomas Jentzsch said:

I already contacted you via PM.

?

I didn't received a new PM from you.

 

2 hours ago, Thomas Jentzsch said:

Another question which results from this: How do I transfer scores in multi player games? I suppose I cannot transfer two or more scores rapidly by simply repeating the transfer loop, right?

right.

 

The PlusCart is silently ignoring a request while an other request is pending. You have to check the response buffer before sending a new request. In the case of the HSC ROMs, however, this is currently not possible, because the response from the backend does not contain a payload and the response buffer does not change. Also most all HSC PlusROMs currently don't read the response.

 

 

2 hours ago, Thomas Jentzsch said:

 Is the protocol prepared for this case, e.g. by transferring a special continue value instead of the game ID?

The PlusROM functions/protocol does not define a special order or meaning of the bytes sent by the request of the device/emulator or the response of the backend.

 

This is all defined by the developer of the PlusROM and backend.

 

I use in my PlusROMs mostly the last byte of the request as indicator which function or route the ROM wants to call at the backend. The bytes before (if any) are then the parameters for this call.

 

e.g. the 10 routes for the C.A.V.E Apocalypse PlusROM are:

$api_routes = [  // byte: Description
 "game_start",      // 0: Start a level.                        Payload: Game number and level number (BCD), 4 bytes.
 "level_done",      // 1: Level finished succesfully.           Payload: Score (BCD), 3 bytes.
 "game_over",       // 2: Level not finished succesfully.       Payload: Score (BCD), 3 bytes.
 "leave_room",      // 3: Player left room to the left.         Payload: State of the room left, 10 bytes
 "leave_room",      // 4: Player left room to the top.          Payload: State of the room left, 10 bytes
 "leave_room",      // 5: Player left room to the right.        Payload: State of the room left, 10 bytes
 "leave_room",      // 6: Player left room to the bottom.       Payload: State of the room left, 10 bytes
 "reset_level",     // 7: Player died reset to last save point. Payload: State of the room left, 10 bytes
 "set_save_point",  // 8: Fuel station in current room reached. Payload: empty
 "load_menu",       // 9: Load startmenu.                       Payload: empty
];

 

the HSC backend basically has only one route (sending scores for a game) and the last byte in the request is the game_id. The number of parameters before the last byte may differ between the games. How these bytes are transformed into a score and a game variation is up to a transformation defined for the game in the database. These transformations may also be able to transform the parameters into two scores depending on the amount of bytes sent. E.g 5 bytes is a one player session and 8 bytes is a two player session of the same game.

 

The HSC backend might be changed, so it can store more scores in the database, if a transformation returns a array of scores. However there is only one nickname in the PlusROM header (And of course we are not going to expand this here). If a developer wants to send multiple users-, or nicknames he has to do it in the PlusROM payload. And for this, he must provide a way to enter this data via the ROM. And of course, if we want to use this with the HSC backend we have to enhance the transformation to extract the usernames from the payload too.

 

 

 

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...