A Lesson for Matrixgames. ;)

[ravinhood]

Oh he's got you there, what about VASSEL?

But, Vassel doesn't use an AI does it? (darn I thought we had him) hehe or you rather, you guys are talking WAYYYY over my head now. I just come up with ideas, you're the ones that are suppose to be smart enough to implement them.

Also here is another idea I have. An AI DATA CACHE, this is a file that increases in size as the AI plays the human which sort of does "learn" how the human plays and counter acts it by doing something new.

This idea is more for games like Warlords or Civilization or Spartan not so much a hex based wargame, but, might be able to be coded in some way to use there as well.

For instance AI initial attack is toward a city, this city is well defended, put that in the AI cache.

With that in the cache it's next outing might goto another city or another "objective hex" and record the outcome of that situation.

It could record battle odds and thus not send more weak units or stacks to the same place it just lost by having weak units or stacks. Perhaps placing a marker on the humans units, it knows its composition now, why not record it (that's what we do) and keep an eye on it and go after it with an increased odds stack instead of sending another puny weak unit or stack out to engage it?

It could record the battle odds and increase them and then go back to that city it was beating its head upon with double or triple power.

Everything on the map is not the most important thing, thus "unseen objective hexes" could be plotted within the makeup of the game to give the AI more cordination and organization about where to move, and with what force and where to defend and with what force.

I've seen some simularities of this in Slitherines Spartan, but, it doesn't learn, thus it will send one stack after another to the same city over and over and that's where it loses, because I will just sneak a stack behind it and start wiping out it's inner or rear cities and it never responds to this quick enough in the end. It's still a great AI, but, if it gives me time to setup that defense in that one city, then I have the advantage, I don't always have that "time" though, so I've lost several games.

Something else I brought up before was to cut all wargame maps down into 64 squares/hexes each and the AI concerns itself with the first 64 squares, then looks at the flanking 64 squares for 2ndary maneuvering. This like chess, since they keep saying chess is so easy to program the AI. If the AI doesn't have to monitor the entire board at once, looks like to me if you bring the scope of vision down to just what is in front of it and to it's flanks with only 64 squares in each to observe it would be easier for it to make a good decision. It always seems (especially with HPS games) the bigger the map, the worse the AI gets. This is pratically true though for all wargame AI's. There's no use calculating how to take Los Angeles when you haven't even taken Washington yet I don't think. And I've seen games where the AI in fact does this type of maneuver, trying to take something on the opposite end of the map when its got clear and untaken objectives right in front of it.

Next problem: Understanding defense. Understanding the Objective is to WIN. Combat Mission would be the number one game of all time, but, the AI is stupid near the end of the scenaro. It's on a defensive mission and it breaks out of it's foxholes near the end and does this parade of death towards my well protected line of attack. It's practically suicidal. It does the same thing in meeting engagements when IT'S AHEAD, it would win the stupid battle if it would just hold it's ground, but, those "objective hexes" have been programmed to be too important and it breaks its line and it's defense trying to take the sole and only objective hex I occupy and thus my men slauther it and I end up winning. That's just sad, really sad. lol

[Veldor]

ORIGINAL: ravinhood

Oh he's got you there, what about VASSEL?

But, Vassel doesn't use an AI does it? (darn I thought we had him) hehe or you rather, you guys are talking WAYYYY over my head now. I just come up with ideas, you're the ones that are suppose to be smart enough to implement them.

No, Vassal doesn't have an AI, that wasn't my point. My point was rather to state the obvious. That anytime something is initially made to be all encompassing, sacrifices are made. But, at the same time it doesn't mean that it can't eventually be better in every regard. Vassal achieves an otherwise insurmountable task of providing a single universal interface, graphical display, input and network play system for the widest possible range of dissimilar titles possible.

It does this by reducing, to some extent, all game types down to certain common aspects. At the same time, certain design parameters are forced upon the games creator in order to achieve such. The same would be true of any AI type solution. Perhaps the developer would have to lay out game elements in a particular way or format in order to "fit into" the AI as made. Or perhaps, with added modular coding, the developer could break some of those boundaries and still find use for the "engine".

Vassal, as is, is a far cry from a "Wargame Development Platform", but its progress and achievements thus far is still proof that such a concept is not totally unfounded, including one which might include an AI (Or Game Logic for that matter in the case of Vassal).

[Veldor]

ORIGINAL: ravinhood
Also here is another idea I have. An AI DATA CACHE, this is a file that increases in size as the AI plays the human which sort of does "learn" how the human plays and counter acts it by doing something new.

Actually thats not too far off from what I meant when I mentioned Server-Based AI earlier. One of the reasons for Server-Based AI is to have a single compilation of all gameplay actions and results. This also keeps the large file off of each client and allows for a bigger relational database to run on the backend. A simpler version of this would have you upload a file to the server at the end of each game and download the "New AI" say on a monthly basis for running on your own PC. On the higher end its basically a neural network, but there are plenty of hybrid versions and concepts to pick from as well.

A true neural network is really a b!tch to work with, a more hybrid approach is much more practical. A convential A.I. is like an old dumb dog that can't learn new tricks. A neural network is like an infant that at first doesn't know a finger from a toe but essentially learns everything (perhaps becoming the next Einstein or, often just as likely, the next Paris Hilton) [:D] Hybrids vary but can be more like having that grown up infant neural network around to correct that old dog when he's pissin where he shouldn't be... [;)]

