Re:Stubborn AI Continuously Overrides my Orders
Posted: Tue May 04, 2010 11:04 pm
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.
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.