RE: A Lesson for Matrixgames. ;)

Matrix Games Forums

Forums Register Login Photo Gallery Member List Search Calendars FAQ

My Profile Inbox Address Book My Subscription My Forums Log Out

RE: A Lesson for Matrixgames. ;)

View related threads: (in this forum | in all forums)

Logged in as: Guest

Users viewing this topic: none

Printable Version

All Forums >> [General] >> General Discussion >> RE: A Lesson for Matrixgames. ;)

Page: << < prev 1 [2] 3 next > >>

Message

<< Older Topic Newer Topic >>

RE: A Lesson for Matrixgames. ;) - 11/29/2005 2:40:29 AM

Veldor

Posts: 1531
Joined: 12/29/2002
From: King's Landing
Status: offline

quote:

ORIGINAL: sterckxe
<boggle> - as every programmer can tell you : a computer science background is no guarantee - I've worked with code-wizzards without any degree and absolutely dreadfull coders with prestigious degrees. Computer programming is more an art than a science.

This statement really extends to all areas of Information Technology/Computing. Partly this is due to the fact that technology changes so often that much of what you'd have learned in school in no longer valid (or at least less so). This is also worsened by the fact that many universities themselves are not able to keep up, so even a recent grad may be at a disadvantage.

Concepts and skills like producing and maintaining readable and modifiable code are perhaps more portable than other things, but even then the tools and interfaces change for how you input, edit, and debug code so in essence, the same statement still applies.
Also, even such staples as C++ can die. I have, for instance, decided to switch to C# (C Sharp).

Larger development teams have the advantage of allowing for specific focus or expertise of an individual. One or more persons just for the network components, One or more for the A.I. , etc. Smaller Dev Teams, or even individual programmers, have to be much more resourceful to make up for this.

And, oddly enough, readable code isn't really THAT important for wargaming projects because there are simply not enough coders, perhaps only one. Assuming the programmer can interpret his or her code (which I sometimes think is doubtful but some swear it does in fact all make sense to them)... Then the most important aspect is really the codes ability to be easily modified and/or debugged. Second is the ability of the program to log and or self-detect problems in its own logic. Perhaps the real problem is when you walk away from the code for awhile (due to game release, a new project or whatever) and then find yourself looking back at it now having to fix bugs and realizing.. Hmmm perhaps this wouldn't seem like such a daunting task had I actually spent a bit more time documenting my code and making it more readable, logical, and debugable.

Alright so no coder ever ACTUALLY says that to him/herself... But I think all (from the dreadful on up) could do a better job of it.

And, for the most part, these abilities come more from experience and/or resourcefulness than any kind of direct schooling.

(in reply to sterckxe)

Post #: 31

RE: A Lesson for Matrixgames. ;) - 11/29/2005 2:47:59 AM

Veldor

Posts: 1531
Joined: 12/29/2002
From: King's Landing
Status: offline

quote:

ORIGINAL: Hertston
And the AI is always there, always ready to play, has no timetabling problems and won't leave in the middle of a game.

Yes! And now you've hit on why ever single computer game ever made with any sort of multi-player capability sucks.

From Red Alert to Diplomacy to more traditional wargames this has been a long standing problem of mine.

Just when I get good at a game and start to win, the opponent (or one of the opponents) decides to drop out.

Why? Simple. Because its no fun to loose, and more importantly if they were playing against the A.I. and losing that hopelessly they'd probably have quit as well and just starting up a new game (That would be more fun as they'd have a chance of winning again).

Ladders, Forced Nicknames, all kinds of systems have been tried... But the only thing worse than a player dropping out of a game is a player who WANTS to drop out but can't. The game is ruined either way.

Just one of many many many reasons why people will always enjoy at least some interaction against a Computer Opponent.

(in reply to Hertston)

Post #: 32

RE: A Lesson for Matrixgames. ;) - 11/29/2005 5:42:55 AM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

that I personally can't see the satisfaction in playing against the lump of metal that is a computer, however good or bad it is.

Which reminds me of the quote (which I might have slightly incorrect): " 'Stone walls and iron bars do not a prison make.', but throw in steel doors, a connected series of watch towers, guards with submachine guns, patrolling German shepards, and a fine selection of concertina wire, and you'll have yourself a very nice one."

My point here is that the quality of the AI depends on the sum of its parts. If there are only two parts and they don't fit together very well, then the opponent truly is just a lump of metal. I feel this way about computers in general too. Steve Job's original plan to sell the Mac without a keyboard in the 1980's fits this description.

