Alive again!
by Kyle Carter · in General Discussion · 04/24/2004 (10:15 am) · 4 replies
Howdy.
So, as you are all aware, TNL launched at www.opentnl.org/. This means the first step towards getting the community server done - a working, stand alone, cross platform network library - is in place.
So where do we go from here?
I think that we should design and prototype a basic community server - a system with clients, a community server, and a data server. The clients talk to the community server, which does business layer logic, and sends requests to the data server, which enforces permissions, data validity, and actually talks to the database.
We can either roll our own client app, embed into Torque, or embed into Zap. Honestly, I don't know which would be better. I'm leaning towards Zap, because I'm enamored with it, and because it would probably make our resulting community library code cleaner (no temptation or ability to implicitly use functionality that Torque has built in). It would also mean we'd have a fun game built on top of the community system, to test it with. ;)
Oh - Mark is also working on a journaling library, which will be an invaluable tool for debugging the community system. We currently need it for Zap, to track down some frustrating crash bugs; I think that we will want to build it into the commserv as early as possible.
That's about the lay of things. Thoughts, feedback, etc? I'd like to get rolling on this sometime in the next few weeks - probably after we get TSE EA1 out the door.
So, as you are all aware, TNL launched at www.opentnl.org/. This means the first step towards getting the community server done - a working, stand alone, cross platform network library - is in place.
So where do we go from here?
I think that we should design and prototype a basic community server - a system with clients, a community server, and a data server. The clients talk to the community server, which does business layer logic, and sends requests to the data server, which enforces permissions, data validity, and actually talks to the database.
The feature set should be basic. Here's my proposal: - Allow clients to create an account and join the community. - Let clients query list of online users. (Everyone is a buddy for the first pass. ;) - PMs to arbitrary users. - Channel based chat system. (No ops or topics or nick changing.) - Server browser functionality.
We can either roll our own client app, embed into Torque, or embed into Zap. Honestly, I don't know which would be better. I'm leaning towards Zap, because I'm enamored with it, and because it would probably make our resulting community library code cleaner (no temptation or ability to implicitly use functionality that Torque has built in). It would also mean we'd have a fun game built on top of the community system, to test it with. ;)
Oh - Mark is also working on a journaling library, which will be an invaluable tool for debugging the community system. We currently need it for Zap, to track down some frustrating crash bugs; I think that we will want to build it into the commserv as early as possible.
That's about the lay of things. Thoughts, feedback, etc? I'd like to get rolling on this sometime in the next few weeks - probably after we get TSE EA1 out the door.
#2
But a more or less stand alone client solution is prefered, so I dont get trouble with Torque and we can use it in general for all other games.
But as I see it the "only" part that is Torque specific would be the script/gui interfacing with the client library. I'm not a big scripter, but I can put together that part without trouble.
How do we cut the cake with who-does-what?
04/25/2004 (11:56 pm)
I'm all for Torque for purely personal reasons - I need it for my game before long. But I only need the "login" and "save user specific data", not the chat, PM and similar, so if you guys are more for Zap then that would be ok too :-)But a more or less stand alone client solution is prefered, so I dont get trouble with Torque and we can use it in general for all other games.
But as I see it the "only" part that is Torque specific would be the script/gui interfacing with the client library. I'm not a big scripter, but I can put together that part without trouble.
How do we cut the cake with who-does-what?
#3
As for how to dizivvy stuff up... Hmm. I guess it depends on how involved you want to be. I have to ride herd on TSE this week, but I should have some spare time. I was thinking I'd spec out some RPC interfaces for the clients and the data server at some point relatively early on. Just a first pass so we can get some basic functionality going.
I guess beyond that I'm not entirely sure how the cake should be sliced. It almost seems like one person should rough it out, then put it in CVS and open it for everyone to work on. Not sure who that person should be, or if that's a good idea or not. Thoughts?
04/26/2004 (9:50 am)
I'll talk to Mark today, but I think that he'll be cool with using Zap as the test case. I propose we keep everything save the GUI code in its own namespace so we can just drop it in to Zap or other apps.As for how to dizivvy stuff up... Hmm. I guess it depends on how involved you want to be. I have to ride herd on TSE this week, but I should have some spare time. I was thinking I'd spec out some RPC interfaces for the clients and the data server at some point relatively early on. Just a first pass so we can get some basic functionality going.
I guess beyond that I'm not entirely sure how the cake should be sliced. It almost seems like one person should rough it out, then put it in CVS and open it for everyone to work on. Not sure who that person should be, or if that's a good idea or not. Thoughts?
#4
We also have to have Torque support, but it might make it easier for other users of the community system to get a handle on what's going on without extra script calls and so forth.
04/26/2004 (12:54 pm)
I definitely think Zap would be the best first implementation target - since it's already using TNL, and it will allow us to have a path that doesn't require Torque.We also have to have Torque support, but it might make it easier for other users of the community system to get a handle on what's going on without extra script calls and so forth.
Torque Owner Harold "LabRat" Brown