pointer

Embeded Postgreqsl 9.1 is 20 Mb, when inited 34 Mb. Pgsql differs from similar products in its management and use of resources. Low resource usage combined with high level DB functionalities would allow to do more efficient data agregation inside DB and not in JS code of AI. Also, historical statistics of games played in the past and similar data could be stored in DB. As I understand that addition of any such 3rd party element would require a lot of consideration for core team, it would be nice if at least most minimal of embedable DBs - SQLite would be added. I am currently developing NewSQL type database (in C++) in some ways similar to Google Spanner, so I undestant pitfalls of RDBMS and some key/value or graph type databases would be very good addition, though added complexity too. As I see, the problem is divided into two: 1) Ability for AI to store data in persistent store. Universal interface for comunicating with database. 2) Specific implementation of DB used by specific AI.

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.

Version is 0.0.12. Will try to find application part responsible for object (people) path decisions and create a patch. Similar problem seems to be when city is garnisoned with walls and shortest route to the target leads via wall - object (peasant) doesn't reroute to go throw nearest gates.

Actors freeze as they want to take same path and are blocking each other. As they reroute at the same time, they block each others way again and infinitely. Video attached: http://www.screencast.com/t/aqAyAQZv