Make MMOLove, not MMOWar.

Posted By: fastlane69

Make MMOLove, not MMOWar. - 08/19/08 22:12

Maybe a fresh start will get us where we want to be. smile


Let's start with a simple question for Conitec:

If almost the entire MP community is telling you the GS Net Engine is useless, then why won't you listen to us?

Why not work WITH us to get a better network for GS instead of AGAINST us in defense of a dead engine in DPLAY?
Posted By: jcl

Re: Make MMOLove, not MMOWar. - 08/20/08 07:26

Originally Posted By: jcl
I've just seen that this thread has grown very long meanwhile. So I apologize that I could not read it in all details. However, I understood that you worked 5 years on an MMOG project that wasn't successful, and you want to communicate that the reason was our engine, resp. some missing features. The main problems that I could extract from your posts were:

- You've heard that the Directplay network library is slow or unreliable, and want another library.
- You want the server to send entity updates only to a subset of clients in its zone.
- You got error messages in your game.
- People told you that you can't do a MMOG with Gamestudio.

Is that a correct summary of your main problems so far?

Please correct me if I'm wrong. Otherwise I'll think about how we can help in your case

When asking questions on this forum, it's helpful when you also read the answers. Either you're having a specific technical problem with your MMOG and are interested in a solution from us, or you are not. Just let me know.

I can understand that when a project is not successful, you want as many people as possible confirming that it was not your fault, but the engine's fault. However, we can only help when you tell us the problems and specify them. So please let me know whether I understood your main problems correctly in my above response, and then we can go forward.
Posted By: EpsiloN

Re: Make MMOLove, not MMOWar. - 08/20/08 09:45

Ok , stop with the arguments...
Lets not focus on who did something wrong or who didnt do something at all.
Conitec assumes that the users cant make their network systems correctly. The users assume that Conitec didnt do the networking part correctly. You're both right.
I can think of 100s of ways to improve my own MMO attempt , wich currently should support between 50 and 100 clients. But , I'm also shure I can think of 100s of ways that Conitec can improve the engine to support more clients. Not only with this encryption (wich I cant use because I'm using A6.4) but also with server to server communication & collaboration on , for example , LAN network and other 'small' features wich can help everybody get to that part...the MMO part.
Cant we just sit down and think together on what is actually the main feature missing in the engine , that Conitec should add ? And , lets leave the users responsibilities aside. Conitec isnt responsible for bad dead-reckoning smile

PS.: Personally , I think , that this Server to server communication is a major feature missing. Yes , you can make it with plugins , but why should users use Acknex if they can use those plugins in other engines ? I'm not offensive right now , I'm just making a point...If Acknex had something like this , or other similar functions , users could use it to get closer to a MMO. There is no point in scripting a whole network system and use it with Acknex if you can use any other engine , or even your own. Conitec can change that by improving Acknexs network system. We all get what we want smile right ?

*EDIT* : I forgot to add...If you cant calculate numbers in your head , people made calculators for you to use...You wont need to learn to calculate huge numbers faster in your head...Same goes here. Not everyone has learned in a school how to make a MMO game. I dont know even the basics in networking...What I've learned , I know from the manual of 3DGS. Do I need to go to a specialised school to learn all that , when an engine can provide me ready to use functions to make a MMO...Everyone should think about that smile and , actually , thats what 3DGS is about. Thats the purpose of having it. Helping users create good games with no knowledge in C++ for example. I'm shure most of the commercial projects here cant be made with the 'lesser' languages out there and C++ would have been required if 3DGS wasnt available...Thats just an example.
Posted By: FBL

Re: Make MMOLove, not MMOWar. - 08/20/08 10:10

Straight to the functionalities:

Not a long list from me, as I haven't dealt at all with MMo, but thopughts that came up and I didn't find a solution without requiring heavy workarounds -> would be fine if they were natively supported

- a lobby system
- "ranged" network functions which only update entities within a definable range on each client to keep traffic to a minimum
Posted By: jigalypuff

Re: Make MMOLove, not MMOWar. - 08/20/08 11:15

a lobby system should be a must for all multi-player games. It is what keeps a gaming comunity alive all games should also be moddable if the publiser wants them to be, but thats a different thing from multiplayer smile
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/20/08 16:32

Quote:
Either you're having a specific technical problem with your MMOG and are interested in a solution from us


The latter. Technical problems with my game are another issue all together which I will address with you privately through consultation.

What I would like is to do is what Firo and Epsilon have done and give our working impressions of what works and what doesn't in the MP engine. Note: this is not a "bug fix" thread, this is an "architecture" thread. The core GS MP Architecture is flawed in my and others opinions and this is what I wish to address.

I'm interested here in talking about solutions to the current MP engine which, as I've stated, most of us feel is a failure.

I'm interested in talking about all the "workarounds" that many of us in the MP community have had to do to create viable MP games and how Conitec can help us to NOT have to workaround.

As Epsilon stated, we should move the discussion towards outlining the current state of the net engine, what works, and what doesn't.

I personally am going to wait to post my issues until others have, like Firo. This way it's not a "one man crusade" but a "community effort".
Posted By: Oxy

Re: Make MMOLove, not MMOWar. - 08/20/08 18:34

I suggest the following to Conitec to cirumvent these kind of Problems:



-Fastlane requires an environment/ client Server communication that deviates from what a newbee to netstuff or a hobby programmer needs.

-The Networking engine is a made to automize a lot of precedures
to create an automatic syncronized 3dgs environment on all clients. The intuition is to have the user make as less as possible to realize a coherent Client-Server enironemnt.
(example: created entities on the server are in the normal case
created n the clients)


Now this is the root of the problems regarding Fastlanes needs,
as he tries to manually switch off or work around the
automatic functions that one step lower (engine) are
build from lower level functionality to help the user.

Bottom Point:

The qutomized functionality that is supposed to ease the development is causing the problems.


The sollution:

Make a pure mode which can be switched on
(pure_networking = on) default off

in this mode, the only things the engine is doing:


-create a serversocket (free choice of the ports) (multiple serversockets if possible)
-create a client"socket", connect to IP+Port manually.

-when connection is established, confirm to client and server.
-client can send only dataarrays to the server
-server can kick the client
-server can send only dataarrays to client (to all clients, a specific client by iD, or a defined clientgroup)
-client and server have to implement their own function to read out or create the dataarrays.
-server can note when client send last data (recognizing broken links)
-server can limit the data received by an client to
x bytes (for example to check login)
-server can block any clientconnection by IP, so any client
from this IP cant open a connection.

