Proposed plan of discussion.
Forum rules
This forum houses many years of development, tracing back to some of the earliest posts that exist on the board.
Its current use is for the continued development of the server and game it has always served: TMW Classic.
Proposed plan of discussion.
first, I would like to propose a plan of discussion.
The plan of discussion will addres WHEN specific topics about server development should be discussed.
The product from the plan of discussion would be a hierarchical requirements to be designed.
After the plan of discussion, we can discuss architecture. To stablish how things should work internally (some of this have been done at the wiki). After the architecture, coding conventions and interface standars are stablished, we can go for a roadmap of implemenation.
the roadpam, states what should be done when, the order and must states release versions, the roadmap sould be planned til 4rth version.
When arriving to the 3dr version, the architecture, conventions and interface, must be reviewed to adjust the roadmap, and then again, setup the roadmap til 6th version.
In this way the server development can be done fast, and more accurated.
The plan of discussion will addres WHEN specific topics about server development should be discussed.
The product from the plan of discussion would be a hierarchical requirements to be designed.
After the plan of discussion, we can discuss architecture. To stablish how things should work internally (some of this have been done at the wiki). After the architecture, coding conventions and interface standars are stablished, we can go for a roadmap of implemenation.
the roadpam, states what should be done when, the order and must states release versions, the roadmap sould be planned til 4rth version.
When arriving to the 3dr version, the architecture, conventions and interface, must be reviewed to adjust the roadmap, and then again, setup the roadmap til 6th version.
In this way the server development can be done fast, and more accurated.
May the Source be With You
- biggeruniverse
- Peon
- Posts: 42
- Joined: 17 Sep 2005, 04:33
Ok. That'd be great if there were several committers that could focus on server development, but I don't think that will be the case.
The landscape to me is something more akin to two cities - each with separate leadership.
The client and the server are separate, with separate resources and areas of focus. Although elvenprogrammer is currently presiding over both, I think that development will reach a critical mass where someone else will need to take point on server development. elvenprogrammer would still have final say (thereby retaining project cohesion), but someone else would be handling day-to-day direction (or vice-versa).
The server development will be far more complex than the client, as everything will happen at the server end. The majority of work for TMW devteam is still to come.
So, in short:
1. elven is going to have to call these shots
2. there should to be two camps the work closely, but on separate parts
3. what's wrong with Java (I needed a third point, and I can't think just now)
The landscape to me is something more akin to two cities - each with separate leadership.
The client and the server are separate, with separate resources and areas of focus. Although elvenprogrammer is currently presiding over both, I think that development will reach a critical mass where someone else will need to take point on server development. elvenprogrammer would still have final say (thereby retaining project cohesion), but someone else would be handling day-to-day direction (or vice-versa).
The server development will be far more complex than the client, as everything will happen at the server end. The majority of work for TMW devteam is still to come.
So, in short:
1. elven is going to have to call these shots
2. there should to be two camps the work closely, but on separate parts
3. what's wrong with Java (I needed a third point, and I can't think just now)
We are on the outer reaches of someone else's universe
- ElvenProgrammer
- Founder
- Posts: 2526
- Joined: 13 Apr 2004, 19:11
- Location: Italy
- Contact:
I agree, I agree, I agree. The problem is that we don't have so many programmers. I was thinking that only one will go on with client development (probably me), while the others will work on the server with Bjorn being the head of them. I prefer myself to avoid the server development because I don't want to waste its code which is still clean. As far as new programmers come, I'll assign them where they're required.
Software factory and QA
Okay, here is the deal.
At my job, I have the liberty to pickup a proyect to teach how to work on real development to students. Also, any code generated by them, goes for a QA phase about documentation and testing.
This way, I could get like 3 or 4, even more developers.
What I need, is the requierement list. That?s why I wanted to discuss first the roadmap of development. I recently saw the development roadmap at the wiki, and I?m planning to use it as a start point.
I could post the major units of the server, and Bjorn say yes/no to the proposal.
I?m still working on the disccusion roadmap, since I was quite busy But I exepect to have it this week...
At my job, I have the liberty to pickup a proyect to teach how to work on real development to students. Also, any code generated by them, goes for a QA phase about documentation and testing.
This way, I could get like 3 or 4, even more developers.
What I need, is the requierement list. That?s why I wanted to discuss first the roadmap of development. I recently saw the development roadmap at the wiki, and I?m planning to use it as a start point.
I could post the major units of the server, and Bjorn say yes/no to the proposal.
I?m still working on the disccusion roadmap, since I was quite busy But I exepect to have it this week...
May the Source be With You
there is no way to make use of the specific strengths and weakneses of your target system through the abstraction layer of the JRE as it is possible with a lower level language like C++.
But anyway, the server development has already been started in C++. it would be useless to start from scratch with another programming language now.
But anyway, the server development has already been started in C++. it would be useless to start from scratch with another programming language now.
- Bjørn
- Manasource
- Posts: 1438
- Joined: 09 Dec 2004, 18:50
- Location: North Rhine-Westphalia, Germany
- Contact:
I don't entirely agree and I hope we can kind of make the protocol a standard for which a compatible server could be developed in parallel. I do however think we should focus on making our C++ server usable first.Crush wrote:But anyway, the server development has already been started in C++. it would be useless to start from scratch with another programming language now.
A roadmap ? Good idea !
I really don't want this topic becoming a "Java vs. C++" discussion. I'd prefer having it discussed about the server roadmap. The thing we're missing now for server-assigned devs, is where to begin with.
For now, I think we need basics. Then, I'd say we have concentrate on:
- Login, Register, and basic chat function, which are almost working right between the new client core and the server.
- Also, we should see how to implement things such as client/server disconnections (The actual client doesn't know when the server stops.)
- And maybe for a third, we should make the server SPEAK a little more. The server should say its version, whether he's using a existing database or creating one, the kind of database he's using, and the file used for the db (as for sqlite), etc...
- And as a fourth, basic admin commands are very welcomed, maybe first to repeat these information, and maybe tell more about connected clients, and so on. Also we should see on how we could kick clients or change their stats levels, display them, etc...
Thanks for reading,
For now, I think we need basics. Then, I'd say we have concentrate on:
- Login, Register, and basic chat function, which are almost working right between the new client core and the server.
- Also, we should see how to implement things such as client/server disconnections (The actual client doesn't know when the server stops.)
- And maybe for a third, we should make the server SPEAK a little more. The server should say its version, whether he's using a existing database or creating one, the kind of database he's using, and the file used for the db (as for sqlite), etc...
- And as a fourth, basic admin commands are very welcomed, maybe first to repeat these information, and maybe tell more about connected clients, and so on. Also we should see on how we could kick clients or change their stats levels, display them, etc...
Thanks for reading,
- biggeruniverse
- Peon
- Posts: 42
- Joined: 17 Sep 2005, 04:33
Hi. Yeah, the guest was me. I really should pay attention when posting...
I like Bjørn's idea of creating (and documenting) the full protocol of the server, so that it could be reimplemented by anyone that's crazy enough to do it.
I like Bjørn's idea of creating (and documenting) the full protocol of the server, so that it could be reimplemented by anyone that's crazy enough to do it.
We are on the outer reaches of someone else's universe