So last night I did a trial run with family in another state.
The networking is not ready.
– Time clocks on the computers were out of sync, I was kinda reliant on that.
– The minimum time to have a packet acknowledgement before resending it was 300ms, the ping was often 500ms or more.
– Sometimes the ping was bad because the game was working too hard on poly trails.
– The game would randomly not clean out models, which would become junk in the game.
And probably other stuff that I couldn’t catch!
All these problems make me think I need to be serious about testing in games. At work code testing is vital, but at home it can still be a time saver.
Yesterday I hit a brick wall.
I was supposed to write the game logic, but I quickly realized that I had bits of game logic strewn across the entire game infrastructure. For instance the networking module was handling state management. Well, I guess it can do that, but what if the state is different? Like async gameplay or what if i just want to sync it differently? Write a new networking engine?
Then I reasoned that single player and multiplayer really should just be scripted modules that control what happens for that type of game.
So I added a plugin for the game that would manage the game state, and with that, would provide a controller architecture. The controller would be responsible for telling the game what to do.
So now all that code that was in the networking module I have moved to the multiplayer game controller. There is a controller for the title, menu and single player game too, but the multiplayer one is by far the most complicated.
I think this separation really works better, now it doesn’t seem so daunting to add a different game play style (so I can experiment) and the networking module does what it is supposed to do and no more.
I’ve just finished making an Acknowledgement system for the game networking. Why bother doing ack’s when I’m using UDP?
There are some critical parts of the game that absolutely need to be communicated clearly or the whole thing will erupt in chaos:
- Hellos to the server when getting things set up
- Map and dynamic level data (objects created beyond what the map contains)
And I’ll probably need more when this project is more mature. EVEN MORE REASONS!
So now I’ve got a nifty function that will return a promise. The promise gets resolved as soon as it gets acknowledgement from the network.
Of course most of the update packets are going to use plain old UDP without extra acks. They will be sent so often that it won’t matter.
Lots more to do. Still hoping to get the 0.0.2 release done this Saturday.
Really hating on windows right now. My windows seven install suddenly started giving me the blue screen of death. I couldn’t repair it 😦
As luck would have it, I did have a windows 10 install on the machine too, but I’ve been reluctant to use it because it is not a solid state. So far it really hasn’t been that bad, but maybe i’ll switch back to Linux for a while. (Blender just seems to work better in windows.)
So work on salsa-sandbox has been pretty much halted. Today i got a build up on the server that repaired lingering issues. This is going to pretty much be how the game is on the 0.0.2 release date (this Saturday). I’m going to sprint to get it done, but prospects aren’t looking good right now.
Implemented Camera shaking. It seems simple, but I think it adds a little drama to the experience.
Also, added a health gauge and tested with some collision damage.
Have a lot of ideas and plans for coding this weekend.
I’d really like to get into some graphical effects that will make salsa sandbox more appealing, but I do have some networking bugs to take care of.
Also need to get a real name for the game…