wraitii
-
Posts
3.455 -
Joined
-
Last visited
-
Days Won
77
Posts posted by wraitii
-
-
Oh, that explains. A very good addition indeed.
-
Maybe I misunderstood the problem, but why can't you check something like:
ent.hasClass("Javelin")
ent.hasClass("Bow")?
Last time I checked the templates, these classes didn't exist. Then again, maybe I missed it. Which would make me feel -incredibly- dumb.
-
Okay, here is the fixed version. I made it so it will work with the release and the SVN version.
I'm not sure if there's any real change... I know I tweaked a few stuffs about farming, but I'm having trouble with my attack plans for some reason.
-
Not sure callbacks are actually needed for the AIs... There's updated often, and with a bit of tweaking, some "watcher" functions could be updated even more often.
I quite agree with the other changes though.
-
We will indeed, thanks for reporting it! And have we ever discussed how yucky it is to hardcode template names in the AI code?
Thing is... Some units lack proper "classes". For example, there is no way to know if a unit is a javelin or an archer. Which, given that now units will work with counters, is -extremely- annoying.
-
There has been a breaking change in svn, with the scout tower being renamed. It is a simple fix, I just thought I should let you know.
Allright. I'll likely release a newer version with the changes I did since last time... There are not too many but I'm sure I changed a few stuffs.
I'm encountering a weird problem, in fact, with the attack plans... For some reason, it appears there are units that are "forgotten" each time a new plan restarts, and I can't seem to know why... Is there any way to check the metadata on a unit?
-
I can answer that: no, it does not, because qBot has no means of processing threats to determine what they are. It only detects enemy soldiers... This is actually one of the things I worked on in Marilyn, but I haven't gone out of my way to implement it yet.
-
I've been quite busy right now with school... And I've been searching for a good idea to improve the attack system once more, I'm not really satisfied by what I have know... And I've also improved the economic aspect of things slightly.
The thing is, for newer change, I think I'll need to change a much bigger part of the code and I haven't got time yet to do that? Perhaps this week as I've got more free time.
-
To be perfectly in the "Mac OS X" spirit, you should likely put anything that's "~/.config/Oad" in "~/Documents/Oad/config" and likewise, cache and "local" would be in this "0ad" folder... Hiding stuffs in the root ~ folder is very un-OSX-y. Alternately, you could use "~/Library/Application Support/Oad", if you want to make it more "hidden".
-
To tell you what AOE III does:
everything "static" is in the bundle. Data and dependencies.
Everything else is in "~/Documents/Age of Empires III". This includes AI files, Savegames, scenarios, homecities.
I think it's basically what you want for 0 A.D.
-
Okay, so to further develop your "open questions".
The biggest downside of an app bundle can be weight. However, this is pretty much irrelevant for 0 A.D. since the libraries are basically lightweight. it's however much more convenient for the rest since it allows a user to simply put the app bundle where he wants and run it, nothing else needed, like most apps on OSX.
As for where to put what, Data and things like that likely ought to be put in "AppPath/Contents/Resources". Libraries should be put in "AppPath/Contents/Frameworks".
What you should actually put in "~/Library/Application Support/0AD" is more likely the hidden "config" folder that currently lies in "~". It should also not be hidden if put there.
-
This seems to be basically what's needed, from a fast-read... As for deployment, on Mac, the apps usually require only to download them and play... Things more complicated, like xCode, which needs dependencies and many many things usually install in a "package" that puts everything where needed.
Linking to resource paths must be done on both the executable and the libraries. Given the variety of libraries used by O&d, I'm quite sure many are already in OSX, but I'm not sure exactly which, so we'll have to troubleshoot this.
And yeah, dropping anything earlier than 10.5 is likely not a problem, mac OS release are usually well followed ( 10.6 was in particular since it was 20$ ).
-
Are we getting random seeds for random numbers in AI?
-
I'm likely going to work on my free time on an improved attacking system. But I wouldn't want to try and do something that Quantumstate is already doing...
-
I gather all given resources and make a forward base near the bot.
train some archers and shield-guys with womens in the home-base and focus primarly on food and a bit metal.
on the forward base I train exclusivly shield-guys and archers that all get to put on wood, quickly build a fort and train 2 rams.
while those rams are producing I send my first little army to deal with their military and then join with a newly produced army and my rams.
What am I doing wrong?
I'm also very new at this game so I don't know any names of units, let alone what counters what. I'm always assuming it follows the rules I'm used to (aoe3)There's no counter right now, it will be in alpha 9 afaik... So pretty much spamming spearmen should do the trick, I think they're the strongest.
I'm gonna give this challenge a shot if I find time tonight... Not too likely however.
-
12 is confirmed as possible
. I'm now thinking even 10 might be on the edge of possibility, 11 looks pretty feasible. Remember that houses and dropsites are not conquest critical, so just concentrate on towers and the CC (if a barracks is built you were too slow 
) and killing the pesky workers. All this qbot playing seems to be persuading me that qbot is too weak though , .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.
-
My point, taking Mumie's lead, is that you have to identify what you want to accomplish by simplifying farms. I'm assuming you want to minimize management, while cost is not really an issue with you. Cost is an issue for me and others. So, if that's the case, then I can see some compromise here by implementing an auto-seeder mechanism. It would act like AOM's auto-queue with one click of the button, rather than like AOK's method of having to continuously queue up batches of reseedings.
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.
-
Tried it out on OSX 10.7, no luck...put the file in the 3 folders you said then tried running it, and it opened a blank window, then crashed...is the error report helpful? not sure which part to post if it is..it's huge compared to the ones in the last page.
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.
Progress reports on funded work
in Game Development & Technical Discussion
Posted
Very interesting stuff on the pathfinding here.