Any news on the A.I.?

[wworld7]

This is a very positive discussion. I am impressed by the tone and information presented.

GOOD JOB!

No matter what is decided I eagerly await the chance to purchase this fantastic game.

Flipper

P.S. It has been twenty odd years since I did any significant programming outside of a telecommunication system (my field is PBX/ACD/IVRs etc...). The discussion brings back many memories (or is it nightmares?).

Be well and may your beer be cold.

WJCII

[SamuraiProgrmmr]

ORIGINAL: cwie

ORIGINAL: Shannon V. OKeets
... there are a whole lot of MWIF forum readers who wonder if you are making words up in these posts.

Well, okay, maybe some of the words I made up. [8D]

[:-] I confess to nothing![;)]

[SamuraiProgrmmr]

ORIGINAL: cwie

We're close enough on most points that I don't think another set of point-by-point responses would add much.

I agree. It has been a fun discussion.

I feel kind of sheepish now that you reveal that you have tried this already. I feel like I have been caught trying to instruct the professor. [:)]

I would love to continue talking 'shop' but alas, this is not the place.

As we wind down, I just have a few more points.

I would like to clarify my statement about the DLL containing state data. I agree that it should keep track of some information. I am not sure I agree that it should keep it's own copy of the 'game state'. This point seems to be bound up with the concept of running the AI in a background thread to speed up response time.

While I think it is a great idea in theory, I am mildly skeptical about its use in reality. If the reason to run in the background is to allow the user to look around while he is waiting, then the games state will not be changing and there is no sync problem. If the reason to run in the background is to allow the player to finish his move, the game state will definitely be changing and there will be sync problems. But since the game state will have changed, the AI may have to reevaluate everything anyway so I wonder how much will be gained. What does your experience show?

As for the issue of temporarily suspending threading, I see it a bit differently. When you need to run a method in the main thread, Delphi suspends the calling thread until the main thread returns an answer. The main thread will return the answer as soon as the application hits idle - which as you know is often. If the application is not reaching idle, then the processor is busy anyway and there is no performance gain to be had.

I must admit that I have no idea how this will be impacted by a graphics-heavy application. I also don't know how the dynamics are affected by the new dual core processors. I would be interested in any insights you might have.

I am quite impressed by your wargame.exe project. It sounds like the old wargame construction set on steroids --- massive steroids.

One last thing, do you use unit testing ala XTreme Programming?

Dean

[Shannon V. OKeets]

ORIGINAL: SamuraiProgrammer

ORIGINAL: cwie
We're close enough on most points that I don't think another set of point-by-point responses would add much.

I agree. It has been a fun discussion.

I feel kind of sheepish now that you reveal that you have tried this already. I feel like I have been caught trying to instruct the professor. [:)]

I would love to continue talking 'shop' but alas, this is not the place.

As we wind down, I just have a few more points.

I would like to clarify my statement about the DLL containing state data. I agree that it should keep track of some information. I am not sure I agree that it should keep it's own copy of the 'game state'. This point seems to be bound up with the concept of running the AI in a background thread to speed up response time.

While I think it is a great idea in theory, I am mildly skeptical about its use in reality. If the reason to run in the background is to allow the user to look around while he is waiting, then the games state will not be changing and there is no sync problem. If the reason to run in the background is to allow the player to finish his move, the game state will definitely be changing and there will be sync problems. But since the game state will have changed, the AI may have to reevaluate everything anyway so I wonder how much will be gained. What does your experience show?

As for the issue of temporarily suspending threading, I see it a bit differently. When you need to run a method in the main thread, Delphi suspends the calling thread until the main thread returns an answer. The main thread will return the answer as soon as the application hits idle - which as you know is often. If the application is not reaching idle, then the processor is busy anyway and there is no performance gain to be had.

I must admit that I have no idea how this will be impacted by a graphics-heavy application. I also don't know how the dynamics are affected by the new dual core processors. I would be interested in any insights you might have.

I am quite impressed by your wargame.exe project. It sounds like the old wargame construction set on steroids --- massive steroids.

One last thing, do you use unit testing ala XTreme Programming?

Dean

There are numerous places where the human player needs to make a decision. In fact, at just about every phase and subphase there is the possibility of the human mulling over what he wants to do. (Reroll or not? Go first or second? Intercept that naval move? Send naval air units into the sea area? What is the best order for my air units in this combat? ...). I see the AIO being able to anticipate, or not care about, the human's decision and begin processing its own logic to determine what it's going to do next. This is what we do over the board while waiting for an opponent (though we might take the opportunity to get a fresh libation). In the case of moving units, it is quite possible that the game state will change so much that the calculations will have to be done again from scratch. But even there, human players tend to move one country at a time, so once the Chinese have moved, the AIO (playing Japan) can analyze the China position while waiting for the human to move in Europe, for example.

