Re: [Audyssey] menus was: Re: game taste was: Re: regarding temporal disturbance
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. -- Signed: Dakotah Rickard --- Gamers mailing list __ Gamers@audyssey.org If you
Re: [Audyssey] menus was: Re: game taste was: Re: regarding temporal disturbance
Hi Dark, I pretty much agree with what you said below. I don't generally have a problem with menus in games accept that in certain adventure games like Chillingham the menus are a bit too clunky. Plus would be rather time consuming to program. A parser system would be far more appropriate in that situation. However, in turn-based strategy games like Trek 2000 and STFC I don't see a real problem with menus. I can see a lot of games where a menu would be preferable over other methods of user interfaces. They are even better when certain hot keys are assigned to various menu actions like n for new game, c for continue game, s for save, whatever. Cheers! 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.
Re: [Audyssey] menus was: Re: game taste was: Re: regarding temporal disturbance
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 3 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
