I'm a pretty good coder. I've worked at my University as a TA for intro level classes for 2 years now and I'm probaby one of the top 10 programmers in my school. However, I have never really worked on any very large projects before, and I feel that is a major disadvantage. The other day, I downloaded the source to my favorite open source game projects. I want to see how far I can get in modding it and I want to try to add a feature or two. However, having never worked with something as massive as this, I don't know where to start. Which brings me to my question.... When beginning to work with a large project for the first time, what do you do? Right now, I'm trying to get a feel for some of the common classes (base entity and screen classes). Does anyone have any strategies? How long do you usually need to spend before you can comfortably make basic changes to the source (and expect them to work)? This is an open-ended question, so be creative in your answers!

Quote:Original post by Tac-Tics
I'm a pretty good coder.

Socrates would have put that differently...

Quote:Original post by Tac-Tics I've worked at my University as a TA for intro level classes for 2 years now and I'm probaby one of the top 10 programmers in my school. However, I have never really worked on any very large projects before, and I feel that is a major disadvantage.

it surely is: those who know, do-those who don't, teach ;-)

Quote:Original post by Tac-Tics
The other day, I downloaded the source to my favorite open source game projects.

what project specifically?

Quote:Original post by Tac-TicsI want to see how far I can get in modding it and I want to try to add a feature or two. However, having never worked with something as massive as this, I don't know where to start.

this is a common problem-regardless of how good/experienced a programmer you are-basically, you are usually confronted with a MASSIVE code base, which more than often merely follows a syntax that you are familiar with, but all of the key functionality is not implemented by syntax but rather by libraries, APIs, frameworks, SDKs.
As such, you need to get a global understanding (overview) of the project, starting with the source folder layout, dependencies, components, entry point-basic program flow.

This is where code browsers can come in very handy-likewise, source code documentation tools such as DoxyGen can be tremendously useful.

Quote:Original post by Tac-TicsWhich brings me to my question....

When beginning to work with a large project for the first time, what do you do?

Usually, I:

- download the source code
- get all its dependencies
- compile & install the dependencies
- compile the source code
- use a debugger such as gdb to step through the source code
- look up projects specific development FAQs, Docs/Readme's, Wiki's
- subscribe to the corresponding development specific mailing list/forums
- run a complete DoxyGen doc built on the code base
- browse the source code in a browser
- use an interactive code browser
- modify minor parts of the program to see how they affect overall behaviour

Quote:Original post by Tac-Tics Right now, I'm trying to get a feel for some of the common classes (base entity and screen classes). Does anyone have any strategies?

Make sure to actually play with the code base on a VERY regular basis, try to get an impression of the code base's layout and design. Search the mailing list archives, subscribe to the mailing lists, ask fellow (more senior) developers SPECIFIC questions. Determine the pillars of the code base (i.e. key-APIs) and make sure to understand how to use them properly.

Quote:Original post by Tac-TicsHow long do you usually need to spend before you can comfortably make basic changes to the source (and expect them to work)?

- VERY basic changes: 4-6 weeks
- moderately complex changes using familiar libraries: 6-12 weeks
- moderately complex changes using unfamiliar (new) libs: 12-20 weeks
- more complex changes using familiar libs: 3-6 months
- more complex changes using unfamiliar libs: 5-10 months
- complex stuff: 12-18+ months after first getting involved
etc.

Basically, this really comes down to how much you know already and how much time you can spend each week playing/working with a project.

Someone who has just learnt the basics of a programming language and framework/API or SDK/library, is pretty unlikely to be able to make any meaningful contribution anytime soon-so, you'll want to make sure to get the basics right first-and this MAY mean, becoming familiar with a project's dependencies (libraries).

Quote:Original post by Tac-Tics
The other day, I downloaded the source to my favorite open source game projects. I want to see how far I can get in modding it and I want to try to add a feature or two. However, having never worked with something as massive as this, I don't know where to start.

Also, in order to ensure that your efforts will actually be supported by the project's developers, you'll want to try starting to fix minor bugs/feature requests-this will make sure that you contribute meaningful code to the project as a whole, while also ensuring that the project's core developers are supportive of your efforts, who otherwise may not have the manpower/resources available to provide support to outside-efforts.
Thus, getting involved in a project's community is really key: make sure to communicate your intentions, provide infos about your background, the time you are hoping to be able to contribute to the project (i.e. on a weekly/monthly basis), request pointers to minor issues that rookies could attempt to tackle and ask for pointers to otherwise possibly useful resources in your effort to get involved in the project. Also, don't be disappointed if your offers don't seem to be appropriately acknowledged: open source is all about self-motivation, and some OSS projects are really not at all coordinated in any hierarchical fashion-so, "ideas" are easily disregarded if they aren't followed up with patches.

When it eventually comes to contributing possibly useful code back to the project, you'll want to ensure to follow the project's contribution guidelines-that is: use proper coding style, patch format and submission channels (mailing list vs. patch tracker), and prepare yourself for some serious flaming if there are problems found.

When communicating with other OSS developers, it is also crucial to keep in mind the suggestions laid out in "How to ask smart questions"- read this and UNDERSTAND it, BEFORE getting involved if you haven't done so already. Even seasoned software developers may be dealt with as though they were rookies if they don't follow these recommendations: I've personally witnessed some very established developers from the closed source world being totally upset after getting in touch with OSS projects, simply because they didn't feel "respected" appropriately.

So, don't take anything for granted: OSS people (and -developers in particular) will usually only rarely respect you for achievements outside their domain (which may even mean outside THEIR specific project!)-while this can be frustrating for accomplished people, this also means that you can quickly gain a good reputation by being constructive.

Quote:Socrates would have put that differently...

Too bad he's dead now.

And about the "top 10" remark, that's more of a reflection of my school's Computer Science program than it is of any personal aptitude. That's probably why I'm asking here on GameDev instead of a classmate.

Quote:what project specifically?

The Stepmania project (http://www.stepmania.com/). I have a thing for rhythm games.



Anyway, to both of you who responded, thank you very much for your input.

I don't have anything usefult ot say, so I'll just post a link.

http://www.joelonsoftware.com/articles/fog0000000053.html

if you do intend to do any development at all, make sure to get the latest source code from the project's repositories (CVS/SVN) and base your efforts on a CURRENT code base!

for any non-trivial modification one of the key components is COMMUNICATION (with fellow project developers)-it will not only ensure that there's no duplicate work created, but also that you'll be closely integrated in the project, so that your work is also much more likely to be directly usable. So, as bothersome as it may be: try to communicate regularly with your fellow developers-otherwise, you may very well end up creating possibly useful stuff that nonetheless is rejected because it may for example introduce inappropriate dependencies (libs) or because of the way your implementation works.