-a client can also run as server (using another port)


ALL OTHER FUNCTIONALITIES TURNED OFF.
no entity creation over the net, not check for loaded levels,
etc...


This is basically all fastlane needs.
This is a good raw basis for a user to create his own networking.
So no "workarounds" are needed, just the skill to
handle and create the higher level networking by himself.

This way it would by possible without an external dll
to create a MMO, and using 3dgs' real strenght the visual rendering.
Posted By: TWO

Re: Make MMOLove, not MMOWar. - 08/20/08 18:46

Nonsense. It's already possible to turn off all the stuff. What he's complaining about is the way the BASIC things are working and that no more advanced features are available.
Posted By: Oxy

Re: Make MMOLove, not MMOWar. - 08/20/08 18:51

Dude I know pretty exactly what I talking about.

A when he has a pure networking all following
tasks are up to his skill to implement it himself using Lite-C
..classical programming
Posted By: MrGuest

Re: Make MMOLove, not MMOWar. - 08/20/08 19:08

Originally Posted By: fastlane69
I personally am going to wait to post my issues until others have, like Firo. This way it's not a "one man crusade" but a "community effort".


Oxy, just list your own requirements not others, Fastlane said he was waiting not he needed a puppet to do it for him

Server -> Server (Although this was never given as a feature, a necessity to support MMOs)
Client -> Server communication while in different levels / zones
Client connection which doesn't crash Server if scripts not compatible, should only reject client
Server -> Client File transfer
Client -> Server File transfer (personally i don't need one yet, but in future projects i'm sure to)
Posted By: TWO

Re: Make MMOLove, not MMOWar. - 08/20/08 19:39

This different connection "types" (server -> cl, server -> server) are handled best with a peer architecture. This means that there are only peers which can connect to any other peer. From my experience I know that this makes multi-server system a lot easier ( compared to other solutions like interprocess communication ).
Posted By: EpsiloN

Re: Make MMOLove, not MMOWar. - 08/20/08 20:40

I have no idea what fastlane 'needs' , but I'm not talking about a base to build on to. When I got myself into this , I wanned to create games easely , without knowledge of higher languages. I do not need to learn C++ in order to create a MMO. If I was able to create a MMO networking in C++ I would never use 3DGS. I would work in a team that is capable of providing its own engine & functionalities...Please , talk about features only , because this isnt getting us anywhere.

Another problem I ran into...
BEWARE laugh LONG EXPLANATION
When I needed to update separate clients , I used 3 skills to identify if the particular client has moved. If it had , I updated this clients entity to another client nearby. This works well , but it updates every client to one another , no matter if they moved. If I had to 'mark' that client as 'already updated' , I had to re-set the skills to match the possition. This unfortunately made it impossible for updating to further clients on the list , because it was already marked as 'updated'. The 'workaround' is to define (for 1000 clients...) 1000 arrays with 3000 elements each , to store the possitions relatively to every client. This means that I have to go thru all that data to check if a client has moved , and use around 8 str instructions with execute 3000 times per client for 1000 clients. I dont even dare trying wink
I dont know if this is possible , or even if this procedure already has a name , but I'd like to use something easyer that does the same job someday. If only we could define and call arrays like skills for each entity...
Posted By: PHeMoX

Re: Make MMOLove, not MMOWar. - 08/20/08 23:25

Originally Posted By: Firoball
- a lobby system
- "ranged" network functions which only update entities within a definable range on each client to keep traffic to a minimum


Another vote for the lobby system, showing lists of server is by far the most user friendly solution to joining a multiplayer game. The age of knowing how to find and type in an ip to join is more or less over as far as the mainstream public goes.

Also the problem that clients can connect and crash servers is a huge problem that needs to be addressed. It´s basically a huge security flaw of the multiplayer system if you ask me.

Apart from that, I´d like to see more features optimizing general multiplayer traffic. I would be more specific about what exactly I´d like to see implemented, but I do not know much about multiplayer architecture tricks and how to get it all more optimized in terms of the underlying technical aspects.
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/21/08 00:00

Watching... waiting... and loving what I'm seeing so far!
Posted By: testDummy

Re: Make MMOLove, not MMOWar. - 08/21/08 02:04

Code:
summary attempt:
sources:
http://www.coniserver.net/ubb7/ubbthreads.php?ubb=showflat&Number=222274
http://www.coniserver.net/ubb7/ubbthreads.php?ubb=showflat&Number=222556
fastlane69, Oxy, jcl, and other users

issues:
*DPLAY (!MMOG compatible!?)
	how?
	Directplay network libary is slow or unreliable!?
		references please
*data corruption
	inability to prevent connection and injection of invalid dat
	clients should not crash server
*global entity update
	the server should send updates only to a subset of clients in a zone!?

features!? + corrected issues!?
*client update
	single
	group
	all
*Direct Play (replace)
	with!? (i.e. Raknet, Enet, ...)
*file transfer
	protocol? (i.e. FTP)
*intra-server communication
*lobby system
	list of servers; direct input of ip is dusty
*MySQL integration (native)
*network diagnostics panel (improve)
*pure_networking = on; default = off
	conn establish; confirm for both client and server
	server can kick clients
	server can send only data arrays to client 
		to all clients
		a specific client by id
		a defined client group
	server can notice broken conns for clients (time stamp!?)
		last sent time!?
	server can limit amount of data received by a client to
		n bytes (i.e. to check login)
	server can block any client conn by IP
		no client from IP can conn
		databased!?
	
	client can also run as a server 
	
	all other functionality off
	
	no entity creation over net
	no check for loaded levels
	
	facilitates higher level networking via .dll
*security fixes 
	prevent connection and injection of invalid dat
	clients should not crash server
*web player


Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/21/08 02:27

As soon as we compile a steady list, I'll repost to ask conitec.

Though the fact they moved this to "the future" and not "morbius" is I guess encouraging! smile
Posted By: FBL

Re: Make MMOLove, not MMOWar. - 08/21/08 07:37

Feel happy that it has not been moved to the beginners forum wink
Posted By: flits

Re: Make MMOLove, not MMOWar. - 08/21/08 12:11

i will like to see file transfers
and lobby system
Posted By: PHeMoX

Re: Make MMOLove, not MMOWar. - 08/21/08 16:56

Originally Posted By: fastlane69
As soon as we compile a steady list, I'll repost to ask conitec.

Though the fact they moved this to "the future" and not "morbius" is I guess encouraging! smile


