Kitoko
Member
I have taken a dabble at trying to create something unique, a client-side game inside the HUD hook known as Tetris. It wasn't fun (or easy) and involved hopping through hoops just to set it up, but here's my experience, and why I am upset at SRB2 for this.
Making the game itself was the easy part, despite Tetris being a full and complete game in its own. It took me a while because it is a game in itself, but writing the script for it was as native to me as bread and butter; A couple hours of writing and bug testing later, and it worked. This is definitely something I have to give credit to SRB2 for, as it'll let you do some truly unorthodox things and get away with it and trust your judgement.
Getting the game to run on its own without any help from the main game state was a little more difficult, because I had to make a token system to ensure one player isn't using another's board, using commands and states to help it link back to the actual game when the user finishes a round of Tetris. Making it send to a high-score board was just for fun.
As soon as I started testing this in netgames, this is where it all went downhill. Players could spectate others and completely break their own board or reset it and even play with other's playfields (though it was more like take their current state and use your pieces) so that made me tear my hair out for a little while, having to try and go out of my way to set up a "verification" method (that is still not perfect and breakable but works for the average citizen) to ensure that the local player was the local player, and that when they spectate another user, the game knows about it.
Then, came one of the greatest enemies of all, the lag. Oh man , the lag. I knew something was totally wrong with how HUD worked for me when I found my controls repeating over and over when the server encountered lag. This was thankfully easily solvable, but not without the side effect of dropping inputs which I was not very happy with and still am. The fact that the network game can actually have an backlash impact on the HUD was absolutely trivial, but oh yes it did.
Finally, to top it all off, after all the work and effort I put into this, I go to join a friend who was hosting this script, and found that despite all my efforts, control lag still had effect and man did this upset me. Apparently (to little surprise) the HUD hook requires an update to its state for some reason meaning that my controls were simply being piped in from the player object itself, meaning that my controls were not client-sided and never will be. I guess I shouldn't be too surprised since the warning shot was the lag impacting the controls itself, but eh.
At this point I've just given up. I can't get SRB2 to perform some sort of menu or HUD without waiting on the server. I don't know what to do now since I have a lot of ideas that revolve around being able to do something on the localized player state.
Making the game itself was the easy part, despite Tetris being a full and complete game in its own. It took me a while because it is a game in itself, but writing the script for it was as native to me as bread and butter; A couple hours of writing and bug testing later, and it worked. This is definitely something I have to give credit to SRB2 for, as it'll let you do some truly unorthodox things and get away with it and trust your judgement.
Getting the game to run on its own without any help from the main game state was a little more difficult, because I had to make a token system to ensure one player isn't using another's board, using commands and states to help it link back to the actual game when the user finishes a round of Tetris. Making it send to a high-score board was just for fun.
As soon as I started testing this in netgames, this is where it all went downhill. Players could spectate others and completely break their own board or reset it and even play with other's playfields (though it was more like take their current state and use your pieces) so that made me tear my hair out for a little while, having to try and go out of my way to set up a "verification" method (that is still not perfect and breakable but works for the average citizen) to ensure that the local player was the local player, and that when they spectate another user, the game knows about it.
Then, came one of the greatest enemies of all, the lag. Oh man , the lag. I knew something was totally wrong with how HUD worked for me when I found my controls repeating over and over when the server encountered lag. This was thankfully easily solvable, but not without the side effect of dropping inputs which I was not very happy with and still am. The fact that the network game can actually have an backlash impact on the HUD was absolutely trivial, but oh yes it did.
Finally, to top it all off, after all the work and effort I put into this, I go to join a friend who was hosting this script, and found that despite all my efforts, control lag still had effect and man did this upset me. Apparently (to little surprise) the HUD hook requires an update to its state for some reason meaning that my controls were simply being piped in from the player object itself, meaning that my controls were not client-sided and never will be. I guess I shouldn't be too surprised since the warning shot was the lag impacting the controls itself, but eh.
At this point I've just given up. I can't get SRB2 to perform some sort of menu or HUD without waiting on the server. I don't know what to do now since I have a lot of ideas that revolve around being able to do something on the localized player state.
