Leaderboard

I would point out that rushing is generally a tactic that is about harassing the enemy by doing things like attacking the woodline, which might be primarily defended by women. Attacks during the second phase hardly can be considered rushes and need to be planned in a different way. Rushing by entering range of the Civic Centre generally is a bad call depending on the circumstances.

I know it's almost ages ago, but I found some time and motivation to continue working on this. I just don't like unfinished projects

Yesterday we met to talk about the general gameplay design of 0 A.D. We, that is scythewhirler, DarcReaver, niektb and myself, an autoproclammed design comitee (thus most of the team is aware of it) that I invited after this thread http://wildfiregames.com/forum/index.php?showtopic=20038. We are not dictatoring how things should be, but try to stick to what 0 A.D. is, refering to the design documents and looking at what is said on the forum (and IRC). So we first met to agree of what describes 0 A.D. for further common works. Relying upon this http://trac.wildfiregames.com/wiki/0AD_The_Vision, we diverged about a lot of points from the current state, about capturing, micro and macro, formations.... Then we agreed this: This surely doesn't say all and may seems just a rephrasing of the design document. It is our starting point for further discussions and decisions. The next meeting will happen on next Sunday. We will discuss each point of the desciptions and act more details for each then and see if the game fits it or what should be modified to get it.

Some probably know Jenkins already. It's an Open Source tool for automated building and testing. The idea is to notice bugs as soon as possible after they are introduced. Let's compare this situation with and without Jenkins to show what I mean (not using Bob and Alice as names for once): Situation: Yves breaks a test only in debug builds Currently (without Jenkins): Yves has tested his change in the game and he has launched the tests in release mode. Everything works as expected and he commits. Two weeks later there's a forum post about a strange problem with the tests. Leper and Sander both can't reproduce it in their first try. On their systems the tests work well. After a few questions in the forum they figure out it only happens in debug builds and after an hour of collaborative analysis they find and fix the problem. Unfortunately some other commits were based on this change during the last two weeks and more changes need to be done. Future (with Jenkins): Yves has tested his change in the game and he has launched the tests in release mode. Everything works as expected and he commit. Jenkins does some automated building and testing with various configurations. One hour later, Yves gets a mail from Jenkins informing him that the tests don't work in debug mode. Yves has worked on the change just an hour ago and everything is still fresh in mind and he can solve the problem quickly because he already knows where to search for it. That's an optimal case but there are a lot of situations where automated testing can be useful. Just think about how often someone broke a test in the past which caused a lot of unnecessary noise on IRC when this person could just have fixed it an hour after breaking it and nobody would have noticed. I you have some time I recommend watching this video, it explains the topic quite well in my optinion (the general part in the beginning at least): I also recommend this short and general overview of what continuous integration means: I have started experimenting a bit with Jenkins and figuring out what can be done and what could be useful for us. Here's what I have so far: Basic building and testing procedure: Jenkins checks for new svn revisions every 10 minutes. It uses svn update for the checkout instead of doing a fresh checkout everytime. Runs update-workspaces.sh with the newly introduced option "--jenkins-tests" Runs make Runs our test executable and redirects the output to an xml file. Fixes a little incompatibility with the XML schema with sed and then uses the generated XML to display the results of the testsThese steps get exectued for both debug and release configurations. Jenkins has a web GUI which displays and visualizes all kinds of useful information. Unfortunately I don't have a DMZ setup at home, so I don't want to make the server accessible to the internet. But I've made some screenshots to give you an impression of how it looks: This is the overview showing a trend (currently a dark cloud because many builds failed while I was testing). On the bottom left corner you see build with two different configurations (debug and release) running. Here you see the tests listed. They all passed in this run. There are also nice graphs showing a history of the tests either for all tests or individual tests. Of course the graph is not very interesting with only two builds and 100% tests passed in both builds: There's also a build history showing when which tests succeeded or failed: Last but not least, Jenkins keeps track of commits and automatically adds people who do the commits to its configuration. We could assign email addresses to people and send mails if one of their commits doesn't pass a build or a test (I heard you can do that, but I haven't tested it yet). I'll continue improving my Jenkins setup to figure out what can be done and what's useful for us. At some point we should probably think about configuring a Jenkins server which is accessible through the internet. At the moment this would be too early IMO. I know that Philip already has a sever, but as far as I know he only uses it for building and hasn't integrated tests or anything like that.

The 20 to 45 minutes part kind of puts me off... A game with such level of detail should be savoured like the finest of meals, not devoured as if it was fast food Would you consider adding a second game-mode (Empire Building?) where the game takes between 40 to 90 minutes? Then people could have time to develop more cities other than a huge metropolis and epic fights could ensue where one defeat in open battle doesn't mean total destruction, since even if that leads to the loss of your best city, you'll have places to retreat and try to claw your way back to victory... In short, a mode where (grand?) strategy is as important as tactics

Welcome anyway Rusty we all have "Homer moments" Doh! Enjoy the Choice

What we mostly did is laying a general foundation about what 0 A.D. is (or should be) based on the design doc. We didn't step into details yet. We certainly shared nice thoughts and ideas but pushed that aside for later discussion (as we should have a base first) With that general idea in mind we're going to work out the details in that idea (again based on the design doc).

Lar uses a low-weight bow and many time does not even bring to full draw. He is trick shooter and very good, but he did not "rediscover" anything.

I can only see benefits in having continuous integration, regardless of the solution that we choose.

Thanks for the input and the support! At the moment I'm looking into how it works technically and what our possibilities are. There are a lot of potential designs but in the first step I don't worry about productive development processes or licensing topics. I mean we could do something like Mozilla with their mozilla-inbound repository where stuff gets committed first before it goes into mozilla-central. We could also checkout custom github repositories or branches and run our tests there. Maybe we could download and apply smaller patches. All that not only needs to work technically, but there are security concerns (we are downloading and executing code) and processes need to be defined. For a solution like the inbound-repository for example, there are a lot of unanswered questions at the moment. Are there manual steps involved? Will committing be queued when one patch is being tested? What happens if a change that comes earlier in the queue breaks the a later patch in the queue etc. I plan to look into how different systems (Windows, Linux, Mac) can be connected and if data can be aggregated at the same place. I'll focus on the technical aspect first.