next »

I think coding an engine, with an experienced group of people you can rely on that are all known by each other, is hard enough. I have no idea how 5-100 people are going to all work on this project, doing their own thing.

Especially if two people are working on the same section at a time. 9/10ths of all the code written will be thrown away because it's redundant.

And I cannot imagine the errors it's going to get, what with people combining code and techniques all the time.

Are you guys going to organize it? Like, set up a list of activities and assign them to people?

Solinx: Post split from ''The code needs to be fully documented''
2playgames: Programming -> General

Don't be so pessimistic

It's not going to be utter chaos, such as you describe it.

What we will do is devide the work, we discuss what has to be done and then let people claim the bits they want to work on. Before someone is going to work on any code for this project, he has to let everyone know what he is going to do. For that purpose there is a forum, for that and for discussion and a good many other things. Without communication, this project is doomed to go down as you describe it. We can not have that happening.

If someone starts on code for the engine, without speaking of it on the board, he takes the chance that someone else is going to work on it at the same time. There is no way to make a rule about this, as there are to many variables around it, but reporting your doings will gain you a preference.

Before this project is over I intend to seek out a few other succesfull projects and ask them about how precisely they have been organising their their projects.

Solinx

There are a lot of open-source projects, and as such there are standard procedures for this. I'm sure we'll be able to apply one of them to this project.

As I've said, we will be establishing a rough design on the wiki before we even write a single line of code.  I'm going to actually be quite angry at anyone who starts writing code before we've really established the architecture of that part of the engine.

There is a misconception among people that programming is mostly coding; this is far from the truth.  Most of the work will be in design.  Most of that design will take place on the wiki where we will discuss what individual classes must be able to do, how they must interact, and how they might do this.  Once we've got a rough design, then someone will code it.  The thing is, it doesn't matter then how they code it; if it fulfills the tasks we established it would need to on the wiki, then it's irrelivent how he programmed it (this is the upside of object oriented programming.  An individual module within the program can work in any way it wants and not affect other components.  All the other components have to worry about are the inputs it takes, and the outputs it gives, not how it operates).

When the time comes, we'll probably have a system where when someone is programming a given module, he'll sign his name at the top and everyone will know someone is working on that class (or group of classes).  There are a few areas I'm very wary when it comes to coding, and doubtlessly we'll want people who really have experience in those fields to do the work there, but I think that we can keep things fairly organized.

I'm going to actually be quite angry at anyone who starts writing code before we've really established the architecture of that part of the engine.

well, there's nothing wrong with starting to write code, as long as it doesn't give the rest of us any limitations (but hey, that almost always happens, so ingnore this )

this is the upside of object oriented programming.  An individual module within the program can work in any way it wants and not affect other components.  All the other components have to worry about are the inputs it takes, and the outputs it gives, not how it operates

yep, i'm starting to realize that more and more every day

Well, as I said, once we have established what it needs to do, and what needs to interface with it (and how), then the design phase is roughly complete, and some code can, in fact, be produced.  The entire program doesn't need to be designed before we start coding any part of it.  However, we should establish (before a single line of code is written) every class that needs to use that one, how they will use it, and what classes that output will in turn be using (and how it will be expected to use them).  We cannot begin coding something until we know exactly what we need it to do.

We are in a phase that we can name 'preproject', but this phase is needed. We must speak about our ideas, possibilities, telling all we think, to pose the foundations of the project. So we musn't polish off this phase too quickly, we have to take our time, and that for the future of the project.

Life Cycle of a produce:

1) Specifications

2) Design

3) Risk Analysis

4) Verification

5) Coding

6) Testing

7) Refinement

8) Production

9) Maintainance

We're currently in phase 1.  It should NOT be characterized as pre-project.  Establishing what we need to achieve in a very objective manner (building an RTS engine isn't objective.  We need details and specifics so that our individual ideas of what this RTS should be are on the same page, and not slightly different each).

-edit-  I hate it when 8 followed by ) produces a smily... makes for horrible listing.  I don't see "disable smilies in this post" as an option, either...

Instead of following these steps rigidly, it would be better combine a few, like step 5 and 6, the coding and testing.

I've lost the document, but I read that having constant feedback has quite an advantage. It helps avoid minor problems in the beginning, that could end up being major problems after the rest of the coding.

Edit:
Ok, not really combining, but stimulate interaction during the process of writing the code.

Solinx

well, you always test when coding something. the testing step basically just means 'extensive testing'

Yes, you're ALWAYS testing as you're coding.  I would always put my work through a thorough tester program before submitting it.

By testing, we're talking like alpha and beta testing.  The program is actually done, and we're testing the completed thing and how it works together, not just individual modules or small sets of modules doing so.

I meant testing by others, to see if it's liked the way it is.

Solinx

Basically with an open-source project you always have the latest code available for download, so anyone can test it whenever they want to.

A suggestion for a way to work on it is to have a master copy of the code. Main staff could modify this master copy, and main staff would be chosen wisely (someone like Darvin or Solinx who is something of a director and is the master of the game vision). "volunteer" members could send in modified versions of the source code that progresses it, and then the main staff can overview it, put it on the priorities list in the appropriate spot, and then add it when the time is right. It could be sticky if there are a LOT of people modding the code, but I assume that you'll get more than two people who are the main "code masters", so to speak.

Yes, a safety mechanism, to make sure the code won't be broken somewhere along the way because two people are working on the same piece. We definetly need something along the lines of what you describe. Naturally, there will be backups, but better to avoid than having to mend a problem.

Solinx

Subversion (SVN)

SVN is a version control system. That means, it holds all the files, and keeps versions. If you want to edit a source file, you do so and then upload ("commit") it back to the server, so that everybody else can download ("update") it. If you make a change you regret, you can always go back to any earlier version of the file. If you're going to work on a file for a long time or intensively, you can lock it, which means nobody but you can change it.

In the case that two people actually work on and commit the same file, it can even compare them and combine (if possible) the changes

In general I worked with svn. The standard work scheme is that   main development line is called 'trunk'. Whenever someone wants too add a major change, he creates a branch, makes the changes, and then merges it back to the trunk.
That way the trunk always compiles and sort-of stable. (I am sure there are more details in the svn manual)

Note that svn is not especially suited for source code. It is simply a versioned file-system. So you can event put in it stuff like 3d models and other data files..

In order to make sure that the trunk is stable, every night there is a script that automatically builds the project and runs its tests. In case something is broken, an email is automatically sent to the responsible person (using the 'svn blame' command). The person that breaks the build is also mocked upon, until another person breaks the build.. 

Handling tasks:
When anyone detects a bug or an issue to be handles, it submits it as a ticket to Trac. Trac is an open-source project management system. All the tickets lie in the Trac system, until some developer takes care of them. A ticket can be a bug, a feature, a task, etc...

-- yuvi

A popular SVN tool is monotone, which is the one I will be using for the project I'm currently working on.

I use the subversive plugin for things that I can do in eclipse, and SmartSVN for the rest