Hi, the pipe approach of Alan Chandler is a good way to reduce request to the APE Server (and client side load). But, the aproach of using div for player instead of canvas might slow down client side performance. I guess you will use PNG sprite animation for user move.
We made some bench to see what has the best performance between canvas and div, and canvas are really more fast for PNG sprite animation and redrawing. Also note that using mootools tween effect is not the best solution to make user move, as each time you'll make a tween effect this will start a new timer. Using one global timer that loop each object and make them move might be the best approach (and this will help you to synchronize player movement). The best thing you can do is to write a prototype and try to stress your browser with a lot of player (not real player connect to APE server, just fake player that move randomly) this will help you to see if your solution is the good approach :) Regards. On Wed, 24 Mar 2010 18:00:09 -0700 (PDT), Spaceer <[email protected]> wrote: > Sorry for my slow response, I've been out of town and got back to > workin on the concept today, with a completly new approach to the game > engine. > After some thought I've realised event based movement is indeed the > way to go, and your solution with different pipes is genious, didn't > think of that, thanks a bunch for your pointers. > I've scrapped the entire concept of canvas redrawin/animation aswell, > basicly my new idea is just using the canvas to preload objects on the > game map, and then place players images on a div ontop of the canvas, > so i wont have to redraw at all but can just simply use mootools tween > to move the player objects around the map. This wont require constant > polls to the APE server either as movement will appear fluent even if > its not 100% exact. I'm thinking that just moving a couple of elements > inside a div when needed should be a lot less Client-heavy then a > canvas animation loop. Any obvious problem with my new approach? :) > > And again thanks Alan. > > > On Mar 19, 7:51 am, Alan Chandler <[email protected]> wrote: >> Spaceer wrote: >> > Started working some days ago on learning APE for creating a >> > javascript MMO online game Engine, am just in the starting phases and >> > working on theories how to as effeciently as possible set up in >> > things. >> >> > Playin around with the idea how to position players around the map in >> > realtime atm, but cant really figure out a good way that seems >> > reasonable to be able to support a lot of players, I'll explain how >> > I've set up the engine so far. I'm using an canvas to draw a map of a >> > hash created of an SQL table that represents the map, maptiles are >> > represented in X and Y for positioning, evry draw (about 20 FPS) the >> > draw function takes out the relevent maptiles from the hash and draws >> > them correctly relevant to the actual X and Y which is seperated from >> > the X and Y of the map hash ( to create a fluent walk and not just >> > walking over tiles). So far so good, but when rendering players, i >> > need to be able to something similarly, check a hash, or the user list >> > properties of the Pipe to find out if other players are within view- >> > range of You, and then draw them accourdingly. >> >> > This i've accomplished trough using mootools each on the user list of >> > the pipe, what i'm worried about however is that running an each 20 >> > times a second on the ENTIRE list of pipe users is not viable >> > longterm, that when the list of user grows. Imagine running this each >> > on thousands of hashe objects 20 times a second. I'm unsure though how >> > the mootools each and hash works though. Is this approach even viable, >> > if not, what would a smart solution be? >> >> I am not sure I fully understand what you are saying ... >> >> ... why do you have to redraw the (presumably static part of the) map >> all the time? >> >> My first reaction to you scanning a list 20 times a second is that you >> should convert to some form of event based approach, sending an event >> when someone/something moves. >> >> Why don't you have a separate pipe for each geographic area, subscribing >> to the 9 pipes that make up the 9 regions/tiles immediately surrounding >> your position. When YOU move, you send a message down the pipe >> representing the region/tile you are currently in, when you cross a >> boundary you sent a leaving region message down one pipe and an entering >> region message down another. When someone else moves, you receive the >> corresponding events. >> >> Locally, you keep an array of known players in the 9 regions around you, >> and update from the movement events coming down the pipes. Add a > person >> to the hash when not previously found, remove them when you receive an >> event that they have left the 9 tiles you are currently looking at. >> >> When you draw each frame (20 times a second), you just use your local >> record of player positions and only update those that moved in the last >> frame. You use a flag in each player record which you reset each frame >> and set when a movement event has occurred. That way, you only have to >> draw an updated player position when they have actually moved. >> >> -- >> Alan Chandlerhttp://www.chandlerfamily.org.uk > > -- Nicolas Trani - R&D Web Engineer Weelya - Improve the web Tel : 04 67 169 778 http://www.weelya.com / http://www.ape-project.org -- You received this message because you are subscribed to the Google Groups "APE Project" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/ape-project?hl=en --- APE Project (Ajax Push Engine) Official website : http://www.ape-project.org/ Git Hub : http://github.com/APE-Project/ To unsubscribe from this group, send email to ape-project+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
