Any news on the A.I.?

[Shannon V. OKeets]

ORIGINAL: flipperwasirish
cwie,

Please spend less time over here and more time working on CWIE2.

I have interest in the both MWIF and CWIE2 projects.

I have a friend who has an XP machine and will not play anything but CWIE.

Flipper

It's simply unproductive to focus on one thing continually. Your eyes get crossed.

And cross pollination of ideas between developers yields better results for everyone.

[wworld7]

ORIGINAL: cwie

ORIGINAL: flipperwasirish

cwie,

Please spend less time over here and more time working on CWIE2.

I have interest in the both MWIF and CWIE2 projects.

I have a friend who has an XP machine and will not play anything but CWIE.

Flipper

ORIGINAL: cwie

If I had more time to spend, it would be spent on CWiE2! Just need 27 hours a day and we'd be fine.

Stop eating and sleeping and maybe you could it (drink, program CWIE2 and pollinate MWIF).


But I need my MWif fix as well, so I drop by to stay in touch. Was a beta tester in the Chris Mariacci days, and MWiF is top of my list of purchases in 2007.

ORIGINAL: Shannon V. OKeets

It's simply unproductive to focus on one thing continually. Your eyes get crossed.

And cross pollination of ideas between developers yields better results for everyone.

I can't argue against such solid logic. I intend to purchase both in 2007 if they make it out the door. But come 2008 the game of choice will be the....drum roll... the Vista version of Donkey Kong

[SamuraiProgrmmr]

Before I start, I would like to say something.

Any time a debate like this is carried on in writing, there is the chance that something will be taken wrong and a flame war will ensue. Please accept that I am debating the issue and have no intention of sarcasm, slamming, disrespecting or any other socially negative actions. If anything I write here is taken that way, it is taken in a spirit different from what is intended.

ORIGINAL: cwie

There are several major issues with this approach :

1. Data Access. The AI 'logic' lives in the DLL, but the 'game state' lives in the main exe. If the AI is to make any meaningful decisions, it will need a means to access all "relevent" state information in the exe. That's potentially a lot of information that needs to be exchanged and kept in sync. If you simply grant the DLL 'access' to the raw gamestate, then you open the door to gamestate corruption. If you develop a mechanism for 'marshalling' the data across from the exe to the dll you have to (a) establish and maintain the appropriate number and types of 'marshalled data' and (b) handle syncing issues - making sure that the AI dll is fully using the 'current state', not a mix of current and past state.

Yes, the game state lives in the main exe. Yes, the DLL may not have unlimited access to the game state to prevent cheating. Yes, there must be a path for the data to get to the DLL. No, there are not any problems with syncing issues.

Even though the DLL does exist separately from the EXE before the program is run, it will be part of the EXE when it runs. DLL stands for Dynamic Link Library. Technically speaking, Linking occurs as the last step of compiling. The machine code that has been generated from the source code is linked together so that every place there is a call to a method (think subroutine) is finally given an address to the method. The concept of DLLs simply delays the linking process until the program is run. So the DLL is effectively part of the main program at executiion time.

This makes the sharing of data much easier. No DDE (dynamic data exchange) must occur between multiple programs that are running. Steve mentioned that he wanted to 'thread' the AIO. That does not, in and of itself, create another executing program. It is still part of the same program.

As for data exchange, it would appear that there would be some inefficiencies in passing the data. What is more likely closer to the truth is that Steve would be calling methods to get the data he wants anyway. Grabbing a piece of data is not always a simple process. I often write functions that 'fetch' the piece of data I want while processing. I call them with parameters that identify what I need at the moment and the functions give it to me. Exposing those calls to the DLL should not cause a great amount of extra processing time.

To prevent the DLL from altering the game state data directly is very simple. When called, the DLL will be passed the address of either a TObject or a function. This TObject or function will ONLY return data and will NEVER change data. As I stated before, the 'orders' that the DLL gives will need to be passed to the game engine in a tokenized form so it can check them for validity before implementing them. This is the only place where non-insignificant processing will be added if this method is adopted. I still don't think it will be that bad.

ORIGINAL: cwie

2. Data versioning. With a separate AI DLL, we need to ensure that the EXE and DLL remain 'in step' in terms of data format and structure. So if Steve releases "MWiFV1.0.exe" and you immediately write "MySuperAI.dll", then Steve is now unable to change any shared data structures in the exe for the new "MWiF-v1.2.exe" without potentially breaking your logic.

Yes, of course. I think this is insigificant. Do you know of any games that haven't broken save games at sometime when a patch was released? If Steve patches the program, he will patch his AIs if necessary no matter what paradigm he adopts for the AIO.

