Sorry for another long post...
I'm not expecting servers to be large anyways, so I'll only send inputs for sprites that share a map. (I'm starting with a 32 player max per server, and I don't think 32 people will share a map at any given time)
@Durund I'm sending input data only, I'm most definetely not sending x and y coordinates (Could you imagine? :-/ Not only would things be choppy, but someone could EASILY manipulate the data..)
Well, thank God that I don't have to worry about the bare technical logic behind this. Lidgren.Network shields me from that. I have many modes of how I send data and input data is sent unreliably. However, the actual updates, as well as the download of the map is reliable and is checked to make sure that each packet arrived to it's destination. But I will have to worry about that last thing you said- but it shouldn't be much of an issue at all (The distances between actual positions and client believed positions shouldn't be game breaking *But they will be slight*)
I think you and durnurd are a bit out of sync in what you're talking about. I think durnurd is talking about what the server sends to the client and you're talking about what the client sends to the server. Naturally you wouldn't want to be sending sprite positions from the client to the server because that's too easily hacked. So yes, you only send the inputs from client to server. But the server has to process everything and send information back about the results of those inputs. This is where you send sprite positions and such, and try to optimize what you are sending. I don't see why this has to be any more reliable than what the client sent to the server. If the client doesn't get the update, the server can send it in a later update. It's not like the server is going to forget where the sprites are. And this is where allowing un-reliability is important for optimization because the server has so much to send.
I realized that Daft Punk has blue aliens the EXACT hue of the Aliens in my game. (AND extremely SIMILAR costumes) notice the jeweled headband... This was purely coincidental.
Hm. I'll have to recolor then. What's a good alien color then...? Magenta? ForestGreen?
If there aren't any better colors and you all truly like blue, I can just tribute this game to one of the greatest genre defying musical groups of France..
Would it be practical to add texture or something? Like make the aliens metallic or irridescent or furry :alien:? Or use a combination of colors like fractals or swirls or ... can you imagine an alien with skin like this?
(I wonder what else they have at http://garmahis.com/reviews/top-10-free-stock-textures-resources-for-designer/)
I see your point. I could have both input and updates sent unreliably, updates are important, but as long as the server ultimately holds the information, it's alright. The problem that I had with that was, what if the update was a huge gap from where the sprite was? (from what the client believed) which is where durund was going.
@durund - I've been sending data sequentially and I'm guessing that's a bad thing.. (I've tested networking with Lidgren once and it worked extremely well, but the person who helped me isn't contactable right now)
The system I use works with deltas. It only sends data when an input is pressed differently from the last frame (Look at me thinking about optimization when I just started working on the game!
I guess it was because I was tired of playing laggy games already) It sends a binary value. "0000000000" The first two digits correspond to the player number, say, player 1 is 01, player 2 is 02, etc.
The next 4 digits correspond to input data (Up, Down, Left, Right)
The 4 after that correspond to input button data (Button1, Button2, Button3, Button4)
0 Represents that a button is not pressed
1 Represents that a button IS pressed
For the longest of time I was afraid to change that, because I thought that if I did, it would slow down things to a gamebreaking level. Thankfully to the CS courses I'm taking, I'm learning about different kinds of numbers, more specifically, Base 16.
I'm eventually going to convert input data to Base16 so I can add more input buttons later on. 4 isn't proving to be enough buttons..
But I'm getting off topic
It sends the delta each time a new input is pressed, or if the inputs pressed on the last frame AREN'T pressed on this frame. Sequentially this wouldn't be smart, because if something about another client isn't recieved by your client from the server, your client will think that another client is either standing still, not attacking, or, still pressing a button.
Then this is game breaking because say the remote client was attacking an enemy and had defeated the enemy, but your client didn't get the data telling you about the attack.. Since the clients execute sprite rules by themselves to minimize data, then an update sent telling your client that the client that was attacking is now FINISHED attacking which you did
receive (When really the server and that client know that the attack defeated the enemy so the enemy is dead on their ends, but since you didnt recieve an update telling you that it was attacking, on your client, the enemy is still alive) would make your client just see the other player casually strolling off with a false sense of accomplishment, as the enemy was still alive in your game.
I know you both could probably say: "Well then send updates about enemies and NPC's- that way when the client receives the positional update, it'll get information saying that the enemy will be dead, right?"
While that would solve the problem, the game implements the item drop system I mentioned earlier, where a defeated enemy drops an item. If an enemy sprite has 0 HP
, it creates an item sprite before Deactivating that can be picked up.Say another player has already picked up the dropped item
. (Item pickups are only recognized by the server. Only the item picked
up by the client's sprite on the server is recognized to have the item) Your (Late)client recieves the update telling you that the enemy just died (And an item should be dropped)But another player has already picked up that item, right?This creates an entire mind-jar where the client thinks that it has an item, when on the server, and to other clients, it doesn't. I can't send the entire inventory data for each sprite (Their inventory data for each sprite is colossal!! It's one of the largest arrays in the game!)
One solution I have is to just do this:
Item Pickups are only recognized by the server, right? Well I'll keep it that way. Clients don't have the power to pick up items on their own then. The server sends the data to the client about the pickup when a sprite on the server picks up an item, telling it that Player<X> should get Item <ID>. THIS however, HAS to be reliably sent.
The server sends all of the clients on that map the data about the pickup, and when it does it also sends the data to the client logged in with the sprite that picked up the item. When the data is received by that client, that data also holds a confirmation ("Coin collected") that tells it that it not only that it should have the item, but it also indicates that the item was successfully received. This way people aren't confused and they don't think they've picked up an item that they don't actually have.
I know this isn't how most MO's would do it, because they have item shops that people spend real money for and cant have players compromising data this way. But it works. I think this is an area that'll take care of itself though. Even if a player attempts to hack by giving themselves an item that they aren't supposed to have by changing the data the server tells them that they're supposed to have, things reset when they change maps or log back in. So I don't have much to worry about. Their game will be bugged and out of sync for attempting to hack, and it won't mess up anyone else. (It's their fault and their problem for trying to hack anyways, right?
) So who cares about them. If it's even an extra healing item, their health will be updated by what I'm planning to do. (read below)
I've found something else that I'm also going to have to send Unreliably. HP, MP, and SP. Say by some error or complication, all the sprites have different values for a certain client's HP, MP, and SP. This is bad because it's game breaking. I'm going to have to incorporate it inside of positional updates. I can't send HP to the clients everytime a person gains or loses HP, because that would be terribly inefficient. (Say someone just walks into a pit of spikes?
So now I have to devise another system to send positional updates.
I can't send this as a variable length value, (Ex: 1 instead of 0001, because I know that each map will be 9999 by 9999 pixels of scrollable size.)
Here's my new way, that I'm hoping for:
I'll send this from the server to each client as a positional update.
Where each digit isn't binary, but, instead decimal, each 4 digits represents what needs to be updated. The first 4 are X the second 4 are Y, the third 4 is the new HP value, the next is the new MP value, and the next is the SP value. Since I know that HP, MP, SP, and X and Y all have a max value of 9999, I don't have to use variable length values. It ranges from 0000 to 9999. And these are the most important values of the sprite-
think of it as 0000-0000-0000-0000-0000
HP MP and SP are all values that the sprites rely on.
I'm going to try and build everything from this system of reliable and unreliable updates, so I don't have to tear apart my code later to fix things.
I could actually optimize that value above even more actually. I'll figure out how to later.
This is why I was so concerned on making positional updates reliable. (And by positional updates, I mean the one that occurs every 10 seconds) But if I use the system I'm using now- it should work with unreliable transmission.
as for using a texture instead of a solid color..
T'was the old title screen to my game. (I didn't like it for being an still image, so I replaced it with something more attention grabbing) I used carpet, a purple metallic bowling ball, and aluminum foil for the texture.
Strangely genius using a texture instead of a solid color for aliens. I love the idea. Metal would be a nice fit too. Maybe even vast, endless stars.
I thing I'll go with a combination of metal and stars for the texture.