[TemKarl]

SamuraiProgrammer,

I would love to continue talking 'shop' but alas, this is not the place.

I agree we'd best not go too far into "Software Philosophy", as Greyshaft puts it (quite well).

I feel kind of sheepish now that you reveal that you have tried this already. I feel like I have been caught trying to instruct the professor.

No, not at all. I've been down the DLL interface road many times for various reasons and with various results. Each time is different, and perhaps the MWiF-AIO is an example where the benefits are sufficient to outweigh the costs. On a personal level, I'd be quite happy to see Steve attempt it!

If the reason to run in the background is to allow the user to look around while he is waiting, then the games state will not be changing and there is no sync problem.

Agreed.

If the reason to run in the background is to allow the player to finish his move, the game state will definitely be changing and there will be sync problems. But since the game state will have changed, the AI may have to reevaluate everything anyway so I wonder how much will be gained. What does your experience show?

Well, like most things in programming, it's all in the details!

I also don't know how the dynamics are affected by the new dual core processors. I would be interested in any insights you might have.

I'll let you know early next year! In theory, dual core is a big step forward. But again, it just amplifies the need to clearly work out the data interface between threads. Threads always work best when they are (a) performing lengthy calculations and (b) working on their own private data stores. If you're using threads to run only short routines, or the routine needs to examine another threads data extensively, you're heading for more trouble. Best advice I've ever seen for writing multi-threaded apps was "Don't". An exaggeration of course, but the issues are often subtle and difficult to manage correctly.

I am quite impressed by your wargame.exe project. It sounds like the old wargame construction set on steroids --- massive steroids.

It was/is ambitious. May still return to it at some stage.

One last thing, do you use unit testing ala XTreme Programming?