This is not a problem because use of 'customized' AIOs will be optional anyway. If there are enough changes during a patch to create these problems, the save game will likely be broken anyway so you simply start a new game with the stock AIOs.

ORIGINAL: cwie

3. Stability is a real issue here - if your AI dll crashes at any time it will take out MWif on it's way down in flames. Imagine you (or someone using your AI DLL) are 2 hours into a game of MWif and it suddenly crashes. What caused it to fail - a long-hidden bug in the main code, or a rogue AI dll? The frustrated player(s) contact Matrix and report a bug.

I think that it will be fairly obvious if a problem only occurs when a non-stock AIO is being used that it is a problem with the non-stock AIO. The gaming industry is filled with mods that 'break' games. There is no reason to believe that this will be any different. Space Empires IV had the opportunity for custom AIs. Some were good and some were bad. The community had opinions on which was which and people actually used them. I will address another point about this in my next post.

ORIGINAL: cwie


At the very least, there's an ongoing need for some sort of support mechanism that sorts out 'core bugs' from 'AI bugs'. And crashes are just the most visible form of problem here - how about an AI that misbehaves by slowly and gradually sending random air units to the North Pole? Once the player discovers this, is it an AI issue, or a core game issue? How do you tell?

The stock AIOs will be no more stable or unstable because they are in a DLL. It will likely be the same code either way.

I seriously doubt that anyone (even myself) would actually build an AIO from the ground up. More likely, they will tweak the functions they are interested in and simply pass the rest of the function calls over to a stock AI.

ORIGINAL: cwie


I've built several commercial apps that have offer this "dll plug-in" type of feature to enable end users to customise and/or extend behaviour. Each of the above issues has occurred repeatedly. Each can be managed/solved, but each requires an ongoing commitment of time and energy on the part of the EXE designer. I've spent many hours looking into subtle problems only to find that the error lies in user created code. In short, it isn't "free" to add a user definable AI.

I disagree with this. When the DLL is a required part of the total package, yes it is a problem. When the DLL is an optional replacement for an existing DLL, no it is not. If someone can't get their DLL to work, they should not release it. Furthermore, the community should not use it.

ORIGINAL: cwie

I'd be happy if MWif shipped with such an extensible AI ... but I also fully understand if Steve wants to leave this alone!

[&o][&o][&o]So would I [&o][&o][&o]

[;)]

To be sure, I doubt this will be part of the first version. But, as I pointed out earlier, if things are structured correctly now, it will leave room for such an expansion. If not, it will likely never happen.

ORIGINAL: cwie