Anyway you cut it, they are much more time consuming to make.

Experimenting with and Implementing these types of things are one of my longterm goals for the titles I'm working on. I've actually been toying with making a simpler free wargame to demonstrate some of the principals behind the logic.

[Shannon V. OKeets]

ORIGINAL: Veldor

ORIGINAL: ravinhood
Also here is another idea I have. An AI DATA CACHE, this is a file that increases in size as the AI plays the human which sort of does "learn" how the human plays and counter acts it by doing something new.

Actually thats not too far off from what I meant when I mentioned Server-Based AI earlier. One of the reasons for Server-Based AI is to have a single compilation of all gameplay actions and results. This also keeps the large file off of each client and allows for a bigger relational database to run on the backend. A simpler version of this would have you upload a file to the server at the end of each game and download the "New AI" say on a monthly basis for running on your own PC. On the higher end its basically a neural network, but there are plenty of hybrid versions and concepts to pick from as well.

I did a little work with neural networks and tracked the 'industry' closely for several years. I'm no longer current in what's state-of-the-art though.

I believe that simpler storage structures are possible when recording success/failure for specific game designs. The Warlords' example could probably be condensed to what went forth where, what did it run into, and what happened. As with all of these things, the lesson learned is context sensitive. In Warlords, the next time you venture forth you can expect the enemy to have a bigger army. My point being that a database of "lessons learned" can be quite compact and not require a server. Combining lessons learned from disparate sources is always dangerous - there might be garbage mixed in with valuable information and the AI unable to differentiate. If the database is maintained locally, then the lessons are more likely to be applicable to the person the AI is playing against.

[Shannon V. OKeets]

