Games in Progress: 3 | Players logged in: 3 | Players Registered: 37413 | Games Played Total: 68656
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: Blitzens ideas to improve land auction and land grant  (Read 910 times)
Blitzen
Mule Senior
****
Posts: 152


Fire, Fire, Fire...


View Profile
« on: September 22, 2010, 08:41 »

You guys are so worried about a dying community... I say you are killing it by not addressing the issues properly.  I might even say you really haven't built anything yet to be killed.

Here is my solution to the big PlanetMule problem, I will leave 3d shooters with 60 players for someone who is offering me money.  And no I won't be waving a magic wand to erase latency... I will hide the latency and force it to be dealt with fairly instead of running away screaming like my hair is on fire.

Scope: a solution is needed to improve the game play during auctions and land grants -- the only times people need to appear 100% in sync.

- the client's entire role is to paint what its told to by the server and to communicate player actions back to the server

- the server is running all the game logic and enforcing valid input - sending back to everyone what is going on

- the client is time slicing all its gfx and proceeds to draw what it actually "hears" from the server

- the server in turn hears the clients input and can send a stop to all the clients when one client "drops"

- clients can sync with the real time clock in order to all get a fair start and stop to the auctions

- the client and server need to adjust for lag, making everyone come down to the slowest players internet speed

- the server logic needs to allow for missing client info and be able to make reasonable assumptions like say, player x was running up when I lost him, maybe x is still running up until I hear again... and moreover I will trust the packets I have and assume x was always running up even if his packets come in later and show differently

- the client might also need to be able to infer what the other players are doing when the server isn't getting through, and also be able to adjust when it hears back the unexpected, and to stop when it doesn't hear anything for too long a period

- like I said, the server would have to be able to make the judgement as to when to force all the players to come back into sync and possibly to make them all wait a few frames from time to time

- it might be nice for long outages to come back paused so people can take a leak while they wait for a spike to die down - someone to reboot their connection

- players might notice a half second delay between their commands and the interface reactions, they will just have to adjust for it

Obviously it needs some tweaks and its very superficial from a code perspective.  The point is it would provide a fair system that is at worst a little more clunky and at best exactly as the original.

As for my suggestion to put servers all over the world, I would think us dedicated fans could spare some PCs all over the world for the cause... think of it like a torrent server system for Mule.  I am pretty GameSpy would give it up too if we just agreed to see some adds while we play.

And thank you for all the wonderful electronics lessons but my point was that the improvements in tech will eventually make "lag spikes" and lag due to "volume" a distant memory. When all we have to worry about is the lag due to physics life will be sweet.  Did you know that your data rarely takes the fastest physical path from point a to point b based on geographics??  The routers it travels through make those decisions and the more of them it travels through the more it slows down the whole process.  The Internet's latency AND bandwidth will continue to improve vastly as more nodes and trunks are added, don't be so bloody thick.

On the by and by,

Latency is a measure of how much time it takes in between the send and receive.  Bandwidth is a measure of how much you can send and receive in a given amount of time.  Thanks for not clearing that up for "many of us" despite the fact that you say we don't understand it.

Quantum mechanics is a branch of physics which is useful but essentially flawed by its premise that everything is just based on probability.  It hasn't served to create a unified theory and it won't help us transmit information using entanglement since it cannot explain the cause of the apparent phenomena.

And lastly, Ontario is not a city, it is a province (like a really big state) and hence my deep desire for online play, my buddies are not all down the street, 1 of them is... I thought I made that pretty clear... the guy in KL with a 250 ms ping is 600 km away from Toronto and using a really slow radio frequency based high speed internet -- no the speed of light isn't the limiting factor ffs!

I don't know whether to laugh or cry in the face of such stupidity, are you related to Bush? Or is it Cheney? cause you make me feel the same way they do whenever they open their mouths!  Tongue

