JsRpg

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

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

• Done:
  
  • System framework
    
  • Smooth(ish) scrolling
    

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

• background data loading
  
• authentication
  
• character selection
  

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.

• movement acknowledgement by the server (the page title changes to reflect various server messsages).
  

• Stuff in the works..
  
  • path-based movement - Anyone want to work on an algorithm?
    

  (MoonShadow) What do you mean by path-based movement? Do you mean route-finding? Is your map currently a regular grid, or is it composed of irregular sections, and if the latter, how do you store adjacency information? Route finding is usually done with some variation or other of this:
  

  • Start by assigning a score of zero to the location of the target and add all its neighbours to a queue of locations to be considered
    
  • While there are locations in the queue and the starting location has not been reached
    
    • Take a location from the queue
      
    • Set its score to be (minimum of its neighbours' scores) + 1
      
    • Add all its neighbours that have higher scores than (this new score + 1) and all its neighbours that have not yet been scored to the queue
      

  Once the algorithm terminates, either the starting location was not reached and there is therefore no path, or there is a path from the starting location to the target that may be followed by moving from each location to the neighbouring location with the lowest score. Once a route is found, you don't have to redo the work unless a different target is needed or the landscape changes to include new adjacencies or obstructions. If some locations cost more to traverse than others, you can work that into the scoring.
  

  I was actually thinking of using an iterative deepening method, but that should work better (Dijkstra's shortest pathing alg?). I'm using a square grid with the function System.map.isPassable(x,y). - Az
  

• Future:
  
  • party system
    
  • realtime battle system
    

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..

• all the other rpg things..
  

• Known bugs:
  

• Fixed bugs:
  
  • IntenetExplorer? + viewport clipping
    
  • navigation tabs.
    

Done :P

• Nothing works.
  

..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

• I clicked 'map' - no feedback.  After a while it asked me to log in with 'any name and password' - I put something in, and it said it was invalid.
  
• I then clicked some of the other options - and again there was no feedback - after a long pause I got what looked like a list of recent additions to the page.
  

I've been working on it over the weekend and it should now show the loading screen properly - Az

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)..