I completely agree with everything Tim said about getting started coding. Also on Lee's above reading, etc.
But to expand a little more... The way I usually try to tackle large code bases (or most coding in general actually), is set goals and just go for them. This is exactly what I did to start RFTS and get used to tpserver-cpp. Don't think too much about what's a good goal, just pick something you know you'll have to do eventually. Odds are you'll either get it done, find out what you need to do first to make it work, or maybe find out that you have a lot of learning to do in area 'x'. For the last case, code examples of much of what you'll have to do are in the mini/mtsec ruleset and the RFTS ruleset, and there's the mailing list, your mentor, irc, and documents on the site/wiki. I usually keep a TODO list with at least two categories: short term, and long term. Also an A/B/C list can be useful; basically, A - must get done, B - really "should" do, C - it would be nice if it were in (mostly polish). Just keep your tasks up to date, and make notes for each task whenever you can. Like Tim said, starting with an empty ruleset and going from there is good. I believe my basic task order was something like: * Create empty ruleset - just get tpserver-cpp to load your ruleset, try calling game load/start and make sure it at least happens. Hint: 'status' is good. *** Which reminds me, Lee (!) the tpserver-cpp console 'help' isn't very helpful at all. I think I ended up peeking at the code to figure out all the commands with proper syntax for the server console :P. *** * Generate the universe - make universe, star system, and planet objects. learn about object types & behaviors, and designs, components, & properties. * Create orders - start with something like 'move' and cite existing orders in the other rulesets for examples on most things * Production / resources - making/claiming new objects (fleets/planets), update the available resources. * Combat / scoring - great, now it feels like i have to have an explanation on each of these. (just do combat and scoring :P) * Polish and/or iterate - more below. It also may be a good idea (depends on the case and the programmer) to do the most simple version of each of these tasks, just to get it working. Once you've got that, you know you've done most of the hard work. Iterate on what you have, getting it closer to the final product, refining, refactoring, fleshing out and polishing. This turned out to be a lot more general, large task management than I intended but I hope it helps, - Tyler (xdotx) 2008/4/28 Lee Begg <[EMAIL PROTECTED]>: > Ok, some concrete advice: > > Start with the ruleset dev book. At the very least it will give you some > intro > and tell you how to set up the basic ruleset module. At least this bit hasn't > changed and is still well documented. > > Next, play minisec and read the equivalent sources (modules/games/minisec/). > See how your experience matches with how it is coded. > > Look at the protocol documentation (read protocol3.php first to help you > understand protocolxml.php). Realise the limitations, and the flexibility. > > Lastly, try for yourself and ask questions on this mailing list or IRC. > > If you find something really cool, add it to the wiki page and/or the ruleset > dev book. The wiki page is here: > http://www.thousandparsec.net/wiki/Tpserver-cpp > > That page will be the primary location of tpserver-cpp documentation, when > some appear. I might write something up there soon. > > Later > Lee > > > > > > On Mon, 28 Apr 2008, Tim Ansell wrote: > > On Sun, 2008-04-27 at 13:22 -0500, Ryan Neufeld wrote: > > > I was going to email this exclusively to my mentor, xdotx, but I > > > figured there may be others who have a say. > > > > > > I am about to hop into some heavy documentation reading this week, and > > > frankly, I have never done anything like this before. What advice do > > > you more experienced programmers have on getting to know a piece of > > > software through documentation? Is it, say, like reading a book? > > > Studying for an exam? Memorization? Trial and error? Playing with code > > > while reading? or a mix of all of the above? > > > > I don't think reading documentation will be a huge amount of help. > > tpserver-cpp isn't very well documented in many places and you will need > > to learn a lot via trial and error. Without a goal in mind you will > > quickly get frustrated and learn lots of irrelevant information. > > > > Choose a goal like "create an empty ruleset module" and then work on > > getting it done. Once you have that working, move towards another goal > > (something like "universe generation" or similar). This will focus what > > you read and give you better understand on the things you do read. > > > > Learn by doing! It is pretty hard to do fatal damage with a computer > > (compared to other disciplines where you can actually do real physical > > damage - IE cut off a limb with a chainsaw ;). With offline revision > > control like git it is even easier to try things and when they don't > > work try something different. > > > > Those are my tips. > > > > Tim 'Mithro' Ansell > > > > <snip> > > > > _______________________________________________ > > tp-devel mailing list > > [email protected] > > http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel > > > > _______________________________________________ > tp-devel mailing list > [email protected] > http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel > > _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