I haven't played a Vassel game - not enough hours in the day (Isn't there somebody working on that problem? And how about the teleportation machine I've read so much about - that would save everyone a lot of time). I've downloaded Vassel and looked at the graphics and have no negative comments about it (now that says a lot doesn't it?). It does what it sets out to do, would that we all could do that.

Still, a universal interface has been in development since the 1970's (Xerox Parc); Vassel's war game engine is the new addition. That probably needs another year or so to develop into a solid, robust engine. I keep reading posts about people having troubles getting started, though once they are over the initial learning curve, players seems very happy with it.

AI for wargames is still in its infancy. There were a few games in the 1980's but very limited in scope (size of map, # of units). CIV II being an exception (if I have my dates right).

And the development of the industry (if I may use such a grandiose term for this small community) is rife with proprietary software, trade secrets, and non-disclosure agreements. Not exactly a conducive environment for the rapid exchange of ideas and synergistic growth.

Ah well, back to the 100,000 lines of Pascal code I inherited.

[Captain Cruft]

ORIGINAL: Shannon V. OKeets
So let me see if I have heard you right. A war game should provide:

(1) modifiable user interfaces,
(2) documented database formats,
(3) good documentation,
(4) APIs,
(5) key bindings,
(6) integration with the O/S environment,
(7) etc., etc.

Perhaps I should have made myself clearer. I try below ... My aim is certainly not to prevent developers making money out of their IP, quite the opposite in fact.

(1) The user interface should be good (intuitive, fast, have safety checks against mousing/typing mistakes, ...) and provide flexibility to accommodate the diversity of the needs and desires of the user community. It should not be a universal user interface designed so players can mess around modifying it to their heart's content. The idea is to hit the ball with the golf club, not retool the golf club. If we ever get around to playing tournaments with hundreds of thousands of dollars are at stake, then I will agree with you on this.

There is the user interface and then there is the cruft. The "interactive map" part of a game where you move and direct units is its core, and I would not propose that should be modifiable. What I am talking about is all the peripheral stuff e.g. menus, dialogs, text strings etc.

(2) Within limits. There is a desire to retain some proprietary information. Your $70 doesn't buy you the source code.

Absolutely. Each game should make it clear what is proprietary and what is not. Then the parts that are declared to be open should be fully documented. Right now I don't know of a single game where this has ever been done. Vagueness abounds ...

(4) Same argument as for #2 but made more forcefully by speaking louder.

This is really the same as question 2. Those parts that are open should be as accessible as possible. What I am trying to get at is that, given their long life-spans, wargames should be more like application development platforms than movies or CDs. Microsoft has not suffered by other people being able to develop on their platform. Quite the opposite.

(5) Same argument as #1 plus ... You can buy other software to modify your keyboard bindings. If this is a big deal for you, I recommend it.

You have the wrong end of stick here, sorry. I am talking about being able to drive things using the keyboard as well as the mouse. That is not something that can be solved by external programs. Every game function should be accessible via both the mouse and keyboard. That applies to any other type of application too.

(6) Oh yeah, here is a great idea. I am sorry for the sarcasm but I have been programming since the 1960's and the OS's come and go. Trying to figure out the inner workings of an OS (and a compiler too by the way) is a ton of work and a constantly moving target. You do want the game to run with the next release of the OS don't you? Or do you seriously expect the developer to go back and rewrite the code internals for all of the games you have purchased every time Microsoft releases a patch to its OS?

Misinterpretation, I should have been more explicit. All I'm talking about is things like being able to copy and paste data or being able to bypass the load/save dialog and go straight into a save file. You know, simple interaction with other programs via standard O/S mechanisms (clipboard and command line).

--
Compared to actually writing a good game all of this stuff is trivial.

[Shannon V. OKeets]

ORIGINAL: Captain Cruft

(1) The user interface should be good (intuitive, fast, have safety checks against mousing/typing mistakes, ...) and provide flexibility to accommodate the diversity of the needs and desires of the user community. It should not be a universal user interface designed so players can mess around modifying it to their heart's content. The idea is to hit the ball with the golf club, not retool the golf club. If we ever get around to playing tournaments with hundreds of thousands of dollars are at stake, then I will agree with you on this.

There is the user interface and then there is the cruft. The "interactive map" part of a game where you move and direct units is its core, and I would not propose that should be modifiable. What I am talking about is all the peripheral stuff e.g. menus, dialogs, text strings etc.

...

What I am trying to get at is that, given their long life-spans, wargames should be more like application development platforms than movies or CDs. Microsoft has not suffered by other people being able to develop on their platform. Quite the opposite.

...

I am talking about being able to drive things using the keyboard as well as the mouse. That is not something that can be solved by external programs. Every game function should be accessible via both the mouse and keyboard. That applies to any other type of application too.

...

Misinterpretation, I should have been more explicit. All I'm talking about is things like being able to copy and paste data or being able to bypass the load/save dialog and go straight into a save file. You know, simple interaction with other programs via standard O/S mechanisms (clipboard and command line).

--
Compared to actually writing a good game all of this stuff is trivial.

Providing the ability for the player to modify menu, dialogs, and text strings is a lot of work. They all have to be designed as modifiable from the start, stored in some form, presented to the user so he can manipulate their elements individually, stored under a unique file naming system so they are acessible again, ... I just did this for a report generating system and believe me, the statistical analysis and mathematics of the core program were 1% of the code compared to the report design and the interface to go with same. Drag and drop routines are very difficult to write and debug. Every element of the interface that can be dragged has to be uniquely coded for its interaction with every element that can have things dropped on it. A real pain to keep track of, since all the variables for all the different elements have to be kept in mind when coding. Object oriented programming makes this doable, but it does not make it easy.

Microsoft's user base is 3 (4, 5?) orders of magnitude larger than a wargame product. I think they have a several more people working on code too.

I do agree on keyboard control as well as mouse control. There are limitations (drag and drop come to mind).

I would say that the emphasis should be that all this stuff is additional.

[Captain Cruft]

OK, yes it is all more work. Undeniable. Plus my analogy with the lovely MS was probably a bit silly. The basic point remains though:

Non-monolithic = More customers in the long-term

Personally I would just settle for

Code: Select all

 c:\ game.exe savefile.dat
 

There's so much you could do with that one little thing. Not exactly threatening anything is it?

[Shannon V. OKeets]

ORIGINAL: Captain Cruft

OK, yes it is all more work. Undeniable. Plus my analogy with the lovely MS was probably a bit silly. The basic point remains though:

Non-monolithic = More customers in the long-term

Personally I would just settle for

Code: Select all

 c:\ game.exe savefile.dat
 

There's so much you could do with that one little thing. Not exactly threatening anything is it?

DOS?

The thrust of your concerns is for better game interfaces and on that point I am in full accord. What I have found makes game interfaces better is forcing the programmers to use what they design. If they actually have to sit down and try to accomplish all the various tasks that the interface enables, then a minor miracle occurs. The programmers go back and rewrite the code so their lives will be easier. If they never actually play the game the same way the purchaser does, then the programmers lack the sensitivity as to what is annoying and what is mind-numbingly tedious. Start up routines/processes are typical candidates for sloppy programming, because when debugging code, the programmers bypass most of that stuff every time they execute the software.

Anyway, we try our best but "perfection is an elusive goal".

[Veldor]

ORIGINAL: Shannon V. OKeets
If the database is maintained locally, then the lessons are more likely to be applicable to the person the AI is playing against.

This doesn't work with a true neural net because its not enough training for the AI. And if you had trained it enough beforehand, its not enough additional input to alter the AI in any noticeable way. Also, with any of this, there is the possible issue of available cpu cycles. That's why hybrid methods are attractive, but thats really all unpaved territory so its hard to say exactly what would work best (local, non-local, etc.). As I proposed earlier, from a purely anti-piracy standpoint, anytime you can legitemately require someone to be connected to the net in order to play your game you are assured nearly 100% legal players (as in the case of MMPORGs) so there is some considerable interest out there in having Server-Based AIs.

Also, to use the tired Chess analogy.. Yes its easier to beat an opponent if you know what moves he likes to open with, what piece he covets, how good he is in the endgame.. but if your AI is good enough none of those things matter because your really choosing the BEST response in the first place.

You could do some kind of weighting. Personally I'd see at least 3 levels..

1. Lowest Weighting = AI playing against itself or against a traditionally written AI.
2. Middle Weighting = AI playing against another human player.
3. Highest Weighting = AI playing against that particular player.

Garbage is and isn't the greatest problem. If its designed right (true of anything no?) then it should have no impact. I suppose a user could go around making purposefully stupid and odd moves to try to get the AI to LEARN bad practices. But to use the chess analogy again, say a user opened with a rook pawn 1 forward followed by the other rook pawn 1 forward... All that should do is add to the "database" of exact situations encountered and how they played out. The AI should still be more than capable of beating such dumb moves, even a traditional AI at that...

On a seperate note, 100,000 lines of Pascal? I was seriously unaware that anyone still used that language in any industry. The last time I used it was 14 years ago which is like a century or two in computer years. I hope your not talking about your game code [:D]

[Captain Cruft]

The DOS legacy is definitely part of the "monolithic" problem, if not the main cause.

My illustration represents the Windows command line, such as it exists. If you can pass a file name to the executable as an argument then you can set up file associations so that you can click on files in Explorer and go straight to the map. Or do the same thing with email attachments for PBEM.

None of the wargames I have played can do this. It is such a basic thing I find it unbelievable frankly. Why make things more difficult? Why replicate functionality provided for free by the O/S? Are you selling a game or a load/save dialog?

Yes it's a pet peeve ...

[koiosworks]

For those interested in game AI programming. I suggest 2 great books.

AI Game Programming Wisdom (with CD-ROM) (Game Development Series)
AI Game Programming Wisdom II (with CD-ROM) (Game Development Series)

http://www.amazon.com/gp/product/158450 ... 5&v=glance

Covers everything from pathfinding to influence maps. Lots of tried and true techniques with practical examples.

One must look at AI in many respects. AI != game difficulty neccessarily. For instance, I can make an impossible to win game with almost no AI just by stacking the cards.

Should AI act like a human opponent, make mistakes, be random etc.. or should it be the perfect 'grandmaster'? Should AI cheat to make a harder game or be 'pure' but perhaps easier?. There are many such topics to building a solid AI. Many may disagree on what makes a great AI. For instance, i hate cheating AIs but some love them (for instance, giving the computer full knowledge of your orders so he can react to your plans). So, to each his own I say. One man's terrible AI is another mans dream opponent.

As for us, our team came from the world of programming complex business AI for supply chain applications and we used heuristics (genetic algorithms) for our games instead of linear programming or decision trees. The tin soldiers AI doesnt rely on cheating either which we are proud of (eg. for instance it does not know your orders). BTW, Alexander's AI is probably better than Caesars since we had too many complaints of "too hard to win" so we dumbed ol Julius down a wee bit [&:]

[Shannon V. OKeets]

ORIGINAL: Veldor
Garbage is and isn't the greatest problem. If its designed right (true of anything no?) then it should have no impact. I suppose a user could go around making purposefully stupid and odd moves to try to get the AI to LEARN bad practices. But to use the chess analogy again, say a user opened with a rook pawn 1 forward followed by the other rook pawn 1 forward... All that should do is add to the "database" of exact situations encountered and how they played out. The AI should still be more than capable of beating such dumb moves, even a traditional AI at that...

On a seperate note, 100,000 lines of Pascal? I was seriously unaware that anyone still used that language in any industry. The last time I used it was 14 years ago which is like a century or two in computer years. I hope your not talking about your game code [:D]

The starting premise was that the AI was learning from the experience of playing. If the opponent is always vulnerable to a hard forehand down the line, then the AI will learn to use that winning tactic. If the opponent defends brilliantly once he gets to the net, then the AI will learn to make sacrifices to avoid that situation. When a different opponent appears, then the lessons learned can be invalid. That is why I view garbage data as destructive to the learning process.

For yet another chess example, its easy to beat many beginners in chess by playing (as white) King Pawn -> King 4, King Pawn -> King 4, Queen -> King Rook 5 and winning black's king pawn (black's second move of pawn to king knight's 3 is common, which drops a rook too). If instead black protects the king pawn, then move Bishop to Queen Bishop 4 and threaten the mate. This attack can be continued rather aggressively for a few moves and beginners have a lot of trouble finding the right defense. Against any quasi-experienced player this opening for white is terrible. I would not like any AI program I created to learn the lesson that this opening should be used.
----
Does it seem any better when I say that the Pascal is the latest release of Borland's Delphi (Turbo Pascal all grown up and now object oriented)? My cynical view is that it is still Pascal at heart. And yes, it is the game code I am working on. I actually really like programming this and get up at 5 every morning full of energy to make more things run right.

[Shannon V. OKeets]

ORIGINAL: Captain Cruft

The DOS legacy is definitely part of the "monolithic" problem, if not the main cause.

My illustration represents the Windows command line, such as it exists. If you can pass a file name to the executable as an argument then you can set up file associations so that you can click on files in Explorer and go straight to the map. Or do the same thing with email attachments for PBEM.

None of the wargames I have played can do this. It is such a basic thing I find it unbelievable frankly. Why make things more difficult? Why replicate functionality provided for free by the O/S? Are you selling a game or a load/save dialog?

Yes it's a pet peeve ...

Interesting. It is easy to code (if you know that the capability exists). Personally, most of the time I run applications by clicking on the program's execution icon and not a file. For the interface I am designing the first screen the user can act upon has the files he has most recently used listed and double clicking on one of them can restore a saved game. Not a lot of additional bother - but some I guess. And other games have a series of steps the player has to dance his way through to achieve the same result - awkward for those of us getting along in years.

[Shannon V. OKeets]

ORIGINAL: koiosworks
Should AI act like a human opponent, make mistakes, be random etc.. or should it be the perfect 'grandmaster'? Should AI cheat to make a harder game or be 'pure' but perhaps easier?. There are many such topics to building a solid AI. Many may disagree on what makes a great AI. For instance, i hate cheating AIs but some love them (for instance, giving the computer full knowledge of your orders so he can react to your plans). So, to each his own I say. One man's terrible AI is another mans dream opponent.

As for us, our team came from the world of programming complex business AI for supply chain applications and we used heuristics (genetic algorithms) for our games instead of linear programming or decision trees. The tin soldiers AI doesnt rely on cheating either which we are proud of (eg. for instance it does not know your orders). BTW, Alexander's AI is probably better than Caesars since we had too many complaints of "too hard to win" so we dumbed ol Julius down a wee bit [&:]

I am firmly in the 'pure' camp.

Do you mean heuristics or genetic algorithms? I see these as two different methodologies. Hueristics can be dedicated algoritms, though they usually are rule based structures/processes, based on expert knowledge. Genetic algorithms are structured to learn through trial and error with numerous repetitive trials separating the poor performers from the good in a generational scheme of cross breeding (with some random variation thrown in).

Dumbing down the AI opponent is a happy endpoint to a successful design - congratulations.

[Veldor]

ORIGINAL: Shannon V. OKeets
The starting premise was that the AI was learning from the experience of playing. If the opponent is always vulnerable to a hard forehand down the line, then the AI will learn to use that winning tactic. If the opponent defends brilliantly once he gets to the net, then the AI will learn to make sacrifices to avoid that situation. When a different opponent appears, then the lessons learned can be invalid. That is why I view garbage data as destructive to the learning process.

I'm not sure that any AI too date has detected patterns in a player through the course of several games (that amounted to any significant change in the AI's strategy & tactics that is). Its tough to program a standard AI to do that (learn), and while a neural net type AI is made specifically for learning, the amount of data/learning ability required is not able to be given(inputed) by a single player. So the rest is up to whoever is creative enough to take the best of both worlds. Fun but perhaps inpractical and why we don't see alot of neural net type AI's or even hybrids.

