quantumstate

Thanks for the report, I have committed a patch which should fix this. I am unable to reproduce the bug so am not entirely sure about the fix so please say if it crops up again. For future reference it is sometimes helpful to know what map and roughly what stage of the game you were in. It would be nice to have but any bug report is better than none .

I have just enabled my newer military code. It can now defend the town so it also sets the citizen soldiers to work, making the economy even stronger. Other big effects are that it now builds towers and advanced buildings and trains advanced troops from those buildings.

Sorry, I have been submitting patches for the game to enable features which I am using in my AI. qBot isn't significantly better than JuBot (if at all) for the versions which will work so I don't consider it worthwhile to mark a release for alpha 7 compatibility. qBot will only be compatible with the svn version of the game until Alpha 8 at which point I will create a release version. My entire (not quite released) military design requires a newer game version plus some other useful more minor useful stuff (currently what breaks) is helpful. I just asked my friend to play-test a couple of hours ago and he hit upon the same strategy. The AI had trained (and lost) about 300 women by the end of the game. I will add towers (crudely placed) now since it is a trivial modification, I am not sure why I haven't done it before. I have actually written a defensive module, unfortunately it doesn't yet release the soldiers from its control so my AI never attacks when it is enabled. I should get it finished soon (time permitting). Edit: Just committed the towers plus quite a few other military improvements. I managed to make a complete mess with git branches but eventually it is all back correctly into the master branch.

I just tested on Latium, qBot built farms at the start. I have had a problem with a wood shortage in late game which should now be fixed and the map looks quite wood scarce so if you arrived at qBot later in the game it may just have run out of wood. I would advise against playing on Latium due to the wood deficit, until the resource drop code is written it won't give a very good game. I would recommend Oasis II or Hellanized Egypt, Badlands should be better for a random map but not great. Make sure you update to the latest version before testing again since I did some significant bug fixing. Thanks for the reports, they are helpful.

All of the AI's are under the same license so can in theory share things. Hindrances are the difference between the AI's (SplitBot is written in Haxe, and qBot has made fairly large architectural changes). I gave my reasoning for starting a separate project in my qBot thread. I certainly hope we can share some things between the AI's, I am pretty sure I will end up integrating some of JuBot into qBot. Currently I have been working on the core parts which make it difficult to be collaborative. I'm sure you didn't offend anyone.

