Menu
▾
▴
RE: [Myrpg-development] Some thoughts about architecture
|
From: <lle...@fi...> - 2002-04-02 10:16:59
|
Hi Alexey, I'm happy to see a message from you here ;) > > Hi! > > One of the main points we should clear from the very beginning is > the overall system architecture. There are a lot of nodes that should > interact with each other in some way. And also we have a lot of > factors that should influence the decision like Internet environment > (firewalls, bottlenecks etc), extensibility potential (supporting > mobile phones, PDAs, 3D acceleration in the future), AI and game > engine, synchronization and replication issues. Agree with you, the Internet environment is certainly the biggest constraint for this project. > I've started to work in this direction and I think that I should > publish some thoughts for public discussion. I ask you to join and > give your ideas as it's one of the most important points now. No problem for that. For the ones who might need some explanations about what is being written here, we are there to give you answers. > > 1. Synchronization and replication of data. > > It is evident that we should limit amount of data transferred > between servers as much as possible. I've had a talk with our lead > analyst on this topic and he had proposed an elegant and well-known > solution. > We should divide all the events in the world in two major > types: global and local. Global solutions are those those that > impact most part of the slave servers at once. For example: new > quest announcement. Local ones influence only small number of > servers. When something happens between some servers it can be said > that a link was established between their sub-worlds. > Number of local events sent should greatly exceed number of > global events. This way we will be able to reduce amount of data > transferred. Indeed, it's the reason why we choose to put more than one server for a world :) To part the amount of work... > One of the implementation could be asynchronous JMS messages. > > Each client should be simultaneously connected only to one slave > server. When any event happens on the server it should > asynchronously notify all of it's clients. I don't think that JMS > will suite here well because it's a server-side and heavy > technology. Maybe some king of lightweight peer-to-peer > communication (JXTA, Jini) would fit well? > What's your opinion? Yes, I thought too about JMS messages. For those who don't know, JMS messages can be seen as "events sent to the server" - for example: the monster #1452 has been killed by the character #4589 => increase the experience of this character... But this solution can only stands for Client To Server events. The other process Server To Client may be implemented by other ways: sockets (but too heavy and not request oriented), server-events pooling (the client ask for new events every seconds)... After some researchs, I think JXTA (http://java.sun.com/features/2001/04/jxta.html) can handle this since it provides some interesting services (Peer to peer implementations...). > > > 2. Internet environment. > > Due to firewall restrictions I don't think that we'll be able to > use pure JMS or synchronous EJB calls. One of the solutions is to > use SOAP/WebServices but it's quite slow :(. > What do you think about it? I've had look at this and here are my answers: EJB calls are done through the JNDI implementation (tell me if I'm wrong). The calls are serialized thus the call can be send on a network on a predefined port (modifiable). If a firewall is present between a server and a client, then there is generally only the port 80 (HTTP) that remains open thus the call through the JNDI port failed BUT the JNDI implementation resend the call by using HTTP-tunneling (transform the EJB call into an HTTP request). This solution is slower than a standard EJB call but works :) In counter part, some process don't happen (callback, Exception are not thrown...) So that's not the solution since the result are not well known (I think) and they depends from the network architecture. SOAP is slow, every one know that but we can count on it since the project'll not be rock stable in 2 weeks... Perhaps the network bandwidth will grow up... (Let me dream...) I found an interesting product: WASP (http://www.systinet.com/products/wasp_lite/), one can look at it, it's free. So, though this point can bring problems, I think of it as a layer that can be inserted when we'll need it. > > > 3. Game engine. > > Most advanced gaming engines now support some kind of scripting > language. This allows to extend the game as far as you wish. I > think that we should also take a scripting engine and built it in. > In such case we will write the game engine and server-side > infrastructure using Java and the rest will be written the script. > We could use JPython for instance. > > The extensibility can be also achieved using interfaces and > pluggable modules. It would have a speed advantage but as for me > it's less flexible. > Also I think that AI routines should be written using scripting > language in any case allowing the users to customize their beasts > :). > > What type seems better for you? How much extensible the game > should be? Hmmm, totally agree, a script language would give to the game a great extensible/flexible status. JPython can surely be what we'll use, does anyone know anything like JPython? > > 4. Non-PC devices. > > The future for mobile devices. Everybody says that :). > I think that we should also take into account future support for > cellulars and PDAs with J2ME installed. > What do you think? Hmmm, why not, one could then take part to the adventure in the bus... ;) I think about the little game given with the PC version of final fantasy VIII. A chocobo game in 2 black and white in a small screen rezolution, the items we could found in this game could be used in the final fantasy game: - chocobo game: 100x100, 2 colors, found items - final fantasy game: 640x480, 16M colors, use items found in the tiny game > > Ooh! I'm a little bit tired. Quite a long letter for me :) ;) but very very interesting! thanks > > Waiting for your response. Please answer if you have something to > say about the questions above. > > P.S. I've drawn simple deployment diagram and published it. If you're > interested take a look at it. Soon I'll check it into project's CVS in > Together ControlCenter format. Okay, no problem, the deployment diagram is available here: http://sourceforge.net/docman/display_doc.php?docid=10405&group_id=45052 It's interesting to see that the master server don't manage any part of the world. Don't you think it can handle this too? > > -- > Best regards, > Alexey Maslov mailto:mas...@ma... > > Best regards to you Alexey :) > > _______________________________________________ > Myrpg-development mailing list > Myr...@li... > https://lists.sourceforge.net/lists/listinfo/myrpg-development |