With greater potential always comes greater risk no?

But the ultimate AI to me is exactly along the lines of one that adapts to me. Because I don't want to be cremated by the AI and I dont want to annahilate it. I want it to be just challenging enough that I can play a hard game and just still barely win. [:D] I'd imagine that statement would work for most solitaire players out there.

For yet another chess example, its easy to beat many beginners in chess by playing (as white) King Pawn -> King 4, King Pawn -> King 4, Queen -> King Rook 5 and winning black's king pawn (black's second move of pawn to king knight's 3 is common, which drops a rook too). If instead black protects the king pawn, then move Bishop to Queen Bishop 4 and threaten the mate. This attack can be continued rather aggressively for a few moves and beginners have a lot of trouble finding the right defense. Against any quasi-experienced player this opening for white is terrible. I would not like any AI program I created to learn the lesson that this opening should be used.

Nice example. In theory a neural net type AI wouldn't end up using this play though as it would have lost too many times having started out that way. I suppose this all comes down to the level of individual or the sophistication of the AI that it would be trained against but once again I dont see it as any different in that regard than a regular A.I. If someone not good at the game programs the AI then the AI is not going to be good.

Does it seem any better when I say that the Pascal is the latest release of Borland's Delphi (Turbo Pascal all grown up and now object oriented)? My cynical view is that it is still Pascal at heart. And yes, it is the game code I am working on. I actually really like programming this and get up at 5 every morning full of energy to make more things run right.

