wraitii

I'd expect Marilyn to behave better at this challenge, since it's from my testings much more efficient in the early game.

Yeah, that's actually a side-effect of the code as it is: since Marilyn waits to have enough units to start an attack, it waits on average 6 minutes before attacking ( in case of a "CityAttack" ). It simply creates an army meanwhile. It could attack earlier, but only if it had reached the "maximum amount" of units, which is about 150 for a "City Attack"... However, if you attack it, it will detect you, and the standing army will chase you. Still, it chases for a very long distance, right now, which is not really intentional. I'll look at the code, I deactivated the "cavalry raids" and the "early rushes" for now, but will put them back as soon as I can. @quantumstate: I said improvement, but I'm not actually sure it's one... It's merely a different way of doing about the same things. The benefits of my systems are that economic and military buildings are always built as soon as possible... The AI usually won't try to build 50 at a time, so it's not really a problem. And the benefit is that as soon as the code decides to build a building, you can expect it to pop up in under 1 minute, which I couldn't always see with qBot. I found my system easier to predict, but it's perhaps not as efficient in some cases. Btw, the "flooding the building queue" is because I wasn't sure there was an improvement... And it's also because I didn't take the time to implement it completely. I did that because as a former AOE : AOK player, I figured building one villager at a time in the early game would bring more resource per villager in the early game (since each spawned villager starts collecting...). I haven't done the math, as I didn't know it. Will have to check. Individual priorities are useful in my attack plans, because this allows to balance armies more easily, I found, while not having too many queues. Again, perhaps it's only a matter of philosophy in the coding. Marilyn does build military buildings fast, but that's likely a side effect of females being built at an insane rate in this game ( as a player of AOE II, getting 50 villies was not easy to do in under 10 minutes.. in 0ad, it can be done in about 5 it seems. ) Farm building is not yet perfect: in the beginning, it detects the amount of available food, and if there's not enough it starts building farms... But then, when the farms deplete, there's usually a small time where he hasn't built new ones.

For those looking through the codes: it's really not cleaned up... There are many unused variables, many unused functions that I haven't erased from qBot. For simpler reading, check the "update" functions first. This is particularly noticeable in the "defence" and "economy" files.

Please excuse the topic description, as it's widely inaccurate, but it's pretty much the reason why I named my AI (improvement over qBot) Marilyn. So anyway, I was on holidays last week with very little to do and a really bad weather, and I started trying to improve qBot, which, while already very capable, isn't perfect. I've come up after one week with a fairly acceptable improvement, I think. It's not incredibly better, it isn't vastly superior, but it's overall , in my testings, more reliable and a bit less game-able. It's still a work in progress, but I'm going back to school tomorrow and won't have that much time, so I'm releasing it as is and I'll upgrade it over time. 18/02/12 update: okay, I've done some fair changes over the original description, so here is a review list of changes over qBot: -Marilyn will go for crates first, then hens/bushes, then only start farming, and will try to build only the required amount of farm. -Better dropsite placement. Marilyn will build dropsites where needed, and in the best way possible. -Improved defense. She detects intrusion in her territory, can detect an attack on a unit, can garrison her citizens. Still a work in progeess. -Attack Plans.Basically, instead of building units and one day saying: allright, I attack, it will create units specifically for attacking and then attack. This is also very much a work in progress. -Slightly different queue-ing system, though this you won't be able to see. -Building things rotated! What remains to be done: -Handling anything water. -Better defense: detecting attacks by ships, buildings, individual units or whole armies, and proper retaliation in each cases. -Better defensive reactivity: remembering where the enemy last attacked, remembering chockepoints, creating armies to counter the enemy... -Improving attacks: different attack types, a better targeting system, sieging, tricking, decoying, retreating, basically anything. -Handling resource gathering better. The system works fairly well but fairly blindly, so there is likely room for improvement. -Handling the bartering. -More diverse strategies (will have to wait for a true random generator) -Dealing with allies/multiple enemies -Likely a few other things. Marilyn should behave better early game than qBot, and about the same in the late game (with the little advantage from the better start). Activate the debugging option in "Marilyn.js", this file is basically the same as "qbot.js". I encourage anybody to try the AI and report whatever they notice. Ask questions if you have any. Download link (as of 02/24/12, a more recent version could be in available in the later posts)

An idea I had this morning in my car... Afaik, siege units were mainly for crushing walls and things like that, not so much for trashing barracks or whatever... Perhaps units could be made to "storm" buildings, encountering resistance, and after some time the building would simply switch allegiance or become "neutral" until taken back. This would allow to storm undefended cities without siege units, and would make walls actually have a purpose. Of course, you might want to wait for a proper wall system to do that.