However, if you keep layering on good decision making capabilities, refine out the gross ineptitudes, and play test the sucker against people at a variety of skill levels, well then the AI opponent can be made to mimic a real person. The old test for AI is if sitting at a terminal you can tell whether it is a person or an AI responding to your typed queries.

I actually do not like the AI programs for chess because they have gone over to rely so heavily on simply looking ahead. With wargames that is rarely feasible because of all the probabilities, combinations, and permutations involved. The poor AIs rely on CPU speed (RTS games), cheating (increasing the materiel available to the AIO, using a different CRT, and/or seeing supposedly invisible units), and/or refusing to play both sides (because that requires both offensive and defensive abilties).

My own pet theory (no experience whatsoever to base this claim on) is that if you want to defeat RTS games, use a slower CPU - so the computer has fewer cycles to figure out what is going on.

Going back to the original quote at the top, there are a whole host of people I do not get any satisfaction playing against because of their personal attributes. My sensory system is easily offended, you see.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to ravinhood)

Post #: 33

RE: A Lesson for Matrixgames. ;) - 11/29/2005 6:06:39 AM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

ORIGINAL: ravinhood
Thus, it's why I've never understood a more direct approach to creating the competant, competivie, challenging AI ENGINE and then licensing that engine for everyone else to use.

It can be argued that that most impressive feature of the human brain is it ability to adapt to changing circumstances. Look at the wide variety of languages people speak in the world. When you ask that someone create a universal AI Engine, it is comparable to asking for someone to create a universal language, that encompasses all the other existing languages.

You can sit down with a rule book and learn a new war game after studying the map and pushing around the pieces. Playing it well might take a few tries, until you get a good understanding of the play mechanics and how things interact. Of course that will be faster if it is similar to something you have seen before. Nonetheless, you are learning at an extraordinary rate. Indeed, if you are not forced to learn something new to play a game well, you will be sadly disappointed with the game because it is just a copy of something you have played before.

Where you are headed with the concept of a universal AI Engine, is proposing that a computer program can be written that can learn to play wargames as well as people do. Or even more unlikely, that it can be written without any learning capability. It doesn't matter which side of that argument you take, the AI community has been stuggling since it inception in the 1960's (or possibly before) to do that with understanding written language and writing 'automatic' language translators. There is a ton of money available if anyone can do that. The reward:cost ratio is fantastic. Some of the brightest people in the AI community have been working on this non-stop for decades without appreciable success. Progress is being made, but it is incremental, not revolutionary. I would argue that finding the underlying concepts for playing wargames well is comparable in difficulty to doing that for human languages.

To sum up, if you think a universal AI Engine is achievable for war games, then you think it is possible to write code that mimics how well you play all the games you have every learned (or will ever learn). Money is not the problem; the problem is much larger than that.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to ravinhood)

Post #: 34

RE: A Lesson for Matrixgames. ;) - 11/29/2005 6:11:08 AM

Erik Rutins

Posts: 37503
Joined: 3/28/2000
From: Vermont, USA
Status: offline

Ravinhood,

quote:

ORIGINAL: ravinhood

quote:

That's no secret and there's nothing to fess up. Your earlier post made it seem as if all but one of our titles had bad AI and that one was only "decent". That's false

That is NOT FALSE that is my belief and a fact to me as a consumer. To sit there and say my own judgements are false is rather arrogant of you.

That's like I walk into a store and tell you the milk is sour I bought and you say it's not!! Just because you like the taste of sour milk.

It's also not very good PR to tell a consumer how they should think about your products.

I'm sorry I upset you, but frankly you got under my skin a bit. It's your opinion and you're right that as such, it can neither be said to be true or false. However, this isn't really a fresh milk/sour milk situation - we're discussing the quality of AI for our line of games. I don't know how many you've played, but I strongly disagreed with the statement you posted. As far as opinions go, there are a lot more that disagree with you than agree and that's the main thing I'm pointing out. Your original statement seemed to me to be voiced as if it were a fact.

I have no problem with opinions, but I don't want potential customers reading this to think that what you said was a fact rather than an opinion. My opinion, which is shared by many others, is that there are many games with much better than decent AI in our catalog. Anyway, I apologize if I came across as arrogant - that was not my intention. I was definitely being stubborn though.

Regards,

- Erik

_____________________________

Erik Rutins
CEO, Matrix Games LLC

For official support, please use our Help Desk: http://www.matrixgames.com/helpdesk/

Freedom is not Free.

(in reply to ravinhood)

Post #: 35

RE: A Lesson for Matrixgames. ;) - 11/29/2005 6:26:36 AM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

