Project Proposal: VolatileServ

[darkprophet]

*** NOTE: This section is for the GTG to post project polls, not for the general community.  We'll let this one stay, but you MUST submit your proposals to the GTG moving forward.  Thank you. ***

Hi all,
This project is dedicated to providing a simpler way for games on all platfroms (Flash, Shockwave, Java..etc) to create and maintain multiplayer games.
It is similar in functionality to ElectroServer

Current Implementation has Swing GUI, Infinite Banning, unbanning.

Furthur features are on the list such as:

• Rooms
  
• Moderator Access
  
• Voting
  
• Banning for certain period of times
  
• Language filtering
  

TCP/IP is the current underlying API, but UDP can be implemented if needed.

It is currently under the BSD License.

[Athomas Goldberg]

Any "no" vote must be accompanied by an explanation. If no explanation for the objection is given by the end of this week, I will go ahead and approve the project.

[kul_th_las]

From the ElectroServer 3 FAQ"

Does ElectroServer 3 support non-Flash applications?
Yes. ElectroServer 3 can connect to any application that has the ability to talk to a socket-server. This includes Java. With ElectroServer 3 you could create some great multiplayer cell phone games!

So, since this thing apparently works with Java apps, then what, if you can be specific, is your motivation to provide this alternative product? Certainly the pricing could be an issue, but they have a totally free version that supports up to 20 players concurrently.

I'd like to vote yes for your project, it sounds interesting, but I don't really understand what it does. Can you be more specific?

Games published by our own members! Check 'em out!

[darkprophet]

money being the highest motivator. 20 concurrent connections are not enough for me personally. I was hoping to provide at least 2000.

Opensource is the next. It seems a shame to have no opensource project like it, as it seems a very lively subject of game servers.

Currently, the only thing the server does is pass messages from one node to all the rest of the nodes without passing the same information back to the node it came from.

Plugin architecture is at the design phase at the moment. But it will accomplish things like message filtering. Message filtering will simply be a class that extends an abstract class (no name yet because its in design) in the actual server. So plugins will be easy to create. Relatively.

Object distribution at initialisation of client (which has just been added to the list) will also be added. This means that you can send objects to the client when he/she has just connected to the server. This can be great for providing violent filtering, maps of cities...etc.

This feature differs from electorserver's "room variables" by providing actual objects rather than variables. ElectroServer will not be able to send maps to clients  connecting to the server.

The server can be a client to another server. This means that you can have many servers running in the "UK" district and still be able to play in the "Londong" area. This provides an easy and scalable way of monitoring how many clients/what map...etc are in each server by obtaining the information from the master server. I believe this feature doesn't exist in electoserver at all.

These are just a few "ideas" i have for this project and will be more than happy to obtain some ideas from the community.

Hope that answers your questions.

[blahblahblahh]

money being the highest motivator. 20 concurrent connections are not enough for me personally. I was hoping to provide at least 2000.

Opensource is the next. It seems a shame to have no opensource project like it, as it seems a very lively subject of game servers.

Depends upon exactly what you want to do, but I think you'll find there are *hundreds* of os projects "like it".

Hard to give an exact comparison, since your later comments seem to be getting a bit of creaping featuritis and diverging from the original quote (just my impression).

Currently, the only thing the server does is pass messages from one node to all the rest of the nodes without passing the same information back to the node it came from.

Plugin architecture is at the design phase at the moment. But it will accomplish things like message filtering. Message filtering will simply be a class that extends an abstract class (no name yet because its in design) in the actual server. So plugins will be easy to create. Relatively.

Object distribution at initialisation of client (which has just been added to the list) will also be added. This means that you can send objects to the client when he/she has just connected to the server. This can be great for providing violent filtering, maps of cities...etc.
...
These are just a few "ideas" i have for this project and will be more than happy to obtain some ideas from the community.

Hope that answers your questions.

I can't see how this is any better than:
- j2ee (has opensource versions)
- Sun's java messaging layer (JMS?)
- opensource projects like Herk's one
- os projects like worldforge
- RMI

(and doing a DOA = dist obj arch is a VERY hard task, unless you're just using CORBA/RMI/etc, in which case what's the point?)

Also, I think if you're attempting something half as ambitious as you suggest, you don't have a hope in hell unless you have some specialists; it sounds like you don't have much experience of multi-tier network systems?

[darkprophet]

no i dont have any experience at all. But thats exactly what id like to gain from this project. And id at least like to try. Id like to get specialist like you blah^3 into it. Its a shame dev.java.net doesn't have something like it.

As for the object distribution, i dont think it will be that difficult as "Altitude" has managed just that.

It will be a nice project and may obtain some nice results.

[blahblahblahh]

no i dont have any experience at all. But thats exactly what id like to gain from this project. And id at least like to try.

Then I'd suggest you are better off starting with something simpler and/or using one of the pre-existing solutions (even better, try several of them) to get a feel for the problems and standard approaches first.

That way, when you come to do your own, you'll have a good idea of how to do it, and you will get more out of it (learn more) in less time (you won't have to start again from scratch because of some fundamental mistake, etc).

Id like to get specialist like you blah^3 into it. Its a shame dev.java.net doesn't have something like it.

Sorry, I'd be unable to get involved.My day job is doing this kind of thing, and a lot of stuff I work on is patented/patent-applied-for; it's very difficult for me to simultaneously work on open-source software without accidentally cross-polluting things and/or revealing information I'm not allowed to .

[darkprophet]

what i currently have is something very simple and very extendable. The extendable thing is whats needs extending (hehehe). The object transfer thing was on the 3.0 release sort of thing. It is planned to be in there, but there is no time scale at all.

What i dont understand is why you are disagreeing with the project. Can you please clarify your point of view for me please?