Details, details. I suppose I could say I'm still using C... But C# .NET (even C++ .NET) has come so far since then its barely recognizeable as C. Pascal was always my preferred structured language, but IMO hasn't evolved as fast as the C world. I can see Delphi's usability for wargames, assuming you buy my statement about them really being more like business applications. Because otherwise gaming is still very much a C-world.

[Shannon V. OKeets]

ORIGINAL: Veldor
Details, details. I suppose I could say I'm still using C... But C# .NET (even C++ .NET) has come so far since then its barely recognizeable as C. Pascal was always my preferred structured language, but IMO hasn't evolved as fast as the C world. I can see Delphi's usability for wargames, assuming you buy my statement about them really being more like business applications. Because otherwise gaming is still very much a C-world.

Curiously enough, I am probably better at programming in C++ (10+ years), but all languages are alike in the end - a bunch of 1's and 0's. As I keep at this project my Pascal skills are returning (1982 was the last time used Pascal). It mostly is just relearning the syntax. Programming concepts are universal across all languages.

[koiosworks]

Do you mean heuristics or genetic algorithms? I see these as two different methodologies. Hueristics can be dedicated algoritms, though they usually are rule based structures/processes, based on expert knowledge. Genetic algorithms are structured to learn through trial and error with numerous repetitive trials separating the poor performers from the good in a generational scheme of cross breeding (with some random variation thrown in).

