The challenges of developing a good AI to ever more complex games

[ZOOMIE1980]

ORIGINAL: Mr.Frag

ORIGINAL: Bodhi

ORIGINAL: ZOOMIE1980
And once again, his "memory" take seems taylor made for employing the use of an RDBMS and a client-server architecture.

What have golf clubs got to do with AI? [&:][:D]

Absolutely nothing at all [:D]

Storage of data has nothing to do with code function at all. Frankly, as long as the data structure is fast, it has no bearing on anything. It could just as simply be stored in XML or as java objects [8|]

Design of data management has a GREAT DEAL to do with how applications code functions. It also has a great deal to do with the amount of data you can manage. There is a REASON why financial settlement systems that deal with BILLIONS of data elements a day, use RDBMS databases and not assinine DOS style fixed, integral indexed arrays, to access and manipulate data and do so utilizing dyanamic containers. Every hear of a 'friggin' hash table? Bet this bunch hasn't!

What the hell is a "java object"? I have coded in Java for many years now, and I use all sorts of class object instances. I guess since they are all defined in Java, that makes them "java objects"? You talking Message Driven Beans? XLTS display objects? What?

Geez, stick what you know. Whatever that is.....

[ZOOMIE1980]

ORIGINAL: Oznoyng

ORIGINAL: Mr.Frag

ORIGINAL: Bodhi



What have golf clubs got to do with AI? [&:][:D]

Absolutely nothing at all [:D]

Storage of data has nothing to do with code function at all. Frankly, as long as the data structure is fast, it has no bearing on anything. It could just as simply be stored in XML or as java objects [8|]

I am suprised Zoomie hasn't nailed you on this one. The value of an RDBMS implementation is in the flexibility that it gives you for manipulation of data. How much space it takes, and even how fast it is are secondary to how quickly you can write the code.

- The best architecture for this kind of game is a pay-per-month game, where *all* data is hosted by the game provider on application servers with an SQL back end. You pays or you no plays.
- No counterfeiting cuz the game is worthless without the servers.
- It would probably run from your web browser - and it will have a better interface because programmers will be able to leverage the web forms capabilities of application servers to produce the interface changes almost as fast as users can request them.
- No OOB/restart issues will exist, because servers can be updated more easily. Fixing a problem in the OOB is an SQL statement.
- You will be able to have people entering turns at the same time, rather than taking turns.
- You will be able to do cooperative development of scenarios. You won't be making a list of changes and sending it to pry, or whoever, you will enter changes directly into the scenario.
- The speed of your machine will matter far less, because the AI isn't running on your machine.
- The AI can be changed on the fly to add capabilities.

BTW, I am quite happy with WitP. I just see alot that could be done with the right architecture.

Think you hit a lot of it right on the head. Highly distributed, virtual gaming systems are the norm nowadays in FPS and even some RTS games. They play VERY WELL in this genre as well. Probably even better. Wolfpack pioneered turn based wargaming via Internet servers over a DOZEN YEARS AGO. They use MySQL base servers. They simply lacked resources and programming expertise. But their concept was solid.

I absolutely believe this is the long range future of this genre of gaming. We simply have yet to get that spark. Sounds like something BEGGING for a SourceForge project....

[ZOOMIE1980]

ORIGINAL: Mr.Frag

ORIGINAL: Oznoyng

ORIGINAL: Mr.Frag




Absolutely nothing at all [:D]

Storage of data has nothing to do with code function at all. Frankly, as long as the data structure is fast, it has no bearing on anything. It could just as simply be stored in XML or as java objects [8|]

I am suprised Zoomie hasn't nailed you on this one. The value of an RDBMS implementation is in the flexibility that it gives you for manipulation of data. How much space it takes, and even how fast it is are secondary to how quickly you can write the code.