Perhaps just leave it here, as I think Conitec will take this thread very seriously. I just hope they'll get around updating things relatively soon-ish. smile
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/21/08 17:03

Quote:
I think Conitec will take this thread very seriously.


I think I have their attention now, yes.
Hopefully for the last time.

I'm ashamed that I had to get so rough to get some attention but as we see, Conitec doesn't come out of the office unless they see a mob outside with pitchforks and torches... which I think we accomplished.

By the end of today, I will compile all the suggestions in this thread (and others) and in the interest of fairness, post it up as a Poll to see what the community wants most in terms of MP/MMP.
Posted By: Scorpion

Re: Make MMOLove, not MMOWar. - 08/21/08 20:56

When I tried MP-scripting I came to a pointer, where I wanted to send data to all clients, but one. That was not directly possible, so I had to make a workaround (where I couldn't use the dead recogning feature the engine provides as example).

I really support the idea of getting some kind of 'puremode' only with the most basic features, so that you can customize everything as you like it.

Of course it would be also great, if the functions the engine provides could become more 'open', so that you can control the processes, which get automated right now
Posted By: Oxy

Re: Make MMOLove, not MMOWar. - 08/21/08 21:52

A pure Mode is simplest way to externalize the mentioned problems from the engine-core, as then
solutions can be created and discussed by using Lit-C code.

Everything can be tailored.
The limit is then just the boundaries of TCP/Ip, latency and
datavolume.
Its also saver for Conitec, as they cant be blamed for
missing functionality/bugs, when the basic pure-mode function
are implemented properly.

Example: encryption:
When needed the user can create his own encryption of the data
in the ip packges, wich is just basic data-manipulation.

Zone-Servers:
when the engine can open and handle multiple client and server sockets
the zone architecture depends just on the
understanding of the user to open and manage the datatransfer.

File-sharing:
Just write a code, that makes the file into a bytearray,
transfer the data, and recompile the file.

For less skilled users, the networking can work as before,
enabeling them to make simple multiplayer games.


Also: there are tree strategic movement pressure given the tastes of users -
They should be regarded to keep up a weight in the gamedevelopment - Conitec should yield them to keep
their product interesting in the future:

#1 expand to portable platforms (not targeted by 3dgs)
#2 expand to gaming consols (not targeted by 3dgs)
#3 expand to multiuser internet games (this should at least get higher priority)
Posted By: EpsiloN

Re: Make MMOLove, not MMOWar. - 08/22/08 03:51

Your 'logic' says , that you shouldnt use 3DGS , but instead find an engine that doesnt have anything so that you could add everything else yourself...I doubt thats the reason why you use Acknex smile
If Conitec creates the system your talking about , I doubt anyone would use it. If someone has enough experience in this 'field' to make a MMO network system (even a team of people) why should he use 3DGS and not create his own engine or use another ? What is the reason to use the Acknex engine ?
If you could create your own engine , why should you use an existing body of a car , when you can put your own on the market and sell it as original , and not just a modified car ?

Also , if someone can create a MMO network system , I doubt they cant create what youre suggesting. If anyone is capable of creating a whole system like that , why do they need a 'base' to build on to , when they can just start from scratch with their very own plugin that does the same job...
3DGS is a package that makes things easyer...It comes with a MP system , not a C++ compiler to build your own. smile I hope you can understand what I'm trying to say smile
Posted By: FBL

Re: Make MMOLove, not MMOWar. - 08/22/08 07:14

Please stay on topic. Discuss this in the other MP thread. This one is for suggestions.
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/22/08 07:23

Quote:
3DGS is a package that makes things easyer...It comes with a MP system , not a C++ compiler to build your own.


A point that is often missed by commmunity and Conitec alike. If you are going to offer MP, support it... don't just pass it off to DLLs, make incremental updates once a year, or rely on a dead architecture such as the MP FPS DPLAY based model that Conitec's A7 MP follows.

And taking the MP ideal a bit further, if Conitec is going to imply MMOG with their engine, then at least listen and give credence to those of us that are trying to make one so as that together we can make a GS MMOG a possibility for everyone!

Quote:
I hope you can understand what I'm trying to say


Eppy baby, you know I understand. wink You, Firoball, Locoweed, Excessus, and I (am I missing anyone?) are probably the only ones that have seriously thought about these issue, put it to practice, AND made it public within the GS realm.

To rephrase what you said, if I may, what you are talking about is the difference between GS Native and GS Client... the latter means that we aren't really using the GS networking system at all... the former means we rely on it. Huge difference from a design and development perspective.

Conitec, from my POV, should decide to be one or the other!
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/22/08 07:32

Quote:
Please stay on topic. Discuss this in the other MP thread. This one is for suggestions.


Despite my endorsement of Epislon's POV, I agree that we should stay OT and talk about solutions, not problems.

Thanks for keeping us on track, Firo. blush
Posted By: jcl

Re: Make MMOLove, not MMOWar. - 08/22/08 08:03

Please keep in mind that the priority of new functions only depends on you, the users. The more people create MP apps, the faster we'll implement new MP functions. If on the other hand only few people create even small MP apps with the current functions - which may be not the fastest, but which work well - further MP features have not the highest priority. People who can't create working apps with the current version won't have any advantages from new features.
Posted By: Oxy

Re: Make MMOLove, not MMOWar. - 08/22/08 08:41

The amount of Multiplayer apps is a function of both
-the skill/determination od the users
-the functionality of the engine

Right now it suffers both.

Think about that is might be also possible that the
mentioned lack of functionality also made the multiplayer
community not to grow?
Posted By: EpsiloN

Re: Make MMOLove, not MMOWar. - 08/22/08 15:35

So , the list so far (If I remember the other posts smile ) :
- Server to server communication
- Lobby system
- A solution to the problem I described (Unnamed laugh )
- File transfer (Not a priority , IMHO)

Did I miss something ?
Short list , but vital to not only MMO but Multiplayer in general.
Of course , we can all add stuff thats not nececary , so lets focus on what is really needed smile Anyone else ?
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/22/08 17:54

Quote:
The more people create MP apps, the faster we'll implement new MP functions.


Ummmm... no? The way game development works, the more MP functionality an engine has, the more MP developers it will attract... not the other way around. Or is it Conitec's opinion that MP may just be a "passing fad" and thus a waste of time to encourage? crazy

Quote:
If on the other hand only few people create even small MP apps with the current functions - which may be not the fastest, but which work well


As I and others have tried to tell you time and time again... GS MP does not work well.... this is the reason the MP community is so small. The gross security flaw of "create a dummy GS app and crash any GS server" should be enough to prove that point.
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/22/08 18:10

Ok, let's start a list and then I'll poll it! Remember, this is not really about MMOG but about making the engine more MP friendly which in turn will make it easier to make a MMOG (which is still the hardest thing in game development... nothing the engine can do or offer will change that fact)

- Lose DPLAY and go with Raknet, Enet, ???
- Server to server communication
- Lobby system
- Security Fixes (ie: the ability of a dummy GS client to crash ANY GS server)
- File transfer
- Web Player
- Individual Client update
- Better network diagnostic panel
- Native MySQL integration

Anything else, please build on this.

(PS: Stupid question but I'm not seeing the obvious way to create a poll as a new topic)
Posted By: Cipher

Re: Make MMOLove, not MMOWar. - 08/23/08 23:02


" I'm interested in talking about all the "workarounds" that many of us in the MP community have had to do to create viable MP games... As Epsilon stated, we should move the discussion towards outlining the current state of the net engine, what works, and what doesn't. I personally am going to wait to post my issues until others have, like Firo. " -- Fastlane

I would like to hear an outline on the current state of the engine's netcode. Fastlane would you oblige us ? smile

I am considering using A7 for an MMO , after a long absence. I would very much like to hear about the general experiences and approaches used in Acknex to workaround its limits.
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/24/08 16:40

Hey, so how do I make a poll? Still don't see the option for it. frown
Posted By: Lukas

Re: Make MMOLove, not MMOWar. - 08/24/08 17:24

Hmm, you could start a new thread and I, as a moderator, could merge it with this thread wink
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/25/08 03:53

Thank you. But my question is more to the point that I make a new thread and I don't see where I can make a poll...
Posted By: badapple

Re: Make MMOLove, not MMOWar. - 08/25/08 04:38

good question fastlane , before they changed the forum over it was very straight forward but now the option doe s not seem to be there
Posted By: Lukas

Re: Make MMOLove, not MMOWar. - 08/25/08 05:23

Just click at "Poll Manager". It's just above the checkboxes wink
Posted By: badapple

Re: Make MMOLove, not MMOWar. - 08/25/08 06:14

here is what i see just above the checkboxes



what im not seeing is a poll manager

am i wrong?
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/25/08 06:52

Ditto. I see as badapple sees.
Posted By: badapple

Re: Make MMOLove, not MMOWar. - 08/25/08 07:27

ok fastlane i figured it out , at the bottom of the page is a style chooser set it to gamestudio and start a new thread you will see the poll manager


thats not cool though that you have to change styles to get it



Posted By: jcl

Re: Make MMOLove, not MMOWar. - 08/25/08 09:23

Fastlane69: May I just answer on your feature request without waiting for more threads and polls?

- Lose DPLAY and go with Raknet, Enet, ???
Planned, but DPLAY is not the reason of a multiplayer problem. It's not the fasteest, but despite contrary rumors it's reliable. At least the dplay features we use, which are just the basic client/server send and receive functions.

- Server to server communication
Ok. This is one feature that we found does not work with DPLAY, so for this we'd indeed need to switch the library.

- Lobby system
Planned, but a lobby server can be also done with the current functions.

- Security Fixes (ie: the ability of a dummy GS client to crash ANY GS server)
Only in nonencrypted mode. A dummy client can not crash a server when you use encrypted mode for sending. Invalid packets, i.e. packets that don't come from a server or client of your project are then detected.

- File transfer
Planned, but not essential for an MMOG.

- Web Player
Same as above.

- Individual Client update
Ok.

- Better network diagnostic panel
What diagnostics are you missing?

- Native MySQL integration
There are already several DLLs by users for this purpose.

When I extract from the above features those that you probably really need for finishing your MMOG, I'd select a different library, server to server communication, and a client update range. Can you finish your game when you get those three features?

Posted By: Quad

Re: Make MMOLove, not MMOWar. - 08/25/08 10:44

non-moderator users are only able to start polls in Morbius' afaik.
Posted By: badapple

Re: Make MMOLove, not MMOWar. - 08/25/08 11:42

hey your right ! thats an amazing coinsidance when i tested my theory about page style i tested it there by starting a thread but not finishing so it wouldnt show up , so i thought i solved it what are the odds of me going to the only forum it would work
thats freaky
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/25/08 18:19

Thanks for the reply, JCL. I'm happy to have you specific feedback on these issues and your viewpoints on priorities as a way to focus our discussion.

Quote:
Can you finish your game when you get those three features?


I've already programmed a client update (works okay) and I have a (lousy) workaround for the needed server-server communication. However, I can't go commercial, nobody can, while this remains...

"- Security Fixes (ie: the ability of a dummy GS client to crash ANY GS server)"

...and if encryption will fix this, then please, please move encryption up the priority scale to "ULTRA TOP URGENT" because all our MP projects are non-commercial until this is fixed.

Quote:
Planned, but DPLAY is not the reason of a multiplayer problem.


I will argue that Dplay is the problem on these three points:

1) you admit it's not the fastest which with todays advances in network engines, is an understantment. As an example, if it takes dplay 2ms to process a packet that another library process in 1.9ms, that is a HUGE deal for MP and especially MMP games.

2) you admit server-server is not possible with Dplay. We admit that it is critical to a well designed MMP. Thus I argue that Dplay is indeed holding the MMP community from growing. What can we do as developers to convince you as engineers that server-server is indeed a critical feature for the growth of the GS MMP community? I've only been saying this for 4 years after all..

