I don't think any of the commanders that day had to deal with playing a computer game where a unit was under the control of a script, the AI, and a themsleves all at the same time. If you could turn off / on the command interface buttons via script then maybe this could all work.
There is absolutly no reason, ever, in any game or any piece of software, for that matter, to make the player fight against the ui or a script to simulate historical frustration; there is no reason for a player to fight the game itself, one should only fight the simulated enemies and their AI or another human player.
I usually don't throw around im an MSCS but in this case I will because this is such bad design not only in practice but in academic cs theory. Not to mention I can't even think of another programatic system or another game that would obfuscate a human control interface in this way.
I get you want the player to feel confused, loss of control, and otherwise be placed in the historical shoe's of Rode's. Anyone who says you as the scenario designer shouldn't be allowed to do that is just plain wrong. If the script engine and courier system could do that in a way that the player wasn't confused by the interface instead of the commanders I would be all for it. So either it can and were just talking about a poorly written script that leaves the control buttons highlighted on the units in question while under the control of the script, or it can't and this was a bad level design decision trying to use the script engine to do something it can't handle.
As a third alternative maybe you just didn't think "Hey! When the script has control I should turn off the unit control buttons, maybe to distinguish them from non-controllable out of command units we should a) put an icon in the unit status window or b) maybe leave the TC button visible with maybe a different color to show its a unit under your command but currently not controllable, maybe I should prototype out these functions for the script and go ask norb to write them into the script library for me, nevertheless I need to put all this in the scenario description so the user isn't completly at a loss for what going on."
I mean if your honestly saying that the control buttons should be visible and semi-usuable while the unit is under the control of the script to simulate a sense of historical frustration, well imho you would be wrong.
Stubborn AI Continuously Overrides my Orders
Re:Stubborn AI Continuously Overrides my Orders
Last edited by jam3 on Tue May 04, 2010 11:43 pm, edited 1 time in total.
-
- Reactions:
- Posts: 25
- Joined: Fri Jan 04, 2008 5:43 am
Re:Stubborn AI Continuously Overrides my Orders
Personally I think the current system does a reasonably good job of simulating the fact that despite the best intentions, the local commander couldn't control what was going on at the time. Fog of War should apply to both sides.
One thing here - do we want historical accuracy or a crowd pleaser?
Difficult call.
Interesting discussion though.
cheers
One thing here - do we want historical accuracy or a crowd pleaser?
Difficult call.
Interesting discussion though.
cheers
Last edited by chris merchant on Wed May 05, 2010 4:33 am, edited 1 time in total.
Re:Stubborn AI Continuously Overrides my Orders
Just for fun....
"I don't think any of the commanders that day had to deal with playing a computer game where a unit was under the control of a script, the AI, and a themsleves all at the same time. If you could turn off / on the command interface buttons via script then maybe this could all work."
1. The commanders of the day had it far worse. Units would CONTINUALLY either disobey orders or misinterperet orders. Sitting in the saddle, a commander sees very little of what his command is really doing. I could do this in EVERY scenario and be well within the presented historical situation. In a perfect world, at the perfect battle, with the perfect officers, your request MAY be achieved on the perfect field of battle. This virtually never happened. But it does often in computer games... (TC button)
2. Turning off the buttons is an OOB change you can do in the SDK. If you do not want them in your command, remove them. You will not get them back. If you do, change the script and remove the restrictions... Either way, it will become non-historical. That is up to you.
"There is absolutly no reason, ever, in any game or any piece of software, for that matter, to make the player fight against the ui or a script to simulate historical frustration; there is no reason for a player to fight the game itself..."
Absolutely no reason in your opinion. Obviously it is working great.
Frustration is not the only thing simulated here. That is just a pleasent side effect.
If you fight against the AI when you know it will cause a problem, then that is your issue to deal with. Don't fight it.
As far as: "...one should only fight the simulated enemies and their AI or another human player."
That would only be 3/4 of a full cup. Remember, subordinates aren't always user friendy. It's part of the historical situation and a GOOD way to simulate a historical event.
I realize that you simply do not want the buttons on if you cant command them.
But you can, with difficulty, or don't have to....
I am not sure what a "MSCS" is, but, by the wording, is sounds like ........computer science? That's cool. It doesn't make you right or me wrong.
The SDK is your friend.
Thanks for the comments
Mark
"I don't think any of the commanders that day had to deal with playing a computer game where a unit was under the control of a script, the AI, and a themsleves all at the same time. If you could turn off / on the command interface buttons via script then maybe this could all work."
1. The commanders of the day had it far worse. Units would CONTINUALLY either disobey orders or misinterperet orders. Sitting in the saddle, a commander sees very little of what his command is really doing. I could do this in EVERY scenario and be well within the presented historical situation. In a perfect world, at the perfect battle, with the perfect officers, your request MAY be achieved on the perfect field of battle. This virtually never happened. But it does often in computer games... (TC button)
2. Turning off the buttons is an OOB change you can do in the SDK. If you do not want them in your command, remove them. You will not get them back. If you do, change the script and remove the restrictions... Either way, it will become non-historical. That is up to you.
"There is absolutly no reason, ever, in any game or any piece of software, for that matter, to make the player fight against the ui or a script to simulate historical frustration; there is no reason for a player to fight the game itself..."
Absolutely no reason in your opinion. Obviously it is working great.

Frustration is not the only thing simulated here. That is just a pleasent side effect.
If you fight against the AI when you know it will cause a problem, then that is your issue to deal with. Don't fight it.
As far as: "...one should only fight the simulated enemies and their AI or another human player."
That would only be 3/4 of a full cup. Remember, subordinates aren't always user friendy. It's part of the historical situation and a GOOD way to simulate a historical event.
I realize that you simply do not want the buttons on if you cant command them.
But you can, with difficulty, or don't have to....
I am not sure what a "MSCS" is, but, by the wording, is sounds like ........computer science? That's cool. It doesn't make you right or me wrong.

The SDK is your friend.
Thanks for the comments
Mark
Mark S. Tewes