- The best architecture for this kind of game is a pay-per-month game, where *all* data is hosted by the game provider on application servers with an SQL back end. You pays or you no plays.
- No counterfeiting cuz the game is worthless without the servers.
- It would probably run from your web browser - and it will have a better interface because programmers will be able to leverage the web forms capabilities of application servers to produce the interface changes almost as fast as users can request them.
- No OOB/restart issues will exist, because servers can be updated more easily. Fixing a problem in the OOB is an SQL statement.
- You will be able to have people entering turns at the same time, rather than taking turns.
- You will be able to do cooperative development of scenarios. You won't be making a list of changes and sending it to pry, or whoever, you will enter changes directly into the scenario.
- The speed of your machine will matter far less, because the AI isn't running on your machine.
- The AI can be changed on the fly to add capabilities.

BTW, I am quite happy with WitP. I just see alot that could be done with the right architecture.

Everything you have mentioned applies to online rpg games, not a single aspect of it has any meaning to a war game where static units with static abilities move around a static map. Online games are *not* time based. Things can change all the time and it makes no difference. On a side note, paying someone else to have a cpu to run your game on costs money *forever*. If you want to pay $20 a month forever to play, thats fine. I'm sure 2by3 would *love* to switch over to subscription fees and just keep milking you for more money each month for a token feature like the online games do. [:D]

In a war game you have a set number of things that you use based on time. The only way to change a unit is to go back in time before the unit was ever used to allow it to be used. Sorry, but that is the very nature of time based games. You can't undo a problem in the past without throwing away everything beyond that point in time (restart).

by the way, anyone who talks about using relational databases to handle a lousy 2 megs of data is a space cadet [8|]

The primary use of the RDBMS is for the AI. With today's high performance RDBMS system we can store litterally TRILLIONS of rows of AI data with near INSTANIOUS access. All these AI concepts we;ve seen folks talk about here recently require massive data storage with quick access for AI purposes.

We can also store thousands of users individual game data elements and do so on powerful multi processor XEON based or powerful Unix servers. And that includes the graphic elements of these games as well.

And why the hell does this game use BMP's?

And why is my CPU always stuck at 90% with this game loaded?

[Oznoyng]

ORIGINAL: Mr.Frag
by the way, anyone who talks about using relational databases to handle a lousy 2 megs of data is a space cadet [8|]

For those of you wondering why Frag gets so much flak from some of us, it is for comments like this. Yes, he has spent a great deal of time helping the player community. Yes, he knows a lot about the game. None of that entitles him to belittle an opinion and it invites name calling and threads spiraling out of control. Nuff said.

As for the issue of whether it makes sense to use an RDBMS for 2 megs of data? There is only one litmus test for using an RDBMS: Would it make it faster to program the game? Many of the enhancement requests I've seen have been for showing more data and allowing for more filtering. Want to add more data to a display, like adding the airops, landcombat, surface, admin, and aggressiveness ratings to the leader selection window? Here is what I would have to do:

Add 5 columns to a select clause. (5min?)
Copy the presentation style for the existing columns (1 min)
Regenerate and redeploy the object to the server (1 min)

In under 10 minutes the feature could be added - and take effect for every user the moment I deploy the object to the server.

Oh, and btw, everyone wants filtering... I've got a new CV TF I want to create. Gimme a list of all Japanese naval leaders with leadership greater than 55, Inspiration greater than 55, airops greater than 60 and aggressiveness greater than 60 that are not currently commanding anything. Using indexed arrays, the code to accomplish it is alot more time consuming to write than it is with an RDBMS. Someone that wants to code the equivalent in C++, I'm too lazy and can't take the time. For me, it would be 1 line of code to allow that kind of filtering.

WitP and similar wargames are about managing largish amounts of data. Anyone that belittles the use of a tool that is universally used in business for managing data needs to rethink that position.

[vorkosigan]

Seems that this discussion is gaining momentum...

A unit is defined as the smallest element capable of independant action.

Let's call that 'agent'.

Anything smaller is simply an element of a unit as it can not act on it's own and does not need to be tracked.

