Ok, so I'm using Mooclick for an online game, and I've got it connecting and everything, but I have no clue how to program the actual game stuff. I need to send X and Y positions, directions, and animations back and forth. I use TGF2, so I can't use String Parser, OINC, or anything like that. Any help? Can I use multiple channels for X, Y, etc?
Hate to break it to you, but even though it's more then possible to create an online game without String Parser, you're honestly not going to get too far without it. MMF2 can only run so many loops per second, and sending a single message has a minor impact on performance as any other kind of event would, so unless you're able to send most of your information you need to send down a single message, you're looking at both a very complex game, in addition to a very inefficient and performance wise, slow game.
Well, I was able to send a single value that lumped them all together somehow, but I couldn't reposition the other player's object using it. Does Mooclick have any dead reckoning or something that might be messing with the values?
i know its long but this is informative and relevant.
most people dont understand what dead reckoning is. it isnt something mooclick would be implementing. its something you implement, as it is a method to guess at the positions of moving players in times of high latency. so if a player WAS moving, but the server is not receiving any more information, the server can keep moving the player on a path close to what the player might be doing until more information is recieved.
if you sent a players x and y coords, unless you receive them, interpret them, and put the player at those coordinates properly, mooclick has nothing really to do with it.
also you dont want to be repeatedly sending x, y coords anyway. a more efficient way would be to send a direction and a speed ONCE when a player starts moving and whenever the player changes direction or speed, and momentarily send the x, y coords so the server can sync the player with its actual position. then send the x, y coords and a stopsignal when the player stops moving so the server can position and stop the player and be ready for more information. less information is sent over longer intervals of time therefore cutting back on bandwidth, reducing latency, etc.
now for your question.
yes and no. you could but it would be very inefficient. you would have to send a lot of tiny strings in a certain order to get the results you want.
example.
send string 'id' to inform the receiver that the next block of information belongs to player with the next incoming peice of information which is an id value.
send '1'
send string 'x' to inform the reciever the next piece of information is an x value.
send '15'
send string 'y' to inform receiver that the next info is y value.
send '27'
send string 'dr' to inform receiver that next info is direction value.
send '13'
etc.
etc.
you might ask "why cant i just send the numbers and always send them in a particular order so i dont have to send a descriptive string before hand, making there less to send?"
well you could but as i said sending the least ammount of information at any given point is the most efficient way of sending data over the net. there are lots of things you are going to need to send as the game gets bigger. bullets, grenades, vehicles possibly, game map events, etc. if you always send the same values in the same order, you would have to send nullified strings that indicate to your interpreter that nothing of interest should be done with that message. an ignore string if you will.
so again, without string parser youd pretty much have to do it that way, rather than the much more efficient and wanted, blob of text information which could look like this
'id1x15y27dr13'
which could end up being any size as each value is delimited by a very short descriptor and the interpreter could extract the information with ease.
Ok, well, I already know what's in the game, and it's just one-on-one, so I probably won't use all of that. But thanks! That'll probably help.
However, I've sent multiple messages at a time before, but I don't know how to differentiate between the messages. I guess if I can get help on that, it'd be enough to make it functional.
well im pretty sure mooclick uses the tcp protocol. thats one of jamie's bragging points about oinc, that it also has the ability to use udp.
tcp is more secure, while being slower. all packets sent arrive at the receiver in order. so sending a message like i said that is descriptive before sending the actual data would solve that.
send a string that says 'x' then send the actual x value.
have a flag that is either on or off. if its off, when a message arrives it should check for a description. when it gets one it should turn the flag on and store the description somewhere, a string object perhaps. then when the next message comes the flag is on so it should be checking for a value. since the descriptor is x it should store the value in the senders x.
lol, why would anyone want to use UDP with a game?
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
When message recieved
-start loop "getdata" "length of the string recieved" times
On loop "getdata"
If mid$("string",loopindex("getdata")+1) = ","
If counter "currentdelimiter" =0
-Set counter "currentdelimiter" to 1
-Set X pos of enemy # to val(....ect.
You know I'll have to make an example of this for you later.
But it IS possible to make your own string parser, its just a pain to do.
Originally Posted by Muz lol, why would anyone want to use UDP with a game?
i hope to god you're joking.
@urban monk - i thought of that, but for some reason i couldnt think of how he could accomplish it when i posted. that would work quite well actually.
n/a
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
29th May, 2009 at 08:24:10 -
I agree with most things in this post but there are a few things I'd like to add.
If you don't have a string parser, yes you could create one yourself, but since you have described your game as a fairly simple one, it might just be a good idea to take advantage of different subchannels. For example instead of having to tag each piece of information with an indentifying string such as "dr" you could simply send information about directions on subchannel 5. Any message sent or received on that channel would be about directions. Similarly you could send information about shooting on channel 4 and speed on channel 3 etc.
Using this method all you would need to do is check which subchannel a message is coming from to determine what information it will contain.
Ie. Message received on subchannel 5 > Set player's direction to the one in the message
Ie. Message received on subchannel 4 > Make player shoot.
However for the xy position you would probably want to send that at the same time. For this you could simply send a long string of numbers with the left half being x and the right half being y values. ie. knowing that your players can move to a max x and y position of 999 means that you won't ever have to send an x/y coordinate above 999. Therefore you could send something like: 451022 as a STRING so that the 0's are preseved.
On receiving this value you would then interpret it as:
left$("message",3) = "451" = X position
right$("message",3) = "022" = Y position (of course converting the string to a value changes this to 22).
There is also another method to send two values as 1 using maths and the mod function. I can't recall it off the top of my head but there are examples floating around and even extensions that do the same thing.
Note that It is also redundant in Moo and OINC to send the ID of a player who is sending a message because that information can be retreive by the extension itself. Using an expression you can retrieve the ID of a player who sent a message.
These methods are of course working with restrictions and there are much better ways to be sending the data. I assume this is what Duh Cecil was working with aswell and I'm sure he would know more effective ways to send data.
Muz - UDP is the best way to send data for fast-paced online games that require speed more than anything else. Most if not all online action games use UDP where possible.
If it matters what order the packets arrive in then you can add identifier tags to the front of each UDP message and then disregard a message if it is older than the current one you are on.
ie. Player sends 3 messages:
"1,100"
"2,200"
"3,300"
These are in the form "message id, xposition"
Then assume that the packets are received out of order by another client:
"2,200"
"1,100"
"3,300"
You could make it so that after it receives the first message it then disregards the second because the message ID is older than the first.
"These methods are of course working with restrictions and there are much better ways to be sending the data. I assume this is what Duh Cecil was working with aswell and I'm sure he would know more effective ways to send data. "
well given HIS circumstances of working with tg2 and not being privy to all the fantastic extensions, either making his own parser using fastloops, or using channels would be the way to go about it. with the parser being the seemingly better of the two.
i have very little experience with moo, but i am familiar with internet protocols and how things are sent by working with windows sockets. someone even more experienced and probably far superior in knowledge of this matter would be jamie, as he is the one creating oinc, one of the best networking libraries ive seen.
agreed with UDP. unless youre making something where the integrity of the information being sent is of highest importance, udp is the better of TCP vs UDP. tcp guarentees that the information will arrive intact and in order at the expense of speed. udp does not guarentee that the information will arrive in tact or at all, and can arrive in any order. although for the most part it will. a small price to pay for speed.
Advertisement
Post Reply
Edited by RedEnchilada