ORIGINAL: Captain Cruft
The standard use of hard-coding numeric parameters and fixed size limits speaks for itself though. Not to mention unmodifiable user interfaces, usage of proprietary undocumented database formats, general lack of documentation, lack of APIs, lack of key bindings, lack of integration with the O/S environment etc etc etc. It may well be that many of the developers know better but why don't they do things properly? See my second point about incentive. Also, introduce another point about the target audience not knowing that they should expect any better.

Sorry to be critical but I do find it all a bit frustrating sometimes.

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.

I agree with 2 and 3, but not the others.

(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.

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

(3) Hey, I've been on this soapbox myself! Nice view from up here!

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

(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.

(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?

(7) Wouldn't you rather have the time and effort go into making games that simulate history in an interesting way - that let you experience some of the same problems that the histocal personages had? That is why I work on these things.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Captain Cruft)

Post #: 36

RE: A Lesson for Matrixgames. ;) - 11/29/2005 6:37:38 AM

Veldor

Posts: 1531
Joined: 12/29/2002
From: King's Landing
Status: offline

quote:

ORIGINAL: Shannon V. OKeets
To sum up, if you think a universal AI Engine is achievable for war games, then you think it is possible to write code that mimics how well you play all the games you have every learned (or will ever learn). Money is not the problem; the problem is much larger than that.

I didn't make the statement, but isn't your answer quite possibly a little too absolute? I've seen others ask the same questions and I don't think its meant that this mythical AI engine would simply plug-in as-is and unaltered. Truthfully I'm not sure that any type of gaming engine is ever that straightforward to use anyway.

I'd imagine such an A.I. engine to be more of a middleware application, for lack of a better term. Perhaps with an enhanced or even graphical scripting language.

Put another way, in a simpler form it could just be a set of reusable C++ or Java libraries and so forth.

The whole point of Object-Oriented languages is to reutilize code. Any programmer who has not made use of that ability is not much of a programmer correct? Surely there is some pieces of this that could be packaged together and enhanced by some of the most brilliant A.I. coders out there and then put together for other developers to use. No?

Likely, it would have its limits for variance from what its original intent was without further coding, but that�s already true of any "engine" out there. And if such work provided a better foundation and starting point for many wargame developers out there, then it would in fact be a very feasible undertaking.

(in reply to Shannon V. OKeets)

Post #: 37

RE: A Lesson for Matrixgames. ;) - 11/29/2005 7:18:15 AM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

ORIGINAL: Veldor
And, oddly enough, readable code isn't really THAT important for wargaming projects because there are simply not enough coders, perhaps only one. Assuming the programmer can interpret his or her code (which I sometimes think is doubtful but some swear it does in fact all make sense to them)... Then the most important aspect is really the codes ability to be easily modified and/or debugged. Second is the ability of the program to log and or self-detect problems in its own logic. Perhaps the real problem is when you walk away from the code for awhile (due to game release, a new project or whatever) and then find yourself looking back at it now having to fix bugs and realizing.. Hmmm perhaps this wouldn't seem like such a daunting task had I actually spent a bit more time documenting my code and making it more readable, logical, and debugable.

Alright so no coder ever ACTUALLY says that to him/herself... But I think all (from the dreadful on up) could do a better job of it.

And, for the most part, these abilities come more from experience and/or resourcefulness than any kind of direct schooling.

Gee, you must be brilliant, I agree with almost everything you said.

I actually write the documentation before the code. I write out the calling sequence (or whatever) as comments and perhaps a few stub ends. Once I have my head around what it is I am trying to do, how it is going to hang together, and how I am going to get it done, then I can start programming without worrying about rewrites to accommodate forgotten elements. [Or to be honest, fewer rewrites to accommodate forgotten elements.] I write my in-line comments for myself to read 6 months from now, when I have forgotten the particulars. I try to maintain good documentation on variables, structures, and calling sequences in separate plain text files for easy access. What I have found from mind-numbingly servere, tramatic experience is that if you can't write the comment, then you can't write the code. If you can write the comment, then do so - it only takes a minute.

When I come back to code that I have written 6 months ago, or a year, or longer, I find I have one of three emotional responses: (1) that's bloody obvious, (2) why that's pure genius!, or (3) who was the idiot who wrote that and how did he get possession of my body (is he still around in here somewhere)?

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Veldor)

Post #: 38

RE: A Lesson for Matrixgames. ;) - 11/29/2005 7:42:48 AM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

ORIGINAL: Veldor
I'd imagine such an A.I. engine to be more of a middleware application, for lack of a better term. Perhaps with an enhanced or even graphical scripting language.