True also, but note that, in WITP, most of the items on the game are elements. And you, while playing, usually combine several units and 'elements' and make up a new 'unit' - i.e. a CVBG. You basically build an 'agent' from those little ( or not so little) odds and ends - you set it with some objectives and set it to make it or fail. But that is in the game just for you - not for the computer. The computer does not need nor appreciate all that richness and detail. What on one side is 'chromed' to appeal the WWII buff, on the other side can - and should - be readily abstracted or simplified.

So saying that a current desktop computer can't handle planning and task assignment and design for 12,0000 'agents' is true (you would need something like ASCI White). But you don't need so much critters all the time

[vorkosigan]

ORIGINAL: ZOOMIE1980
Sounds like the starting material for a SourceForge project???

[8|] Why not? But let's develop the discussion a bit further...

ORIGINAL: Grotius
These posts are on the second page of the thread entitled "AI/No AI" in the WIF forum. See

tm.asp?m=640847

I will read that.

ORIGINAL: ZOOMIE1980
And once again, his "memory" take seems taylor made for employing the use of an RDBMS and a client-server architecture.

ORIGINAL: Mr. Frag
Storage of data has nothing to do with code function at all. Frankly, as long as the data structure is fast, it has no bearing on anything. It could just as simply be stored in XML or as java objects

ORIGINAL: Oznoyng
I am suprised Zoomie hasn't nailed you on this one. The value of an RDBMS implementation is in the flexibility that it gives you for manipulation of data. How much space it takes, and even how fast it is are secondary to how quickly you can write the code.

ORIGINAL: Mr. Frag
In a war game you have a set number of things that you use based on time. The only way to change a unit is to go back in time before the unit was ever used to allow it to be used. Sorry, but that is the very nature of time based games. You can't undo a problem in the past without throwing away everything beyond that point in time (restart).

by the way, anyone who talks about using relational databases to handle a lousy 2 megs of data is a space cadet

ORIGINAL: ZOOMIE1980
The primary use of the RDBMS is for the AI. With today's high performance RDBMS system we can store litterally TRILLIONS of rows of AI data with near INSTANIOUS access. All these AI concepts we;ve seen folks talk about here recently require massive data storage with quick access for AI purposes.

We can also store thousands of users individual game data elements and do so on powerful multi processor XEON based or powerful Unix servers. And that includes the graphic elements of these games as well.

ORIGINAL: Oznoyng
For those of you wondering why Frag gets so much flak from some of us, it is for comments like this. Yes, he has spent a great deal of time helping the player community. Yes, he knows a lot about the game. None of that entitles him to belittle an opinion and it invites name calling and threads spiraling out of control. Nuff said.

As for the issue of whether it makes sense to use an RDBMS for 2 megs of data? There is only one litmus test for using an RDBMS: Would it make it faster to program the game? Many of the enhancement requests I've seen have been for showing more data and allowing for more filtering. Want to add more data to a display, like adding the airops, landcombat, surface, admin, and aggressiveness ratings to the leader selection window? Here is what I would have to do:

I am always marveled on the amount of lag one gets on discussions when several TZ's away [:)]

I agree with both Oznoyng and Zoomie on the RDBMS issue: RDBMS are perfect for becoming the 'storage facility' of a 'high-tech' AI agent knowledge-base. The idea is not new: when people working on machine reasoning grew tired of brown-outs wiping out several hours of 'knowledge programming' they turned to the efficient persistence offered by DBMS.

I agree with Mr. Frag that someone that buys an Oracle license (or sets up a PostgreSQL server or even a MySQL server) for managing 2 megs of data is a 'space cadet' (a donkey we would say here on Spain). But:

i/ You will be managing more than 2 megs of data. Apart from the obvious (the OOB) there is the information one gathers as you play the game. For instace: "I got four hits on the Lexington and was set aflame" or "a convoy of AK's was detected on x,y heading west". If you have this information efficiently stored and properly indexed for fast retrieval you can set on top of that a reasoner - something simple like Prolog - and get the AI to make 'smart' chainings like: 'Since I beat the crap out of Lexington, it might be that now we have carrier superiority in the area' or 'I will dispatch two B-25 squadrons for a night raid over Rabaul port facilities, since Rabaul is in a straight line from (x,y) to the west'. Plain, unstructured blobs sequentially stored on a file is right for storing an FPS texture DB - but in this case something more sophisticated is needed.

