I have it as well, just too lazy to bother with it, and 20 seems like a good number of equations to clear for warm up to the marathon mode.

Edit:

Alright, in theory, I have this set up to choose math symbols at random, then decide values and change them until it gets a whole number (don't want to have to worry about decimals). I'm going to need to set up an empty box for the math symbol to show up in that is entered.

So, all that should be left is:

Display of the equation
Gather key input and compare
Verify which mode, cap at 20 questions
Verify which mode, end game at first mistake
Compare and generate high score table

In theory, not that much work.. Hopefully a demo will be available tomorrow!

This is what I think I'll be using for the display.

I need some ideas for the cap, or should there be one? should I start it out at a max of 99 for each side of the answer, or should I cap it and let it gradually get more difficult? If option 2, got any ideas on how I should increase the cap as it goes on? Marathon the cap would have to be capped at some point, since you don't want them dealing with 70981345760871345078*0823751087 kind of numbers :p

Also thinking about trying to make the numbers more adaptable and keep the box closer to them based on how many digits are in each of the variables, maybe just keeping the = and Answer where they are and move the others based on the length?

I've not tested to see how fast it generates a division problem, I should look into that.. Just to make sure it will be fast enough.

Just checked, it seems to generate it quickly enough, so that's good. Might be some lag on division, but not much I can do about that :<

You could increase the cap by simply doing a sum(cumSum(rand(#))), which could be a viable source. Of course, there are many others ways of doing it as well.

Something to think about.

unknownloner brought up a good point in hcwp, I need to verify those fun cases where more than one math symbol might equal the same answer.

The idea I am going to use to solve the problem is run through all 4 variations of the equations anyways and store them to a list, then see if any of them equal eachother. So, if they either press the correct key, or it still is correct because the equation is correct, then they can progress.

Writing this down because my brain is not firing on all cylinders and I don't want to forget this idea.

mmm
Gonna make it fast without lag I hope? Otherwise it will ruin the gameplay if it is slow and doesn't register keypresses fast enough.
Good work

Code:


F is the answer of the equation before it displays
D is first variable
E is second variable
B is the math symbol selected by the calc
theta is the math symbol selected by the user

Even when I select the wrong symbol on purpose, it tells me that the answer is correct, and that Z=1, even though I have a DelVar in before it. :/

Any ideas on why it is doing this?

Here is some pseudo code on how to solve this. I hope it helps. Notice that I do not even bother checking B. All I do is see if the operation the user pick works or not.

Code:

Yeah, thanks to you and Merth for that suggestion. I'll try to get that implemented sometime tomorrow and see if I can't get this game released.

In BASIC form:

Code:


I'm sure Weregoose will show up and show us a much better way to do it. Maybe something like this:


Code:

Reordering "/*+-" to "+*-/" allows this expensive one-liner:


Code:


This is why we use lists.

But why do the math? Why not just examine getKey?

Umm... Not sure if this is correct, but this is my interpretation of what you need:


Code:


θ=0: D/E
θ=1: D*E
θ=2: D+E
θ=3: D-E

EDIT: Oh wait, this is if getkey is parsed beforehand. Weregoose++

Went with /*-+ for easier detection of which key was pressed, math was easier that way.

And was just trying to set up a way to catch different equations equalling the same thing, but was was pointed out, it's just easier to test the equation dependent on which of the keys were pressed.

So, got up to the results screen set up



You can see that penalties work properly

I still need to work on setting up an increasing cap system (might need to limit it to how high it can go for Marathon, though) and implement high score detection.



I still also need to finalize some of the text placement there, and possibly change the color for 'penalty' and the numbers to a more bright red color.

Thoughts? And anyone want to help with the cap system?

Is the problem deciding how to scale up the cap as the player answers more questions? Or is the problem designing the equation for how to determine the cap based on the number of questions answered and/or answered correctly?

I'd like the values that can be displayed to increase as the player progresses through the equations so the equations get a bit harder. I don't know how much of the screenshot you watched (I missed several on purpose by randomly pressing keys :p) but the equations are fairly easy.

Well, I'm sure you're using a randInt() or two to compute the operands, so it's really just a matter of deciding how quickly you want it to scale and adjusting the upper bound of the randInt() accordingly. For example, the following code will use single-digit numbers for the first 5 questions, up to 2-digit numbers for the next 20 questions, and up to 3-digit numbers after that. However, I think you want the addition and subtraction questions to have larger numbers than multiplication, and division questions should have the smallest values of all (and ideally have integral quotients!). My code below doesn't take this into account.
Code:

I did indeed watch it, and they are very easy.

Thanks I just bounced it up to handle 3 digit values.

And I do indeed use 2 randInt(s. But I don't really do any checking other than on division to make sure that the answer is a whole number. I have the cap set up on a variable which both randInt(s abide by, so this will make it very easy to integrate. Thanks!

I recommend that for division, you always make sure for starters that the first number is larger than or equal to the second number. In fact, how about as a special case for division, you pick a number for the dividend (the part on top), call it A, then pick a random integer between 1 and A for the quotient. That will give you the value of the divisor (the part on the bottom), B, since if A/B = C, then A/C = B. That would help constrain the value of B better, but I would still recommend you find more ways to ensure that B is an integer. in that case.

I also have two suggestions for the UI:
1) When you get a question right or wrong, I recommend first displaying the operator that the user picked, then replacing the green check or the red X on the bottom with a brighter, bolder check or X with thicker lines. Pause for about 1 second, then update the counts of incorrect and correct answers, maybe pause for a fraction of a second, and then display the next answer.
2) I guess my second suggestion was part of that: pausing for longer to let the user see whether they were right or wrong.

My reasoning for division as it is was to not need a lot of different things to have to verify, for speed reasons, as the game is timed.

My current creation of equations:


Code:


Which ties into some of your suggestions. I don't want to tie up displaying something for very long because the player is going to want to improve their time, and having the calculator slow things down isn't very nice to them and their goals. I was actually thinking about reducing the rand(25 a little further, but figured I'd wait until I could play it on calc.

The bottom values aren't meant to increment, they show off your high score obtained playing that mode. Hence it being "Highscore Normal" for the above. I don't want the person distracted by how they are currently doing, only the goal of what the best they've done in the past That's why I'm also not updating the time, though the original did. There would be some slowdown there as it has to process/keep track of the seconds, disperse them to minutes, then display. Too much slowdown for that.

I'm a little uncomfortable about that, because technically the time to compute a value for F there is unbounded. I'd prefer a more O(1) sort of system, but as long as empirically that is fast enough even for 3-digit values of D and E, I have no particular objection.

Again, as long as you feel the timing is correct playing it and pretending to be an end user, I believe that that's reasonable.

Ah, I see, that makes more sense. I'm not convinced that that's the best system, though; I feel like a user would generally expect the scores at the bottom to represent their current score, and might be confused that the numbers were not changing. I'd be curious to see what other people think about that.