Also, how it works?
the play of the game system works by recording positions, velocities, direction, items, animation, damage received, and death every 30 milliseconds. its optimized so it only records position, velocity, and direction every 30 milliseconds and stores special data when players take out items, animate, receive damage, or die. the play of the game right now is 15 seconds long and the way my system stores data means i will only have to save around 500 - 700 variables to file when someone gets a play of the game. this can be done quick enough that saving 30 players worth of data won't hang the server up for more than 20-30 miliseconds (this can be improved though so it doesn't hang the server up at all). a save file is also created when the potg is made so that an accurate map will be loaded for the potg replay so the replay won't look glitchy due to added/removed bricks after the potg was made. detecting if someone gets the potg is simple i only check to see if someone gets more kills in 15 seconds compared to the previously awarded potg kill count (note: i want assists to factor into calculating who got potg too which will be done soon). when there is no potg, you have to get above or equal to 2 kills in 15 seconds in order to win potg. this guarantees there'll be a play of the game because pulling off 2 kills in 15 seconds is quite easy.
in order to play the potg back, the save file is loaded up to a different trench 'arena' so i don't have to delete bricks in the other one. bots are then created to represent players and using schedules play back the data stored in their respective recordings with their positions offset so they are placed in the replay arena. avatar data is also saved when the potg is made so even if someone disconnects there'll still be a bot for them in the replay. my friend charles made a cool little build to show who got potg and during the time the other players in the server are watching that title build thing the map is being loaded up at a fast pace. the script i made for loading it is able to load up 9k bricks in under 5 seconds thanks to the simplicity of a customized save file.
Can you tell us the problems you have run into while making play of the game and your solutions?
this is the actual interesting part of this post because you might actually learn a thing or two from it. one of the more important issues i faced was figuring out an efficient method for creating/storing the data. before i seeked help from zeblote i only knew of three ways to record the data: increase a number for a global variable and store data that way which means a /massive/ amount of memory would be used up because i was creating new variables without deleting the old ones every 30 milliseconds (i calculated that it would use up 21 mb per minute for 16 players, in an hour it would use up 1.2 gigs of ram which is just unacceptable). the second way was to completely delete variables (via DeleteVariables() ) after i didn't need them but that proved to be slow and significantly affected the ping even though i was only deleting a few variables at a time. this method seemed to be the best memory wise because it didn't waste any memory at all but having a bad ping in a tdm game is unacceptable. the third way was to simply clear the variables after using them. this is different from completely deleting them; it just assigns an empty string to the variable but the variable pointer is still stored in who knows where in the memory. this was better on memory as it only used up 4.2 mb per minute for 16 players but in my eyes any memory (or ping) increase was unacceptable and wouldn't work. i was stumped so i asked the god of blockland modding zeblote for help and he told me to use a circular buffer system. this means instead of creating new variables whenever i need to store new data i just reuse old ones. here's the wikipedia article:
https://en.wikipedia.org/wiki/Circular_buffer . i swear whoever created this looked into the future and saw my potg struggle and made this just for potg because this method of storing data is perfect for potg data.
playing back potg data also proved to be a struggle because sometimes the recordings would be out of sync for recently connected players. this would mean that the new players' recordings would be out of sync and would make everything look forgeted up. this was an easy fix however i just stored the time the recording started for each player and if there was a difference compared to the mode of starting times the different players' recording would be offset further in time.
any other issue compared to these two are minuscule. i encountered various issues concerning recording and playback but they were fixed with only a few lines of code. this is a testament to how easy it is to make good things for blockland though. i started making the potg on monday this week and it was ready for use on wednesday. i worked hard on it for like a total of 10 hours. its only 1000 lines of code long and can probably be cut down to 700/800 because i left a lot of the old code commented in case stuff went wrong. this is a testament to making cool things in blockland. if you have a cool idea, no matter how complex, if you work hard on it you'll finish it quickly and without huge issues (the data storing issue i just described was an easy fix once i asked for help (also ask for help if you're forgeted people will answer because people in the modding community are good people)). you'll also learn things too like how i learned about circular buffers in my potg creation adventure
i hope i answered your questions well. if i didn't post some more and i'll answer those too
