Your game needs you to Economise with Data
Author: | ChrisB
|
Submitted: | 1st January, 2003
|
Views: | 6276
| Rated: |
|
|
But this isn't Uncle Sam telling you. This is your hard drive; your dial-up connection. They go for latency, not bandwidth. An empty byte is a wasted byte. What could I possibly mean?
Online Transfer - Blast to the past?
It may speed up things, but non-guaranteed sending is not the way to cure lag in your multiplayer game. You aren't just sending the text you specify in the event editor - MOO and DirectPlay add some other stuff to make sure your data goes to the right place. And this other stuff is going to cause problems and slow down your game. Consider narrowband users: not everything can go at once! Not even DSL will cope with Always>Send Player's X position.
So what's the answer? String Parser 2 of course. With its handy Tokenising feature you can send & receive multiple bits of data quickly and easily. A very basic 'dead reckoning' example's output would look like this:
167,300,16,50
A comma delimited list of various values. From left: X position, Y position, Direction, Speed. This is a lot quicker than sending each value individually on separate subchannels, and has the added benefit of updating ALL of the player's various properties at once.
To decipher this, you'd have to do the following with String Parser:
1) Add the delimiter "," at the start of the frame
2) When you receive the message, set the Parser's string to the message.
3) The message will be parsed, and you can retrieve each value using the Get Element expression. (This is a string, so remember to convert it to a value if necessary.)
Also, it's not a good idea to constantly send data. Only send it when it's required - such as when the player changes direction or speed, or shoots a bullet (necessary to get the correct position!).
So that's that done. What next?
Did you know about INI's 64kb limit? Well, you do now.
Ahh... so many examples that save data with INI. So many fools! Tying together data will save those all-important bytes wasted by otherwise saving as different items. Many level editors or action-replay examples are made the wrong way - make sure you get it right!
So, what else can there possibly be?
The Binary object, of course.
If you have datafiles, it's a good idea to use the Binary object to compress them (if you have many) when they're not in use, and decompress when the game requires it. My forthcoming level editor compresses most data as maps can contain many tiles - and many levels can take up quite a lot of space.
So remember this, when you make your games. Every little helps!
|
|
ChrisBCrazy?
Registered 16/08/2002
Points 5457
|