we used AI 'order' advisors who used best guess hueristics to recommend specific unit orders for each unit given that units situation. we then sent these recommendations to the master AI who pared up many many generations of unit orders to come up with the best strategic plan for all the units. these orders were then implemented.

So in effect, we used the genetic algorthm to handle grand strategy and coordinate unit behavior.

hope that makes sense (our AI guy might have to come pipe if that does not get the jist of how we did it across).

PS all our games are in C#. A Microsoft case study on our engine is available at http://www.microsoft.com/resources/case ... dyID=16499

[Veldor]

ORIGINAL: koiosworks
PS all our games are in C#. A Microsoft case study on our engine is available at http://www.microsoft.com/resources/case ... dyID=16499

Yep. When C# was first available there was a stronger case against it. Now as its matured quickly even the C++ fanatics have moved to make non-Microsoft .NET versions of it. I never really got why. Perhaps since Microsoft wrote C#, by making a non MS version of it, they can pretend they aren't saying anything good about MS or supporting MS I guess.

So Microsoft got something right finally with .NET and C#. They have always been excellent at making development tools. Its part of why Novell died on the server front. It may be what helps the XBOX 360 survive long term on the console front.

It's too bad a lot of the rest of the gaming world is too slow to hop onto C#. I only wish I had sooner. I hate re-coding things but it will only save time and effort in the end. [:D]

If you can't tell I'm very very fond of C# (Still hate Java though [;)])

I should add I've never felt that way about a language before. C++ was more of a love-hate relationship. [:D]

[Shannon V. OKeets]

ORIGINAL: koiosworks

Do you mean heuristics or genetic algorithms? I see these as two different methodologies. Hueristics can be dedicated algoritms, though they usually are rule based structures/processes, based on expert knowledge. Genetic algorithms are structured to learn through trial and error with numerous repetitive trials separating the poor performers from the good in a generational scheme of cross breeding (with some random variation thrown in).

we used AI 'order' advisors who used best guess hueristics to recommend specific unit orders for each unit given that units situation. we then sent these recommendations to the master AI who pared up many many generations of unit orders to come up with the best strategic plan for all the units. these orders were then implemented.

So in effect, we used the genetic algorthm to handle grand strategy and coordinate unit behavior.

hope that makes sense (our AI guy might have to come pipe if that does not get the jist of how we did it across).

PS all our games are in C#. A Microsoft case study on our engine is available at http://www.microsoft.com/resources/case ... dyID=16499

It makes sense to me.

How did you get the numerous 'plays' of the game necessary to evaluate performance? Did the program play against itself?