ii/ You can use a 'lightweight' RDBMS - such as SQLite. I have personally worked with it and it's fast, SQL compliant an most important, easy to adapt to your needs. And last but not least, it sports LGPL.

PS: I appreciate very much Mr. Frag combativeness.

[vorkosigan]

And there is an example of this 'logicist' approach applied to wargames. Even delivered through Matrixgames: Campaigns on the Danube.

A friend of mine owns it and always is commenting on its AI outstanding 'situational awareness'.

[Oznoyng]

ORIGINAL: vorkosigan
I agree with Mr. Frag that someone that buys an Oracle license (or sets up a PostgreSQL server or even a MySQL server) for managing 2 megs of data is a 'space cadet' (a donkey we would say here on Spain). But:

Yes and No. For running a few thousand games and acting as the storage facility for those, Oracle would be a good choice.

For a client-only version of the game like WitP, I would use Sybase iAnywhere. Last I checked, you can use a runtime version of the engine and distribute it with your app for free. The runtime version does not allow schema changes. The entire engine resides in around a meg of disk space and there are no complex install routines. You develop your schema with the full engine, then just copy the .db file and use it with the runtime engine.

I set up a database for WitP data in iAnywhere. I exported data from the scenario files and I can now get all kinds reports that you can't get out of the game. I wanted a list of IJA Fighter group commanders that I wanted to look at as replacement candidates, so I wrote a quick query, and got the attachment below. It is a list of all IJA air units that have a leader with overall skill or inpiration less than 55, airops or aggressiveness less than 60, or administration less than 30. Sorry in advance for the sucky formatting, I do not have the web-enabled version of Powerbuilder at home.

[Ron Saueracker]

