Dakotah, This is Aaron again. I'd rather participate in this thread with
my own email account, but I don't seem to be getting messages from this
thread on my own account for some odd reason.
The grid suggestion would be a good idea when you know what's left and
right of you, and that there is in fact something to your left or right.
One thing we have done in our future game is in one particular
situation, movement to be specific, we have two options. You can go into
the movement menu then there are two items, approach, and retreat. If
you press enter on either, you get an edit box asking how far to go.
However you can use your right arrow without first pressing enter to
scroll pretty rapidly the amount that you would like to go. It always
starts at 0, and it resets every time you use up or down to go to the
other option, from approach to retreat for instance. if you went back to
approach, it would still be 0 even if you had it at 30000 before you
moved. You just hold right arrow and when it gets close to how far you
want, you hit enter and since you did it that way you don't have to
type. Originally we were going to just do the edit box, but that was
going to be pretty much the only spot in the whole game where you have
to know how to type. So since we were that close, we thought this up so
a 5 year old or maybe someone who is newly blind could more comfortably
control the game. Since you have to learn the arrow keys and enter key
to do everything else, this turned out to be a pretty cool idea, at
least that's what we hope. As for interrupting menus, so far this is one
of the most responsive, that means low lag between the pressing of a
button and the response you get menu systems I've run into. We do have
interruption capability so if you want to go quickly down the menu
there's no need to wait for it to finish rambling before you can proceed
to the next menu item and, moving quickly doesn't introduce any further
lag that would decrease responsiveness on the way. Our game speaks
entirely using recorded speech. So we scrapped the idea of using sapi or
screen reader speech to do anything. There might be a couple of
exceptions like activation management, but we haven't completely ironed
that out yet, so not sure yet. Anyway, we have it actually stringing up
a bunch of speech files for a single menu item like, for instance, that
movement menu, when you arrow to it, if you sit on it long enough and
don't interrupt it's speaking, it tells you after it says vessel
movement, how far from the enemy you are right now. So we can string
number files and what ever else together for single menu items, and we
still have the capability to interrupt speech. There are other games out
there that do this, but I've seen some that don't. So I'm pretty pleased
that I managed to actually make it work. That and I have tried to keep
the speech files trimmed pretty well, and I'm employing a technique that
some others have used where by you use two speech objects and flip back
and forth from one to the other just a short instant before the first is
actually finished playing. This helps somewhat to reduce the choppy
affect you get when stringing a series of speech files together. Also
it's a good idea to try and keep track of where the game will be using
certain speech files, and try to record with inflection that would make
sense when you put the files together along with what ever other files
in the particular area of the game that its used for. As to hot keys to
instantly open menus, that one I haven't quite beaten yet, I tend to
crash my menus when I try to use alternative means by which to open
them, so for now that's not in, but if I can I'd like to eventually put
it in an update, if it's not already in by the time we release. One of
our private testers earlier today couldn't believe how large the game
was, and then couldn't believe I used .wav files with no compression at
all. I tried to use .ogg files, but even compressing them to 256k
quality I could detect a difference in the sound even though I'm pretty
deaf. And, I lost a lot of that amazing responsiveness I'm so proud of.
Apparently, I could load the .ogg files into memory at game launch, but
then this game wouldn't be one of the quickest launching games I've ever
seen. So I think for now it'll be all .wav files. Lol.
Btw, the speech system I'm referring to is my own voiceover script, note
I mean voiceovers in game not the voiceover screen reader here. It is
supposed to be available open source on my website for other bgt
developers to take advantage of, but I haven't polished it off
completely and put it up there just yet. The menu system I'm using is
just BGT's dynamic menu class but I have managed to make it actually use
my voiceover script, and it works amazingly well!
On 5/21/2014 1:43 PM, Dakotah Rickard wrote:
I'm afraid I came to this topic really late. I have no idea what's
being developed or the questions asked so far.
However, like a complete whacko, I'll post my two cents anyway.
First of all, menus are an awesome tool. They are useful, in fact I'd
go as far to say a necessary standard part of most games. The problem
I find, in our games, is that what starts out as a simple menu end up
becoming this god-awful, holy crap, when will it end affair. To that
end, I suggest what I feel to be several important things to keep in
mind in menu creation.
First, if you have a menu, make sure that speech is interruptable.
Second, context menus with keyboard shortcuts are really awesome where
possible.
Third, and this one is often overlooked, how would it be to have menus
as a grid rather than a list? Swiping/hitting down/whatever cycling
method we're discussing might make it work like a list (if end of
column, then next column at 0) or something, but the thing that I
think we lack, most of all, is a sense of immediacy in our games, and
that is at least in part because of the amount of menus and such we
typically have to navigate.
This is a bit rambling, and it may be unhelpful, impractical, or
unwelcome, but I do hope it helps.
Please feel free to be more specific, and I'll do that also.
On 5/21/14, dark <d...@xgam.org> wrote:
Hi.
I don't see a problem with menue driven interfaces for the sort of tactical
combat type game your developing, or indeed for various other sorts of
games. Entombed for example uses a very minimal walking system for moving
around the dungeon, but everything like equipping your characters, deciding
on actions and targets in battle and grabbing loot is all menue driven.
My only personal issues with menus as the only interface, are firstly, the
time it takes to go through them, and secondly, that in some situations
(particularly in games like adventure games), with heavy item management
they can be rather clunky and limit the games' content.
For example in the now defunked game from bavisoft chillingham, every action
takes going through at least two menus. If you are in a room and want to
travel somewhere else, you need to arrow across to "go" and then across to
the direction. if you want to tie rope onto a hook to create a grapling hook
you have to arrow across to use in the main menu, arrow across a list
composed of both your inventory and objects in the room to rope, then be
asked "with" and arrow across your inventory to hook.
Similarly, if you examine a desk and find a secret draw, you have to arrow
across to examine, arrow across to desk, get the description of the draw,
then repeat the process and look in the draw. this also provides complexity
for the programmer having to continually add items to the menus, complexity
that could easily be fixed with a limited parza system, sinse it's much
quicker to typ "x desk" than go through all those menus.
That being said this is a very specific issue with adventure games, and
possibly rpgs with multiple characters, attacks and weapons. It does not
affect other games at all, for example yesterday i was playing a quick hand
of spoonbill's blind gamers nomination whist, which just involves menus for
looking through your cards and deciding what to play, (you also hit the
number for the number of tricks to bid).
so yes, menus are an okay idea, but depending upon game complexity they may
run into issues of being overly clunky.From reading the documentation for
your first game I don't think that will be the case, (we'll see for certain
when it's released), but that might not be so of some of the more complex
things your doing in the future.
As regards pausing the game, well to be honest Shades of doom already has an
instructional menu, and the game pauses freely while your in it. It's true
it's not context sensative, but it is well laid out enough to give a very
quick overview.
Context sensative help is of course a great idea for none real time games,
and indeed something which is really taking off in ios games which don't
usually come with manuals. Pausing a real time game is for me just par for
the course, it then depends upon the quality of the help system and how easy
it is to navigate to find the information you want quickly. One reason why
shades of doom and the quickhelp with F1 is such a good idea.
Beware the grue!
Dark.
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to
gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gamers@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gamers@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