3) From a business perspective, if you are trying to sell your product, be it to an investor or a publisher, they will cringe at the mention of Dplay. Dplay carries a bad reputation in the industry and NO GAMES HAVE BEEN MADE WITH IT IN ABOUT 5 YEARS. Thus keeping it as the frontline GS solution means that any MP/MMP developer is already at a HUGE disadvantage in terms of funding and commercializing their game merely because they are using an outdated and often mocked engine.


As always, I represent the MMP camp and thus do not represent the full MP community. Others should chime in JCL's feedback to get a good view of what the GS MP community needs.
Posted By: FBL

Re: Make MMOLove, not MMOWar. - 08/26/08 06:24

Encryption is in beta:

http://www.conitec.net/beta/dplay_encrypt.htm
Posted By: indiGLOW

Re: Make MMOLove, not MMOWar. - 08/26/08 13:32

I know this might be a little off-topic but:

I see encryption is coming for A7, will this be rolled out to the older A6 or is this security hole only apply to A7? If this security issue is a problem for A6 do I then need to upgrade? This rabbit hole really does run down a long way...

The more I read, the more worried I get frown
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/26/08 18:05

Quote:
will this be rolled out to the older A6 or is this security hole only apply to A7?


As A6 is no longer supported and encryption may very well turn out to be a Lite C feature, I'm guessing you'll have to upgrade as encryption will not make it into A6 (since nothing new will make it into A6).