This all sounds great but doya think it will actually happen? I probably have a better chance of drilling Dana Delaney than seeing this come to pass.[:(]

[Oznoyng]

ORIGINAL: Ron Saueracker

This all sounds great but doya think it will actually happen? I probably have a better chance of drilling Dana Delaney than seeing this come to pass.[:(]

In a word, yes. As much as it pains me to admit it, Zoomie is right about a few things. One of them is that an RDBMS would make programming a game like WitP much easier. In a world where the costs of developing games are mostly labor ones, it will all go overseas and/or will leverage tools more to make it easier to do. In the world of pirating, the architecture that has the logic centrally located on servers that can't be copied is the one that will make the most money. Finally, a game that you pay for on a monthly basis will be updated, fixed, etc. One where you pays your money and gets what you gets is less likely to be updated.

[Mr.Frag]

You can disagree all you want, but do it from a factual basis.

Go into your WitP save directly. Look at the size of the file. Now that we are talking facts instead of fiction ... would you again care to discuss the amount of actual data involved?

Now, when one removes string names from that data (which is roughly 50% of the actual data) and gets down to real "data" that needs to be manipulated and remove all the whitespace, you are in the 500k range.

To deal with this 500K worth of data, you want to impose a 200+ meg overhead? *that* is what defines a space cadet [:D]

just for the "touchy" folks ... a "space cadet" is someone who chooses the most complex and costly method of doing something just to show how smart they are instead of using the simplest and most efficent method.

Now, if and when a game comes out that is *bigger* then WitP, perhaps we can revisit the use of an "normalized" database.

Not to mention the humor aspect of this, whats the going price for Oracle, Sybase, DB/2, Informix, MSSQL, etc? Think you can fit a runtime + connect licence into that $70 game price? [:D]

[Ron Saueracker]

I'd go for the billing concept. Sure would be cool if games like this could be less a labour of love and more a profit venture. I also like the possibility it provides for redesign, as design rigidity is why I cooled on certain aspects of the game. If it was generating regular cash flow it would not be too naive to think that it would not be prohibitive to reevaluate various decisions.

[vorkosigan]

ORIGINAL: Mr.Frag

You can disagree all you want, but do it from a factual basis.

Go into your WitP save directly. Look at the size of the file. Now that we are talking facts instead of fiction ... would you again care to discuss the amount of actual data involved?

Now, when one removes string names from that data (which is roughly 50% of the actual data) and gets down to real "data" that needs to be manipulated and remove all the whitespace, you are in the 500k range.

To deal with this 500K worth of data, you want to impose a 200+ meg overhead? *that* is what defines a space cadet [:D]

just for the "touchy" folks ... a "space cadet" is someone who chooses the most complex and costly method of doing something just to show how smart they are instead of using the simplest and most efficent method.

Now, if and when a game comes out that is *bigger* then WitP, perhaps we can revisit the use of an "normalized" database.

Not to mention the humor aspect of this, whats the going price for Oracle, Sybase, DB/2, Informix, MSSQL, etc? Think you can fit a runtime + connect licence into that $70 game price? [:D]

[:(] I do not wish to get involved in a flame war. Seems that nobody read my posts carefully or did not understand anything -> I do not understand why Mr. Frag tries to outmaneuver my points just using the same arguments I do. Did you bother to visit the SQLite site? And skim over the documentation? Or taking a look into code examples? Or cared to briefly ponder what means no license fee at all?

What angers me a bit is that predisposition to label people with different ideas as loonies, nit-pickers or *space cadets*. And then that self-sufficiency implicit in the "it works, ain't touch it" statement. It does not work at all - it barely works. And it can work better, if we wish it to. My position is not a criticism, per se, but just that of "some people have already done better - so anybody else can".

I was just trying to find people that thought alike just to make the thing to happen, as Ron Saueracker wisely pointed out in a previous post. I did not want to tread into the domains of gnarly, emotional, deaf trolls. Maybe I should try looking elsewhere [:(]

[Mr.Frag]

Commercial products can not be based on freeware no matter how attractive it may seem.

Think like this:

Lets say a game is written using "xyz". Game ships to paying customers. Whoops, "xyz" is broken. Sorry folks, we know you paid us money for our game but it's not our fault it doesn't work, it's "xyz's" fault. Maybe they will fix it someday but no, we are not giving you your money back. Not an acceptable position for a company to be put in ever. You use what you have the skill to fix in house. It's called risk management.

Still waiting to hear some legitimate reasons for using normalized data with such a small amount of data to deal with in the first place coupled with static requirements for data use.

Nothing inherently wrong with SQL, just pointless for such a small scale exercise. If you were tracking things down to the nit and wanted the ability to roll back to any specific point in time and you simple ran *everything* as a transaction against the database, that would certainly make it of use, but I've yet to see a game of this type with an undo button.

[Bodhi]

ORIGINAL: Mr.Frag
Still waiting to hear some legitimate reasons for using normalized data with such a small amount of data to deal with in the first place coupled with static requirements for data use.

You seem to be thinking exclusively in terms of WitP as it is, I think many of the other comments are related to how a game like WitP could be developed, especially from the viewpoint of an AI that is able to "learn" with data requirements that are not static. The original post, thread title and most of the discussion are of a more general nature than a discussion of the WitP way of doing things.

[Mike Scholl]

ORIGINAL: Ron Saueracker

This all sounds great but doya think it will actually happen? I probably have a better chance of drilling Dana Delaney than seeing this come to pass.[:(]

Somebody else with a "Dana Delaney fixation"? I knew there was a logical reason
why I so often agree with your posts.

[Mr.Frag]

Somebody else with a "Dana Delaney fixation"? I knew there was a logical reason
why I so often agree with your posts.

Too Old for me [:'(]

[Ron Saueracker]

ORIGINAL: Mike Scholl

ORIGINAL: Ron Saueracker

This all sounds great but doya think it will actually happen? I probably have a better chance of drilling Dana Delaney than seeing this come to pass.[:(]

Somebody else with a "Dana Delaney fixation"? I knew there was a logical reason
why I so often agree with your posts.

[:D]

[Tankerace]

..... tisk tisk tisk [:D]