Why not just serialize the sprite objects (including "inputs")? Binary serialization is much more efficient than decimal serialization. That's what the save/load game function does. The sprites have all this info. Do your sprites not have HP/MP/SP on them? If not, serialize whatever structure it is that contains that info.
At the moment I'm just sending the properties that I need. By only sending the input state, it's only 0000000000.
If I'm sending all serializable data in SpriteBase, I'm sending more data than I need to.
Normally there's only two things I need to send:
Input Data (I'm going to look into Sprite.inputs)
I don't want to send anything BUT Sprite.inputs for each frame, I'm looking on MSDN about Serialization, is there a way for me to Serialize ONLY THAT field on SpriteBase? It seems that on MSDN to exempt fields from serialization, I have to use attributes set on my class. However, there's times I'm going to want to serialize certain fields and other times where I'm going to need to serialize other fields.
I'd love to send only a serialized version of the input data for SpriteBase, but I'm unsure if my method results in much less to send, or if serialization results in much less to send..
Here's another thing about serialization I'm wondering about..
I know serialized objects are stored as bytes, but is the output format bytes
or a byte array
? Lidgren can easily send byte arrays. But here's my other question-
Is this serialized data extremely large? Or reasonable to send to all clients every 10 seconds? If I'm sending all clients a serialized version of a SpriteBase object for positional updates, and there's about 4 objects on the map, would it be too much to handle?
X/Y/HP/SP/MP/ well, come to think of it- I'm going to need to send everything BUT the array that holds inventory data. So I'm going to be forced to serialize that..
So for positional updates I understand that I'll need to send serialized fields for SpriteBase, but for optimization's sake, will I need to serialize for input data
Ignore my silly question about the byte array format. I've solved half of it I guess. I can send the serialized byte array..http://www.digitalcoding.com/Code-Snippets/C-Sharp/C-Code-Snippet-Object-to-byte-array.html
but I'm unsure about how to load data from a file that stores the byte array back into the Map to tell it how many sprites are in the Map's SpriteCollection, and then load the sprites' individual parameters and "instances" for lack of a better term, back into SpriteCollection.
I'm going to have to look into LoadGame. If I have any more issues I'll try and post them hereEdit
Ignore that one too, Deserialization is extremely simple. (Insanely simple)
Ok, but this all doesn't solve my problem for the SaveFiles. It stores the current map to a hashtable in saveunit, but by storing the map, it's also storing the map's tile data automatically...
I can't be selective about this. I'd probably have to go and find the map that was saved in the SaveUnit, and then find out how MapBase handles it's tile data through individual instances of LayerBase, which I'd have to go into individually and use a method from GeneralRules.MapBaseObject.AllInstancesOfLayerBaseforThisMapBaseInstance
to clear their tile data.
Then there's the matter of sending serialized sprite data. I'd have to find some way to tell the client which serialized data belonged to which sprite when the server sends serialized data to the clients, which is another mind-jar within itself.
The one way of doing things is having the server handle XML files alongside the save files for each map. Through each of these XML files I could have tags such as <Players> <Player 01> *Serialized Data </Player01> <Player 02> *Serialized Data </Player 02> etc.(I never mentioned this, Lidgren.cs and NetController, the two objects that I use for Netgames at the moment, keep an array of players for each map, assigning each of these players's sprites a unique incremental ID from 00 to 99 *It increments every time a new player joins and fills in gaps whenever a player leaves, or that was my recollection of how it worked when I last tested it almost 8 months ago.. * I can just use these unique values to determine serialization data. I was already using it for input data.)
Then I would have to send the XML file to the client for each positional update and let the client handle deserialization and then the processing of each field from the data by reading the XML file.
Come to think of it, this could work for inputs as well. But instead, I could serialize SpriteBase.inputs and send that as a byte[SerializedDataByte] instead of using the XML file where byte holds PlayerNumber at index 0 and serialized data at index 1. It would be much faster than having to wait and process an XML file.
Or I could use the above system and just exclude XML files altogether. What do you think?
(It looks like I'm going to be spending more time on optimization again. Just when I thought I was finished. But then again, isn't most time usually spent on optimization?)