Posts: 169
Threads: 14
Joined: Mar 2011
Reputation:
0
One of the things that used to turn me off quickly in PBMs is having to learn a lot of codes. People are not supposed to have to figure out how to talk to computers any more, they should be able to give orders in something approaching standard English,
Yes, "Feed/Rations" is harder to program for than "G9/ST-FU" and it will require that either you give the player an input program so he can select "feed rations" and the program will translate it into back-end-readable code or you turn to regular expressions so that "Fedd/Ratons" is recognized as close enough for government work.
Posts: 1,475
Threads: 340
Joined: Jan 2011
Reputation:
9
But, is the government playing the game? If not, then is "close enough for government work" sufficient?
Posts: 408
Threads: 36
Joined: Jan 2011
Reputation:
4
(03-26-2011, 02:58 PM)JonO Wrote: One of the things that used to turn me off quickly in PBMs is having to learn a lot of codes. People are not supposed to have to figure out how to talk to computers any more, they should be able to give orders in something approaching standard English,
Yes, "Feed/Rations" is harder to program for than "G9/ST-FU" and it will require that either you give the player an input program so he can select "feed rations" and the program will translate it into back-end-readable code or you turn to regular expressions so that "Fedd/Ratons" is recognized as close enough for government work.
Hear hear! The games I have played are mostly so code-intensive it's like the 80's. I put up with it out of love and devotion, but one of the real strengths of a web-based approach ought to be a really good, intuitive interface. Instead of manipulating spreadsheets and encoding your intentions, you ought to be able to click and drag bits of your empire around, move a "quantity" slider up and down, have intuitive default values auto-populate with your orders, etc.
Posts: 166
Threads: 14
Joined: Feb 2011
Reputation:
3
I wholeheartedly agree. While I don't mind them as much as the code-based orders, I also detest regular orders like the kind in Far Horizons.
Players are constantly using incorrect syntax, forgetting commas, confusing "sections". Hence my desire to create a GUI during/after this FH game.
Posts: 169
Threads: 14
Joined: Mar 2011
Reputation:
0
(03-27-2011, 01:50 PM)Ramblurr Wrote: Players are constantly using incorrect syntax, forgetting commas, confusing "sections". Hence my desire to create a GUI during/after this FH game.
I agree. The primary functions of GUIs are: A. to make everything intuitive. Having to RTFM in order to give an order is just wrong. B. Make it impossible to give a wrong order. By 'wrong' I don't mean one that has disastrous consequences, but one that cannot be carried out.
One of my pet peeves is the error handler that catches a mistake that could have been made impossible to make. It's like the programmer is setting the user up so he can yell "gotcha!" You'd fire an assistant who dealt with you that way, but are expected to think that a program that acts like that is user friendly.
Posts: 166
Threads: 14
Joined: Feb 2011
Reputation:
3
Exactly!
A perfect example from Far Horizons that one of my players just encountered involved the TRANSFER order. which syntax is:
Code: TRANSFER amount item source, destination
The player mistakenly comma separated every field, i.e.,
Code: TRANSFER amount, item, source, destination
Why the arbitrary requirement that only source/destination be separated? Pretty ridiculous.
Posts: 169
Threads: 14
Joined: Mar 2011
Reputation:
0
(03-29-2011, 02:03 PM)Ramblurr Wrote: Exactly!
A perfect example from Far Horizons that one of my players just encountered involved the TRANSFER order. which syntax is:
Code: TRANSFER amount item source, destination
The player mistakenly comma separated every field, i.e.,
Code: TRANSFER amount, item, source, destination
Why the arbitrary requirement that only source/destination be separated? Pretty ridiculous.
My guess is that the programmer was combining those two fields into a single variable that was passed to a subroutine or maybe a stored proc and thought the player should be kind enough to provide the separator.
The way I am handling transfers in RW is the player drags cargoes from a representation of his hold to a representation of his loading dock. Then he selects from a list of available recipients, and clicks on a commit button. He can still screw up, of course, but it won't be because the game mechanics tripped him up.
Posts: 408
Threads: 36
Joined: Jan 2011
Reputation:
4
I would propose 2 items that dramatically improve the user experience:
1. default orders. In this Far Horizons game, I have been delighted to discover that at the bottom of each set of turn results, there is appended a blank order set with all the basic codes in place, along with a few "suggested" orders. My scout ships have the locations of the nearest stars pre-set in their navigational arrays -- all I need to do is leave those jump orders in place, or replace them with my own overrides.
2. standing orders. Many games have repetitive tasks that need to be done each turn. Send the freighter to the mining colony - pick up all the lithuanian ruby dust - move freighter back to home world. If this needs to happen every turn, just set up standing orders to handle it, and the player can concentrate on new development while still enjoying status reports on all his drone labor.
Posts: 166
Threads: 14
Joined: Feb 2011
Reputation:
3
Yup. Both are great features to have in large-scale empire building games.
FH unfortunately lacks standing orders. Hmm.. maybe something to implement. I wonder if it is actually needed however. Micromanagement isn't really necessary in FH I suspect.
Posts: 1,475
Threads: 340
Joined: Jan 2011
Reputation:
9
Default Orders and Standing Orders are all fine and dandy, but it would be nice if I actually understood what to do with the current order options.
|