Yes (although it's pretty limited when testing interfaces), and XP is the guiding philosophy behind CWiE's development.

[SamuraiProgrmmr]

ORIGINAL: cwie

Best advice I've ever seen for writing multi-threaded apps was "Don't". An exaggeration of course, but the issues are often subtle and difficult to manage correctly.

My only experience with threading was to perform tasks that were not part of the ongoing work being done by the user. Mostly automated data gathering and report sending via email in background threads. It is a great way to utilize processor time while the user is reaching for a key or moving his mouse toward a click point.

At first it was cantankerous, but it smoothed out and runs without problems now. Definitely worth the trouble.

It was/is ambitious. May still return to it at some stage.

Dream not small dreams for they have not the power to stir men's hearts! GO FOR IT!

Yes (although it's pretty limited when testing interfaces), and XP is the guiding philosophy behind CWiE's development.

To those of you who don't recognize these terms... It means that while CWiE is being developed, a parallel program is being written whose only function is to test CWiE to make sure it is working as planned. This is great when you start making mass changes .... Now at least you will know when it breaks and not get any nasty surprises later.

Translate that as "Version 2.0 is easier to develop"


I have truly enjoyed this. Keep up the good work!

Dean

[Ullern]

I for one have written quite large programs (in 10k line size) but as I have never been bothered by demands for user interface or true time behaviour I still don't have any idea what you guys are talking about. [:'(]

[SamuraiProgrmmr]

When writing code in sections (units) that are used by each other, the part of the code that defines what the other sections of code see is called the interface and the part of the code that actually does it is the implementation.
 
'Publishing the interface' is how you let other sunits of code know what they can ask this section of code to do.
 
10K lines?  I don't know how to say this, but the last big project I finished was between 140K and 150K.  The current project I am working on is just over 250K.  The project I am going to be working on as soon as I finish this one *may* top 500K.
 
The new development platforms generate a lot of that, but as time goes on more and more is expected of a program so the code base grows and grows.
 
Dean
 

[Ullern]

ORIGINAL: SamuraiProgrammer

10K lines? I don't know how to say this, but the last big project I finished was between 140K and 150K. The current project I am working on is just over 250K. The project I am going to be working on as soon as I finish this one *may* top 500K.

I think you put it rather nicely. I would have been suprised if this was not the case. [:D][:D]

[Shannon V. OKeets]

ORIGINAL: ullern
I for one have written quite large programs (in 10k line size) but as I have never been bothered by demands for user interface or true time behaviour I still don't have any idea what you guys are talking about. [:'(]

Size of program in lines of code can be misleadnig, and it always has been. Harking back to the early 1970's, saying lines of code without mentioning whether they were in assembler, Fortran, or Cobol didn't mean very much.

C was the first language I encountered where the language specifically separated the definition of what a routine required to communicate with other routines from the code that implemented the routine's functionality. The former was called a 'header' file rather literally because it was the first part of the routine.

To write code that called the routine you only need access to the header file. This enabled, for instance, large libraries of routines to be made available in object/compiled form and called from application programs merely by including the header files (which define the parameter passing between the library routine and the application program).

The second concept used extensively in the discussion was threads. This is an extension of having a computer perform multi-tasking (more that 1 program running at once) to within a single program. Essentially, the program 'multi-tasks' within itself by having mulitple threads running at once. The analogy to a multi-tasking operating system is sound; you can use that as a basis for understanding a discussion of threading an application.

[TemKarl]

ORIGINAL: Shannon V. OKeets
...
C was the first language I encountered where the language specifically separated the definition of what a routine required to communicate with other routines from the code that implemented the routine's functionality. The former was called a 'header' file rather literally because it was the first part of the routine.
...

Steve,

I thought I'd comment on this simply because it's one of those little details that bugs me, but seems to worry very few others! C and C++ don't actually define the concept of a header file at all. The languages allow separation of interface and implementation, but don't require it. Commonsense usage by C and C++ programmers, supported by most IDEs, has given rise to the concept of header files, but strictly speaking the languages themselves do not require, nor define, header files. This, IMO, is a huge weakness for these languages, and one that Delphi, Pascal and Modula-2 (amongst many others) have corrected.

Doing any serious large scale development in C or C++ is extremely difficult without using header files, but the fact that the compiler really dosn't see any difference between code a '.h' file and code in '.c' file leads to a number of subtle problems when trying to reuse code.

[Shannon V. OKeets]

ORIGINAL: cwie

ORIGINAL: Shannon V. OKeets
...
C was the first language I encountered where the language specifically separated the definition of what a routine required to communicate with other routines from the code that implemented the routine's functionality. The former was called a 'header' file rather literally because it was the first part of the routine.
...

Steve,

I thought I'd comment on this simply because it's one of those little details that bugs me, but seems to worry very few others! C and C++ don't actually define the concept of a header file at all. The languages allow separation of interface and implementation, but don't require it. Commonsense usage by C and C++ programmers, supported by most IDEs, has given rise to the concept of header files, but strictly speaking the languages themselves do not require, nor define, header files. This, IMO, is a huge weakness for these languages, and one that Delphi, Pascal and Modula-2 (amongst many others) have corrected.

Doing any serious large scale development in C or C++ is extremely difficult without using header files, but the fact that the compiler really dosn't see any difference between code a '.h' file and code in '.c' file leads to a number of subtle problems when trying to reuse code.

Thanks.

[TemKarl]

ORIGINAL: Shannon V. OKeets
Thanks.

[:D] Although I use C++ almost permanently now, I often think back to the "good old days" of Modula-2. And Delphi is a nice middle-ground choice!

[Shannon V. OKeets]

After pondering this for many months, I decided the only way I can link the rules that are written in plain text, for the AI Opponent, to the game variables, internal to MWIF (e.g., year, terrain type, unit type, movement points remaining), is to create a translation routine for just that purpose. The common computer science name for this routine is a Parser.

1 - Each variable that the AIO rules need to reference will have a code (VarCode) assigned to it that can be used in the rules as they are written.
2 - The translation program will convert each VarCode into a variable within the program.
3 - Constants, ConstCodes, will likewise be translated (e.g., Fine weather, Clear terrain, 4 movement points).
4 - Many functions, FuncCodes, will need translation (e.g., Within Range, Greater Than, Equal To).

This is tedious to do because there are so many of them, but actually very easy to code.

I need to define the language structure/syntax next.

[SamuraiProgrmmr]

<breathes into a paper bag to stop hyperventilating>
&nbsp;
Does this mean that we (the community) might be able to write our own AIs?
&nbsp;
<breathes into a paper bag to stop hyperventilating>
&nbsp;
My offer to help with the documentation (if needed) still stands, though I won't be able to spend much time on it for a couple of months due to deadline pressure at work.
&nbsp;
Dean
&nbsp;

[Froonp]

ORIGINAL: Shannon V. OKeets
This is tedious to do because there are so many of them, but actually very easy to code.

If I can help, just ring the bell.

[Shannon V. OKeets]

ORIGINAL: SamuraiProgrammer

<breathes into a paper bag to stop hyperventilating>

Does this mean that we (the community) might be able to write our own AIs?

<breathes into a paper bag to stop hyperventilating>

My offer to help with the documentation (if needed) still stands, though I won't be able to spend much time on it for a couple of months due to deadline pressure at work.

Dean

Maybe. Partially. Within strict guidelines. Without much documentation. Without any utility programs.

This is simply not on my task list for MWIF product 1. And there is a lot on my task list.

[Shannon V. OKeets]

ORIGINAL: SamuraiProgrammer

<breathes into a paper bag to stop hyperventilating>

Does this mean that we (the community) might be able to write our own AIs?

<breathes into a paper bag to stop hyperventilating>

My offer to help with the documentation (if needed) still stands, though I won't be able to spend much time on it for a couple of months due to deadline pressure at work.

Dean

Here is the primary routine for AI decision making. It is called by Game Control at numerous places in the sequence of play - basically whenever a decision needs to be made by the AIO. The task index determines which decision the AIO needs to make.
=============
// ****************************************************************************
procedure TDecisionMaker.Decide(const TaskIndex: Integer);
// ****************************************************************************
// This is the universal routine for processing AI decisions by a decision maker
// ****************************************************************************
var
GS: TGrandStrategist;
MC: TManufacturingCouncil;
CIC: TCommanderInChief;
FL: TForeignLiaison;
JCS: TJointChiefsOfStaff;
AD: TAdmiralty;
AM: TAirMarshal;
FM: TFieldMarshal;

begin
case DMType of
// ****************************************************************************
// Grand Strategist decisions
// ****************************************************************************
dmtGS:
begin
GS := TGrandStrategist(Self);

case TaskIndex of
1: GS.DecStrategicPlan;

2: GS.DecUSEntryOption;

3: GS.DecInitiative;

4: GS.DecUSEntryMarkers;

5: GS.DecOffDefMarkers;

6: GS.DecUSSRMarkerBP;

7: GS.DecIntelligence;

8: GS.DecDestroyFactories;

9: GS.DecHomeCountry;
end;
end;
// ****************************************************************************
// Manufacturing Council decisions
// ****************************************************************************
dmtMC:
begin
MC := TManufacturingCouncil(Self);;

case TaskIndex of
1: MC.EvalUSEntryOptions;

2: MC.DecProductionPlan;

3: MC.DecProduction;

4: MC.DecForcePool;

5: MC.DecMoveFactory;

6: MC.DecBuildFactory;

7: MC.DecRepairFactory;

8: MC.DecBuildAhead;

9: MC.DecConvoys;

10: MC.DecResourceRoutes;

11: MC.DecDefStratBombing;

12: MC.DecGearingLimits;
end;
end;
// ****************************************************************************
// Commander in Chief decisions
// ****************************************************************************
dmtCIC:
begin
CIC := TCommanderInChief(Self);;

case TaskIndex of
1: CIC.EvalUSEntryOptions;

2: CIC.DecDOW;

3: CIC.DecPeaceUSSRJapan;

4: CIC.DecMutualPeace;
.
.
.
.

=============

This, in turn, calls the routines for each specific decision maker. For instance:
=============
// ****************************************************************************
// Class TGrandStrategist
// ****************************************************************************
TGrandStrategist = class(TDecisionMaker)

private
// CurrentSP: TStrategicPlan; // Modified/In progress

public

constructor Create; // DMType := dmtGS;
destructor Destroy; override;

procedure DecStrategicPlan;
procedure DecUSEntryOption;
procedure DecInitiative;
procedure DecUSEntryMarkers;
procedure DecOffDefMarkers;
procedure DecUSSRMarkerBP;
procedure DecIntelligence;
procedure DecDestroyFactories;
procedure DecHomeCountry;
end;

=============

I intend for each of these procedures to be based on rules written in the AIO rules language (plain text) that gets parsed and stored in internal data structures (the program will parse the rules only once).
1 - The plain text is parsed and stored in internal data structures.
2 - The program calls a decision maker's procedure when a decision needs to be made.
3 - The program uses the stored version of the rule to make the decision. There will often be references to dynamic game state varaibles (e.g., weather, impulse #).

It is very likely that each decision will have its own data strucutre, though obviously I will try to use a general/standard structure(s) whenever possible.

Parsing means that there is a language being used. For my own purposes I will document the language. I have no interest at this time is making that documentation any more elbaorate that absolutely necessary - for me to write the AIO rules.

If the player decides to write his own rules but wht heee wroten nto bye transssssslationableing. Boom![X(] Perfection or explosion. No sympathy.[:-]

[SamuraiProgrmmr]

ORIGINAL: Shannon V. OKeets


If the player decides to write his own rules but wht heee wroten nto bye transssssslationableing. Boom![X(] Perfection or explosion. No sympathy.[:-]

Perfection or Boom! [:)]

Sounds like the good old days of non compiled languages .... can you say Workstation Basic? (The only platform I ever used that you could change code on the fly and pick up execution from the same spot - uggh)

Seriously, though. I understand.

If I can do anything to lift enough of the burden to make this feasable, I am happy to help. Whether it be Version 1, 2, 3, or 12.

Have a great day, Steve, and keep on coding!!!

Dean

[Shannon V. OKeets]

Dean & Patrice,

When I get to a point where I can delegate some AIO tasks, I'll come calling. Thanks for the offers.