Which is not a bad thing considering that you get to make and send structs over the network with A7 and integration with other Net Libraries should you choose is more transparent in Lite C than C-Script.
Posted By: indiGLOW

Re: Make MMOLove, not MMOWar. - 08/26/08 18:28

I've not switched bcz I am concerned about the learning curve for A7, considering how long I have been working with A6.

Now it looks like I will have to schedule this upgrade in, thats not to mention the fact that this exploit must have been a threat to A6 and therefore undermined the commercial use of our Pro purchase...

Doesn't seem right to me, but I guess if it's no longer supported there will be no comeback...

It's not like I am having enough problems with Multiplay as it is!

Edit: Maybe someone could look at our code and estimate how long it would take to re-write for A7? Any takers PM me smile
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/26/08 20:18

Going from C-Script A6 to C-Script A7 is trivial. Do not worry about that.

Going from C-Script A6 to Lite-C A7 is more involved, but not a whole rewrite. Merely look at what Conitec says in the manual about the conversion and I think you'll be fine.
Posted By: indiGLOW

Re: Make MMOLove, not MMOWar. - 08/26/08 21:27

Yeah I have done a little digging on this, maybe its not a huge deal. Still no rush for it just yet, until we're further with our own MP development I think A6 will be just fine until then.

Thanks your advice and re-assurance has restored my confidence a little. plus I made some personal progress with our first steps at multiplay support smile

I am looking forward to reading the next response from conitec for future MP functionality and when d_play is changed, what is it changing too?

Very interesting indeed. Thanks again
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 08/27/08 16:22

Quote:
when d_play is changed, what is it changing too?



Uffff... who knows when and who knows into what. First we have to convince Conitec that losing DPlay will bring in more MP business, then we have to convince Conitec that DPlay is the laughing stock of the MP world, and finally we have to convince Conitec of which engine is best.

It's like we have to work hard to make sure that Conitec does the right thing... silly really, but like you, I have too much invested in GS to give up now... especially now that we have Conitec's attention in the matter!
Posted By: jcl

Re: Make MMOLove, not MMOWar. - 08/29/08 09:57

I don't think that changing DPlay to a different library will require modifications in existing projects. Most multiplayer functions will remain unchanged under a different library. The only severe drawback would be that the network simulator (-sim option) won't be supported anymore. The simulator works with DPlay only.
Posted By: indiGLOW

Re: Make MMOLove, not MMOWar. - 08/29/08 13:48

Thanks JCL.

My guess is that the -sim option may be less of a concern with actual live testing being more of an accessible option these days.

Although I couldn't pretend to understand its full use, maybe it's more important than I think? How severe is 'servere'?

Anyway, it's good to here that current projects should not require modification, unless its new functionality that maybe becomes available due to switching libraries.
Posted By: Garrettwademan

Re: Make MMOLove, not MMOWar. - 09/03/08 17:24

I am very pleased at what I am reading. I am also currently trying to create a mmorpg game, and have been since LocoWeed has published his intro to Multi-player. My goal is to have a game that can overall support 500 players over one or several servers. I have spent weeks on tweaking multi-player code to have clients join a server and be totally satisfied with it. I read all over the forums that 99% of MMOg games fail, but I am not giving up. My hope is that with the update of the engine, we will be given more and more commands to help us get to our goal. I for one would like to see more commands implemented into the game engine to support production of games like these.

my request to help me finish my game;
- What others have posted on server to server communication
- Lobby features
- More security
- File transfer function from at least Server to Client or Clients
- Static variables we can adjust to the main script to let us optimize multi-player games.
- Some way clients can create a model on their client machine and have the server know it was created and broadcast and update that entity to other clients. (maybe a command like ent_createClient)
- A way of determining if the packets made it to the client without any loss or distortion, without having to write code to echo back
- An easier way of sending data/file/var to a single client without broadcasting to all clients
- Any other commands to simplify or speed up the communication between Server and clients, for games played over the internet that support more than 8 players.

This would be my request to finish my game. I still won't give up on creating this game, I have faith in Conitec that they will start gearing towards Multi-Player (more than 8 players) friendly support...So count me in Conitec for someone who is creating this type of game.

Extra Note: I know 500 players is not possible or reasonable at this time, and certainly not efficient. The only thing I can do is sit back and wait patiently until there is more support for this.
Posted By: TWO

Re: Make MMOLove, not MMOWar. - 09/03/08 18:19

Originally Posted By: jcl
The only severe drawback would be that the network simulator (-sim option) won't be supported anymore. The simulator works with DPlay only.

http://www.jenkinssoftware.com/raknet/manual/networksimulator.html
http://www.jenkinssoftware.com/raknet/manual/statistics.html
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 09/03/08 19:07

Great find Two!

Neatly answers the question of what better statistics are and allays any fears of the network simulator being exclusive to DPLay. wink
Posted By: HPW

Re: Make MMOLove, not MMOWar. - 09/03/08 20:29

Unity3D also uses Raknet for Networking: http://unity3d.com/support/documentation/Components/net-MasterServerBuild.html
Posted By: jcl

Re: Make MMOLove, not MMOWar. - 09/04/08 11:21

I talked to Raknet this spring and they made us a good offer. But the problem is that switching to Raknet still means you need to pay them license fees when you want to do a small multiplayer app. I'm not sure that this is what the majority of users want. Therefore when we make the change, I tend to use a different library.
Posted By: TWO

Re: Make MMOLove, not MMOWar. - 09/04/08 15:19

RakNet is free for non-commercial usage (which are most of the few mp apps here). And for commercial usage, don't we just have to pay ~100$ ?

http://www.jenkinssoftware.com/raknet/manual/ReplicaManager2Video.html

The only thing I'm concerned of is that it will take a lot of time to expose most of the features to lite-c.
Posted By: Quad

Re: Make MMOLove, not MMOWar. - 09/04/08 18:18

yeah it is 100 to 2000. you choose the price.

a poll could be started with clear explanation(like you need to pay 100$ if you make a commerical game etc.).
Posted By: Oxy

