From: Paducah, Kentucky
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.
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.
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.
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.
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.
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.
I'd be happy if MWif shipped with such an extensible AI ... but I also fully understand if Steve wants to leave this alone!
So would I
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.
* 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.
Bridge is the best wargame going .. Where else can you find a tournament every weekend?