Selection Logic Technique

Started by
6 comments, last by Pink Horror 10 years, 6 months ago

I've been using Khan Academy to develop and discover my own techniques. The code is compiled in real time and, giving the fact that you can't upload images, I think it is a perfect place to practice game programming, considering that you have to make things from scratch.

I would like to present you my technique to deal with selection, wether it is applied to a menu or an inventory.

Here's the link:

https://www.khanacademy.org/cs/selection-logic-technique/2177841234

I would like to know your opinion about it. I've made another examples:

https://www.khanacademy.org/cs/advanced-selection-logic/2160408149

I'm a beginner in Game Programming and I have not finished any game of mine using SDL, yet. But, I hope that we can discuss my technique and that someone finds it useful. At first glance, it was hard for me to make a menu with pure C and SDL, and my solution was primitive and manual. So I've found a way to solve the problem.

I thank you very much for the attention.
Advertisement

Your bool array is redundant. You just need one variable to keep track of whatever inventory slot or menu item or rectangle is selection. You don't need a bool array to store that information a second time.

Also, why isn't "activator" just a number? Why do you store the selection index (what I'd normally call this thing) in activator[0] instead of activator?

In your examples, you some array of things, and you want to know which thing is active. That's just one integer of information. You shouldn't have to go looping through all your objects all the time just because you've changed which one you're focused on. You only have to loop over everything to draw.

I'm considering large amounts of selectable objects. I could use just one variable, but in this case, I would not know what to do if I had 900.000 items to select. In fact, I would be bored to write code for 20 already, if I had to do that "manually".

An inventory system with 3000 items ... really? Well, I've found several issues in the code. Please understand the following as constructive criticism:

1. Giving variables in a broader scope (and "global" is as broad as possible) unexpressive names like "n" and "d" isn't be of use for readability and memorization but name clashes. The names "selectionLogic" and "activator" are better in this sense. Naming the iteration variable "i" inside the very small scope of the for loop is (IMHO) okay.

2. Invoking "applySelectionLogic" inside the "draw" function mixes unrelated functionality (single responsibility principle).

3. When at the very left and still pressing the LEFT key, the counter in "activator[0]" falls below zero. Similarly, when at the very right and still pressing the right key, the counter in "activator[0]" exceeds the amount of places. Due to the missing limitations, one has to press the opposite key as often (or long when counting on key repetition) until the counter gets back in the valid range.

4. You initialize "activator" as a two element array, but accessed ever is only the first one.

5. BTW: Why is activator an array at all?

6a. This part "&&i<n" of the 1st conditional inside the "applySelectionLogic" is meaningless, because the outer loop already ensures this.

6b. This part "&&i>-1" of the 2nd conditional inside the "applySelectionLogic" is meaningless, because the outer loop already ensures this.

7. Probably, the issues 6a and 6b hints at an attempt to protect the access to "selectionLogic" (although not strictly necessary, but from a logical pint of view). In that case the both parts have to be exchanged and also made stricter: "i>0" and "i<n-1", respectively.

8. If you have a 1 out of N selection, why do you need to store it in an array of length N? EDIT: I mean, one does not want to iterate an array, hitting almost ever a "this item isn't selected" until in the end finding the wanted "this item is selected". Please don't be deceived due to the seemingly fitting of the array inside the "draw" function (s.a. issue 2).

9. The system is (at least on my computer) not very responsive. It pauses at will, but performs the meanwhile happened key repetitions shortly after. That makes it unusable.

Comments on the style: Although perfectly valid, comparisons with "false" and "true" are somewhat redundant. It is like querying "is it true that a condition is true?" instead of "is the condition true?". (And, BTW, why is "= []" preferred to "new array()" in the means of best practices?)

The solution is much too complex for what it yields in. For a 1 out of N selection from an array, a simple index is necessary for storing the selected element. But perhaps it is just in preliminary stage? However ...


... I could use just one variable, but in this case, I would not know what to do if I had 900.000 items to select. ...

... in a case where it is to be expected that a few of many items are to be selected at the same time, one still would not do it that way. This has 2 reasons: (a) It were a waste of memory (899.990 items are not selected but require memory) and time (iterating the entire array), and (b) there is no way to store the order in which items were selected (a feature that often plays a role). So, the better solution in such a case would be to look at the whole as a "sparse selection", e.g. storing the indices of selected items in a variable length array.

I thank you very much for your post, haegarr. Concerning the variables "n" and "d", I'm well aware of the problems of using such names. I use variables of just one letter only in Khan Academy, because It's nothing "official" or "readable", its just for learning purposes; therefore I don't bother too much with the names. I type the same things almost everyday for practice, and It's really cumbersome to give them proper names there.

Activator is an array because I've considered, initially, the y axis as well.

I'll try to write a more elaborate version of the solution, keeping in mind your hints. They were very useful. As I've said, I'm a beginner and I'm learning all of it by my own, so many things escape from my awareness.

What I intended to create was:

A selection-solution for N number of things/items. Which means iterating until N to store the information, and applying the logic in all items, keeping track of which item is selected and which item is not. Without the "activator", the loop goes from 0 to N at the same time that the key is pressed. I can do it with all precision without using loops, as I've said, because it is much easier. But, considering that we have N items to be selected, we don't know how much items we'll need to deal with, and therefore I could only think in arrays and loops.

Concerning the "[]" instead of "new array()", it is probably because my first language was Python and because I'm infinitely more "procedural" than "object oriented".

I think that the "precision" problem is a "timer" problem. The input is too fast. In SDL I can deal with it, but in Khan Academy I'll to implement something to deal with the "clock ticks" manually.

haegarr.

https://www.khanacademy.org/cs/selection-logic-technique-precision-fixed/2187116040

Now you can actually see the activator (As a rect), and I've used a bizarre something-like-a-timer to control the speed and enhance precision. Just like the another problem, if you change the N variable, you'll have a different amount of options.

It is not absolutely perfect yet, but I think it is a question of "adjustment". The input is way too fast, and it is necessary to control its speed with a "timer/clock" or whatever.

I'm considering large amounts of selectable objects. I could use just one variable, but in this case, I would not know what to do if I had 900.000 items to select. In fact, I would be bored to write code for 20 already, if I had to do that "manually".

Please explain how one index is not enough for 900,000 items. What doesn't work about it once you have a large number of selectable objects? Something that relies on iterating over an array to update input scales worse that something with no iteration. As your application grows, avoiding redundant information becomes more and more valuable. You shouldn't add extra stuff just because a problem feels bigger. That's just making the problem worse.

Meanwhile, if this is for learning, you should try to do everything the "right" way and not get lazy about naming and readability. If this is how you program when you're trying to make an example for others to follow, I'd only expect your style to get worse when your code is not as public.

I wouldn't work on a more elaborate solution. I'd work on the simplest solution for the problem at hand.

This topic is closed to new replies.

Advertisement