I got your PM, but might as well reply in this thread.
Pretty much how LCS development works is that changes are made when people feel like making changes, then the nature of the changes is whatever the people making the changes wants it to be. This may include fixing bugs, adding neat features, balancing gameplay, fixing spelling errors, whatever.
If you have enough programming experience to have at least a vague idea of what you're doing and won't break things, I'm pretty lax about giving helpful people rights to commit changes to the SVN trunk. If you want to work on something big or controversial (completely rewrite a system, add potentially offensive content, or something else like that) then you might ask for opinions in this forum first, or work on it as a mod and release the modded version. For smaller things, I would go with the Wikipedia methodology and be bold, since you can't break anything permanently even if you do have SVN commit access.
There isn't a proper to-do list, but if you're interested in ideas, there's this document:
LCS Crazy Ideas ListMy best suggestion for trying to navigate the code for the game is to not try to understand everything at once. Liberal Crime Squad has a chaotic, spaghetti code architecture that doesn't even come close to following best practices. Instead, decide on what you want to learn. Want to know how an attack is resolved? What makes something hit or miss? Focus on that and just search for that answer. Look in fight.cpp and find where it's rolling attacks... search the code for things that show up on screen, since all that text will show up in the code as well. Using this system, you can build familiarity with the features you're interested in. This works even better if there's something you want to *change*, since then you can try changing the code you're focusing on and recompile to see if it did what you thought it did. Like learning the laws of physics, running experiments and verifying your theories will quickly allow you to build an understanding of how the game was written. Eventually you will have successfully made the change you wanted to do, or successfully added the feature you want, and can go off to work on another area of the game, if it pleases you.
Another alternative, though not what I suggest, is to do what I did when I was learning the game's code. When I first downloaded the code, I was mostly just curious how it worked. I spent an entire day just reading the entire code front to back like a book before editing anything. Every time I got to something, my goal was to figure out what it meant, and what that corresponded to in the game. Only after I finished this process did I decide to go back and make a few changes I'd wished for when playing. This approach gave me a good background for later going on to maintain all aspects of the game, since it ensured I had few blind spots where I had no idea how the game did a certain thing. Still, this approach seems like overkill in hindsight.
Author
Topic: Assisting with development (Read 1595 times)