I haven't looked into splitbot and I haven't tested with it much because I have found it a bit buggy (building placement before the fix, it also locked up occasionally/spat lots of error messages (which I should have bug reported but didn't, sorry)). Since I started with a testbot base and primarily test with JuBot opponents I can provide detail on the differences. Queue System The primary difference currently is my replacement of the plan system. JuBot doesn't plan ahead, by this I mean that practically nothing calculated in a turn is used after that turn. So Jubot looks at the current state and a bit of the past and works from there. Qbot's queue system tries to plan ahead, so with qBot the system queues ~70 female citizens from the very start of the game. It also queues up 30 soldiers at once. Stuff like houses it doesn't do so much since I want the population supply to keep up with the number of houses, otherwise wood is wasted. The benefit of this approach is that for resource gathering my AI can look ahead in the queues and see what will be needed and gather that ratio. In contrast JuBot looks to see what resource it is running out of for the plans at the current turn and gives them more workers, so JuBot should be less able to cope with sudden changes in resource requirements. The other benefit is speed, my system remembers stuff so things like workers training can be done less often since it has a big queue to work through. Note: I have been bug fixing the predictive resource code this morning after I found it wasn't working properly so testers may have noticed unbalanced gathering (probably too much food, stone and metal), this was a bug in implementation which will be fixed soon. I plan to look at the training rates and recognise when a lack of training structures will be a bottleneck, currently my AI doesn't build much so too much building isn't slowing its speed, in my brief testing I think qBot builds up fastest at the start of the game but then gets hindered by not being able to use citizen soldiers to gather. I also restricted economy a bit to help not lag the game with too many workers walking around. Economy This is fairly complete except for building resource drops which is unimplemented, I am thinking of using JuBots implementation, maybe with some tweaks. Military System My main current work is revamping the military section. This is still all sitting in my development branch because it is a heavy work in progress. It has taken me a while for two reasons: firstly I was away for a few days and have moved back to Uni so have had less time; secondly I have been messing with different approaches in general so have been thinking about the general architecture of the military section. What I have settled on is a system which tracks the id's of the military units. This will be faster than storing a role in metadata and continually rescanning the entities to look for units with the metadata. Also it forces keeping track of units more carefully, so it will watch the events for when units are destroyed and react based on this information. There will be a general military manager which will train units, keep track of the id's and manage everything generally. Then there will be attack managers which can request units and will then keep control of them until they die or it releases them for general use. So there will (hopefully) be a raiding module, a decoy module (which would be initiated by a main attack module), a "scorched earth" module (wipe everything in its path), a siege module etc. These will be strategic level control and will be chosen in some way so hopefully with enough different ones the AI won't be too predictable and can strike at weaknesses. Jubal mentioned that he was thinking of working on a battle level AI which would hopefully be able to be shared between AI's, so my strategic level modules would pass control to a battle controller when they encountered some enemy units. Terrain Analysis This is a completely theoretical plan which I haven't done any code for at all. It is below a few other priorities so will be a while before I could do any work on it. The idea would be for the AI to look at the map and pick out important features. My thoughts so far have mainly been about choke point identification. So it will be presented with the map and will produce a list of distinct routes to the enemy base. This would be helpful for attack planning and defence i.e. build fortresses blocking every approach. I think I know how to do this (basically find the shortest path, look for a narrow point sufficiently close to my base, store this, put a fortress arrow range sized unpathable region at that point, repeat until there are no more routes). Navy I have not thought about this. I aim to do the other stuff I mentioned first. I personally don't really like sea maps so would prefer a challenging AI on land rather than mediocre on land an sea. Conclusion That is a rough outline of what my AI does and what I plan to do to develop it further. Hopefully this will help people testing to see what is a bug and what is unimplemented and let the other AI people know what I am doing.

One thing you can try is using a text search on the 0AD folders. If you have a search that does indexing this can be very fast. Also all the data about any entity in the game is in the binaries/data/mods/public/simulation/templates folder. The rest is mainly source code with javascript stuff being in binaries/data/mods/public/simulation/ and the C++ source has a wiki page here but I don't know how accurate it is. It would be nice to unify it but I think a searchable system would be too much effort since you can do text search anyway on your computer.

Thanks for testing, obviously it isn't meant to do that, more to the point I haven't observed it do that. Could you tell me what map you were playing on and which player number qBot was?

I have been thinking a bit about what I would find useful for AI's. There is basically one idea that I think would be helpful to have in C++ so it can run faster. Basically it is the same method that testbot (and hence jubot/qbot) use to place buildings. So it is a set of image functions acting on a 16 bit one channel image. Useful functions would be: addInfluence(position, radius, strength, type) which adds a circular spot to the map with the amount added depending on radius. See spoiler for example: The parameters would be: radius (radius at which function drops to 0 strength), strength (increase amount at centre point), type (the type of drop off function). If this was able to be calculated very rapidly I would use it for a large number of things in my AI. Building placement is already like this, adding an influence for each tree would allow efficient resource drop placement. Using enemy soldiers you could calculate the centres of enemy armies so working with groups of soldiers rather than individuals. Enemy villager concentrations would be useful for raiding. Negative influences could be used to create avoidance maps for attacking armies so my soldiers don't try to fight within range of a fortified position without siege. Basically everything where there are large numbers of entities on the map can be helped by using this to find concentrations of that thing. Additional useful functions would be an equivalent of expand influences (see testbot for a sample implementation) which acts roughly like a blur. For reading the map findMaxima and findLocalMaxima would be helpful. They don't necessarily need to be perfectly precise, speed is a high priority. The reason I suggest these to be added to the C++ api is that they are cpu intensive and for things like finding enemy armies it would be good to run them as frequently as possible. Another separate thing which could be nice would be an API which tells the AI how much processing power it can have, so on fast computers it could compute things more frequency to get more up to date information and play a bit better but on slower computers it could not make the game lag. I was thinking that the current profiling code could be used for that. My current AI design will have a timer slowing certain things down anyway so it would be easy for me to handle (to some extent). Finally I would like a promotion event, since currently it simply sends deletion and creation events.

I can't really comment on inter-civ balancing very much but I have noticed some pretty big problems with some units. This is a pretty uncomprehensive list though. Spartan hoplites are heavily overpowered, 5 spartans can take on 15 standard spearmen. Athenian Ekdromos were barely better than the thracian peltast in my test, this is possibly because of the tendency of ranged units to all target one unit at once which tends to lead to over-saturation of spears per target so the advantages disappear. Siege is rubbish against units, even the ballista which are meant to be good vs units. Splash damage would probably go a log way to helping this. In my tests you needed something like 3 times the resources spent on siege vs peltasts. Celtic war dogs seem to be too strong for their cost, only needing food gives a major advantage with he current farming system which gets lots of food with little management, also they are cheap even counting wood as equal weight to food.

Currently you have to manually type the ip address of the host in. You could try the irc channel for finding other players. In the future there will probably be a lobby system built but not in the immediate future.

In my previous post I was trying to say that the rounding problem can move the position literally halfway across the map (in the horizontal direction). Could you try this fix: var scaledX:Int = Math.round(x / MapHelper.TILE_SIZE); var scaledY:Int = Math.round(y / MapHelper.TILE_SIZE); var position1D:Int = scaledX + MapHelper.map.width * scaledY; In MapHelper.hx line 138.

I think that for the game to modify anything in the program files folder is against the rules. So only the installer should be touching program files. This is good for security since it means stuff won't be touching program files without admin permissions so your program can't get subtly modified by a virus. So the games cache isn't meant to go there since it will be modified after install.

Hunting was used by very good players because it was the fastest gathering resource. It was micro intensive which meant that not so good players (like me) found it too much hassle (except boar). Early in the game is vital for serious AOE2 playing so a little extra speed for food gave a serious advantage.

Looking through the code there is one possible source of error that I can see. In your getMapDataAtCoord function I notice that you do round( (x + y*width) / tilesize ) Refactoring you get (almost, you could get +-1 from rounding, but it is clearer like this): round( x/tilesize ) + round((y/tilesize) * width) From this you can see for example if y = 26 then y/tilesize = 6.5 so after multiplying by the width you get a stray width*0.5 added on sending the x coordinate right across the map. So just make sure you round straight after the division before converting to 1D and hopefully it will work. To minimize other errors I would recommend keeping your buildings at a constant orientation since with your corner checking it would be possible for the edge of a building to cut over the corner of another without the corners or centre being obstructed.

I would be interested in your ideas. One thing I might suggest is to take a glance through the design document and making a quick search of the forums before typing up your ideas. This will save you the work of writing out ideas that are already planned and will make it more interesting for the rest of us since we will be reading new ideas . Horses requiring land is an interesting idea, and would be pretty easy to implement. One question is what happens when I lose territory, do my horses start dying? (I don't think that would be good, I would just block training). I think slow breeding times would be annoying. 0 AD isn't realistic in that way, people don't breed like rabbits either yet they spawn rapidly. It would penalise a strong economy player by limiting their build rate (this is my favourite play style so I have vested interests ). I still am unsure about the merits of horses requiring land, it requires more thought, at the moment I am swayed in favour of the idea.

I have pushed an update which reallocates workers occasionally and also fixes a divide by zero error in the resource priority code, the result is that it now works correctly and doesn't fatally run out of gold. Also I fixed a typo so the maxattacksize thing actually works now.

My favourite would probably be Rome TW, it is pretty old by now though, or maybe Medieval 2. I think the gunpowder ones (Empire, Napolean) aren't as good since the tactics are so different. I would mention that they are a completely different style to the Age series, since the economic side is turn based and on continent scale. I found them very fun though. Have you played any of the command an conquer series? They are less economy focused but are very good games as well.

I suspect that this is because with the new house building logic jubot now tries to build multiple buildings per turn. With qBot I found that when you try and do this, because the build commands are not instantly executed the new foundation doesn't affect the obstruction map (since the foundation doesn't exist yet) so the building placement puts another on top of it. The easiest fix is to just limit your AI to one building placement per turn which works fine since you couldn't build that fast. This would be new because the building logic has changes in jubal's latest patch to make houses demand driven.

What problem have you found? In my testing the collision map hasn't given me any problems.

Ah, thanks for this I had been wondering why it stopped training, that makes sense now. The reason is that the worker reallocation isn't written yet so by the time gold starts being needed by the dynamic resource demand system all the villagers are allocated to food or wood.

There are actually events being generated currently which include an attack notification, AI's can't access this at the moment though. I just created a ticket for it since it is a two line change. http://trac.wildfire....com/ticket/972 . Detecting attacks before they hit is a different matter but is an internal AI script matter. There are quite a lot of other general things which need work however, I guess me(qBot), Jubalbarca (juBot) and lexa (splitBot) are the main active people working on AIs, other people at the dev meeting would be better for other stuff.

Yes, this is because you have multiple qBots. The default attack behaviour currently is to wait until they have twice as many soldiers as the most powerful enemy. So they were just sitting because the other qBots would have matched the training rate. This is because I haven't got round to implementing most of the military module. I have set a new maxAttackSize=60 as a quick fix. That sounds strange, I haven't seen behaviour like that. The current building placement code is still from testbot and is due to be replaced though (sometime, there seems to be a lot of stuff to be replaced ). I think my idea of a really strong economic bot (lots of workers) is probably causing a lot of slowdown as well. I have lowered the max number of gatherers a bit for now. Edit: You are indeed correct in your edit.

That sounds pretty good in general. I will hold off doing this at the moment because of the lacking defence logic. Currently the defence works by letting the idle soldiers attack when the enemy gets within the radius (this is unitAI code). So setting them to become workers automatically would mean that there would be no defence at all with the current AI, the attackers would gradually slaughter them 1 by 1. But once incoming enemies can be spotted this would be good. Also I have just commited a change to the resource predictions. From a quick test it seems to be allocating them a bit better and it should cope better in the future.

Thanks for the comments, at this early stage my planned improvement list seems to be pretty large, quite a few are "architectural" things which makes it hard to figure how much improvement they will give initially but should help later on. Yes this is a problem in the predictive system because houses and barracks get put into the queue just before they are needed so the prediction code can't see them far in advance. This is compounded by the economic manager never reassigning villagers. I plan to fix both of these problems fairly soon by rewriting the futureNeeds function and implementing the villager reassignment (I just need to make sure the villagers aren't being reassigned constantly wasting loads of time walking between places). This sounds like a pretty map dependent fix, I would prefer to have a better system. The jubot approach should be better in principle, I haven't looked in detail at how it works though. I don't think it is worth spending time figuring out how to do your suggestion when it will be replaced later. The main complication for this is sorting out how to juggle them between the economic and military managers. I think generally the military manager should have priority and will be able to use the citizen soldiers whenever it wants them. The military manager is still is a state of flux so it might be best to leave this at the current time until it stabilises, otherwise the changes may get out of date very fast. The villager reassignment issue will also affect this. It would be great if you do want to work on patches, it is just that I don't think that this area is a good one to look at currently, unless you plan on broader changes to the current role system.