Design Document

#1 Looks good for a start. How about putting this into CVS (if its not there already)?

A few questions and comments.

IMHO one of the big problems with Tribes 2 ingame community was, that it was self containing. Meaning no integration to anything at all except its own little world mimicking existing services (email, webbrowser, icq).

When I read the above document I could be a little scared that we will make the same mistake.

"IRC-style chat" - why not make it IRC with our own pretty client on top? Again a T2 example from my RL - every single european competitive T2 clan has channels on QuakeNet. It would have been great if the T2 ingame chat client simply was another client connecting to Quakenet.

We need the "RL" IRC server connection as recruitment for clans is impossible from within the game client (hard to connect to the channel if you dont own the game yet)

Our task in this would then be to hide all IRC technicalities away, and code an easy to use client where you dont have to think about servers, bots or other similar stuff. Just click the "go to clan X channel" and it connects to that server and joins the channel set by the clan admins.

We (GG) could then host some forums for the hosted community serveron the IRC server, and if someone buys our system, they could set up their own irc server - or simply use an existing network.

Same goes for "email" or "browsing" (if we want something like that at all). Lets use smtp and http - hopefully with LPGL (or similar commercially exploitable licenses) clients we can use as basis.

#2 Ok, it's in CVS now.

Well, Tribes2's community stuff was actually implemented on IRC like you describe... :)

The reason we're not doing what you describe is because IRC is not as scalable as Torque's networking technology, and one of the goals of the project is to make a community system that can scale into the millions of users on commodity hardware.

I do agree that the self-containing nature of Tribes2's community system is something we should try to mitigate. Although I don't think we can make it as pervasive as IRC right off the bot, I do think we can take steps to make it easier for people "outside" the system to talk to people "inside" the system.

There are a few parts of that already in the design doc. For instance, having gaim and trillian plugins will let people participate without being in game; the same can be done with the XMLRPC interface, for things like forums. Releasing a decent standalone client that just did community stuff would be a wise decision as well.

I think it's for the managers of the community system to determine what the criteria are for membership. I would lean towards needing a cd key to get in, but that's just my opinion, and easily to make configurable. If we had a GG community system set up, requiring a valid ignition key would be a good basis for account registration.

#3 Implementing on top of IRC brings in a host of undesirable problems - I spent months trying to make the PTLink IRC server work properly as the T2 community system, and it never really worked the way I wanted it to. There are a lot of things IRC doesn't handle well, like authenticated login, names with nonstandard characters, arbitrary binary messages. Also, IRC doesn't scale well in terms of message traffic, and because it's based on TCP, it's hard to configure backend servers to properly handle large numbers of connected clients.

What I'd like to see eventually out of this project is a spin-off that would be a standalone community system client - a combination between chat, an IM, and a community browser. It could be sort of a free "viral" vector for publicizing the community system, and getting new users for GG titles.

We're going to have to have some notion within the system of "communities" that users can join - if, for instance, a user has purchased more than one game or product.

#4 Another thing...

supposing we added support for emails or the like, we could (fairly) easily add a smtp->CS bridge, and let clients connect to the system using regular email clients, but with the added benefit that all logins would be authenticated, and no out-of-system emails could make it in. Just a thought.

#5 Okie dokie

Personally I think we are making somewhet of a mistake. We are reinventing the wheel and coding everything ourselves "because everything else is not good enough for us".

Its the classical "not invented here" syndrom, and I'm afraid we are going to end up in a situation with several half baked solutions.

I'm not saying that we cant do it - everything is possible - but we are 4 guys with RL and other projects. If we are ever to succeed, we can do 2 things imho:

* Create a long term roadmap where we take things a step at a time, release often with small pieces of the functionality implemented
* Base it all on existing protocols/servers/api/libs/code, so we dont have to recode everything from the nuts and bolts

I follow you on the commercial side. It would be nice to be able to fully control all aspects of registration and membership. But I do think we can make this without recoding several existing network functionalities.

