EDIT TO CLEAR THINGS UP: I use the term "area" to mean a square which is part of a grid which controls loading of models on the client side as well as mulitplayer information. I use the term "zone" to indicate a group of "areas" (maybe 9 or 16) which are controlled one a single server and controls only multiplayer data.

I was hoping to get some info on the whole "Zones" system. I understand that this is a relatively new installment to 3dgs and one which many people shrug off as an "impossibility".

Ok let me start by giving you a bit of information about my experience. Apart from my many years experience with Web development and databases I have fairly recently (the last few years) been mucking around with 3d graphics/computer physics and more recently multiplayer games. Also i was around at A4, dropped back in for A6 and have decided to return again to the 3d game scene for A7.

I did have the shell for a 2d mmo about a year ago but i kind of gave up as the whole 2d scene was a waste of time in my opinion. I did NOT however have a very advanced "zone" system. I did have a player that could log on, get his information retrieved from the server and walk around and chat to everyone else.

My "zone" system did work in terms of only loading information about players which where in the same are as you (or adjacent areas) and did NOT send this useless information to people who were outside this range. Also on the client side all information landscape sprites etc were unloaded as the player moved away.

I use the word "areas" instead of "zones" as my areas where rather small, maybe slightly larger then the size of the viewable screen so as to have 9 "areas" loaded at all times. The only problem I can see with using the 3dgs version of "zones" is that if the player wants to have loaded the information of 2 "areas" which cross "zones" (one in one zone and one in the other), or even if the "areas" idea is not implemented, then the clent would have two options:

A: disconnect completely from one and connect the other creating a sort of "loading bar" scenario.
B: Send informaiton to both servers. This is the most desired idea although I am not 100% how well this will work with 3dgs.

Geez, that was a lot

I understand that this isn't going to happen over night but I would like to at least attempt this maybe with some of you guys helping as a learning experience if nothing else.

Thanks,
Alex

P.S. I kind of rambled on a bit but hopefully you can get what I'm at

I'm not really sure what your talking about, but ya zones are possible with 3dgamestudio. And actually they are really easy to impliment if your understand of A7's multiplayer system is pretty solid.

Quote:

---

I understand that this isn't going to happen over night but

---

Well I don't know about you, but for me it actually did happen over night. . Well the code phase did, the hardest part is the planning. Sketch out where all the data is going and what kind of data you will need to send in a notepad. Take the pad with you where ever you go and document it as it comes to you. I sat down at my computer only after that part was finished. The actual programming was very easy once I knew exactly what I wanted to do. In the past I guess the trouble was I didn't know exactly what I wanted to do.

Basically I just want some information on maybe connecting to 2 servers at once. sending my info to one, but receiving from two. I think that is where I am currently stuck

You should seriously look at the GSTnet plugin, when you plan a multiserver approach,
as this dll it not as static as the 3dgs multiplayer architecture.
(and you can also ask the developer about features)

I think the idea of areas in 3dgs is great - i'm working on an "area" being made up of tiles itself, and the tiles are cached locally with a CRC type check of current status for an area.

I'm hoping to get multi-server data streams going too, GSTnet looks pretty nice - although a personal dll to handle the multiple streams in and out may be the way to go for a moderate-m-o-r-p-g as I'm going for.

GSTnet isn't updated yet to A7. Pity, really as I had a go at this sort of thing the other day too. Their site says they were planning to work on the upgrade of the dll to A7 in Feb, so hoping it won't be far off.

Don
have a great day

If I where to plan and make a MMO, I would use Java.
Where the Server is running in Java+SQL, and the client-link is
also Java on the players computer.

Then the java-client is linked with a information pipline to 3dgs,
running as seperate Thread.

This would let me concentrate on developing the Multiplayer components in java, and
the visualizations in 3dgs.

Is that because you've got experience with networking in java, or because it has innate abilities we won't get with port stuff in C?

Don
have a great day

Its just that I know most in Java. Java has a very nice networking engine,
and can be run as server-software on any Linux-server.
You can of course also take the direction with C/C++

I would just seperate the mulsiplayer functionalities from
the visualisation, to use the strenght of java and 3dgs.

Fair enough - For my project I'm still going to set up my project in straight A7 - using GSTnet once updated (soon i hope ) but I'll make sure I abstract the mp layer, so that if it turns into a larger project, I can work on a seperate server / client setup.

Don
have a great day

It could be also possible to write the server in Java,
and directly communicate with the GSTNet plugin via TCP.
For this I would just need to know the network protocols and datastructures used
by GSTNet.
Expanding this to use in Java should not be the problem from the technical side,
although it needs some indepht buildup to have a fluent communication.

3dgs is fine for using it as the displaying client. but as basis for the Server solution it sucks.