Re: Make MMOLove, not MMOWar. - 09/04/08 18:47

Then the licence to fully use A7 would be split to two
interlectual property owners:
Conitec and the owner of RakNet.

I dont think Conitec wants that to happen.

And seperating Raknet as a supported plugin
would make the multiplayer non functional without it.

A solution would be to operate it by an engine-command either
over dplay or raknet, but that would
just be a lowest common denominator solution.
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 09/04/08 19:22

That is a valid point, JCL. There is the another problem and that is that the license is only for one application. You'd have to pay each time you make a commercial MP game. However...


Counterpoint 1: there have been only 1 or 2 commercial MP projects in the last 5 years AFAIK.
Counterpoint 2: anyone that is making a MP project AND wishes to go commercial should have at least $100 dollars they can earmark towards the license.


I agree that the licensing for Raknet makes it difficult for it to become a community wide, multiple product solution UNLESS Conitec and Raknet make a deal where they bundle the cost of Raknet with the Pro version. However, if you present the MP history of our community to Raknet, I think the case can be made that the entire community would only need a single indy license if you take my meaning. :P

In other words I see nothing wrong with having MP users pay $100 as a minimum to commericalize their game... everyone else can just play around with it for free! cool
Posted By: HPW

Re: Make MMOLove, not MMOWar. - 09/04/08 20:10

Raknet costs "$8,000 - Per-platform Site License" for commercial Developer or $100 for one Application.

@JCL: Do you know another good Network Engine?
Posted By: D3D

Re: Make MMOLove, not MMOWar. - 09/04/08 20:22

Would be a great day if GameStudio used RakNet and I don't even mind to pay $100USD to have all the features in a plugin. Don't want to buy Pro because i'd never make anything commercial with GameStudio, though I can see potential for serious developers if this was a option.

In the meantime i've created my own RakNet plugin that works with Litec, but its just simple from the tutorials and doesn't provide all those neat features. That would take me years learning to get it working. Now that I have read all the MP threads. I do hope some solution will come in the near future. If not for me, at least for people that are using the engine for commercial purpose.
Posted By: Quad

Re: Make MMOLove, not MMOWar. - 09/04/08 22:02

i agree that, if someone ever makes a commerical mp game,they wouldn't mind 100$.

a7 really needs better mp support(and physics).

raknet and a new physics engine will give some more life to a7.(ode is aged,dplay is aged, A7 is aging on this features.)
Posted By: Oxy

Re: Make MMOLove, not MMOWar. - 09/05/08 08:04

RekNet could of course also use price discrimination:

make a special build-in build for 3dgs with limited capabilities.
wich is financed by the purchase of 3dgs. And offer an optional payed licenes / full implementation for
3dgs users, who want to really have
complex multiplayer, and are willing to pay for it.
Posted By: FBL

Re: Make MMOLove, not MMOWar. - 09/05/08 08:26

Add a switch between DPlay and Raknet.
Those who are willing to pay, can use Raknet, for small multiplayer stuff DPlay will do.
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 09/05/08 19:26

So it seems that:

a) The community would not mind the extra $100 to commercialize their Raknet Based projects.

b) The community thinks that there are various business options that Conitec and Raknet can undertake to make it the Net Engine of Choice.

Are there other non-technical issues with RakNet we can expose aside from price and licensing?
Posted By: Joozey

Re: Make MMOLove, not MMOWar. - 09/05/08 23:53

Not such a showstopper, but I found it remarkable that there is only one Raknet support room on the IRC network, featuring 6 people total. For normal software products I wouldn't be surprised, but raknet is a developper tool, which made me wonder a little.

Anyway, I love having the option to go for professional multiplayer at any time, if I can pay the costs when I want to do so, and not integrate the costs in any future 3dgs editions, forcing me to pay for an option which I will not use (yet). But I trust that this is a thing I do not have to worry about smile.
Posted By: Joozey

Re: Make MMOLove, not MMOWar. - 09/06/08 01:19

I did some more research for other solutions, but the results are not plenty. I have little experience with massive multiplayer development and it's requirements, so I just listed everything I found worthy showing. (Yes, 3 results and 33% plausible for usage laugh ).


Some products I think are not up for the task:

http://opensource.linuxgamepublishing.com/grapple.php
Although it sounds better than 3dgs's current functionality, it's somewhat too basic. (the readme has more specific descriptions).

http://enet.bespin.org/
Well, it's actualy already saying so on the main page.


One hidden gem that may be up for it:

http://jcatki.no-ip.org:8080/SDL_net/
http://www.libsdl.org/
SDL_Net I got recommended by a MMORPG developper that wrote an interesting article about MMOG's on devmaster. This solution is not as big as raknet either, but it's clearly capable of handling a mmorpg.

Article: http://www.devmaster.net/articles/building-mmorpg/
Note that he also recommends Directplay, this either means some people here are wrong, or he is wrong. But he proved his point already by succesfully creating a mmorpg. Although not with dplay, I expect from him to know what he is talking about.

Game in dev: http://www.eternal-lands.com/
Players online: http://game.eternal-lands.com/online_players.htm
That made me quite exciting indeed, and the article was a good read.
Another note: There is a big community for SDL (as well on IRC), which is a big plus for me ^^.

It doesn't look as professional as Ragnet, but I think it could be a good alternative, especially for beginners as there is alot of support and tutorials.
Posted By: TWO

Re: Make MMOLove, not MMOWar. - 09/06/08 08:44

Ra_k_net!

Keep in mind that there's only 1 man behind RakNet. Though he supports his customers in his forum (daily answers, other users help you too) and over icq. So even as a non-commercial dev you get pretty fast and good support. Also, the manual covers all of the code, plus he has video tuts to help the beginners.


*coffee*
Posted By: Tobias

Re: Make MMOLove, not MMOWar. - 09/06/08 12:26

How about Enet, I found that recommended on many websites and it seems fast and stable:

http://enet.bespin.org/

When A7 anyway only uses the basic network functions, and uses its own encryption and server handling, it makes no sense to let us pay for Raknet when Enet can do the same.
Posted By: Joozey

Re: Make MMOLove, not MMOWar. - 09/06/08 12:40

Well, like I said is what the first page says:
Quote:
ENet is NOT intended to be a general purpose high level networking library that handles authentication, lobbying, server discovery, compression, encryption and other high level, often application level or dependent tasks.

That's why I think it's not suitable.
Posted By: Excessus

