 |
| |
|
|
Asmodean
|
 |
Aarhus, Denmark
Aug 1999
time: 06:31
|
|
I have started this thread to counter what I am starting to see here. Namely a bunch of guys starting to make changes, without coordination, and seemingly without access to eachother's documentation.
Now I'll start by saying that I am not a coder, so I won't get into the technical details of this. But care has to be taken somehow that this doesn't get jumbled all from the start.
An online version of VSS would be great, but since we don't have that, and since we don't have access to any other common network than the internet, let's start there. Apolyton.
Let's set up organized thread to
1) Document the changes that are made
2) upload the files that are changed
3) Discuss which of these files go into the Apolyton project, and why
Now there are at least 4 different copiled version out there, all not the same. Do we go with one of these, or do we combine them, taking the best from each. If the Apolyton project is ever to amount to something, coders need to work with the same set of source files, not 4 different sets.
We need to, at some point decide on who does what. We need to decide on the order that things have to be done, and we need to name a project manager. Those that work on the Apolyton project then need to work with the project manager, and do the stuff the he assigns them to do.
Of course things get a little mixed up here at the start, since everybody is excited about this, but somebody has to take over here, or we'll never get anything done.
I would do it, but I know next to nothing about coding (my project management skill lie in other areas) so this rules me out. But what about Locutus? He seems to know about coding, and I am sure he can manage this project.
Asmodean
|
|
| |
|
| |
|
|
|
kaan
|
|
Aarhus
Mar 2001
time: 05:31
|
|
Dont worry about getting this thing under control, well be bound to make a common source tree sooner or later.
Right now the right thing to do is to let ppl play with the source and get familiar with it, next step is getting the sound and directX things ported to an open platform but thats in the future for now.
my 2 cent
kaan
|
|
| |
|
| |
|
|
|
Locutus
|
|
ACS CTP1/2 Manager & Civ4 Co-Manager
|
 |
Hengelo, The Netherlands
Nov 1999
time: 06:31
|
|
As for getting organised, I don't really mind people playing around with the code... that's still the best way of getting to know it.
But I agree we will soon have to start with at least systematically documenting our action, preferably also acting in a systematic fashion and planning our actions.
Right now there may be several different versions of the game out there, but they don't make major changes to the code yet. Just a few lines here or there, nothing that can't be merged (assuming everyone at least documented their own changes).
While we sort out how to get organized, what tools to use, who does what and what to do first, I think it's fine if people mess around with the code a bit and see if they can fix the most obvious bugs. This will also help in quickly getting out a patch once we really get going, which will greatly help in maintaining an interest in this project (it's a plain fact that people in general want to see results and want to see them fast, otherwise most will just loose interest and move on to other things).
After the first patch we could focus on documenting the code more thoroughly and systematically, and hunt down and fix the more complicated bugs. Once most/all of the known bugs have been fixed (this may be a while), and depending on how long that will take and how many bugs are found maybe also a few times before that, we will want to release another patch.
By that time we should have a good grasp of the game and can hopefully move forward with actually implementing new features and making more radical changes to the game. This should probably start conservatively, with things that everyone agrees should be changed (such as the AI) and only gradually move on to features that not everyone may be happy with (such as strategic resources). That way people who want a better AI aren't automatically stuck with a resource system they don't like. But that's long term thinking...
|
|
| |
|
| |
|
|
|
ahenobarb
|
|
I don't know who is going to get the job, but a good place to start would be to have everyone agree on a list of the real bugs that are in the game (like veterans status, the AI not building commercial improvements, etc.) and then taking each item in the agreed list and making a sticky thread at the top for each of them. Then the coders from groups 1&2, mentioned here can cherry pick the problems they want to work on and when one is solved, move on to the next one. Then when all the bugs in the list have been eliminated and the mod limits have been lifted, remove the sticky status of the threads, and release new patch of the game.
After that, turn to SLIC and the unimplemented feature of the game like PBEM, space, pacman, whatever... With sticky threads for each of them as well.
Then, the part I like to call "crazy ideas" from group 3. Work them into the game, with sticky threads.
Nice, neat, topical. 
Last edited by ahenobarb on 04-11-2003 at 09:49
|
|
| |
|
|
|
Asmodean
|
|
Aarhus, Denmark
Aug 1999
time: 06:31
|
|
quote:
Originally posted by Locutus
As for getting organised, I don't really mind people playing around with the code... that's still the best way of getting to know it.
But I agree we will soon have to start with at least systematically documenting our action, preferably also acting in a systematic fashion and planning our actions.
Right now there may be several different versions of the game out there, but they don't make major changes to the code yet. Just a few lines here or there, nothing that can't be merged (assuming everyone at least documented their own changes). |
If that's your decision as would-be project manager, then I respect that. I do advise caution, though. I suggest amending the FAQ with something along the lines of:
code:
If you are a coder, and expect to do any work on this project,
it is vital that you document every change you make to any file in the source tree.
Relevant comments must be added in the code itself,
and you must furthermore keep an external record of every change you make,
and where you have made it, for easy reference.
No undocumented code whatsoever can expect to end up in the Apolyton project.
quote:
While we sort out how to get organized, what tools to use, who does what and what to do first, I think it's fine if people mess around with the code a bit and see if they can fix the most obvious bugs. This will also help in quickly getting out a patch once we really get going, which will greatly help in maintaining an interest in this project (it's a plain fact that people in general want to see results and want to see them fast, otherwise most will just loose interest and move on to other things). |
Again, the fastest way to results here, would be to get a firm structure going, with regards to who does what. Right now we still only have a bunch of programmers working independently.
When that is done, then it is time for the project manager to decide what gets done and in what order. There seems to be a general concensus that the first order of business should be bug-fixing and implementing the changes from 1.11. If that is the case, fine. But it is the project manager who decides this.
quote:
After the first patch we could focus on documenting the code more thoroughly and systematically, and hunt down and fix the more complicated bugs. Once most/all of the known bugs have been fixed (this may be a while), and depending on how long that will take and how many bugs are found maybe also a few times before that, we will want to release another patch. |
Why make it harder for our selves. Are we really that good, that we can expect to release a working patch from code that is not systematically documented. I know it's the tedious part, and I know it will put some people off the project, but if we are going to do this, why not do it right?
Look, I know I am the word of caution here, and I you want me to shut up, just say so. I will do it. But I have simply seen too many projects die due to poor management. Let's not make this one the next, shall we?
Asmodean
|
|
| |
|
|
|
Pyaray
|
 |