I can see that its the same principle the GG site is running on. But it also gives some obvious problems with manpower - e.g. the search engine on the forums. It works sort of, but is not what ppl expect from a search engine, and it seems GG has no time to fix it. We will end up in the same situation is my nagging thought.

So I would propose that we keep the goal in mind, create a long term roadmap with all these things laid out, and a release plan. E.g.

Version 0: Net framework working (internal release)
Version 1: Master server functionality (first public release)
Version 2: Authentication and registration (second release)
Version 3: Persistant storage for arbitrary (game related) user data
.
.
Version n: Internal "IRC" system
Version n+1: Internal "email" system

This gives us feedback from what customers want, so we can adjust things. And we dont try to create a monster of a codebase in the first try, but capitalize early from the investment.

(This might all be how you planned it already, but thats not what I'm hearing)

Maybe a meeting to discuss this?

#6 Just to toss my $1.50 into the discussion :)

Until the system can provide more then a master server with authenticated accounts... it's not going to have any selling power due to the current freely available resources. That's just a simple truth

Can this be built overnight by the 4 of us factoring in RL commitments... No, but I bet it can be done in a fairly reasonable timeframe if a few things are taken into consideration.

The client side scripts will most likely be event driven, so prototyping services on a TCP connection and using the TCPObject to provide a backend emulation layer is possible. It's not a perfect method, but as long as the event model is consistent and designed beforehand it will be workable.

As for the order of implementation I'd go for Profiles, E-Mail, Chat, Forums, and Community tools as the progression. My reasoning for the order is that each one builds on the last and each one will add another layer of complexity over the previous.

Some things I can think of that would be nice to have fairly quickly to make some of these things easier / prettier:

1. An array control with column and row headers and hidden row ID field that can be sorted
2. Binary file transfer (images) both up and down

As for what the customer wants.... Would that be the Developers who will be adding this to their game... or the gamers who will be using this in the games it is added too?

People are strange... The RSS news viewer resource I posted was something I worked on over a couple days simply because I was bored... There are at least 3 in-development games adding it in.

I've got a POP3 Mail reader written in TorqueScript I'm half tempted to post as a resource one of these days.

#7 @Thomas - you read my mind. I was just thinking about posting a roadmap...

On more general philisophical grounds, we're recreating some wheels here because we have a new and superior technology to work with. This project is predicated on two things - the need for an integrated community system in games, and the presence of a dramatically superior networking technology. We need to reuse existing technology as much as possible, though.

Basically, as far as a roadmap goes, I think we can go...

Stage 1: Basic network infrastructure. (This is done; adaptive rate, efficient posting of the same event to MANY users, a basic login process, etc. etc.)
Stage 2: Master server reimplementation. (Work was started on this over the summer.)
Stage 3: Basic IM and chat functionality (ie, an IRC clone).

... from that point we need to fit in getting clustering working, bots, profiles, and so forth; I think we'll have to plan things out when we get into Stage 3, though, and can see the lay of the land.

A meeting would be a great idea. Perhaps early next week? I'm dead from tests till then.

Things I don't think we want in the core community system: forums, e-mail-a-likes, web-a-likes. There are already good and sufficient implementations of such systems out there, and I think we'd do ourselves a disservice to add them early on or as a core feature. I think that we can easy add them through the data layer if we want them; the problem is that Torque is not an optimal presentation layer for that sort of content.

We're building a highly scalable chat and IM infrastructure. As a side effect, we can expose database services to clients, do bots, and so forth. But to go down the road of providing mail, forums, file serving, etc. at this stage would be a mistake.

-------

@Harold: You're spot on as far as commercial viability goes.

I'm going to address some of your other comments in another thread.

Our customers are the developers who add this to their game. Their customers are the gamers who will use it. I make the distinction between "customers" and "users" to distinguish; it's not the best but it works. :)

Stuff like the RSS viewer are great "bang for the buck" resources, and I think that we can get this to be much the same; add a lot of whizbang features to your game with minimal investment.

#8 ___________

#9 I've got a new build of the design doc in CVS.