Put another way, in a simpler form it could just be a set of reusable C++ or Java libraries and so forth.

The whole point of Object-Oriented languages is to reutilize code. Any programmer who has not made use of that ability is not much of a programmer correct? Surely there is some pieces of this that could be packaged together and enhanced by some of the most brilliant A.I. coders out there and then put together for other developers to use. No?

Likely, it would have its limits for variance from what its original intent was without further coding, but that�s already true of any "engine" out there. And if such work provided a better foundation and starting point for many wargame developers out there, then it would in fact be a very feasible undertaking.

The reusable amount of code is very small. It really depends on the level of overlap between the 2 game designs (to restrict the discussion to just 2 games). Do they both uses hexagons? Do they both have level terrain (or gradations in elevations)? Do they match as IGOUGO or WEGO? How about stacking? ZOCs? Area based movement? Units that can fly? Unit visiblilty to the enemy? Supply lines? I could extend this list to include every rule that goes into war games. The real difficulty is not programming each aspect of the game design/simulation but all the interactions between them. And the interactions between the interactions. For example, are helicopters limited as to what level of terrain they can fly over during rain and what is the effectiveness of ground fire on them when they are forced to fly lower? When they are hit (damaged not destroyed) does their visibility at lower elevations change?

Programming the game's simulation elements is very hard, primarily because of the interactions. Programming the AI is hard for the same reason. The AI has to be very skilled at understanding the interaction between the game design elements. Change the design elements and the AI skill level drops drastically. The AI code is almost universally specific for the game design. Not very portable to other games - unless the second game is a close clone of the first. Which brings us around to why clones are so popular with developers.

AI's are not like databases because AIs are not very well understood. One of the claims of the AI community is that once things become well understood, they are no longer of interest to the AI community. AI gurus take credit for creating a lot of things that we use every day (e.g., operating systems, the Internet). Within this self-conceit, if it is called AI, then it isn't well enough understood to be written as packaged elements. Perhaps it is evolving towards that though. I don't track the AI world as closely as I did back in the 1980's.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Veldor)

Post #: 39

RE: A Lesson for Matrixgames. ;) - 11/29/2005 8:09:07 AM

Veldor

Posts: 1531
Joined: 12/29/2002
From: King's Landing
Status: offline

quote:

ORIGINAL: Shannon V. OKeets
.....It really depends on the level of overlap between the 2 game designs (to restrict the discussion to just 2 games). Do they both uses hexagons? Do they both have level terrain (or gradations in elevations)? Do they match as IGOUGO or WEGO? How about stacking? ZOCs? Area based movement? Units that can fly? Unit visiblilty to the enemy? Supply lines? I could extend this list to include every rule that goes into war games. The real difficulty is not programming each aspect of the game design/simulation but all the interactions between them. And the interactions between the interactions. For example, are helicopters limited as to what level of terrain they can fly over during rain and what is the effectiveness of ground fire on them when they are forced to fly lower? When they are hit (damaged not destroyed) does their visibility at lower elevations change? .....

Yes, it could be akin in effort to developing DirectDraw, Direct3D, DirectInput, DirectPlay, etc. A "DirectAI" if you will. Yes I realize that other DirectX components are more specifically related to addressing a particular hardware element, but other middleware examples exist in the business world that are no less narrow in scope.

Also I'm sure it would be more than acceptable for such a system to incorporate certain assumptions and limitations more in-line with what defines a "traditional wargame" (that being the most common type a potential developer would be looking to create in the first place). So that means hexes and perhaps an IGOUGO architecture etc.

Easy no, Possible yes.

On a seperate, but somewhat related note, look whats been done with programs like VASSAL. In the past some might have said... "How could one program accomodate for the interface and graphical requirements for everything from card games to multi-board monster games"? Yet somehow VASSAL does just that. It covers 80%-100% of whats needed in those areas and allows you to alter/add the rest with extendable coding etc.

(in reply to Shannon V. OKeets)

Post #: 40

RE: A Lesson for Matrixgames. ;) - 11/29/2005 8:56:11 AM

ravinhood

Posts: 3891
Joined: 10/23/2003
Status: offline

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

< Message edited by ravinhood -- 11/29/2005 9:22:06 AM >

(in reply to Veldor)

Post #: 41

RE: A Lesson for Matrixgames. ;) - 11/29/2005 9:30:00 AM

Veldor

Posts: 1531
Joined: 12/29/2002
From: King's Landing
Status: offline

quote:

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).

(in reply to ravinhood)