* EDITED TO ADD : Almost forgot the biggest up-front time consumer - documenting the gamestate!!! If you're really going to write a solid AI as a dll, you'll need to understand just what the hell all those data structures do. That's not a minor task - describing the data, it's structure, and its 'lifecycle' (when it has meaning, when it doesn't).

Yes, there is some truth to that. In the old days, we were limited to 8 characters for variable and method names. Today, however, the names can be very long (and descriptive) and the development tools have useful functionality built into them to keep long names from being a hassle while writing code. Good choices in descriptive names will minimize the impact of that problem.

Also, the 'game state' should always have meaning. The question is really whether the AIO is interested in that state to make its decision.

CWIE, I am genuinely interested in your rebuttal.

Dean

[SamuraiProgrmmr]

Some of you may be asking WHY?  Why does he care?  Why does it matter?
 
Good Question!
 
Here is (I hope) a good answer.
 
WIF takes a very long time to play.  In my limited experience, (as in bridge), being brilliant is not nearly as important as not making mistakes.  Every game of WIF I have ever played was decided when someone made a terrible error and thier opponent capitalized on it. 
 
In my previous post, I mentioned Space Empires IV.  This was a game that took a very long time to play.  We would spend literally months on PBEM games.  When they were over, the were generally decided by one of three major factors:
[ol][*]Diplomatic Treachery (It's part of the game).
[*]Inequitable starting situations giving some players a disadvantage that they can never overcome.
[*]Choices made before the game started that could not be changed during the game.[/ol]
#2 and #3 are the points I would like to key on.  Many games were foregone conclusions because of #2 and #3.  No one knew for sure what that conclusion was until the game played out.  Nonetheless, choices made in the pregame customization of your race and the random encounters of NPC races early in the game usually (in my experience) determined the winner.
 
So, we would play for months to find out what was determined in the the first week (or even the first 30 minutes of play)!
 
SEIV had a player community that tinkered with customized AIs.  That was nice because the AI was not always that challenging.  Some of the community provided ones were pretty ruthless.  All of them had their problems, though.
 
One of the neat things that happened in that community was that occasionaly, someone would run a 'tournament' pitting player provided AIs against each other.  So instead of taking 3 to 5 years, in 3 to 5 weeks, a good tournament could be run and the AI writers could go 'back to the drawing board'.
 
In this case, they had all of the fun of playing the game (except human diplomacy) without the drudgery (I know of people that took 4 hours to do a turn late in a game).
 
This is what I am hoping for.  This is why.  I would like to be able to pit my skills as a WIFfer and as a programmer against others. Life is such that I don't have time to play.  I want to be able to 'experience' playing the game - i.e.  Figure out which strategies work and which ones don't --- get feedback on my ideas --- challenge some of the best! 
 
However, I know I won't have the time to devote to it.  And I don't want 3 months of play time to be wasted because I forgot to garrison Alaska. (Don't ask - it actually happened [:(]). 
 
Oh well,  I have rambled enough.
 
Thanks for reading.

[Froonp]

Some of you may be asking WHY? Why does he care? Why does it matter?

I am happy you care, and I don't need to know why [:D] [:D]

[Shannon V. OKeets]

Dean,

I like your ideas. When I redesign the game engine (probably in December) to support NetPlay, PBEM, and the AIO, I'll keep all this in mind. Still, documenting (so an outsider can understand and modify) the 5 or 6 hundred processes that will be used to drive the AIO decision making won't be part of MWIF product 1. That extra delay would be unfair to many people.

[SamuraiProgrmmr]

Steve,

In the SEIV game I was speaking of, there was basically ZERO documentation... Just the CSV files with the existing scripts and have at it!

Assuming you go with the DLL idea....

The only documentation that would be absolutely necessary would be to publish the interface section of the DLL . If the procedure and function calls are named informatively, the rest should be fairly straightforward.

In case it matters, I would volunteer to help document those if you would be willing to answer questions occasionally and point out errors in the documents.


[X(][X(][X(][;)]

[Shannon V. OKeets]

ORIGINAL: SamuraiProgrammer

Steve,

In the SEIV game I was speaking of, there was basically ZERO documentation... Just the CSV files with the existing scripts and have at it!

Assuming you go with the DLL idea....

The only documentation that would be absolutely necessary would be to publish the interface section of the DLL . If the procedure and function calls are named informatively, the rest should be fairly straightforward.

In case it matters, I would volunteer to help document those if you would be willing to answer questions occasionally and point out errors in the documents.


[X(][X(][X(][;)]

WARNING: I will not forget your offer.[:)]

[SamuraiProgrmmr]

[X(]
 
By the way....
 
My name is Rufus T. Bumpkin.
 
I can be found at:
 
4200 E Sunken Drive
East East Miami, East Florida BR549
 
[;)]
 
Seriously,
 
I am here when you need me.
 
Dean

[Zorachus99]

ORIGINAL: SamuraiProgrammer
However, I know I won't have the time to devote to it.  And I don't want 3 months of play time to be wasted because I forgot to garrison Alaska. (Don't ask - it actually happened [:(]). 

I NEED TO KNOW How did it occur, ramifications, and could the Japanese really do something with that? The bad old days of off-board boxes?

Sounds vewwy interesting!

Perhaps we need a WIF thread to share about WIF games of yore.

[SamuraiProgrmmr]

It has been 10 or 15 years but I will tell you what I remember.  Any of this is suspect, but the general picture is correct.

This was before we even got the first copy of Africa In Flames, so everything was off map boxes.  If I recall correctly, the Aleutian Islands were represented on the pacific map.

There is some history.  Every game of WIF I have played has been against the same person.  He had played before and so I was always behind the curve on understanding the game.  He beat me solidly every time we played except one.  We always played the Global War scenario (probably not the most efficient way to learn the game) .  In all of the games we played, I have yet to play an actual D-Day invasion.  The games were simply over by then.  I was still learning and it was more interesting to start again and try to not make the same mistakes. 

As Japan, he had been working hard at collapsing India, so as you can well imagine, US Entry was wayyyy ahead of the curve.  Trust me... It doesn't do you as much good as the Allies as you would hope.  The US was in the war but had not built up much of a fleet.  I sent what I could against Japan in the small islands to take pressure off of India immediately (MISTAKE #1).  Meanwhile, I had sent most everything else into the European theatre (MISTAKE #2)

He was geared up strongly for infantry and was cranking them out.

When I committed too much of my navy to take a couple or three islands (MISTAKE #3), he sent the erstwhile Indian reinforcements into the Aleutians.  Due to low gearing of ground units (MISTAKE #4) and an economy only just waking up (See MISTAKE #1), he was going to have 3-1 or better against the West Coast of the US no matter what I did.

I conceded so we could start again.  Each time I was beaten, we would swap sides and go again.  Each time the games got better.  But yes, it happened!

[Zorachus99]

Interesting story. I figured the off-map boxes had to be the culprit. I've often either been a peer or a teacher. After about 5-6 years my student (who developed an unending love for the game) soundly clobbered me and my tricky little gambits. I felt like a proud pappa

[SamuraiProgrmmr]

I just have to tell this.... and then I will stop posting off topic...[8|]
 
We had started playing with the Africa In Flames Rules and Days Of Decision starting the Grand Campaign in 1936.  This was the first edition of DOD and I believe we were interpreting things correctly... but who knows?
 
I had been threatening him with buidling the Maginot Line all the way to the channel and finally did it.  This made him unhappy because his tried and true methods for harming France were not going to be as reliable.
 
I got frisky with the British and had moved all (MISTAKE #1 [:D]) 4 of my NAVs out on the beginnings of a journey that would have them in place to pound the Italian Navy quickly upon the start of the General War.  My intent was to have them back to England before Germany could turn up the heat for SeaLion.
 
He started going through his small stacks of counters (It was 37 or early 38) and studying and thinking and announced that he wanted to stop playing for the day as he had a big decision to make.
 
????
 
"Ok, fine. we can stop and pick up next time, but what is it you are thinking about?"
 
He told me he was thinking about declaring war on the Commonwealth early and to my horror he had the stuf in the right place and my navy was out escorting (Same old overcommitment -  Gung Ho Dean).
 
It was clear that he could seriously dent the Commonwealth and probably bring the game to an early end, but I tried to exude confidence (there was really nothing else to do).
 
The next week he came over and studied the map for 30 minutes and finally said:
 
"I can't for the life of me see what you have planned, but I don't trust you" and went on with his turn.  He did not declare war early.
 
At first opportunity, I quickly moved the NAVs back into place to defend Britain from sea attack and explained to him that I had no master plan to thump him but had just not considered that he would do it.
 
That was the last time we played WIF. (We have played many other games and even team up for bridge.) The game stayed in the cabinet in that state for about 6 months before he finally conceded rather than come back to play.  I think it broke his heart to realize that his beloved Germans could have had their way with the CW and he passed it up because he thought I was a (in his words) "sneaky rat bastard".
 
I still chuckle at this.  Had I known it would have been the end of WIF for so long, I would have let him invade.
 
Oh Well
 

[SurrenderMonkey]

Samurai,
 
The very best games create these kinds of moments.  [:)]

[TemKarl]

SamuraiProgrammer,

Please accept that I am debating the issue and have no intention of sarcasm, slamming, disrespecting or any other socially negative actions.

And the same applies here.

So the DLL is effectively part of the main program at execution time.

Yes, but not at design time! A key point of a DLL is to enable development of code that does not directly understand it's enclosing framework - it interacts with the exe via a clearly defined (and limited) interface. This is a two-way street : the DLL code (a) works independant of the details of it's enclosing shell and (b) cannot directly affect it's enclosing shell. The fact that at runtime it is - from the operating system's persective - all part of a single executing process doesn't affect the fact that it was designed as a separate logical entity.

No, there are not any problems with syncing issues.

Well, I'd disagree here, except in some very rare circumstances. Without getting into too much detail, what I mean by 'sync' here is that the AIO DLL needs to keep it's own 'state' in step with the main gamestate. To make decisions, the AIO probably needs to gather and build tables and structures of it's own, which are not visible to the main exe. Incorrect duplication of data is a major source of programming errors ... especially in threaded apps. Unless the AIO has absolutely no internal state whatsoever between calls to it's interface, then syncing is an issue.

As an example, the AIO probably tries to keep track of the relative 'value' of certain map hexes when determining possible moves. This "AIO internal" data is built from information derived from the gamestate, but updated and refereshed by the AIO. Imagine that as part of the AIO, the main program needs to ask the AIO to determine a land unit movement. The AIO requests info from the gamestate, and updates it's internal data. It then decides to move unit 'X' 3 hexes west, and the program acts on this decision and updates it's gamestate accordingly. Yet this single move may affect much of the gamestate - changing supply states for units and hexes in surrounding areas, cutting rail lines, changing calculations of production/resources, etc . The exe now asks the AIO for another movement. At this point, how much internal state does the AIO need to refresh? Everything? Or can it assume that some data simply cannot have changed since the last movement calculation? If your answer is "it needs to access/refresh all relevant data' then the question becomes "How does the AIO writer determine 'relevant data'"? Unless you understand all possible consequences of all possible actions, you have to either (a) play it safe and gather everything everytime or (b) try to optimise by gathering just what you think is necessary.

Perhaps this is a poor example ... and perhaps having a poor example is an indication of a weak point! But to me if the AIO is a separate logical entity then it will need at least some internal state to operate efficiently.

This makes the sharing of data much easier. No DDE (dynamic data exchange) must occur between multiple programs that are running.

Correct, and my use of the turn 'marshalling' may have created confusion. I did not mean to imply inter-process communication or COM interfaces. What I wanted to convey was that when the AIO DLL is written/designed it will need a 'view' of the data. That 'view' is not necessarily the same as the main programs 'view' - we probably want to restrict some data, for example. Hence, you need to create a defintion/description of the gamestate that is appropriate for the AIO.

The idea of 'marshalling' is far more important if threading is involved - access to data from two threads (even if one is only reading) must be tightly controlled.

(re: versioning)I think this is insigificant. Do you know of any games that haven't broken save games at sometime when a patch was released?

Well, I don't know how to measure the significance. The issue here is that you place a permanent 'caveat' on Steve - future changes he may wish to make need to consider the effect on custom AIOs. Sure, he can decide that a change is necessary and anyone taking the new patch must restart any saved games. But this also means anyone who has written and distributed a custom AIO needs to recheck and potentially rewrite/debug their code.

This is a catch 22 situation. If very few people ever write AIOs, then versioning is insignificant ... but then by definition the entire ability to write custom AIOs is insignificant! If custom AIOs are a great success, then versioning looms as a major issue.

I think that it will be fairly obvious if a problem only occurs when a non-stock AIO is being used that it is a problem with the non-stock AIO.

I can agree that MOST crashes in a custom AIO will be pretty obviously an error caused by the AIO. But I've done enough plug-in work to know that the problem lies in the 20% of issues that aren't obvious, not the 80% that are.

The stock AIOs will be no more stable or unstable because they are in a DLL. It will likely be the same code either way.

And Steve and Matrix have a direct responsibility for ensuring that stability, and fixing it if it's not there. The problems can come from determining who is responsible for "preceived instability" resulting from AIO development.

To be sure, I doubt this will be part of the first version. But, as I pointed out earlier, if things are structured correctly now, it will leave room for such an expansion. If not, it will likely never happen.

Agreed, to a point. Programming is always an exercise in choosing alternatives, measuring benefit versus cost. You've made the case to show the "benefit" of an AIO as a separate DLL with a tightly defined interface. I've simply tried to shown that there is a "cost" that comes with this approach. It's up to Steve to decide, based on what he knows of his requirements and his timeframe.

Good choices in descriptive names will minimize the impact of that problem.

The longest software project I've been actively ionvolved with has code that is now almost 20 years old, and is still in production use and (ongoing) development. Documentation is never sufficient. And getting one programmer to explain his decisions (it's the 'why' more that the 'what' that often matters) in writing to another that he has never met is ... tricky at best.

Also, the 'game state' should always have meaning. The question is really whether the AIO is interested in that state to make its decision.

Ah ... perhaps this is just a point of detail. As an example, in CWIE there are hexes containing resources. If the German captures such a hex during a game turn, the hex is immediately considered 'German owned'. However, the variable that tracks the number of german controlled resources is only used in the 'production cycle' which occurs every 4 turns. So that variable is only updated at the start of the production cycle, to reflect all activity in the past 4 turns. Accessing that variable during any of the preceeding 4 turns would produce a possibly incorrect value. The program knows this, and doesn't access this variable. An AIO writer however might assume that when he finds a variable called "NumGermanOwnedResources" that he can access this at anytime. He'd be wrong, and a subtle bug has entered the system.

In the above example the 'gamestate' variable that tracks German controlled resources is valid whenever the program needs it to be. That doesn't mean it is valid at all times.

CWIE, I am genuinely interested in your rebuttal.

To be clear, I'm not arguing against your suggestion. Merely trying to point out that it's not a "free ride" to go down that path. We've kicked a few ideas around for the possible (but not yet definite) AI for future inclusion in CWIE-II, and the DLL idea is on the table. The other main contender for offering 'custom-AI' that we are considering is to offer a limited scripting ability, with key 'execution points' in the main code that would allow users to write their own scripts. Both approaches share many common pitfalls, and it's possible that if and when we proceed with the AI work that customisation will not be a feature. Or maybe it will!

[SamuraiProgrmmr]

ORIGINAL: cwie

And the same applies here.

Great! I really hate it when good discussions go bad due to misunderstandings.

ORIGINAL: cwie

Yes, but not at design time!

True, but I don't think it matters. The DLL will get its data in one of two ways. It will either be passed an object or record that contains all of the data or it will be passed the address of an object that will give it the data when it asks for it.

Either way, the DLL will have to have access to the interface of that object or record. (Earlier when I said the minimum documentation would be the interface section of the DLL, I was wrong. The interface section of the global data object or the data interface object will have to be published as well. (How's that for too many uses of the word interface [:(])

It is common for separate encapsulated segments of a project to use the same interfaces.

ORIGINAL: cwie

A key point of a DLL is to enable development of code that does not directly understand it's enclosing framework - it interacts with the exe via a clearly defined (and limited) interface.

I agree with that statement in general, but there are specific situations where it can be more encompasing.

One would be a situation where a piece of software was sold to different customers with different levels of functionality (and at different prices). The main module would expect 'FOOBAR.DLL' to exist but would not necessarily know which version of 'FOOBAR.DLL' was there. As long as the interfaces matched it doesn't care how the DLL does its thing as long as it gets done. (This is very similar to what I am proposing if not dead on.)

Another is where the development platform for the main project is not well suited for a specific task and does not play well with other platforms. I worked on a project where the main development was done on a Macintosh. It was an interactive Atlas of the Human Body for medical students. A windows port was required. Some functions that were provided by the MAC OS were not so easily provided for in Windows. The development platform was mostly a 'show and tell' that displayed images. I wrote the DLL in Delphi to handle the 'outline', 'cut' and 'paste' functions that were already there in the MAC version of this package. In this case, it was the main program that was blissfully ignorant and the DLL that had to make do with a limited interface.

ORIGINAL: cwie

This is a two-way street : the DLL code (a) works independant of the details of it's enclosing shell and (b) cannot directly affect it's enclosing shell.

The DLL is encapsulated. It should be able to work with any program that can use its interface. IMO, it should not directly affect it's enclosing shell - BUT - Depending on how the interface is written and used, it can. The Main program can pass a pointer to an object or data structure which the DLL can use and allow it to change the data.

This is why I suggested passing an 'interface object' that can answer the DLL's questions. This prevents disreputable developers from 'cheating'.

ORIGINAL: cwie

Without getting into too much detail, what I mean by 'sync' here is that the AIO DLL needs to keep it's own 'state' in step with the main gamestate. To make decisions, the AIO probably needs to gather and build tables and structures of it's own, which are not visible to the main exe. Incorrect duplication of data is a major source of programming errors ... especially in threaded apps. Unless the AIO has absolutely no internal state whatsoever between calls to it's interface, then syncing is an issue.

If one of the parameters to every call is a helper 'interface object' that can answer questions, the DLL will not have to maintain it's own copy of the game state. It will likely keep track of it's plans to prevent 'double clutching' from turn to turn in close situations, but I would think that reevaluation of 'preconcieved notions' should be a regularly occuring process. How it is triggered is probably best done based on 'what turn/impulse/phase' is it. Every time the game engine calls the DLL, there will be a context to the call. For example, the game engine will not ask which unit to move during the initiative roll phase or ask for builds during a movement phase.

ORIGINAL: cwie

As an example, the AIO probably tries to keep track of the relative 'value' of certain map hexes when determining possible moves. This "AIO internal" data is built from information derived from the gamestate, but updated and refereshed by the AIO. Imagine that as part of the AIO, the main program needs to ask the AIO to determine a land unit movement. The AIO requests info from the gamestate, and updates it's internal data. It then decides to move unit 'X' 3 hexes west, and the program acts on this decision and updates it's gamestate accordingly. Yet this single move may affect much of the gamestate - changing supply states for units and hexes in surrounding areas, cutting rail lines, changing calculations of production/resources, etc . The exe now asks the AIO for another movement. At this point, how much internal state does the AIO need to refresh? Everything? Or can it assume that some data simply cannot have changed since the last movement calculation? If your answer is "it needs to access/refresh all relevant data' then the question becomes "How does the AIO writer determine 'relevant data'"? Unless you understand all possible consequences of all possible actions, you have to either (a) play it safe and gather everything everytime or (b) try to optimise by gathering just what you think is necessary.

Perhaps this is a poor example ... and perhaps having a poor example is an indication of a weak point! But to me if the AIO is a separate logical entity then it will need at least some internal state to operate efficiently.

No, it is a very good example. But I don't think it matters. If the DLL can ask for any piece of information when it needs to access it, then it doesn't need to keep its own copy and worry about sync problems. There are certainly difficulties in planning ahead (as Steve mentioned), but I don't know of any good way around them. If something changes, how can you tell how much it affects your plan unless you replan?

The key is arranging things so that the DLL can ask the game engine for information but cannot directly change it.

ORIGINAL: cwie

Correct, and my use of the turn 'marshalling' may have created confusion. I did not mean to imply inter-process communication or COM interfaces.

OMG -- ANYTHING but COM - I once accidentaly SLAYED a Windows install experimenting with COM.

ORIGINAL: cwie

What I wanted to convey was that when the AIO DLL is written/designed it will need a 'view' of the data. That 'view' is not necessarily the same as the main programs 'view' - we probably want to restrict some data, for example. Hence, you need to create a defintion/description of the gamestate that is appropriate for the AIO.

thus the helper object to serve data to the dll

ORIGINAL: cwie

The idea of 'marshalling' is far more important if threading is involved - access to data from two threads (even if one is only reading) must be tightly controlled.

Absolutely true. I can't speak for other languages, but Delphi has a special function that asks the main thread to process a method to prevent these problems.

ORIGINAL: cwie

Well, I don't know how to measure the significance. The issue here is that you place a permanent 'caveat' on Steve - future changes he may wish to make need to consider the effect on custom AIOs. Sure, he can decide that a change is necessary and anyone taking the new patch must restart any saved games. But this also means anyone who has written and distributed a custom AIO needs to recheck and potentially rewrite/debug their code.

This is a catch 22 situation. If very few people ever write AIOs, then versioning is insignificant ... but then by definition the entire ability to write custom AIOs is insignificant! If custom AIOs are a great success, then versioning looms as a major issue.

Yes. When Steve changes the game state data, it may break the AIOs or at least make them stupid. He would release new interface information and AIO creators would need to update thiers.

ORIGINAL: cwie

I can agree that MOST crashes in a custom AIO will be pretty obviously an error caused by the AIO. But I've done enough plug-in work to know that the problem lies in the 20% of issues that aren't obvious, not the 80% that are.

And Steve and Matrix have a direct responsibility for ensuring that stability, and fixing it if it's not there. The problems can come from determining who is responsible for "preceived instability" resulting from AIO development.

I can't argue with problems not always being obvious. But, I would hope that anyone who would percieve a publisher to be at fault after installing a purely optional plug in that only changes existing functionality instead of adding functionality would be too uniformed to bother in the first place.

ORIGINAL: cwie

To be sure, I doubt this will be part of the first version. But, as I pointed out earlier, if things are structured correctly now, it will leave room for such an expansion. If not, it will likely never happen.

Agreed, to a point. Programming is always an exercise in choosing alternatives, measuring benefit versus cost. You've made the case to show the "benefit" of an AIO as a separate DLL with a tightly defined interface. I've simply tried to shown that there is a "cost" that comes with this approach. It's up to Steve to decide, based on what he knows of his requirements and his timeframe.

I agree wholeheartedly. I am just excited to realize that it is still early enough in the development cycle to make those decisions without even more 'cost'. Nothing hurts worse than someone changing the requirements of a piece of software after you have built code upon the premise that those requirements were not needed. ('Requirements' is too strong a word for what we are talking about but I think you know what I mean.)

ORIGINAL: cwie

The longest software project I've been actively ionvolved with has code that is now almost 20 years old, and is still in production use and (ongoing) development. Documentation is never sufficient. And getting one programmer to explain his decisions (it's the 'why' more that the 'what' that often matters) in writing to another that he has never met is ... tricky at best.

Tricky? Some days I would rather take a beating than answer that question. It is always a value judgement, isn't it?

ORIGINAL: cwie

Ah ... perhaps this is just a point of detail. As an example, in CWIE there are hexes containing resources. If the German captures such a hex during a game turn, the hex is immediately considered 'German owned'. However, the variable that tracks the number of german controlled resources is only used in the 'production cycle' which occurs every 4 turns. So that variable is only updated at the start of the production cycle, to reflect all activity in the past 4 turns. Accessing that variable during any of the preceeding 4 turns would produce a possibly incorrect value. The program knows this, and doesn't access this variable. An AIO writer however might assume that when he finds a variable called "NumGermanOwnedResources" that he can access this at anytime. He'd be wrong, and a subtle bug has entered the system.

In the above example the 'gamestate' variable that tracks German controlled resources is valid whenever the program needs it to be. That doesn't mean it is valid at all times.

Now that is an interesting point. Just because I want to know doesn't mean that Steve thought I would want to know at that time. Is everything adjusted on the fly or are some values batch processed? Steve knows. Maybe he will tell.

The way around that may be simple or it may be hard -- depending on the specific piece of information. If that piece of information were provided by a function that recalculated it, it would always be right. On the other hand, if it is a time intensive calculation, now some of our speed and efficiency went out of the window.

ORIGINAL: cwie

To be clear, I'm not arguing against your suggestion. Merely trying to point out that it's not a "free ride" to go down that path. We've kicked a few ideas around for the possible (but not yet definite) AI for future inclusion in CWIE-II, and the DLL idea is on the table. The other main contender for offering 'custom-AI' that we are considering is to offer a limited scripting ability, with key 'execution points' in the main code that would allow users to write their own scripts. Both approaches share many common pitfalls, and it's possible that if and when we proceed with the AI work that customisation will not be a feature. Or maybe it will!

The debate is accepted in the spirit it is offered. Hashing out possible problems is certainly part of the early process. Thanks for letting me be part of it.

I am fully aware that as a deveoper, you are always weighing 'bang for the buck'. Development costs time which is money. I am a developer too. I have been programming computers professionally for 23 years. I understand these things. My personal cross to bear is that I always want to do things 'exactly' right and therefore development is slow. And therefore it is expensive. But, so far, the results have been good and my 'users' are generally happy.

Scripting will certainly be able to be used by a larger group of players.

The two are not necessarily mutually exclusive. If the game engine asks the scripting engine questions about what to do, then maybe the scripting engine could be implemented in the stock DLL which could still be replaced by a user implementd one. (run, duck, and cover) [:)] I say this with tounge only partially in cheek.

It is clear that cost to value will be the determining factor and that is exactly how it should be. Exactly.

You guys keep up the good work and understand this above all. If the decision is made not to expose the AI to oustide influences, I will smile and buy the game just like I will if these ideas are implemented. I promise not to whine or beg. I promise to be happy.

Dean

[Shannon V. OKeets]

To be thunk about.

What I enjoy(ed) most about this discussion, which I found intellectually stimulating, is that there are a whole lot of MWIF forum readers who wonder if you are making words up in these posts. To them I will simply say, "No, they're not. And yes, programming is that complex."

[TemKarl]

SamuraiProgrammer,

We're close enough on most points that I don't think another set of point-by-point responses would add much. I'll just add that my caution on this issue is heavily colored by my own personal experience. I've done exactly what you are proposing here - build an interface into a program that allowed us to (a) supply an (internally built by us) DLL that provided 'default' behaviours and (b) allowed end users to modify and extend that behaviour if they wished by substituting (or chaining) their own DLL. Worked very well straight out of the box.

The end result? After 3 years, we removed the functionality entirely. The costs in documentation and DLL support, and interactions with ongoing core code changes, made it a maintenance nightmare. Once bitten, I guess...

Two quick specifics :

If the DLL can ask for any piece of information when it needs to access it, then it doesn't need to keep its own copy and worry about sync problems.

Perhaps this can't be answered without getting into the details. But it seems to me that the AIO will need at least some 'state' of it's own to perform any real/complex decision making.

... but Delphi has a special function that asks the main thread to process a method to prevent these problems

Been a while since I touched Delphi, but as a general rule language-based support for threading basically involves temporarily suspending threading. Which kind of defeats a lot of the reason for doing it. To get high performance threading (and performance is the main reason for threading really), you need to ensure that you keep interactions between threads right down low. That generally means you can't have the main exe running in thread 'A' and changing the gamestate while the AIO runs in thread 'B' and uses the 'helper' object to read the gamestate. Again, this encourages you to keep a copy of relevant state in the AIO to avoid thread conflicts.

---------------------

For what it's worth, the current CWiE code base is actually built from a project we began 5 years ago. That project was intended to create a 'framework' exe for hex based wargames, and the rules, data and AI for any specific game would be supplied as DLLs. Simplified greatly, the project was to deliver a 'wargame.exe' that never changed, and you'd buy a "MWiF.DLL" and drop it onto the harddisk. You could also then buy "CWiE.DLL" or "SquadLeader.DLL" and they'd all work with the basic "Wargame.exe". The EXE provided the core interface, map drawing and handling, menus, toolbars, etc. The DLL provided game rules, map and unit data, and AI. And since the DLL interface was well defined, in theory anyone who wanted to spend the time could write their own 'game.dll' and plug it in.

It all worked (had two test/same DLLs up and running for development purposes), but it's been put to one side to focus on CWiE.

One day we might have to revisit that idea!

[TemKarl]

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]

[Greyshaft]

ORIGINAL: Shannon V. OKeets
"... And yes, programming is that complex."

Actually its worse. These fine gentlemen have been discussing philosophy of software design. Once they agree on the philosophy (assuming that they CAN agree [:D]) then they need to prepare a Functional Specification (start with the MWiF rulebook and charts and increase by 2-300%)and only then can they start the coding of tens of thousands of lines of code with 100% accuracy of syntax.

Better them than me.
I'll sit here tweaking my 100 line Java module and keep a low profile...