PS Hiya Death_Mule17, I was a Habs fan before I gave up on all NHL hockey right around the last player stike / owner lock out... being in Toronto I hardly got to see any Habs games on TV so that didn't help.  For the record the Leafs haven't been worth watching for 40 years now.
Logged

_______________________________________
Death to all smurfs.  Even the pretty one.  Grin
dynadan
Mule Regular
***
Posts: 93


View Profile
« Reply #1 on: September 23, 2010, 02:06 »

@Blitzen
Ok have read your post several times, and I think i understand what you are trying to say, but I still don't understand how you would implement it in the practical sense especially when your stated goal all along is to make the game an exact duplicate of the original version.  The way I am imagining your system working in regards to working at the slowest players speed is a lot like how the land selection phase works.  That would indeed make auctions very clunky, slow, and very much different from how auctions ran on the original.  It might make them more fair.  But as I have mentioned there are already ways to prevent someone taking advantage of you just because they have a lower ping.  You just have to give yourself more reaction time.

I wish you had put this in the thread about land auctions because this is the first time i have seen a post you have made that is anything except complaints.

I will let the developers respond as to whether there is any merit to your suggestions.

@Leahcim
    My point about the multiple servers around the world wasn't that we couldn't come up with the resources to do it, but more that we don't have the number of players to fill them up or make them necessary.

  I realize there is a difference of opinion when it comes to exploiting host advantages.   I play as hard as anyone, but I don't see this as being the same as knowingly abusing a flaw in the land selection process.  For the most part only the more experienced players have spent the time to figure out how to host, and those are the players that need an extra advantage the least.  I will continue not to press the button on the last selection round if my position dictates that i should not receive a plot, whether i am the host or not.  I realize that trying to hold everyone to this same self imposed standard is impossible.  And if I have one complaint to the developers it is that you have not fixed this issue.  Compared to trying to get rid of the latency issues of land auctions this seems to be a relatively easy fix.  The land selection already seems to work how Blitzen was suggesting the land auction should work.  With the speed of the process being dictated by the slowest person.  I don't see what the issue is with having the preselect phase (when frame changes on plot before) treat all choices on a last to first basis rather than how it is now with last place sometimes getting 1st priority (sometimes not) and then after that having it be based on ping lowest to highest.  Forget the land auction thing altogether.... this is the fix that would most improve the functionality and fairness of the game.  The secondary selection phase (before frame changes on plot you want) i understand will still be affected by ping.

One last thing Blitzen, I don't want to drag our discussion all over the boards so i will just put this here.  I have seen you post that the game is currently using a central server.  This is not the case.  This is why its sometimes useful to actually play the game instead of just doing it in your head.

Logged
data2008
Administrator
Mule Expert
*****
Posts: 288



View Profile
« Reply #2 on: September 23, 2010, 07:03 »

@Blitzen
Ok have read your post several times, and I think i understand what you are trying to say, but I still don't understand how you would implement it in the practical sense especially when your stated goal all along is to make the game an exact duplicate of the original version.  ...

I will let the developers respond as to whether there is any merit to your suggestions.

We are going to tackle this one as I write this.

@Blitzen:
dynadan is right, that PM1 has not changed to a server based netcode.
It is still P2P with one player acting as host server.

That means there is the problem of a host advantage, and we are serious to fix any problems in the two most critical areas you mentioned, that is land grant and land auction.



I play as hard as anyone, but I don't see this as being the same as knowingly abusing a flaw in the land selection process.  For the most part only the more experienced players have spent the time to figure out how to host, and those are the players that need an extra advantage the least.  I will continue not to press the button on the last selection round if my position dictates that i should not receive a plot, whether i am the host or not.  I realize that trying to hold everyone to this same self imposed standard is impossible.  And if I have one complaint to the developers it is that you have not fixed this issue.

You are right, the land grant bug that the host shouldnt win a tie if its not for his position is thought of RIGHT NOW! With either 1.3.1 or 1.3.2 we will aim for solutions and hope you guys help us test ou various implementations to make sure they will work in "hard competition".

