This topic contains 4 replies, has 0 voices, and was last updated by  Willis 12 years, 11 months ago.

  • Author
    Posts
  • #2900

    Willis
    Participant

    Gavin I have been playing with some ideas in the back of my head and lets just say they origionated from the idea of a game recording /replay/ system. In the essence that a player can watch and relive a game play-by-play.

    But I was just curious, how much of scorched is based on random probability? Let me run down a senerio: Say you have two games running side by side – each game perfectly identical to the one next to it, same terrain, same location, same winds (direction + force), etc.. if on one game you attempted a shot, and then an hour later attempted the same identical shot on the second game… would those shots actually play out identiclly?

    What about in that senerio if the weapon in question was massive – say a DH. Or what if was underground – say a Digger. Or how about rollers? At what point would scorched not be capable of repeating itself (least be predictable)?

    #13574

    imported_gcamp
    Participant

    Gavin I have been playing with some ideas in the back of my head and lets just say they origionated from the idea of a game recording /replay/ system. In the essence that a player can watch and relive a game play-by-play.

    Sounds nice, kind of like a recording demo feature.

    But I was just curious, how much of scorched is based on random probability? Let me run down a senerio: Say you have two games running side by side – each game perfectly identical to the one next to it, same terrain, same location, same winds (direction + force), etc.. if on one game you attempted a shot, and then an hour later attempted the same identical shot on the second game… would those shots actually play out identiclly?

    Some of the things would be identical, others not. Things like funky bomb direction, lightning shape, etc would be different.

    What about in that senerio if the weapon in question was massive – say a DH. Or what if was underground – say a Digger. Or how about rollers? At what point would scorched not be capable of repeating itself (least be predictable)?

    From one run to the next the outcome would be different.

    ….However….

    Scorched 3d must be repeatable in some way as the same outcome is played out on multiple clients connected to the same server. In this situation the server keeps them all the same, giving them the required information need to make the same shots (the random seeds used etc).

    So to record a game it should be possible to record all the traffic sent from the server and replay that to the client. I think if that was done, then the client would think it was connected to the server and perform exactly the same way.

    #13575

    hobbesme
    Participant

    @gcamp wrote:

    @willis wrote:

    Gavin I have been playing with some ideas in the back of my head and lets just say they origionated from the idea of a game recording /replay/ system. In the essence that a player can watch and relive a game play-by-play.

    Sounds nice, kind of like a recording demo feature.

    HEEELLLOOOO?!?!?!?

    You make it sound as if this is the first time you’ve read ANYTHING about a record/save game feature request!?!?!

    In fact, I’ve been asking for it for so long :

    … that I think the methods should be named after me :

    • S3D_Turn.ObnoxiousHobbesmesReallyCoolButIgnoredSaveTurn()
    • S3D_Turn.ObnoxiousHobbesmesReallyCoolButIgnoredSaveGame()

      😉

    @gcamp wrote:

    Scorched 3d must be repeatable in some way as the same outcome is played out on multiple clients connected to the same server. In this situation the server keeps them all the same, giving them the required information need to make the same shots (the random seeds used etc).

    So to record a game it should be possible to record all the traffic sent from the server and replay that to the client. I think if that was done, then the client would think it was connected to the server and perform exactly the same way.

    This is EXACTLY why I figured this feature wouldn’t be too impossible to implement. Just need method(s) to save the calculated simulation input seeds for later replay on the client.

    #13576

    imported_gcamp
    Participant

    HEEELLLOOOO?!?!?!?

    You make it sound as if this is the first time you’ve read ANYTHING about a record/save game feature request!?!?!

    Fair enough, you can get the credit if you want 😛

    This is EXACTLY why I figured this feature wouldn’t be too impossible to implement. Just need method(s) to save the calculated simulation input seeds for later replay on the client.

    I don’t even think it would be that hard, just recording the coms messages sent from the server to the client. But it would be more difficult to do an in game action replay type idea.

    #13577

    poolee
    Participant


    What if the client just kept the last say 120 seconds of action in a rolling recording file?

    The when the client wants to keep a piece of action for posterity, the press F12, for instance, and a file is recorded in a predefined folder with the current date/time stamp (??).

    Some sort of replay control panel will be required (a separate proggie?)

    Just some random thoughts…

    Poolee

    #13578

    Willis
    Participant

    Well what I was thinking in the long run — to be blunt I was taking a crack at creating a template for the saving. — well if we had a scorched feature, or an additional program to run the saved file. **WARNING ALL FUTURE CONTENT IS MERELY ME BRAINSTORMING SO TAKE CARE TO HURT MY FEELINGS 😆 **

    But the file would be generated as games progressed. Each game would have its unique identity. There would be in the scorched3D directory there would be a /recordings/ directory, and with each game have a directory called for example: /0003134/ Which is a unique ID of the game (keep reading). Inside the directory is in the following mannor:

    various XML files such as:

    server.xml
    landscapes.xml
    accessories.xml

    And any other file that would be used via the server to define the game.
    These files are small in size so trasnfer should be of little concern. Maybe formulate a layout to eliminate redundent saving of files.

    After that a game save file (I’ve been developing my template/example in XML) which stores all aspecs of the game,rounds,moves. Each game is assigned a unique ID (remember the directory name?) via the server. What this really helps on is when the user departs from the game and returns later in the same game. (say leave at round 3 returns for round 8). So saving can pick up where left off.

    Then saving occures in whatever mannor. After the game and saving is complete.. the user and send this file into the program (be it scorched or whatever) which can be jumped from point to point (replay the same move over and over) or left to default to play it from beginning to end.

    Thats my thoughts on how things could be, what I was curious is, would people prefer to see things play in the same length of time as it was in real life (say someone waited to the last second to make a move) or would you like everything to be activated right away and keep playing without delay of time?

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.