Post #: 42

RE: A Lesson for Matrixgames. ;) - 11/29/2005 9:55:57 AM

Veldor

Posts: 1531
Joined: 12/29/2002
From: King's Landing
Status: offline

quote:

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)

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.

(in reply to ravinhood)

Post #: 43

RE: A Lesson for Matrixgames. ;) - 11/29/2005 12:00:01 PM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

ORIGINAL: Veldor

quote:

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.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Veldor)

Post #: 44

RE: A Lesson for Matrixgames. ;) - 11/29/2005 12:14:50 PM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

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.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Veldor)

Post #: 45

RE: A Lesson for Matrixgames. ;) - 11/29/2005 6:04:12 PM

Captain Cruft

Posts: 3652
Joined: 3/17/2004
From: England
Status: offline

quote:

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.

quote:

(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.

quote:

(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 ...

quote:

(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.

quote:

(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.

quote:

(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.

(in reply to Shannon V. OKeets)

Post #: 46

RE: A Lesson for Matrixgames. ;) - 11/29/2005 7:42:41 PM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

ORIGINAL: Captain Cruft

quote:

(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.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Captain Cruft)

Post #: 47

RE: A Lesson for Matrixgames. ;) - 11/29/2005 8:03:26 PM

Captain Cruft

Posts: 3652
Joined: 3/17/2004
From: England
Status: offline

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

c:\ game.exe savefile.dat

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

(in reply to Shannon V. OKeets)

Post #: 48

RE: A Lesson for Matrixgames. ;) - 11/29/2005 8:56:33 PM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

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
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".

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Captain Cruft)

Post #: 49

RE: A Lesson for Matrixgames. ;) - 11/29/2005 9:38:24 PM

Veldor

Posts: 1531
Joined: 12/29/2002
From: King's Landing
Status: offline

quote:

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

(in reply to Shannon V. OKeets)

Post #: 50

RE: A Lesson for Matrixgames. ;) - 11/29/2005 9:49:52 PM

Captain Cruft

Posts: 3652
Joined: 3/17/2004
From: England
Status: offline

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 ... ;)

< Message edited by Captain Cruft -- 11/29/2005 9:51:43 PM >

(in reply to Shannon V. OKeets)

Post #: 51

RE: A Lesson for Matrixgames. ;) - 11/29/2005 10:19:55 PM

koiosworks

Posts: 813
Joined: 6/20/2004
Status: offline

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/1584500778/104-7433077-4127925?v=glance&n=283155&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

(in reply to Captain Cruft)

Post #: 52

RE: A Lesson for Matrixgames. ;) - 11/29/2005 11:54:35 PM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

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

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.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Veldor)

Post #: 53

RE: A Lesson for Matrixgames. ;) - 11/29/2005 11:59:57 PM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

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.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Captain Cruft)

Post #: 54

RE: A Lesson for Matrixgames. ;) - 11/30/2005 12:08:13 AM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

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.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to koiosworks)

Post #: 55

RE: A Lesson for Matrixgames. ;) - 11/30/2005 1:10:35 AM

Veldor

Posts: 1531
Joined: 12/29/2002
From: King's Landing
Status: offline

quote:

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.

I'd imagine that statement would work for most solitaire players out there.

quote:

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.

quote:

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.

(in reply to Shannon V. OKeets)

Post #: 56

RE: A Lesson for Matrixgames. ;) - 11/30/2005 1:33:14 AM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

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.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Veldor)

Post #: 57

RE: A Lesson for Matrixgames. ;) - 11/30/2005 2:15:38 AM

koiosworks

Posts: 813
Joined: 6/20/2004
Status: offline

quote:

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/casestudies/CaseStudy.asp?CaseStudyID=16499

(in reply to Veldor)

Post #: 58

RE: A Lesson for Matrixgames. ;) - 11/30/2005 2:27:28 AM

Veldor

Posts: 1531
Joined: 12/29/2002
From: King's Landing
Status: offline

quote:

ORIGINAL: koiosworks
PS all our games are in C#. A Microsoft case study on our engine is available at http://www.microsoft.com/resources/casestudies/CaseStudy.asp?CaseStudyID=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.

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.

(in reply to koiosworks)

Post #: 59

RE: A Lesson for Matrixgames. ;) - 11/30/2005 8:37:23 AM

Shannon V. OKeets

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

ORIGINAL: koiosworks

quote:

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/casestudies/CaseStudy.asp?CaseStudyID=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?

_____________________________

Steve

Perfection is an elusive goal.

(in reply to koiosworks)

Post #: 60