DBP SERIES #1: THE MENU PART 2

What’s the next stage? We need some interaction!

This is where the variable ‘selection’ comes in. This variable will store a number that will be associated with a selection on the menu. The range of selections is 1 to 5, as we have 5 items.

So in our GUI function, we need to turn the previous bit of code into an ‘if-then’ statement. An if then statement is useful for our games logic. It’s basically, “If this happens, then this happens”. We want to include the text commands in this statement.

image

There some new stuff to learn here. This is all inside of the ‘for’ loop we made in the last tutorial. Now there’s 2 text commands. But what is going on here? It’s pretty simple. Because we’re using 1 to 5 as our selections, it’ll be able to match the 1 to 5 in our for loop. The two if then statements are asking whether or not the selection matches an item.

The first statement. Into plain English,”If the selection isn’t the same as ‘x’, then just show the menu name at coordinate 10 and 10+h”

The second statement. Into plain English. “If the selection IS the same as ‘x’, then sow the menu name with additional text that represents an arrow (<-) at 10, 10 + h”

Now we need some input. The input will be handled inside of Update(), they’re 2 very simple If then statements.

image

By using the arrow keys, you can alter the selection. As the number increased, the further down the list you go. The ‘wait 200’ is to stop the input being too sensitive. This would normally be a terrible way of avoiding sensitive controls in a normal situation, but this keeps it simple enough and it will not cause us any problems. You’ll also notice I used a colon. What a colon does is allows you to merge lines together. In an ‘if then’ statement, it means I can list its results on a single line.

If you compile. it’ll work, but you’ll notice 1 problem occurs, your selections disappear if you go too far up or too low. This is because we’ve not restricted how many selections we can have. We’ve only got conditions for 5 selections, yet the number we have available is infinite.

In your LateUpdate(), you’ll need to add a couple of lines to restrict it. Now you can see why I’m using a late update. I could stick any changes to my selection in update anywhere and it won’t cause any bugs on how ‘selection’ is clamped, because it will always be called after ‘Update()’.

image

If this were called BEFORE we had any input to change the selection, then the above would simply have no effect. Hence Update() then LateUpdate()

Translation into plain English: If the current selection is lower than ‘1’ then set it to ‘1’. If it is higher than the total number of menu items then set it to the total number of menu items. It’ll stop the number going less than 1 and more than 5.

Now run and you’ll find that you can cycle through your menu.

image

The next step is to give each selection a function. The simple, non-flexible method is: (for Quit)

If selection = 5 and returnkey() = 1 then end

But I’m not going to make it that easy, because you might remember when I talked about adding or removing items from the list. If I added 2 more items, heck, if I added 2 more items before Quit, then it would no longer be selection five. This maybe not be so applicable in a title menu, but in an inventory menu, it’s pretty important.

So, what I need the computer to do is parse through my variables and pick a Menu item called ‘Quit’. Think of it like looking for something specific on a database. Or typing something into Google, though of course, instead of thousands of results, there’s only one and it’s looking through a total of 5 items. With this method, you could change all of the names to ‘quit’ and when you hit enter on any of them it’ll close the program. Useful, eh?

image

Into plain English. When the user hits ‘return’, look through all menu items (x =  to menucount) then check if it’s called “Quit” then close the application. For every type of item you want you can just add another statement.

image

I’ve put ‘end’ as we haven’t got anything for ‘New Game’ or ‘Load Game’.

That’s it for part 2. Why not experiment and try this?

Instead of having your code check the name of the item, give it a ‘purpose’ and then have the code read that. You might set your purpose to “end”, “start” or “loadgame”. In your menu create 2 instances where the purpose is set to ‘end’, but have 2 completely different labels. With code you’ve learned in these 2 parts, it should be possible. Why would you want to do this? Lets say you have 2 types of healing potions in your inventory in a game, instead of listing the name of every single potion and created an effect for every single one, you could actually cut it down to a single condition if you use that method. So you could have as many types of health potions out there without altering this part of the code. Handy.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s