Jump to content
  • entries
  • comments
  • views

More Menu Fun

Sign in to follow this  
Trapper Zoid


Controls Menu

I decided to finish off one of the more complicated submenus first - the controls definition menu. Although Ice Slider is simple enough to get away without one of these, I really want one that I can copy across to future games. Plus it's always good manners to allow your players to define their own controls, of course. Although my control system only allows keyboard input at the moment, it does allow up to three key definitions for every game action - more than enough for something like Ice Slider.

I mentioned in the last post that I thought there might be a few snags implementing this menu, and that certainly was an understatement. Some of the highlight problems:
  • SDL has a nice function called SDL_GetKeyName that returns SDL's name for each of the keys. Unfortunately these strings make use of the full ASCII set, whereas my Aenigma font "Stranded" that I'm using only has the alphanumeric glyphs defined. Thus I had to define my own array of strings to name each of the two hundred odd keys defined by SDL. And of course, as is required when hand writing such a long array, there was an obscure off-by-one error that put all the strings out of alignment (turned out to be a missing comma). I'm also unsure whether all the names are correct - I still have to test all the keys and peform some fine tuning there.
  • I'd already written an input control listener wrapper thingummy-jig that translates raw input data into event signals corresponding to game actions. However this control menu is a special case that needs to break that layer and get some raw data whenever a new key is being entered. This lead to all sorts of interesting problems as you need to press a key to tell the program that you are entering a new key. My menu structure as it is is basically a huge state machine made of nested switches, but I had to had another layer just to deal with that problem.
  • Continuing from the enter a key problem, I've found out that SDL considers NumLock and CapsLock to be pressed down whenever they are active. I still haven't fixed that problem yet - I'm going to see if SDL has a setting to deactivate that behaviour. If not I'll either put in some special code for those keys or just disable them completely.
  • I found it's not a good idea to immediately change the keys once they are modified in the menu, especially if you use the defined arrow keys to navigate around the menu. Even worse is when this applies to deleting keys and you allow the player to clear all the definitions [smile] (fixed that one: you have to have at least one key definition, and now you must choose "save" to apply your key bindings)
  • When I had almost finished the menu, I realised that I really needed those "save" and "reset" options, and they would have really mucked up the hacked together menu system I'd already written. So I had to rewrite most of the control menu code again. It's still a deep structure of switch statements, but at least now it's more understandable and allows those extra commands.

I still haven't finished with this menu - I'm unsure about whether I should allow the player to bind two actions to the same key or put in a logic test to stop that, and there's some cosmetic changes I'll need to make to the looks and the names of things - but it's there, workable and "good enough" for the alpha.

Next up is the graphics submenu, which will probably only have a handful of features to begin with as there's little already defined. Once that's done, I'll leave the other menus until later and I can start on the game code proper.
Sign in to follow this  


Recommended Comments

I'm really glad you mentioned that the "define keys" menu has to have an input system that sits outside of the "map keys to actions" system that the rest of the game uses.

That's the kind of thing that seems obvious when someone else points it out, but would have never been something I ever thought about until it bit me in the ass.

You've probably saved me hours of work and frustration there [smile].

On a related note, ever feel like writing all these menus and stuff is more hard work than the actual game? I do. I'm trying to get a framework for this stuff built on my new game before I even start writing the game bits because I know otherwise I'll never go back and do it at the end.

Share this comment

Link to comment
Original post by EasilyConfused
On a related note, ever feel like writing all these menus and stuff is more hard work than the actual game? I do. I'm trying to get a framework for this stuff built on my new game before I even start writing the game bits because I know otherwise I'll never go back and do it at the end.

In the case of Ice Slider, definitely [smile]. The gameplay itself is not going to be particularly challenging - it's a very simple game. The challenge I've set myself is to "do it right" - meaning put in the menus and a reasonable about of polish. That way when I move to a more challenging game I'll already have a sizable amount of code I can lift across, or at least the expertise to make decent decisions about how to approach designing the program.

Although it is a bit concerning how large this menu code is turning out to be...

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!