Leaderboard

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.

Personally, I think all merc camps should have the same /basic/ shape, just styled according to biome/culture.

Just as an FYI, we've got the 0ad.me domain. Not sure if this is the best use for it or if it's best used for something else in the future, but thought I should mention it so you're aware it exists.

Hi all here is a building that I'd like to see in the game since it is historically accurate. http://en.wikipedia.org/wiki/Mint_%28coin%29 I was thinking that it could be a special building, for scenarios, or something for some of the factions to have which would either refine metal or, improve trade routes. I could also be an eyecandy building. Here is an example of a building from my favourite game(after 0ad) Die Siedler V : Das Erbe der Könige (The Settlers 5 : Heritage of Kings) In that game every building refines extracted ore (wood, stone.. etc) except this one for it is not present as a playable building. There is also a ticket made about this game with animated buildings. So what do you think about adding this kind of buildings to the game ? Also here you can see how obstruction was calculated in this game.

Cilician Pirates would be cool.

Initially we can use 1 model and then start to differentiate them as we go along.

Regarding the mercenary camp, the idea would be for its architectural style to be "independent" or similar to that of a particular civilization native to each biome?

eduh: Thanks for your interest. Sadly my progress is slow ^^.

In my hypothetical RTS game design, a 'Mint' was a buildable structure that gave a trickle of coinage income.

Lol Michael xD Didn't find a bigger one?

Yeah a lot, has it a bump or a specular or only AO/Texture ? some parts look a bit flat Anyway good job. Or maybe too "clean" not sure.

I think its looking better now...

I have two proposals regarding A* in terrain-analysis-pathfinder.js: Inside the main while loop, values should not get fetched via 'this.' because there is an existence test behind and the ternary (? performs better than 'if/then' if branching is not intended. Estimated improvement >50%. I haven't seen all maps, maybe a bi-directional A* would help too.

Salute. I don't think I heard about Eadweard Muybridge or his work. It looks very interesting. Walk preview:

No, I'm quite sure this module pattern will continue to work in the future because it doesn't use special Javascript features or anything like that. The pattern is so commonly used that it will have to be supported for future versions. With the ES6 specification they even try to integrate the idea of modules directly into the language. So maybe we could simplify the notation or get some additional benefits at some point. I haven't yet checked how this new type of modules will work exactly. Get some information about these new modules here. The issue is that the C++ debugger API changed even more than the rest of the JSAPI and the whole server component of the debugger has to be rewritten. There's a Javascript API which is more stable and it would probably be a good idea to use that instead. I also wondered if there would be a way to somehow connect existing debuggers more directly to avoid maintenance work, get additional features and have a UI that people are already used to.

you can run that on any map, including random maps. Here's the script I'm currently using: ./pyrogenesis -quickstart -autostart="unknown_land" -autostart-ai=1:aegis -autostart-ai=2:aegis-autostart-random=25255 -autostart-civ=1:gaul -autostart-civ=2:rome You can change the civs, the random seed, the map, and even the Ai difficulty (using -autostart-aidiff=$PlayerID:$DifficultyLevel)

> seriously what is needed to make 0AD run Aegis vs. Aegis? Solved that with: "D:\Games\0 A.D. alpha\binaries\system\pyrogenesis.exe" -autostart=Aitest01 -autostart-ai=1:aegis -autostart-ai=2:aegisand a simple map: The confrontation was short, four units died, two females got stuck after building a storehouse. I think I invest some weekends to see what is needed to watch an epic battle on a map like this (without stone and metal). A genetic AI would require a complete abstraction. Every available action needs to be referable as a string, so new generations could be mixed and mutations have a data structure to work on. That's probably the far end of the road. Also two good gen sets do not necessarily have clever offspring. Somehow a fit function has to decide off game whether there is progress at all. On the other hand eventually very optimized AIs would be generated - kinda AI mining, though.

Limited set of feature isn't good enough. All features of an AI are closely linked. You need to be able to beat it on all features. Also I'd like to say that since I arrived here, I have seen no-one start serious work on AIs. 0 A.D. is also limiting because it requires extreme flexibility.

This is a good idea. But I think what he actually means is, that many AI versions get coded, and then setup a tournament to constantly prove on the blunders. I mean in reality this is exactly why civilizations have wars. Its the constant "tweaking" the bettering of technology and problems and obstacles the enemy throws at you, necessity sets in, and necessity is mother of invention, innovation and progression.

Great idea! So what are you waiting for? Roll up your sleeves and get coding buddy! :-)