I like that. Something that, as long as you have the resources, ensures you have at least one "queued" farm for reseeding.

There 's a weirder issue though... On Lion, when I play 0AD, there's a weird issue with the desktop that becomes "translated"... it's hard to explain really but it's like everything in the desktop was 200px higher than it really is (clicks are wrong and so on). Restarting the Finder fixes it, changing a few stuffs fixes it too, but it's fairly weird.

It should be helpful anyway. I'm not sure which version I've posted where, but this is the latest version. Just download it and start the application without changing anything, it ought to work.

Yeah, I didn't include AtlasUI.dylib because I couldn't get it to compile, but I didn't really try either because I focused myself on getting the game to work first.

I'm going to be away for a week, so won't be able to help much during this time, but the Idea is that you need to add a "copy file" phase and a "run script" phase to your Xcode projects. In the copy file phase, you'd copy every single dylib needed (I record 25). In the run script, you'll have to change the links so that it works. You may want to take a look at this. I don't think it can compile as such, and it's not a perfectly up-to-date project, but it'll give you the idea.

I just finished uploading a bundle that might already be deployable. Could you try downloading this and starting the game? It should work.

Note that the Collada loading problem can be fixed in a more "convergent" way by simply adding a bit of platform-dependant code. I did so in my release: I Changed the DLL loader function LoadAnyVariant to this static void* LoadAnyVariant(const CStr& name, std::stringstream& errors) { for(size_t idxSuffix = 0; idxSuffix < ARRAY_SIZE(suffixes); idxSuffix++) { for(size_t idxExtension = 0; idxExtension < ARRAY_SIZE(extensions); idxExtension++) { CStr filename = GenerateFilename(name, suffixes[idxSuffix], extensions[idxExtension]); // Here's what I added // this should ensure Collada is properly loaded. #if OS_MACOSX if (name == "Collada" || name == "AtlasUI") filename = "@executable_path/../Frameworks/" + filename; #endif // we don't really care when relocations take place, but one of // {RTLD_NOW, RTLD_LAZY} must be specified. go with the former because // it is safer and matches the Windows load behavior. const int flags = RTLD_LOCAL|RTLD_NOW; void* handle = dlopen(filename.c_str(), flags); if(handle) return handle; else errors << "dlopen(" << filename << ") failed: " << dlerror() << "; "; } } return 0; // none worked } (note that I link to "Frameworks" because I copied there every library needed for the game. Linking even the Data in it can be done too, but requires slightly greater changes. I also report the fact that going from FS to windowed mode crashes. Though the fullscreen mode works correctly. As for the release, indeed linking every library with the app bundle is needed and not too hard (a simple copy and scripting issue, which is fairly straightforward.) Note that some of the libraries used are relying on other libraries, so you have to make sure you modify everything (not only the executable and the libraries, but the calls between libraries). Putting the Data inside the game bundle might not be a priority for now, as long as the game works when you start it.

Do you plan on improving the military aspect of qBot? Additional question to anyone: is there any way to simulate LOS for the AI?

I've actually fixed that in my release. It has to do with the fact that you're trying to use dynamic libraries (dylib) on MacOSX, and the game can't find them because they are not where they "should" be. You have to run a script. Try searching "Mac os X deployment dylib" for more information.

Could you "report the problem to Apple" and paste the error code? And have you downloaded the data? If not, download the data, and put the application in the same folder as the "mods", "config" and "tools" folder. In case there is still a problem and it appears you have done everything right, could you open the console and paste the error messages appearing?

I'm fairly sure a Mac OS X deployment is not that hard... I've got fairly basic knowledge and could get it to work starting with the Xcode workspaces.

Can anybody try this version? I'm not sure which it is, but it should fairly work.

Hmmm. Shouldn't do that... I'm actually going to have Christmas now, so I won't be able to update for a few hours. Merry Christmas all. I get it... There's indeed a problem, I'll fix it as soon as possible

No, afaik the Data should be kept zipped (but the developers will answer that better)... That's a weird problem, it looks like you have an outdated version of libpng in your X11 folder... I suggest you download the latest version of X11 and retry. OpenGL should already be in your HD/Library/Frameworks. You're likely trying to use the former version of my precompiled 0A.D. , which has bugs with Collada and some libraries, I'm uploading a newer one which should work independently. edit: Okay, try replacing the application (only the application) by this one. Normally, you don't even have to update X11 as this version should rely on the one bundled with it (which means that it should simply work).

Okay, so this is the basic core of my Xcode project. It's not brand new, it's only an improved version of the workspaces that the game creates when following the instructions on the wiki. You'll need two things, I think: the data (downloadable here) and the "libraries" folder, with compiled libraries. I have included the basic one, but I don't think it'll work with it... So you might have to go though the "normal" installation process as described on the wiki once, and then replace the files with mine (but the "libraries" folder). (Note that I have included a "Libraries" folder in /system , this one is not the one I'm talking about. I'm talking about the one in the root folder.) Download link, If you're having any trouble, please report. This includes the fixed Collada thing, but Atlas doesn't work. I'm compressing a new "precompiled" executable and am going to upload it later today, this one should actually be deployable.

I'm straightening it out and then uploading. I think I won't upload the data to save space, nor the compiled app, so you'll have to put it in the right folder, I'll indicate which. Edit: Okay... Still trying to get the raw minimum, but at the very least I fixed the Collada issue. In fact, because it's loaded at runtime, the game couldn't find the dylib. I've added a little fix in "DLLloader.cpp" which should not conflict ( I used a "IFDEF mac os X") which solves the issue, you'll see when I'm over.

Darn, I wrote Alpha 9, I'm getting a bit carried away. I didn't really troubleshoot this, so it's likely fairly buggy even if it starts but i uploaded it to see... I'm going to release my source code tomorrow, which will hopefully be more useful. edit: apparently the Collada problem that was encountered with the former version still happens on Lion... I'd like to know if anybody can confirm or infirm.

I've got a version of the Alpha 8 that should be deployable for Mac os X. It works on 10.6 and 10.7 on the two computers I tried at home, and it should have no particular dependencies other than OpenAl, OpenGL and the basic libraries that come with OSX. If anybody can report, download it here. It should work, but I can't guarantee it 100%. At least it worked on the computer where I went through the whole "compiling", and on another computer which is basically "vanilla". Btw, I encountered few compilation problems, mainly linking problems. In fact, using dynamic libraries on OSX is a real pain, there needs to be copying and script running. I have not included the source in this file, but I can tell you how to fix the Xcode Project for the most part. It's basically allright, but there are a few things to fix here and there, and libraries are a -real- pain. Thing is, a shell script that downloads every library necessary and puts them in the right folders could really straighten out the installing process on Mac OS X, but I think my knowledge is a bit lacking on the matter.

I think, even if you keep a fairly basic combat system, that doing different damage depending on where the shot comes from is an -absolute- necessity. This is something I've never actually seen done... Perhaps it was, perhaps it was not. Anyway, this should be in the game, and it should be documented.

Adding my two cents about formations and formation movement and gameplay addition. Something I remember from Rise Of Nations was that unit got "entrenched" after standing still for some time. This allowed for one thing that I have found in no other RTS: actual flanking. Now while entrenching is likely out of scope for 0 AD, the formation system, if it is kept fairly robust, à la R:TW can simulate such a thing: formations should get a bonus against "front attack", "side defense" or whatever, so it makes sense to use them, and should remain fairly consistent: breaking them up should not be instant ( since this would negate "flanking" ). A way to implement this would be to have some sort of trigger for each unit which would have different states: "Free", ie not in a formation, "in a formation", and "making/breaking formation". Now I'm not sure how the combat system works in 0 AD, but I don't think units individually receive differentiated damage depending on where it's coming (flank/front/rear)... If so, then very well. If not, then it would be a really cool thing to implement. Anyway, units "free" would behave normally, units "in a formation" would get damage depending on what the strong/weak points of the formation are, and basic combat. Units forming or breaking, on the other hand, would be fairly defenseless and would receive much bigger damage. As for how this relates to pathfinding: formations should be a bit slower than normal walking (which would help the pathfinding too), and remain fairly tight when moving forward. I think it should absolutely remain so until it has to "break". The specifics of when it has to break are tricky to choose... I think the most straightforward way to do it is that if keeping the formation deviates the path from more than X degrees from the optimal path, the formation will break (something like 30° seems reasonable). Breaking can be handled in two ways... The ugly one is simply to make each unit behave individually, but this is a nightmare and really not nice. A much better way to "break" a formation is to divide it into smaller "sub-formations", until the sub-formation can go through the obstacles (I'm taking the corridor example here). SO a 8x8 turtle formation could break into 4 4x4 smaller formations, and each would go through one at a time and then reform. This would be the optimal way to manage such a thing, methinks. Of course, with the problem of an object getting partly in the way (such as what was drawn on page 1), a simpler solution of "moving away from the obstacle" should be adopted.