Talk:Development Center

From PlasmaWiki

Contents 1 User Features 2 EJB3 3 Groovy 4 JGroups 5 Web Page 'portal' and Client Application 6 Platform Support 7 Documentation and Examples

[edit] User Features

• User profiles (with avatars)
• groups
• friends
• email

Like a mini social network, but this would help you find players of games your interested in. Could also support concept of guilds for players to form.

• User stats
• Ladders
• leagues
• rankings
• point systems

This adds a more global competetive component, hopefully resulting in people playing more. Group/guild rankings - just another way to compete. Rankings/points could be used to unlock game features (this ismore for a game implementation then the framework)

Basically add enough value added features the framework to make players want to use it, even if the game they play can be initiated without it (or with another service like gamespy).(Econn)

These are all really good ideas and should be included. I'm a little unsure about the email since there are tons of email systems out there. However, allowing the user to register thier email and allow users to be updated when information changes that they sign up for is cool. (guurk)

Friends makes sense, and guilds. Groups could be based on which games they have registered and are active, maybe having clans within that space.(guurk)

The second list is cool too, on a per-game basis of course. I suggest that when a game is registered in the system, the registrar can select if they wish the system to support league / ladder play, clans, rankings, points...etc. (guurk)

[edit] EJB3

Implementation: Use EJB3. This will make the framework more generic and more appealing to different people who wish to use it. It should in theory support any EJB3 compliant persistence or app server, but in reality maybe provide config for most common (like jboss and mysql).(Econn)

There is no question about EJB3 :)... that's all I've used professionally for almost 3 years now (yes, beta). No going back...

I figure that jboss and mysql is good to start. If, and I say IF there is enough users to support adds or subscriptions or charge for game registration (small amount) then we can expand hardware. I don't want to make money off of this... I want it to be able to handle itself. The other option is to allow anyone to host a server, then we cluster them all together to handle user growth. Game downloads would be handled by the respective game registrar.

[edit] Groovy

I also suggest adding embedded Groovy ability for some functionality to be scripted by users.

[edit] JGroups

There was also talk about JGroups on the jME forums.(guurk)

[edit] Web Page 'portal' and Client Application

I'd suggest that there would be a web page based entry into the system, but also a client side application for access into the system. This would allow for more flexability. I hate to keep bringing up Steam, but much of what we are talking about is done in Steam from Valve. An Open-Source version of that kind of functionality is simply a good idea, the 'business-model' is already proven.

IT is a good idea, I do not think there is any open source projects like this. The closest ive seen was http://www.threerings.net/code/. They have a game lobby but it does not have all the features here. I played with it a bit but there is a serious lack of documentation. Anyway for web based client it might be worthwhile looking at Grails. I think it now supports ejb3 entities so domain objects could be reused here. --Econn 16:27, 27 September 2006 (MDT)

I have no experience with Grails, however, it looks very interesting.

I also took a look at the threerings.net thing and saw a couple things that look interesting. One espcially being the GetDown application. One the one hand I like the idea. That's exactly what I'd think of doing. However, I figure that an Open Game Network should support more than just java based games. That leads me to the next section.

[edit] Platform Support

Not only should we have a separate client and a web portal entry. But all games should be able to integrate our services into thier applications directly. Thus allowing them to add chatting, game rooms etc. directly into thier runtime games.

As such we shouldn't just support api that works with Java (although a focus there doesn't bother me.)

So, we should look at exposing most, if not all our services in at least 3 different ways:

1. Remote EJB/JMX/JMS
2. Non platform dependant WebServices ergo - SOAP
3. CORBA - Now-a-days exposing your ejb interfaces via Corba is as simple as turning a config switch in an xml file.

This way C++, C#, Java, perl, python... whatever language a game is build in would still be able to use our services.

[edit] Documentation and Examples

In order to actually make a system like this interesting for the Open Source and Garage games crowds we've got to have plenty of documentation on how to interface to our system with tons of examples.

I propose that with each step in a roadmap would include the time it takes to fully document/test and exaple-ize (a word?) every exposed service feature.

I agree here. The best open source project is useless if people cannot figure out how to use it. For examples I thought we could take some existing open source card game(s) and do a tutorial on how to make it work with the framework. Hopefully this would require minimal changes to the game. We might even get help from the games contributors. The other examples would be how to build a networked game using the framework protocol(s) Econn

Here Here! (guurk)