Re: Make MMOLove, not MMOWar. - 09/06/08 20:28

Hello there 3dgs community. Long time no post from me, I've been busy with other projects smile I really don't have the time to read this entire thread, but I just want to comment on some things. Forgive me if this has been said before.

Quote:
- Security Fixes (ie: the ability of a dummy GS client to crash ANY GS server)
Only in nonencrypted mode. A dummy client can not crash a server when you use encrypted mode for sending. Invalid packets, i.e. packets that don't come from a server or client of your project are then detected.

That's right, but for performance reasons you don't want to encrypt everything. So I consider this problem not solved. It is very important to note that switching to another library in the way that jcl envisions is not a solution either. The problem (as I mentioned several years ago when I found this flaw) is at the core of the 3dgs network architecture; if you use another network library to implement the functionality of "updating variables by index", you'll still have the same problem.

The only way to fix it "properly" is to break with the current 3dgs MP programming model. Something I don't think conitec would like to or should do (from a commercial perspective, not a software engineering one). The current model is pretty good for newbies (although it does regularly lead to confusion). What I propose is that conitec or an independent company/contractor develops a plugin binding RakNet, but with a new (well thought out) programming interface that is more suitable for large scale multiplayer games. This way you won't have issues with backwards compatibility and avoid licensing issues with RakNet (conitec only distributes a binding plugin, RakNet dll must be gotten from jenkins software).

Such a plugin should use the more traditional programming model where the user sends "packets" and not "variables". Packets can be inspected by user code upon receiving them (to check what kind of packet it is, and then to see if it is within the range of allowable values). Basicly just stay close to RakNet's interface by writing a thin C-style layer over the C++ RakNet library. I have written such a plugin and it works well but unfortunately I am not allowed to distribute it.
Posted By: Oxy

Re: Make MMOLove, not MMOWar. - 09/06/08 21:37

like I stated ealier, make a "pure mode" low level
networking mode,
that concentrates on transmitting raw data
from A to B.

The rest is up to the user the program the functions to use it.

the whole 3dgs multiplayer concept
(entities updates by the server, all running in
a certain "level") is the problem.
Posted By: Tobias

Re: Make MMOLove, not MMOWar. - 09/07/08 06:40

The MP concept is not the problem. You need not use it, if you want not to send variable or entity updates, just send packets and dont send variables and switch off entity updates. But for beginners starting with MP, the concept is good.

I think what's lacking was encryption/security that seems implemented now, and then server to server communication. Updating only clients in range is not necessary I think because I'm with Excessus here, this can be programmed by the user.
Posted By: FBL

Re: Make MMOLove, not MMOWar. - 09/07/08 11:54

When disabling automatic updates you'll run into problems when new clients join.
The entities won't be updated correctly leading to weird results.
To overcome this you either need to workaround a lot or enable automatic updating for a short time so the model file and the like are adapted. After a few waits, disable all automatic updating again. This was my approach for the last time I tested MP.

It would be nice to have another implementation which takes care of removing disconnected client player entities and initially updates player entities of newly joined clients (even when further automatic updating is disabled) without having to fiddle around with such tricks and workarounds.
Posted By: Tobias

Re: Make MMOLove, not MMOWar. - 09/07/08 17:46

It already takes care of that, or so I think, with the join and leave event of clients.
Posted By: FBL

Re: Make MMOLove, not MMOWar. - 09/07/08 18:58

It does - but you have to turn on automatic updates.
That's annoying if you only want to have things updated automatically upon join/leave (you have to take care of that on all connected clients, otherwise you could jsut use connect/disconnect events)) but want to do the cyclic updates manually.

If you don't believe me - try it out.
Posted By: jcl

Re: Make MMOLove, not MMOWar. - 09/08/08 07:05

We can implement a flag for activating entity updates only when a client joins. I'll add that to my list. However, when you update entities anyway by script, why don't you do that with the same script when a client joins?
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 09/08/08 08:29

JCL is right.

If you have a system that selective update clients, we have found that it's easier to "link" the join/update procedure with this selective update.

In other words, a client is going to get updated on what other users are close to it's avatar. Upon joining, the only user close to itself is itself... so we do a self-update. After this, this self-update continues to work (with less information) until we meet another person at which point this update is now sending two pieces of information: your updates and the person in range of you. As you can see, the join event should be no different than the update event except for whatever extra information is needed at login on the client.

Hence the solution (once again) is to either re-write the GS Network Architecture such that selective updating is natural and login is taken care of that way
or
not use GS Architecture at all and make it part of your selective update routine like we have.
Posted By: MMike

Re: Make MMOLove, not MMOWar. - 09/08/08 09:43

A dll plugin would be great, sorry if im spamming but we need this mmog thing and i need too, and my knowledge in making plugins is low, and gs should support mmog
Posted By: FBL

Re: Make MMOLove, not MMOWar. - 09/08/08 11:19

Originally Posted By: jcl
We can implement a flag for activating entity updates only when a client joins. I'll add that to my list. However, when you update entities anyway by script, why don't you do that with the same script when a client joins?


When a player joins I want it to be fully updated (so to say initialized) on ALL machines. That's mainly visual things like the model itself, its scale, the skin....
Of course I can code this and do an update for every single entity parameter - but it's so much easier to have this done automatically if desired.
So my workarund was to activate automatic updates (reseting NOSEND) for a short period after a client joined and once everysthing is initialized, switch over to manual updating.

The cyclical updates in my case are kept to a minimum. Mainly only keystroke information, movement stuff, entity status mode (used for animation and certain entity events). Things like animation (generally visual things) are done by each machine itself without transfering such information between server/client to keep traffic low. At least low enough for like 4 players via ISDN connection - since I'm not working on a MMOG no distance dependent update and other thigns are required.



Summarizing: This is not a blocking point, it's just a matter of easy use wink
Posted By: PHeMoX

Re: Make MMOLove, not MMOWar. - 09/09/08 19:22

Originally Posted By: jcl
I talked to Raknet this spring and they made us a good offer. But the problem is that switching to Raknet still means you need to pay them license fees when you want to do a small multiplayer app. I'm not sure that this is what the majority of users want. Therefore when we make the change, I tend to use a different library.


I think it would not a bad idea to go with RakNet as it seems to be quite good, but to be honest.. I would rather not have to pay a separate fee just so I can release my MP projects.

Anyways, if all this is going to change, I'll definitely buy A7 asap.
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 09/09/08 19:24

JCL,

Can we set up a poll on the issue of paying for commercialization with RAknet?