Hopefully, we can offer something before the weekend, stay tuned and keep up the good discussion!
Logged
Blitzen
Mule Senior
****
Posts: 152


Fire, Fire, Fire...


View Profile
« Reply #3 on: September 23, 2010, 07:37 »

Well guys I was going to post this tomorrow cause I am going cross eyed now at 3am here... but here goes anyway:

I can appreciate your points about playing before commenting but honestly it was stated that they would have this implemented in the next version... I thought that meant the current version now... it must be another case of me misunderstanding what was decided...

I meant for you to read all my postS not just this one btw Wink

But what your saying also means that the current solution CANNOT already be what I am suggesting...

I really thought they had decided that a centralized server was the only way to combat the packet bombers and redonculous host advantage.  I actually "quit" playing this version before I fully understood the nasty exploits.  I quit because of the cheaters, smurfs and a general disappoint with the game as a whole... you would have to my all my postS to know the specifics at the time...  I have been following the boards closely since then, or at least I thought I was...

Further to my "solution" I don't think the current version of the game is using any centralized timing and real time clock synchronization at all.  It seems like players can be totally out of synch with one another and the "server" doesn't enforce any kind of timing rules.  I.e. first one to reach the host and say they hit the button gets the plot, instead the server needs to consider a time stamp with every bit of info.

Forgive me for being so abstract but I will try to expand on it all.


Givens are:

- Auctions last a definite length of real time and price changes at a given rate.
- Land grant moves at a given rate of real time over a given set of properties.

Ignore land grants for now...

The logic would flow like this:

The server says to all the clients, start an auction at an exactly time in the near future (+- 250ms) to reuse some other numbers, and you will all start out running when the time arrives.

--> Now everyone's computer can keep time to within an amazingly tight precision.  In other words, 1 second is 1 second -- remember the real time clock is independent of the entire CPU, it will always (for our purposes) be exact.  In other words, any two clients will never be more or less out of synch than
their initial difference -+ 250ms in this example.

--> So everyone's computer is going to send "updates" to the server at set time intervals.  Those updates will contain the real time since auction start, the current action (up, down, stop).

--> Now you might think a person with 10ms ping might have a very fine grain of control, but the server still has to enforce that the slowest player has to be given a buffer for his client to react in time with everyone elses.

--> Now a person with a 250ms ping would have a clunkier grain of control, I don't deny it, if it takes 250 ms for his message to get to the server thats 240ms more to notify the server... But he is assured a fair shot despite it all because the central server is assuming he is running up in those first few moments and deciding that he never stopped just because some of his "in-between" updates never made it in.

