ec2-3-230-1-126.compute-1.amazonaws.com | ToothyWiki | RecentChanges | Login | Webcomic

[jsRPG] - a project by Azekeal
Are you the person I spoke to at LAC? If so, I'm Serge, and you might like to not credit me until I've actually done something to help.. :) - MoonShadow
I am he - sorry about not emailing. I lost the address, so I thought this might lure you out. I'd disagree about you not having helped; you came up with a number of ways of implementing concepts, which is more than most sections of the project at the moment :P

Javascript based client for a "massively multiplayer online role-playing game"
Just to point out that is this is a concept demo to show what can be done with js and xmlhttp rather than a valid system for supporting 1000s of players

Causes the main CPU usage, due to moving the entire viewport each update. I will heavily optimise this later - Az
Should now be better usage, I originally aimed to switch the backgrounds every whole tile but I messed up the condition so it was updating *every* loop
use the first character in the guest account - see the pretty animation when walking (okay, so i just chucked an arrow on it, but the idea is there). The point is that animations come (relatively) free as browsers are optimised to handle them.

turn-based would probably work best if parties are implemented. timeouts can be used to ensure disconnections don't lock the battle up. - Az
How about real-time but with strict ordering and making thinking time, rather than reaction time, the main factor? Something like this: every participant in a battle has a time bar. This increases slowly. When time bar is full, an action can be taken. When an action is taken, the time bar empties. A single action order can be queued up while the time bar is filling - if you do that, the server guarantees that the action will take place immediately when your time bar is full; otherwise, other people will get a chance to act if their time bars become full while you dally. - MoonShadow (btw, I'm still up for helping with the coding.)
I've been thinking about that I think that it'd work for the most part, but what happens after the bar fills up completely? Does the player then get to do an action whenever he wants?
No, not quite it. A player *can't* act while his bar is filling. Once it's full, his action takes place as and when he does it - there's no synchronisation, so other players don't have to poll - if they get there first, they get there first; *except* for any action queued while the bar was filling, which is guaranteed by the server to take place as soon as the bar is full and so before those of any players whose bars are still filling at that time. This means play does not get held up if someone takes ages to make a move, but if someone knows precisely what they want to do they are guaranteed their turn. - MoonShadow
If so, then all the other clients in the battle would have to continually poll the server for updates as to whether he's moved or not. Perhaps a looping version would be better, that if the user hasn't queued his move before his bar fills up, it empties again. In this way the clients can all work out when they need to poll the server and would also make the game quite realtime..The main problem we have left is syncronisation, in that different connections speeds mean that it will be difficult for a client to 'know' the current time at the server. If a client has queued an attack for the end of his bar, which happens at 4:00:15pm - how does each client know what 'now' is and hence how long to wait before checking the battle state? Timing a server request does not guarantee future network speeds...
I'm thinking perhaps a small 'dead-zone' past which clients can't queue actions till next round and not only allows the client to be SURE the update time has passed but also gives enough time for the server to respond. So:
  • Deaden queue (no more input).
  • Ask server for current time + battle state, sending queued actions.
  • Undeaden queue, client starts more queuing actions
  • Server responds with current time + bState (contains time til next bar filled)
  • Wait until current time + time till bar filled < now (since the time given by the server will be in the past by the time it gets to the client, so we're sure it's finished).
  • Repeat (deaden queue and request...)
your email is moonshadow[AT]toothycat.net, right? I'll send you the zipped file - you'll love the security of the admin section :P (btw, I should rewrite the get/post bit, 'tis a tad...crudded up; evolution of the function was not kind - I even use the arguments variable with typeof *shudder*). I don't suppose you want to rewrite the pathing algorithm? I have two implementations (one's commented out at the bottom), but they're both quite slow for non trivial paths..I was thinking perhaps a straight walk until it hits an obstacle, then it tries to get round it (limited to some length path) or stops..

Hi there.  I don't mean to complain, but MMORPG alrerady exists as a page, and the place you have put this page sounds like it should be for a general description of MMORPG techniques, rather than specifically JsRpg.
Done :P

Still, here are my comments.
..except the map scrolling and movement, which are the things he said worked. Check out the version number ;) - MoonShadow
No map visible.  No movement.  No nothing.  --Vitenka
Ah. Works here (FireFox 1.0, Debian/stable). - MoonShadow

Instant feedback upon clicking things, please.
Using FireFox as my browser for this test.  --Vitenka
I've been working on it over the weekend and it should now show the loading screen properly - Az

Tested again with InternetExplorer - same results - only the log page accessible.  Question - your page states that it works better for FireFox than InternetExplorer, but it has an ActiveX? control on the page.  Is that just your flashy exclamation mark, or won't that mean it can never work in FireFox?  --Vitenka
Nope. It's [this thing], I would imagine. Or if it isn't, it ought to be :) - MoonShadow
The script does use xmlhttp, but the way InternetExplorer and Firefox implement it are different, hence it tries first ActiveX? and then XMLHTTPRequest if that falls through. The only thing about InternetExplorer is that it doesn't do clipping properly (style="overflow: hidden") so you can see the map in the viewport moving, covering other things. Oh, and it has really bad z-indexing. Still, I'll fix that soon
...and indeed, I have fixed it. It should now work with both Firefox and ie equally. Firefox still renders nicer (ie sometimes flickers the map tiles), but ie seems to run faster (probably *because* it doesn't to try to render so well)..

Works much better now - the automatic guest login brings me to a map.  (Tested at work, on IE)  --Vitenka


ec2-3-230-1-126.compute-1.amazonaws.com | ToothyWiki | RecentChanges | Login | Webcomic
Edit this page | View other revisions | Recently used referrers
Last edited April 16, 2005 9:10 pm (viewing revision 11, which is the newest) (diff)