If the only reason to not use RakNet is because of the licensing fee, I would like to see for how many people this would be an issue. A poll asking this question could remove this as a potential barrier to integrating raknet into the engine.
Posted By: Quad

Re: Make MMOLove, not MMOWar. - 09/09/08 23:13

Yes, I already offered to start a poll. A poll that pointing out non-commerical usage is free and license fee is $100 can be started.

Non-commerical usage is already free.And if someone wants to go commerical, $100 should not be problem.(id rather paying $100 for raknet instead of going commerical with dplay.)

and lobby system,auto patcher,security,Voice communication, far better MMO capability than play. I could pay more than $100(you know, you pick the price) for such robust library if i ever do something commerical.

check the class/function list on the raknet manual, such funcs. exist:
RakNet::ClanJoinInvitationAccepted_Notification

nearly everything needed for a mp game.
Posted By: jcl

Re: Make MMOLove, not MMOWar. - 09/10/08 08:49

Polls are unnecessary for feature request. I've understood that problem anyway.

We can't require from our users to pay additional license fees for multiplayer applications. On the other hand, I also see the demand for advanced multiplayer features, such as voice communication which is not offered by lean free libraries such as ENET.

At the moment we tend to a solution like an open library interface that allows end users to implement their own mp library and override the engine mp functions. We're also thinking over a similar approach for a physics engine.
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 09/10/08 10:05

Quote:
But the problem is that switching to Raknet still means you need to pay them license fees when you want to do a small multiplayer app. I'm not sure that this is what the majority of users want.


Quote:
We can't require from our users to pay additional license fees for multiplayer applications.


I'm confused. Your first quote makes it sound like if the majority of users wanted to pay the license fee, then it wouldn't be a problem to integrate raknet. Your second quote however makes it sound like RakNet is completely out of the question.

Which one is it?
Posted By: jcl

Re: Make MMOLove, not MMOWar. - 09/10/08 10:31

Neither. A Raknet option is not completely out of the question, but basic multiplayer must work without additional license fees.
Posted By: FBL

Re: Make MMOLove, not MMOWar. - 09/10/08 13:13

Originally Posted By: Firoball
Add a switch between DPlay and Raknet.
Those who are willing to pay, can use Raknet, for small multiplayer stuff DPlay will do.


bump wink
Posted By: fastlane69

Re: Make MMOLove, not MMOWar. - 09/10/08 16:16

Quote:
A Raknet option is not completely out of the question, but basic multiplayer must work without additional license fees.


GS integrated RakNet would still "work" without additional licenses. The license fee is not required to develop games with RakNet, only to commercialization that requires license fees.-- which very few GS MP developers engage in though ideally more will when the GS Network is updated. And IMO, we of the MP community are very clearly comfortable with this scheme!
Posted By: JibbSmart

Re: Make MMOLove, not MMOWar. - 09/15/08 01:49

Quote:
At the moment we tend to a solution like an open library interface that allows end users to implement their own mp library and override the engine mp functions. We're also thinking over a similar approach for a physics engine.
laugh laugh laugh

both of those sound very, very tasty. especially the physics part. but the multiplayer part sounds just as useful in future (for me. at present for others, i'm sure).

julz
Posted By: Carlos3DGS

Re: Make MMOLove, not MMOWar. - 10/06/08 17:25

Originally Posted By: jcl

- Native MySQL integration
There are already several DLLs by users for this purpose.


Where can I find them?

(just in case: I'm using A7)
Posted By: Carlos3DGS

Re: Make MMOLove, not MMOWar. - 10/06/08 18:47


We are just starting our project and I must admit I was very concerned after reading through many threads on 3DGS's multiplayer capabilities in the forums (especially with the security issues). After some talk we have discarded our mmo project temporarily until these issues are fixed and decided to completely rip out any multiplayer capabilities from our project.
We too believed this development tool was mmo capable from what we read on the web page and were shocked when we discovered otherwise on the forums. This thread does give us some faith in conitec and we sincerely hope all these problems will be taken seriously and issues solved in an upcoming patch or release.
Unfortunately we cannot delay the project a couple of months beond our schedule to develop plugins, dlls, or fixes for this engine. Luckily we have discovered these problems here in the forums during our first month of development so our entire project is not canceled, only we are discussing to temporarily "transform" it into a single player project while these issues are being adressed. We hope to get what we believe we paid for soon, to be able to develop a "second title" an "online version of our game 2" in the near future.


As for all that has been said in this thread:

1- We personally wouldn't mind paying a raknet license for our mmog.

2- Any help from the multiplayer community would be greatly apreciated if you had any dll plugins for Enet or Raknet we could use in order to continue on the original concept of this project.
Posted By: Oxy

Re: Make MMOLove, not MMOWar. - 10/06/08 19:00

GSTNet (nfs42) would be the next best partner to contact, if you
look for a serious workaround.
Its the next best 3dgs multiplayer sollution.
Maybe you can discuss custom dll issues with him,

populace is another multiplayer project you can
look into.
Posted By: Carlos3DGS

Re: Make MMOLove, not MMOWar. - 10/08/08 11:11

Populace was the first solution that caught my eye. But on their website it says 32 players, which is not the limit needed for this mmo. Also in its specifications it does not state mutiple zones (levels) are supported.
Any other ideas would be welcome (preferably in private messages to not off-topic this thread).
Posted By: Oxy

Re: Make MMOLove, not MMOWar. - 10/08/08 15:00

Another network communication dll is peacemakers? http plugin.

works for A6, not shure if it works for A7.

You can send rewuest data to an http server and receive the response.

(this is very much on topic by the way)
Posted By: Carlos3DGS

Re: Make MMOLove, not MMOWar. - 10/09/08 12:58

Going to take a look at Gstnet and Peacemaker to see what possibilities they can offer.
Thanks for the info, greatly apreciated.
Posted By: Carlos3DGS

Re: Make MMOLove, not MMOWar. - 10/13/08 08:33

Took a look at GSTnet and on their website it states only 16 players are supported by it, so im looking for a different solution
Posted By: Carlos3DGS

Re: Make MMOLove, not MMOWar. - 10/16/08 12:08

Any other suggestions?
Posted By: nfs42

Re: Make MMOLove, not MMOWar. - 10/28/08 20:30

16 clients restriction is only due to my test possibilities.
real restrictions came from used hardware, u/d bandwidth
theoretically there is an internal restriction atm of 999 global entities ;-)
© 2024 lite-C Forums