Santa Ana, CA, USA
Oct 2000
time: 21:31
|
|
quote:
Again, the fastest way to results here, would be to get a firm structure going, with regards to who does what. |
Be careful, when it stops being fun, people will leave in droves. Firm structures are the way to make things work in the corporate world, but I've never seen it be succesful in a net project. Net projects only survive as long as they're interesting, if it starts feeling like work, people will start resigning if they don't get a paycheck. 
Pyaray
|
|
| |
|
|
|
Asmodean
|
|
Aarhus, Denmark
Aug 1999
time: 06:31
|
|
You know, you're probably right, pyaray.
By firm structure, I am not that concerned with dates and deadlines. Those things are nigh on impossible to work with on a net project anyway. What worries me the most is the integrity of the source. The coordination between a growing number of programmers that go ahead on their own, with no central coordination.
Perhaps!! it will go well, but there is no guarantee, which is why I would feel more comfortable with a project manager assigning tasks, and taking care of all the loose ends. Off course it would be the foremost task of this guy, whomever it will be, to listen to the coders, and assign only tasks that they're interested in. A net project is doomed if people get to do things they don't like.
Asmodean
|
|
| |
|
|
|
DDowell
|
|
Västerås, Sweden
Nov 2001
time: 06:31
|
|
I actually hesitate to change anything in the code since I don't know who is supposed to do what and when.
I don't like the idea of having ten versions of the game lying around. It should be ONE Apolyton version and for that we need some sort of management.
I regret that I can't take it on myself since I'm already involved with another project and don't have time to be anything but a programmer on this one.
|
|
| |
|
|
|
centrifuge
|
|
quote:
Originally posted by ahenobarb
I don't know who is going to get the job, but a good place to start would be to have everyone agree on a list of the real bugs that are in the game (like veterans status, the AI not building commercial improvements, etc.) and then taking each item in the agreed list and making a sticky thread at the top for each of them. Then the coders from groups 1&2, mentioned here can cherry pick the problems they want to work on and when one is solved, move on to the next one. Then when all the bugs in the list have been eliminated and the mod limits have been lifted, remove the sticky status of the threads, and release new patch of the game.
After that, turn to SLIC and the unimplemented feature of the game like PBEM, space, pacman, whatever... With sticky threads for each of them as well.
Then, the part I like to call "crazy ideas" from group 3.
Work them into the game, with sticky threads.
Nice, neat, topical. |
Ahenobarb as a good idea here. This sounds like an easy way to get organized while keeping everyone: programmers and non-programmers involved. 
|
|
| |
|
|
|
DDowell
|
|
Västerås, Sweden
Nov 2001
time: 06:31
|
|
KeyGen, you are my hero!
Your first priority must be (in my view) to enable the use of CVS (with server here on Apolyton perhaps?).
|
|
| |
|
|
|
MrBaggins
|
|
Sounds great.
As your first task, you might consider coordinating the effort to ensure that we figure out what is causing the problem with the code. We need to find exactly why the darn thing is crashing for some, but not for others. There has to be a common issue, or something those that have got it working have done that others haven't
Martin seems to have it working fine. As does John?
DDowell, Locutus, Solver and myself I know are having issues.
It seems something to do with Assert problems. We need to get some collaboration going to find the solution so that everyone can assist, otherwise there is a lot of potential help going to waste
|
|
| |
|
|
|
Locutus
|
|
ACS CTP1/2 Manager & Civ4 Co-Manager
|
|
Hengelo, The Netherlands
Nov 1999
time: 06:31
|
|
So first we had no project leader and now we have two? 
Maybe it would be best if the two of us shared that responsibility? After all, I'm pretty much coordinating everything on behalf of the Apolyton staff anyway, and in that responsibility I have access to a lot of stuff others such as Keygen don't (website, directory, ftp, news, forum moderator functions, possibly a CVS server, a direct line with Markos and Dan, Activision, etc). On the other hand, I'm also a programmer and I'm probably most useful to the project when actually coding.
So maybe Keygen and I should work together like Markos and Dan do: let Keygen do the daily routine of organizing the people, setting targets, etc (a la Markos) and let me do background work like website, 'tech support', external communication, etc (a la Dan). And of course we could fill in for each other whenever the other one's not available (though if I'm not here Keygen would need a lot of help from Markos, Dan and Ming).
|
|
| |
All times are GMT. The time now is 05:31.
Apolyton Time is 00:31. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
03-11-2003 23:33
|