Leaderboard
Popular Content
Showing content with the highest reputation on 2013-03-15 in all areas
-
I'm opening a new topic since the API version 3 has now been committed. Kind of a conclusion on the past 2 weeks' work before I head back to school, and probably abandon developing 0 A.D. for a good 2/3 months. Warning: this is a huge wall of text, mainly intended for my own reading later, so that I may pick up where I left off without too much trouble . So basically I'm fairly happy of how much progress has been made on Aegis in these 2 weeks of holidays I got (on top of the work I did back then). Defense has been fixed to a fairly great extent, the attack has improved, the economy has learned how to deal with technology and phases without really losing much in terms of efficiency (there's room for improvement, though), and generally everything has been made more robust than it was before. There is however still a lot to do, as most players and myself can already tell. I would like it if we could release a "Hard" AI that did not cheat. Currently hard mode cheats by gathering 33% faster (and very hard 66%). In order to do this, many things to consider: First, the AI build order needs to be perfected. I've watched replays of mainly Quantumstate and Alpha123, but there is still work to be done, everything is not perfect. Furthermore the economy manager still isn't completely rational in the way it assigns workers, which makes the AI lose a few precious seconds now and the, but this is particularly problematic in the early game. Also, it doesn't trade. Secondly, the AI is still very hardcoded. I've switched most of the "time" checks to "number of workers" checks but this is far from enough. The AI is generally hardly aware of itself when it takes decision, thus leading to average decisions, and mostly to a lot of trouble with unexpected cases. In particular, raiding the AI early currently tends to cripple it, as it does not recover well enough, trying to start attacks instead of focusing on rebuilding an economy, things like that. Thirdly, building placement in general needs to be improved. the code for dropsite placement is in itself fairly efficient, and returns generally pretty good results. However, the code that decides when to build a dropsite is extremely inefficient. Placement of most other buildings is basically random with a few tweaks and doesn't really follow any particular logic, when it probably should. Third big issue: the defense system is still quite flawed, both from the "no sense of self" effect of the AI, which will make it defend useless things, defend in obviously losing battles, or not defend enough when it ought to, and the many flaws in the logic. It's basically very "instant" defense, it doesn't really consider what happened in the past or what might happen. Case in point: a tower on the border near an AI dropsite will basically make it get all its workers killed as it doesn't really notice. Fourth big issue(s): attack and unpredictability. The first subpoint is that the AI sucks at attacking. Basically it makes relatively balanced armies, but it sends them to the enemy and doesn't really consider how to use these units the most effectively, making its attack mostly useless against a skilled (micromanaging) player. Secondly, the AI is extremely predictable. It has only one real "strategy", if you can call it so, which is also extremely hardcoded and not at all enemy dependent. Work on that is less of a priority, of course. The AI should probably handle the above points first, and then we will be able to consider making it actually do interesting things. Finally, I'll post again the "to-do" list I had posted on the AI API version 3 topic back in early november, as most of the points are still valid -No real naval support. It can handle attack over water, in a basic way, but that's it (Update: that actually might have become slightly buggy) -No handling of multiple-island realms. For Aegis, its starting island is all there is on the map. -No handling of the cases where the AI runs out of resources to gather. It will start lagging and clogging the queue manager. Linked with the above points. -The defense system is really basic. It can't handle continuous frontier skirmishes, placement of defense buildings is not logical, no wall building, it's not reacting perfectly to attacks either. No sense of "this is a dangerous area, I should avoid going/collecting/building there". No support for building units that counter the enemy favorite units. So many other things... -No diplomacy support (see Fexor's post in the general development forum) -Economy is still perfectible: drop sites placement and building could be optimized, as could be building construction, or even Build Orders in general. There are some slightly insane behaviours here and then. Generally this is probably the area where the AIs hold up the best, particularly Aegis. (Update: see above.) -Very partial technology support. Aegis goes up in phases, but it's not flexible. The API support for tech may not be perfect either. (Update: actually, it now researches all techs, but chooses them randomly. So work needs to be done on that). -Partial attack system. It's OK at strategy, but bad at tactics and will generally attack inefficiently (though Aegis is better than qBot at that). -no LOS/scouting support. AIs see everything. (Update: this is actually linked to making the AI react naturally: even when cheating, it should be aware of its enemies and take decisions based on them) -optimization is far from perfect, though it's slowly getting better. Some possible improvements: hierarchical entity collection filtering, getting the AIs not to iterate over all units in a single turn once in a while but balance the load... (Update: probably better now, but there is still ton of room for improvements). A last word about something that is still bothering me: the queue manager. Currently it gives "accounts" to each queue which grow over time as the AI collects resources. It works fairly well, but it has a tendency to make the AI sit on resources, particularly when the gathering rates are low and the needs high. I think going for the most human approach here is what would work best, but I must say I actually have little idea of what the "human" approach is. Basically we might need the rest of the AIs to register what they will probably want to train/build in the next minutes for the future needs to be fairly stable (which will also help econ…). Then we need the AI to actually pass stuff, making sure it doesn't sit on tons of food just because the next item needs a little wood, and to do it with the maximal efficiency. I am not sure what the best system for that is, but I think the current queue system isn't quite perfect. Edit: moved to general forum.2 points
-
2 points
-
From my understanding, a fairly large portion of ancient armies (or at least of the post-Marian Roman one) were formed of local auxiliary units. While I consider work on the AI and computer speed far more important than anything else at this point, I do think that this would be a very good feature for Part Two, especially with the introduction of the Imperial Romans. I would imagine auxiliaries as being keyed to the map at play, much like the Natives in Age of Empires III, though there probably shouldn't be little villages cluttering up the map; auxiliaries should be trained at a special building. The Imperial Romans should probably have a low amount of standard units and have a bonus for the local auxiliary units. Also, perhaps this topic could serve as a list of potential candidates.1 point
-
Hello, i am currently creating new AI for 0 A.D. as it is one of my interests to architect interesting to play against and adapting computer player. One that will not act same every time You play with it. For this reason AI is more like human and less like "all knowing" pre programmed machine. It has pregrommed game logic and concepts but tries to improve its game strategy based on previous experiences. For this reason statistical math would be used (I have experience in this field). Downside is that in order to learn from previous experiences ingame data is not enough and data from previously played games is needed. Possible ways to do it: 1.1) Local SQLite database ( + easy to embed, OS license) 1.2) Local PostgreSQL database ( + embedable, powerful, OS license; - not as slim as SQLite) 2) External/server based PostgreSQL database with past experiences of all feedback submiting AI instances. In this way AI could access large experience base and do really humanlike strategy decisions: building, organizing military attacks ( + large experiences database; - difficult validation of feedback quality) 3) Local PostgreSQL/SQLite database with prefetch of additional packs of "experiences" from server ( + large initial experiences database; + no critical dependencies on extenral/internet resource) What has to be done: 1) AI interface (from C++ side?) should allow scripted/javascript AI code to access persistent storage and execute SQL queries. In other words DB interface. What will be done from my side: 1) Code for AI 2) C++ code for interface with DB 3) Local and remote database architecture What is of question to me: 1) Should I coordinate this work with someone in order for it to be later merged into 0 a.d.? 2) Maybe posibility of persistent storage is no no from the perspective of Core team? Time frame: initial working result till middle of May. Maintainability: I have future plans to maintain this AI and involve other people in its development and development of 0 a.d. As I am working in the University and there is posibility to organise some of courses in the way that would benefit both students and lecturers and on the other hand 0 a.d.1 point
-
1 point
-
As a reply to the blog post, I am willing to help with any optimizations, but of course I do not want to do any work that has already been done. Since the last post in this thread is more than a month old, I was wondering what tasks are still available for a starting developer. As an alternative, maybe it'd be a good idea for me to find performance critical functions using profiling/callgrind and find something that is relatively easy to fix just to get started.1 point