--> the Server is also going to validate the updates it receives and be very pro-active about detecting attempts to cheat (for instance it should not be seeing any updates with premature time stamps which shouldn't yet exist).

To keep everyone in synch it would also need that the client cannot turn or change direction until after the server has received the message and confirmed and obviously allowed enough time to tell everyone... So the server tells everyone the same thing:  at an exact time in the near future some player is now doing something new (up/down/stop).

I admit the game would have to sometimes pause and enforce a resynch sometimes.  It is the only part you can't avoid, but I still say its safe to assume internet latency will diminish in the decades to come, to the point of irrelevance in human terms.

And like I said, when everyone has a workable ping and clean connections, you will have a great remake alot sooner than that.

Now you could bring back random first to line and bob's your uncle imo.




Since the cursor moves so fast in land grants it might require some change,  The server is going to read everyone's updates and compare the client time

stamps, the clients are again going to be waiting for confirmation before painting the lot!  But it might also be necessary to add a very little time out whenever a plot gets picked since we know the round trips that are required are going to need it... now I can still try to hit my button earlier on the plots I want and think my position offers me a better or worse chance in the event of a tie, without any real concern latency. 


Anyway its very late and I am getting in WAY over my head here... I have never written any code like this and have no idea how to outline it in a concise, practical and thorough manner.

I enjoy and look forward to all replies... even the ones that make me spin!  Cheesy
Logged

_______________________________________
Death to all smurfs.  Even the pretty one.  Grin
dynadan
Mule Regular
***
Posts: 93


View Profile
« Reply #4 on: September 23, 2010, 10:52 »

I don't disagree with anything you have said on this last post concerning land auctions (Progress! LOL)  I am not sure if it is feasible or not.  Again that is the developers decision since they are the ones putting in the hard work. 

I am not a M.U.L.E. purist.  All I care about is improving the game play.  For me this includes fairness (hard to have fun on an uneven playing field), and functionality (I think we could all come up with fair systems that would erase the lag, i.e. 1 bid every second.  But they may not add to the functionality of the game.  And most importantly Fun.  The fun factor is what i think the last auction change added that the old system of running it up had diminished.  The only downside i have seen is the lag/latency problems associated with what people see on their screens compared to what really happened.  If your system (or any other)  can satisfy all 3 of those criteria I am all for it as well. 

As far as land selection goes, I really think the system already in place uses basically the system you describe for what you want to do with the auctions.  Again the developers could say for sure.  But from playing 100's of games i know that the land selection always moves at different speeds depending on who is playing.  That is why i have no doubt that the developers can make a fair system (much improved over even the original game) for dealing with the land selection phase.  I know that even on the C64 version there was a version of latency ( I remember always volunteering to play the keyboard because whoever had the spacebar? would get first priority on land selection)  That's why making the changes i outlined in my previous post i think would be very easy to implement.  If I had any idea the programmers were this responsive I would have made this suggestion long ago.   I can't even estimate how many players have quit because of this single issue.  Anyway Kudo's for committing to address this issue!!!

Back to the land auctions... The only problem i see with implementing your suggestions, Blitzen, is what you refer to as the clunkier control a player would have.  I don't know how often the system would have to "resynch".  Basically each slice of time would be determined by the player with the highest ping.  So the system would for sure not be as smooth as it is now, but it would certainly be accurate.  And each auction would consist of 1000 (or some number) slices of time.  Again, I do not know if this would be a feasible and fun way to do things or not.  I am pretty sure that the current system resynch's every so often as it is now,  that seems to explain people's bids jumping and the timer going up instead of down sometimes.  I am just describing how i see the game working now, I could be totally wrong here and I look forward to hearing about it from the developers if I am.

Anyway I have a few more idea's for improving the game here at PlanetMule but I will save them for another thread so as to not muddy the waters anymore than they are already.  I have a feeling the purists are going to be calling me some more names.  It may be best for the harmony of the site to just let me focus on helping with PM2.  I think a new MULE has HUGE potential.
Logged
C64 nostalgia
Prototype Tester
Mule Senior
****
Posts: 159



View Profile
« Reply #5 on: September 24, 2010, 06:36 »

[This thread seems to have the most detailed posts about "lag" issues... so I'll post here, but I guess it could go in four or so others. Move it, if it makes sense.]

Honestly, its a fundamental game requirement now days that games support real time online multiplayer anyway...  Shocked

The biggest difference between Planet MULE and classic M.U.L.E. is lag. The very thing that makes Planet MULE great (online multiplayer support) is the very reason we have such disappointment. Lag is an almost universal complaint -- purists and moderns even agree. Finding a solution to severely mitigate lag issues should be paramount. This goal is hugely important not only for Planet MULE 1 but especially for Planet MULE 2. People will be far less tolerant of issues from a game they spent money for.

I know very little about programming, so I won't try to suggest a technical solution. But, those solutions have to exist. An amazing amount of online games are available... even games running on low-resource handheld gaming devices and cell phones complete with added wireless complexities.

During the first MULE 2 trials back in the Spring, Pescado made the cry for change. Now, Blizten... (Amazingly, they have similar styles, too.) It's time to really seriously find, create, buy... a solution.
« Last Edit: September 24, 2010, 06:38 by C64 nostalgia » Logged
Blitzen
Mule Senior
****
Posts: 152


Fire, Fire, Fire...


View Profile
« Reply #6 on: September 24, 2010, 08:07 »

@C64 nostalgia I would love to read what Pescado had to say... I might of missed it but I thought I read all the interesting threads since creation on here!  Then again I may have read it and thought "well said" without realizing that to post that thought is also vitally important.   I know I have read similar complaints and arguments to many of my own, but I don't often remember names.  I really suck with name recall...


Thanks dynadan, I too am shocked by our progress!  Grin

...I always took left side of the keyboard cause my uncle was left handed!  ill have to mention that to him next time we sit down to play....

But if what you say is true "...keyboard because whoever had the spacebar? would get first priority on land selection" I will be shocked and name calling someone again very soon... muhahaha! Do you have any hardware discussion links that discuss such problems on any system, not necessarily c64 or atari 800?  Would love to read about it... print it out... use it as evidence.  Cheesy

Re. "As far as land selection goes, I really think the system already in place uses basically the system you describe for what you want to do with the auctions.  Again the developers could say for sure.  But from playing 100's of games i know that the land selection always moves at different speeds depending on who is playing. "

I think you have actually proved that the current system doesn't work as suggested since as you say it always moves at different speeds.


Re. "what you refer to as the clunkier control a player would have.  I don't know how often the system would have to "resynch". Basically each slice of time would be determined by the player with the highest ping.  So the system would for sure not be as smooth as it is now"

Preventative resync would have to happen whenever the lag has become too great and the system risks being too far out sync by continuing to infer for a players missing information.  This is usually a temporary thing that happens to everyone's connections from time to time.

I think the process for correcting most desynchs would be mostly seamless and cause one or more players to experience some jumps to new values.

(A player with a permanently brutal ping would have to be penalized and warned about it, the penalty would be the natural consequence that they cannot have the same level of granularity in auctions that everyone else would, and that they might have to fail a lot of "ties" to prevent exploits.  They wouldn't stand a chance on popular plots... A competitive player, beyond some threshold would probably not enjoy the experience.)

Also each time slice to paint would be determined by the individual clients machine, targetting 30-60 fps... in other words the clients play the auction animations according to the clock, if it can't keep up it skips drawing frames from the animations to compensate... the "time slice" for communications would really be a measure of granularity of control, i.e. you can't decide to go up and down in an auction more than once every "whatever is the worse expected ping"... but your individual clients might still communicate to the server every 10ms, the server simply takes the average response in the absense of all expected responses over some fancy sliding slice of its own.  Likewise the clients can be sent messages every 10 ms but they just work out the expected outcomes when server information is absent.  I would expect the server might have to adjust the whole thing when that maximum trip time goes up and stays up, i.e. the internet becomes more (or less) busy.

A need for a detected resync also exists.  To do it, you do have to send a little more information back and forth at set intervals, ie. complete status checks of all potential variables and when things are out of wack resync.  To be specific, player positions, current directions, current price, current real time since start.  When anyone of those get too far out of sync you have to resync and someone might find out player x had started moving a half second or more ago etc...

This does happen sometimes now, but I think it is quite different and not handled as well as it could be.

In the resynching logic all cases of who should get the plot problems, the player who desynch'd should not get it... its their connection and their responsibility, let them suffer and discourage cheaters by denying them an opportunity.

The land auction would be the only place I would expect players to really notice negative effects of latency and lag spike, thinking they had a plot and being corrected would suck.

Whereas finding out you are 10 dollars behind on a plot you were just winning isn't the end of the world. as you guys have already pointed out, that you just have to adjust for how close is "safe".  The dance would be intact and you would still be able to drive your buddies up and down with fear tactics.

To accommodate all possible pings, if desired, it can be further programmed so that the scale of time increases and makes auctions be 3 times longer, slowing down the maximum movement rate of change by an equal factor etc... and now your communication lags / laggers won't go out of sync so much.  But I probably wouldn't want to play that way personally, especially if you did something foolish like included this time scale in the development phase where multi-player sync is currently unnecessary.

By clunkier control I am referring to the consistent delay before the game "registers" that your changing direction, this would be the time it takes to tell the server plus the expected time for it to tell everyone the change is happening (ie. scheduled to happen at some real time frame in everyone's interface).  Plus the time for actually executing the supporting code on both ends...

I really can't tell, I know >1 GHz CPUs are common and that equals 1,000,000,000 Hertz, or cycles per second, which would translate onto 1,000,000 instructions per millisecond, which would would still beat up a c64 I would think... but most people now days have huge operating systems eating up instructions and creating a whole new type of lag spike, if they are really silly they also have a bunch of other applications running all the time and too little memory to handle it!  For these unfortunate souls the expression you can't please everyone applies imo.  Also, those 1,000,000 instructions are machine, aka assembly, I know Java is interpreted and adds even more opportunities for software lag.  As I said about Java and hardware access, I think you would need direct x, some assembly, and some form of minimum standards for connection latencies to really do it right on Windows machines.

But I am ass-uming a lot of things all over the place!!!  So to everyone involved if all I am saying is rubbish, my apologies for wasting your time.  Embarrassed


Lastly, to the devs, out of curiosity are you guys aiming to support players on dial-up connections?  I ask cause I once played a 3d shooter on a server where such players were not allowed in order to improve the game performance... every now and then one would log in and the game would chop for everyone... and then they would get kicked Wink
Logged

_______________________________________
Death to all smurfs.  Even the pretty one.  Grin
Blitzen
Mule Senior
****
Posts: 152


Fire, Fire, Fire...


View Profile
« Reply #7 on: September 24, 2010, 11:43 »

In another thread, dynadan made me think about the time speedup that happens in the original when everyone stands still at auctions. For a minute I thought it was a deal breaker but not really.  The auction total time is still known, however the clients can be told to speed that time up and to slow it down as required.

It might add some complexity but its entirely doable in my head anyway.
Logged

_______________________________________
Death to all smurfs.  Even the pretty one.  Grin
Blitzen
Mule Senior
****
Posts: 152


Fire, Fire, Fire...


View Profile
« Reply #8 on: September 24, 2010, 12:14 »

BTW dynadan, someone else started this thread for me (?Peter?) and I didn't realize it was technically dragging our previous argument into yet another place, where it is now totally out of context and quite unfair to you.

Despite that, my apologies I probably should edit it a little... but then you would have to edit yours and then I would have to edit this one... we'd miss something and confuse em anyway... so forget that idea!

So instead here is the link to the entire discussion that brought this unfortunate situation about in case anyone missed it.

I think it was epic and very good reading, not Oprah material or anything, but firery as all hell, enjoy!

http://www.planetmule.com/forum?topic=1052.0 (not suitable for all ages and intellect, think twice before you join the fray)!  Cheesy

All kidding aside I hope we can find a solution to this problem so please post your thoughts, and dynadan sounds like a nice guy when you don't go around calling him silly names anyway...
Logged

_______________________________________
Death to all smurfs.  Even the pretty one.  Grin
leahcim99
Prototype Tester
Mule Senior
****
Posts: 131


MULE - its does a mind good....


View Profile
« Reply #9 on: September 25, 2010, 00:23 »

Is the world ending and no one told me?

Blitzen and dynadan agree?Huh
Logged

"So long...and Thanks for all the fish"
Blitzen
Mule Senior
****
Posts: 152


Fire, Fire, Fire...


View Profile
« Reply #10 on: September 26, 2010, 09:15 »

I don't think we agree on everything so no worries yet.  Undecided
Logged

_______________________________________
Death to all smurfs.  Even the pretty one.  Grin
Pages: [1]
  Print  
 
Jump to: