Further evedince of why game design has gone downhill in the last ten years. Real game design should be like art, the why should be more important than the how.
Computers can do math, game designers should be creating worlds not number crunching.
You guys need creative people that come up with NEW ways of doing things, not just leg humping "the way it is done" with cheesy insider math problems.
The soultion to this problem is: Why the heck are you making something so complicated that normal people can't figure out how it works? Game producers need to start following a rule that good musicians have been using for a long time: KISS. Keep It Simple Stupid.
The only way to get to 20 would be to allow missions such as Click Object 1 and then Click Object 2 which is cheating to say the least.
How is that cheating? It sounds like a perfectly reasonable mission to me. I mean, sure you're allowing a person to write missions that go a, aa, aaa, aaaa, aaaaa, etc, but those missions suck and the person submitting them would be told they were a terrible mission writer. The whole point of the exercise was to make 20 different missions with a limited set of useable objectives. I would also point out that I think "defeat NPC then collect drop then defeat other NPC" is perfectly fine, and sounds like storyline to me (defeat badguy, take his magic sword, use it to defeat the dragon, etc) whereas click glowwy, then click other glowwy, then click other glowwy, then click other glowwy is a mission I'd never do. Of course, this is a slippery slope, because I would also argue that in many cases the ordering matters from a contextual perspective (defeat NPC then click object feels like "defeat the boss and defuse the bomb" whereas click object, then defeat boss feels more like "steal supergun then use it on boss"). Whether or not I would lose points for using the same mission objective combination twice in that case is debateable, but I would defend it if it fit the storyline I had in mind, and I think having a storyline in mind, and an interesting, non-repetitive one at that, is the bigger picture.
...
It's a question of combinations verses permutations. The language of mathematics is specific.
If the original question is based on permutations, or slight variations based on object variations - it becomes a very easy problem indeed - not really even worth a question.
For example "Click Object"
Quest 1: Click bucket
Quest 2: Click water
Quest 3: Click tub
etc...
and if it is based on specific NPCs:
Quest 1: Kill (Biggest) Boar
Quest 2: Kill (Biggest) Bear
Quest 3: Kill (Biggest) Bandit
etc...
and if it's based on allowing chains as you suggest then you could do:
Quest 1: Click Club
Quest 2: Get Club and Kill Bandit
Quest 3: Get Club and Kill Bandit who drops spear (get spear)
Quest 4: Get Club and Kill Bandit who drops spear (get spear) and use spear to kill Knight.
etc...
All pretty uninspired stuff but that would meet the requirements of the question if it reads as you say... and if that's the case there is no challenge there?
Further evedince of why game design has gone downhill in the last ten years. Real game design should be like art, the why should be more important than the how.
Computers can do math, game designers should be creating worlds not number crunching.
You guys need creative people that come up with NEW ways of doing things, not just leg humping "the way it is done" with cheesy insider math problems.
The soultion to this problem is: Why the heck are you making something so complicated that normal people can't figure out how it works? Game producers need to start following a rule that good musicians have been using for a long time: KISS. Keep It Simple Stupid.
IMHO anyhow.
And who exactly writes the formulas that the computers execute later? Computers don't program themselves, you know. Waving your hands and saying "and then they should properly balance these skills" doesn't get it done. You have to code in explicit values for the game to use, and that means that you'd better have some idea of what the particular values that you're going to choose will do.
How exactly do you propose to determine when mobs or players die if not using formulas?
Further evedince of why game design has gone downhill in the last ten years. Real game design should be like art, the why should be more important than the how.
Computers can do math, game designers should be creating worlds not number crunching.
....
And who exactly writes the formulas that the computers execute later? Computers don't program themselves, you know. Waving your hands and saying "and then they should properly balance these skills" doesn't get it done. You have to code in explicit values for the game to use, and that means that you'd better have some idea of what the particular values that you're going to choose will do.
How exactly do you propose to determine when mobs or players die if not using formulas?
Programmers
A game designer can say "I want the Adept Wizard to be able to take down a Lesser Troll with three fireballs, on average."
Then the Programmer can do the math - and decide what sort of system works best to calculate the hows and wheres of where damage is allocated.
Bad analogy time: Do you drive a car? Do you know how to repair the engine or (on most modern cars) programme the fuel injection system?
Because when you drive a car - you point the thing in the direction you want and decide how fast to travel and when to slow down and stop.
You don't choose the brake system, or the engine parts, or the gear ratios - people who know far more about these things than you have already done that. And the guy who decided on the car body shape didn't do that either. He knew that certain features and space would be required then he worked with a whole bunch of other people to make it work. They do that based on general information about the sort of driving customers are likely to do. Most cars are designed to travel at about 100-120km/h comfortably these days. You may not drive at 120km/h today. You don't have to sit down and explicitly work out all the required parts to do that just to drive home from work.
Edit: Or maybe a Junior Designer(?) would do this work.... but it's number heavy and not so much a matter of design as making the numbers work. So it's not what I consider 'design' so much. In building this sort of work is done by Quantity Surveyors, who don't actually 'design' so much as manage.
However, we have advanced to the point where you can write novels on a computer without having to program your own text editor. There are people who have a passion for creating worlds who don't have a passion for statistics. Alas there just aren't a lot of world-building toolkits designed with non-programmers in mind.
Further evedince of why game design has gone downhill in the last ten years. Real game design should be like art, the why should be more important than the how.
Computers can do math, game designers should be creating worlds not number crunching.
....
And who exactly writes the formulas that the computers execute later? Computers don't program themselves, you know. Waving your hands and saying "and then they should properly balance these skills" doesn't get it done. You have to code in explicit values for the game to use, and that means that you'd better have some idea of what the particular values that you're going to choose will do.
How exactly do you propose to determine when mobs or players die if not using formulas?
Programmers
A game designer can say "I want the Adept Wizard to be able to take down a Lesser Troll with three fireballs, on average."
Then the Programmer can do the math - and decide what sort of system works best to calculate the hows and wheres of where damage is allocated.
Bad analogy time: Do you drive a car? Do you know how to repair the engine or (on most modern cars) programme the fuel injection system?
Because when you drive a car - you point the thing in the direction you want and decide how fast to travel and when to slow down and stop.
You don't choose the brake system, or the engine parts, or the gear ratios - people who know far more about these things than you have already done that. And the guy who decided on the car body shape didn't do that either. He knew that certain features and space would be required then he worked with a whole bunch of other people to make it work. They do that based on general information about the sort of driving customers are likely to do. Most cars are designed to travel at about 100-120km/h comfortably these days. You may not drive at 120km/h today. You don't have to sit down and explicitly work out all the required parts to do that just to drive home from work.
Edit: Or maybe a Junior Designer(?) would do this work.... but it's number heavy and not so much a matter of design as making the numbers work. So it's not what I consider 'design' so much. In building this sort of work is done by Quantity Surveyors, who don't actually 'design' so much as manage.
I don't work in the games industry but I do work in the software industry. Most programmers do not design the features of the product. They merely implement what has been specced by the product managers. However, that doesn't say they do not have a say so in how it should work, but they do not have 100 control on that.
It actually is rather inefficient to have a programmer design what the product should be, because that distracts them from well programming.
Then the Programmer can do the math - and decide what sort of system works best to calculate the hows and wheres of where damage is allocated.
Ideas are easy, implementation is hard. If an employer has a choice between a creative person who can do math and a creative person who cannot do math, how do they judge whether the non-math person is bringing superior artistic ability to design that outweighs the fact that they will never be able to assign that person to the implementation team?
( perhaps another way to look at it is whether a game is better or worse for having strict seperation of roles in its creation - a topic of debate that I do notice pops up from time to time )
I don't work in the games industry but I do work in the software industry. Most programmers do not design the features of the product. They merely implement what has been specced by the product managers. However, that doesn't say they do not have a say so in how it should work, but they do not have 100 control on that.
It actually is rather inefficient to have a programmer design what the product should be, because that distracts them from well programming.
Fair point.
I have been trying to think of a better way to say what I mean with regard to what i consider 'design' as opposed to number crunching...
Then I thought of something I did years ago in the ol' Pen and Paper days... (Yeah, I am that old and a nerd):
I wanted a game that was Sci-Fi-ish and there wasn't a lot out there I liked.
There was Traveller but it didn't really capture what I wanted. Then I found Star Frontiers and sorta liked that too - and really liked the Knight Hawks mechanics. I also fond some other stuff with hover tanks (can't recall where from?) and found another game with mechanics I quite liked for melee and projectile combat.
So the next thing was to integrate all the parts I liked and 'balance' them. I took a lot of the elements from the Traveller game and converted them to work with Knight Hawks. This involved changing stats and working out what a Traveller Ship would cost in Knight Hawks Credits.
This was basically just data work. I do not consider anything I did here as 'design'. I could see what the actual Knight Hawk game designers had intended and I simply made Traveller ships 'fit' into that design. But I did not design anything.
Later however, I wanted a mechanic that allowed players to land (or crash) a damaged ship on a planet. None of the game systems had any mechanic for this - so I designed one.
The design principle was simple "Players make a roll based on Pilot Skill & Ship Damage & terrain to determine if they land or crash - and how severe the crash is. I want results varying from a perfect landing to disasterous crash."
And from there it was back to the numbers to make it 'balanced' so that players actually stood a chance. And to make it fun for my players it worked out that 95% of the time 100% of the player characters would survive so long as the pilot had some control. This is not realistic - but killing player characters every other day tends to upset players!
Later I redesigned the system to allow for a number of "Piloting Rolls" on the way down where results were cumulative - so players felt that they could "regain control" based on skill... or (as somtimes happened) lose control due to bad choices and failing skill. I also found that players are more forgiving when a character dies at the end of a chain of 10 bad rolls compared to a death due to one bad roll.
I also Designed solar systems. Placing planets, moons, cities and bases. This was done to create an atmosphere and setting. No real numbers involved here - more a setting based on the desired outcome. (i.e. a frontier system, lightly settled and lawless, with heavy mining corporation interest and pirates - as well as a secret military base.)
I hope that better explains my distiction between design and just number crunching and balancing?
Then the Programmer can do the math - and decide what sort of system works best to calculate the hows and wheres of where damage is allocated.
Ideas are easy, implementation is hard. If an employer has a choice between a creative person who can do math and a creative person who cannot do math, how do they judge whether the non-math person is bringing superior artistic ability to design that outweighs the fact that they will never be able to assign that person to the implementation team?
( perhaps another way to look at it is whether a game is better or worse for having strict seperation of roles in its creation - a topic of debate that I do notice pops up from time to time )
Because the history of art already tells you this. Einstein failed math remember? John Lennon claimed he was terrible at math and accounting, the list of highly creative types being really good at creativity, and not so good with technical skills is vast. There are far more creative genius that are good at one thing, and not the other. There is actually some pretty reputable brain science done on this, the type of thinking required to do math is vastly different that what creative types typically do, its almost two different systems. You get better at what you train. If you train creativity, you will be more creative, if you train math and technical skills you will be better at that. Can there be people that are good at both? Maybe, but they are likely not as good at either as someone specialized in one or the other.
The reality is our society doesn't really reward creative types until they suddenly appear out of nowhere, and then they are rock stars. Creative types are often odd, eccentric individuals that don't have the skills "normal" people do because they spend so much time on creative things. Math is creativity in a sense, so don't get me wrong, there are plenty of creative mathematicians, but the skill is a different one.
Music is my best example, because I know it best, but there are many technically advanced musicians that are perfect technically, but fail to move us emotionally when they play. They make better producers/engineers than actual musicians. Both are required to make a great album, but both have different skill sets.
Video game companies would be wise understand the difference if they want to see growth in their industry.
My initial answer was wrong for part 3. It should be:
Average is 50x0.5 + 60x(0.52) + 70x(0.53) + 80x(0.54) + 90x(0.55) + 100x(0.55) = 59.68
If the tick that does the 10 points that get you to 90 hits, you get a swing at another tick, if that last tick misses, you still did 90 points, and if it hits, you did 100 and stopped. My weighted average failed to take that into account the first time. Sorry about that.
....
BTW - I was re-reading the thread and wanted to say that this answer is correct.
The alternate way to check this is to list all the possible "rolls" and consider the results.
For those not mathematical - sometimes it helps to visualise the results
The surprise is that there are in fact 32 possible outcomes (2x2x2x2x2) although many people don't initially realise this... still they are in great company - it took two great mathematical minds to find the solution that had confused people for years.
So - the possible outcomes ("Y" means roll succeeds, "+" means roll fails)
I have also shaded out the failed columns in the table
YYYYYYYYYYYYYYYY++++++++++++++++
YYYYYYYY++++++++YYYYYYYY++++++++
YYYY++++YYYY++++YYYY++++YYYY++++
YY++YY++YY++YY++YY++YY++YY++YY++
Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+
(Edit - sorry doesn't line up properly once posted)
The obvious point people raise is "How can there be 16 'fail' results from after the first roll fails? You don't continue past that point!"
In short - that's how probability works. But that was the very thing that initially confused even Pascal and Fermat.
So the results are
16 x 50 points of damage (First roll fails)
8 x 60 points of damage (First roll succeeds and second roll fails)
4 x 70 points of damage (First and second roll succeed and third roll fails)
2 x 80 points of damage (First, second and third roll succeed and fourth roll fails)
1 x 90 points of damage (First, second, third and fourth roll succeed and fifth roll fails)
1 x 100 points of damage (First, second, third, fourth and fifth roll succeed)
So that is all 32 possible outcomes covered.
And as FrinkiacVII said there is actually an equal chance of doing 90 or 100 points of damage (1/32 each)
So the total damage over 32 rolls is 800 + 480 + 280 + 160 + 90 + 100 = 1910points
On the subject of "math skill" vs. "creativity" I want to point out that you CAN have both, and I think it helps a lot. If nothing else, you want to determine from the hiring process what the applicant's strengths and weaknesses are in those regards. It's not that they we're only interested in one aspect of the job, they were kicking the tires on all of it, as they should. Look at the discussion I'm having on this board with Gyrus about combinatorics. A person framing a question about game design needs to have some clue whether what they're asking for is even possible given the constraints they're imposing. Otherwise you get people at the upper levels making impossible requests of programmers, and then acting like it's the programmer's fault when it doesn't ever come together. Similarly, a person desiging a superpower for a game needs to understand how powerful that power is in comparison to the other options. Is it the BEST power available for it's opportunity cost, and of so by what margin does it outshine the next best option? Is it the best for CERTAIN archetypes? Is it sub-par but able to fill a hole in my attack chain? Is it so bad that I would want to avoid it? Is it a reasonable amount of damage for a power in the first place? What should its endurance cost be? How long should it take to recharge? Do we need to balance it by tacking on a debuff to the person using it? These are all QUANTITATIVE questions which need to be addressed in the design process, and that requires math. I mean, sure beta testing will catch a lot of major mistakes, but you still need to get it somewhere CLOSE to right the first time, and you still need to design it with some faint clue as to how comparatively good or bad it is. So I think the math comes with the territory, like it or not. This is not to say that you JUST want numbercrunchers, you want creative people who can crunch numbers, there's a big difference there.
Going back to the combinations vs permutations argument, I think you have to cut the game design test some slack in the vocabulary. I mean, most people, when telling you to make 20 missions out of 4 objectives, aren't asking you that question to see whether you're capable of proving the theorem that says it's technically impossible, given the mathematician's technical definition of what a "combination" is as compared to a "permutation". At the end of the day they want to see the missions you come up with, they want them to be fun, and to avoid feeling repetitive. If they try to neg you on repeats, that's when you say "Well, TECHNICALLY the task you asked me to perform isn't even possible, and here's why, so I just did the best I could. I promise you that everyone else who took this test failed on that criterion, or else they didn't submit 20 missions. I may have bent or broken a rule there, but you gave me no choice." or maybe you note that in the submission as a disclaimer then make 20 of your most interesting missions anyway. Or you know what, who knows, maybe they did ask that question to see if anyoine would catch them that it wasn;t even possible. That's certainly a point of the whole math argument I'm making here. In any event, I think after some clarification or negotiation, they'd still want 20 good missions, even if we had to redefine what a combination is to get us there,
"Well sure, the FrinkiacVII looks impressive - DON'T TOUCH IT - but I predict that within 100 years computers will be TWICE as powerful, ten THOUSAND times larger, and so expensive that only the five richest kings of Europe will own them." -Prof. Frink
Bad analogy time: Do you drive a car? Do you know how to repair the engine or (on most modern cars) programme the fuel injection system?
Because when you drive a car - you point the thing in the direction you want and decide how fast to travel and when to slow down and stop.
You don't choose the brake system, or the engine parts, or the gear ratios - people who know far more about these things than you have already done that. And the guy who decided on the car body shape didn't do that either. He knew that certain features and space would be required then he worked with a whole bunch of other people to make it work. They do that based on general information about the sort of driving customers are likely to do. Most cars are designed to travel at about 100-120km/h comfortably these days. You may not drive at 120km/h today. You don't have to sit down and explicitly work out all the required parts to do that just to drive home from work.
You don't need to know all of the internal details of how a car works in order to drive it, just like you don't need to know all of the internal details of how a game works in order to play it. But we're talking about hiring people to design games, not just play them. I wouldn't want to play a game designed by someone who has no clue what the game is doing. Would you want to drive a car designed by someone who doesn't know anything about brakes or engines, and hope that it doesn't spontaneously combust on you?
However, we have advanced to the point where you can write novels on a computer without having to program your own text editor. There are people who have a passion for creating worlds who don't have a passion for statistics. Alas there just aren't a lot of world-building toolkits designed with non-programmers in mind.
It's one thing to hire someone who doesn't have much of a math background to place trees and hills and buildings in a game world, or to write quest text. But writing damage formulas? Come on. It's one thing to flub a question because of the pressure of a job interview or the awkwardness of transmitting precise information over the phone. But given ample time and little pressure, someone who doesn't find the first two parts trivial and the third easy has no business writing the underlying formulas that make a game work.
Further evedince of why game design has gone downhill in the last ten years. Real game design should be like art, the why should be more important than the how.
Computers can do math, game designers should be creating worlds not number crunching.
....
And who exactly writes the formulas that the computers execute later? Computers don't program themselves, you know. Waving your hands and saying "and then they should properly balance these skills" doesn't get it done. You have to code in explicit values for the game to use, and that means that you'd better have some idea of what the particular values that you're going to choose will do.
How exactly do you propose to determine when mobs or players die if not using formulas?
Programmers
A game designer can say "I want the Adept Wizard to be able to take down a Lesser Troll with three fireballs, on average."
Then the Programmer can do the math - and decide what sort of system works best to calculate the hows and wheres of where damage is allocated.
If the game designer can't specify what he wants more precisely than that, then about the only sensible way for a programmer to interpret it is, "I have no clue what I'm talking about, so you can do whatever you want."
You don't need to know all of the internal details of how a car works in order to drive it, just like you don't need to know all of the internal details of how a game works in order to play it. But we're talking about hiring people to design games, not just play them. I wouldn't want to play a game designed by someone who has no clue what the game is doing. Would you want to drive a car designed by someone who doesn't know anything about brakes or engines, and hope that it doesn't spontaneously combust on you?
You do know that cars are designed by many people? The guy who designs the chassis is not the same guy who designs the engine.
That was my point.
Game 'designers' shouldn't try to be experts in everything. And these days they can't.
The questions about math and how many points of damage a spell can do are fine on one level of design I suppose.... but really nothing a programmer (or even a competent modder) couldn't do.
It's one thing to hire someone who doesn't have much of a math background to place trees and hills and buildings in a game world, or to write quest text. But writing damage formulas? Come on. It's one thing to flub a question because of the pressure of a job interview or the awkwardness of transmitting precise information over the phone. But given ample time and little pressure, someone who doesn't find the first two parts trivial and the third easy has no business writing the underlying formulas that make a game work.
Errr... careful there... I think you just described the "designers" at Games Workshop!
Errr... careful there... I think you just described the "designers" at Games Workshop!
BURN!
In the grim darkness of the far future, nobody can do their kids' math homework.
I can remember a discussion (YEARS ago) on a message board (I think it might have been actually on usenet, if not some really old website forum) where a guy posted an army list which included "Bionics" for his leader. This caused a discussion of whether or not Bionics was worth its points. The way Bionics worked at the time was if your leader failed a save and lost his last wound, normally he'd die and be taken off as a casualty, but the Bionics give him a 1 in 6 chance at surviving. After that, if he "died" again, you got another chance to roll a 6 and save him. Essentially, the argument revolved around how many more wounds you were effectively giving your leader when you bought Bionics. It turns out that even with assumption of infinite turns, the bionics are worth, on average, 1/5 of one wound (and that was arrived at by using a shortcut formula that involves taking a limit as n goes to infinity). The guys response was basically "Yeah, but I always seem to make my Bionics roll, so I like it:" to which we all replied "Then your dice are loaded." For what it's worth, I gotta believe that nobody at GW ever did the math to determine what the actual average value of the Bionics was in terms of army points, but at least they didnt make them so cheap that everyone took Bionics every time. Bad options can exist and not really hurt anything, they just make other options look better by comparison. That said, like EVERY leader model that looked at all cool had bionics. They were always a badass model option and almost never a worthwhile army build option. There's something to be said for making the visally appealing/impressive stuff in the game actually good in game terms too.
"Well sure, the FrinkiacVII looks impressive - DON'T TOUCH IT - but I predict that within 100 years computers will be TWICE as powerful, ten THOUSAND times larger, and so expensive that only the five richest kings of Europe will own them." -Prof. Frink
On the subject of "math skill" vs. "creativity" I want to point out that you CAN have both, and I think it helps a lot. If nothing else, you want to determine from the hiring process what the applicant's strengths and weaknesses are in those regards. It's not that they we're only interested in one aspect of the job, they were kicking the tires on all of it, as they should. Look at the discussion I'm having on this board with Gyrus about combinatorics. A person framing a question about game design needs to have some clue whether what they're asking for is even possible given the constraints they're imposing. Otherwise you get people at the upper levels making impossible requests of programmers, and then acting like it's the programmer's fault when it doesn't ever come together. Similarly, a person desiging a superpower for a game needs to understand how powerful that power is in comparison to the other options. Is it the BEST power available for it's opportunity cost, and of so by what margin does it outshine the next best option? Is it the best for CERTAIN archetypes? Is it sub-par but able to fill a hole in my attack chain? Is it so bad that I would want to avoid it? Is it a reasonable amount of damage for a power in the first place? What should its endurance cost be? How long should it take to recharge? Do we need to balance it by tacking on a debuff to the person using it? These are all QUANTITATIVE questions which need to be addressed in the design process, and that requires math. I mean, sure beta testing will catch a lot of major mistakes, but you still need to get it somewhere CLOSE to right the first time, and you still need to design it with some faint clue as to how comparatively good or bad it is. So I think the math comes with the territory, like it or not. This is not to say that you JUST want numbercrunchers, you want creative people who can crunch numbers, there's a big difference there.
Going back to the combinations vs permutations argument, I think you have to cut the game design test some slack in the vocabulary. I mean, most people, when telling you to make 20 missions out of 4 objectives, aren't asking you that question to see whether you're capable of proving the theorem that says it's technically impossible, given the mathematician's technical definition of what a "combination" is as compared to a "permutation". At the end of the day they want to see the missions you come up with, they want them to be fun, and to avoid feeling repetitive. If they try to neg you on repeats, that's when you say "Well, TECHNICALLY the task you asked me to perform isn't even possible, and here's why, so I just did the best I could. I promise you that everyone else who took this test failed on that criterion, or else they didn't submit 20 missions. I may have bent or broken a rule there, but you gave me no choice." or maybe you note that in the submission as a disclaimer then make 20 of your most interesting missions anyway. Or you know what, who knows, maybe they did ask that question to see if anyoine would catch them that it wasn;t even possible. That's certainly a point of the whole math argument I'm making here. In any event, I think after some clarification or negotiation, they'd still want 20 good missions, even if we had to redefine what a combination is to get us there,
For the 20 mission test, I think they were primarily interested in seeing whether you could come up with 20 interesting and varied missions, not in how you interpret the non-repeat requirements.
-----
Choosing formulas that will give interesting gameplay is a type of creativity. It's different from being able to draw a pretty picture or compose music that sounds good, and someone who is good at one isn't necessarily good at another. But it's still a type of creativity, and it's one that is absolutely vital to game design. Whether your formulas give interesting gameplay is perhaps the single largest factor in determining whether a game is any good.
Furthermore, in many (most?) cases, deciding what the formula should be is most of the work in implementing it. Even a mediocre programmer should be readily able to implement any of the three formulas in a game. There are some situations where the way that you'd naturally describe a formula doesn't match the way that computers want it presented, such as pathfinding or collision detection. For those, yeah, you want a good programmer to do the implementation. Though in those cases, you might also need a programmer to come up with the formula, as someone with no programming experience might not understand that this formula is 100 times as much work to implement as that one.
But if you're choosing the underlying formulas of game mechanics, that's an additional level of abstraction. It's a lot harder than the plug-and-chug type of computations in the test. Well, choosing an arbitrary formula isn't hard; it's only hard if you want the formula to actually make for interesting gameplay--which hopefully you do. For that, you need to not just be able to do routine computations, but also to have good intuition about what sort of effects different formulas will have and what different effects you can get by varying the parameters.
Someone who doesn't understand formulas but tries to pick them anyway is counterproductive and worse than useless. A designer who wants to pick high level goals for the formulas without understanding the underlying math is also useless, as he's likely to pick things that are contradictory. (Politicians do this all the time: for example, we want to increase spending, cut taxes, and pay off the national debt.)
Now, choosing formulas is an important part of game design, but it's not the only part. Someone who doesn't know much math but can write really interesting quests may well be valuable. Just don't let him start tinkering with formulas--or choose the rewards for the quests he writes.
The 20 question quest series, a little dubious in its details as it may be I think would be a fun exercise.
The math question I love, most people assume that the programmers do all the math and the game designers do all the design outline, I imagine they still have to at least have a basic understanding of the way the system works in order to create good content.
For example you can be a computer programmer and not know HOW to do advanced math you just have to know how to tell the compiler to do advanced math. You still have to understand the concept behind the math though.
My answer for the math questions... since its a phone interview would be: 1) 100 assuming it lives through all ticks, 2) 75 again assuming it lived through all hits, 3) While Im sure this is meant to seem very complicated it starts with 50 damage, so the answer is 50:60>61 (read as fifty to sixty but less than sixty-one) since no two computations are going to be the same. Now off of a phone interview sure I could sit down and work out an actual average but on the phone Im just going to spitball it. Which I suspect the question is alot more about how do you handle pressure and a lot less about how are your math skills.
Look forward to the next, game programming and design is my first love Im sure I will end up a .net Software Engineer but its still my first love.
This is probably off topic, but still somewhat relevant I think. When CoH first came out, they didn't explicitly display to players how much a given enhancement really affected a given power. You have to sort of infer from damage dealt what was going on behind the curtain. They eventually changed it so you could see how much a damage, accuracy, recharge rate, etc your powers had down to like 2 decimal places. In the early days, when we were all "flying blind", people used to obsess over making sure their powers had maximum allowable enhancers, and would grind for swag to make it so, even to the point of getting killed intentionally to slow the rate at which they lewveled up so that they'd have the influence to actually buy the anhancers they needed when they hit a level. And this was when the leveling was at it's slowest, comparatively (years later, there was full disclosure about enhancement numbers, and leveling got a lot faster in general, for a number of different reasons). People ignorant of the actual quantities involved will naturally try to just maximize something, often long after they've reached the point of diminishing returns. I would think that game design has similar issues. If you don't understand the inner workings of the powers, you're not capable of understanding what sort of problems you have, and how best to solve them, and which parts are best left unperturbed.
"Well sure, the FrinkiacVII looks impressive - DON'T TOUCH IT - but I predict that within 100 years computers will be TWICE as powerful, ten THOUSAND times larger, and so expensive that only the five richest kings of Europe will own them." -Prof. Frink
It's one thing to hire someone who doesn't have much of a math background to place trees and hills and buildings in a game world, or to write quest text. But writing damage formulas? Come on.
I'm not a fan of the themepark model, but it does allow quest design to be seperate from the mechanics of the verbs those quests use, The person creating the lore and the dialogue technically doesn't need to know anything about how the fights actually play out - those two layers could be done by completely different teams with different skill sets.
My initial answer was wrong for part 3. It should be:
Average is 50x0.5 + 60x(0.52) + 70x(0.53) + 80x(0.54) + 90x(0.55) + 100x(0.55) = 59.68
If the tick that does the 10 points that get you to 90 hits, you get a swing at another tick, if that last tick misses, you still did 90 points, and if it hits, you did 100 and stopped. My weighted average failed to take that into account the first time. Sorry about that.
....
BTW - I was re-reading the thread and wanted to say that this answer is correct.
The alternate way to check this is to list all the possible "rolls" and consider the results.
For those not mathematical - sometimes it helps to visualise the results
The surprise is that there are in fact 32 possible outcomes (2x2x2x2x2) although many people don't initially realise this... still they are in great company - it took two great mathematical minds to find the solution that had confused people for years.
And as FrinkiacVII said there is actually an equal chance of doing 90 or 100 points of damage (1/32 each)
So the total damage over 32 rolls is 800 + 480 + 280 + 160 + 90 + 100 = 1910points
1910 / 32 = 59.69 points.
There is but a tiny flaw in your logic. 90 and 100 do not have the same chance of rolling. Once the 4th tick (90) occurs from that specific moment are both just as probable as the other BUT the base logic for this problem is the next tick has a 50% chance therefore each tick is twice as likely as the next. If you look at your beautiful color coded post you will see that you have debunked yourself because the Y in the previous row attribute to the 90 in the next row which is a fail roll for tick5. so i would allocate the points like so:
I believe you got momentarily mixed up on the which tick which of the numbers 80, 90. 100 refer to. If the damage stop on the 4th tick, it's 80 damage (50 + 3x10 + 0). If you get to the 5th tick, you are going to be doing either 90 ( 40 + 4x10 + 0) or 100 ( 50 + 4x10 + 10 ) damage, each equally likely. When looking at how you got to 90 or 100 damage, there is no difference in the number of rolls each possibility saw, which is where you got mixed up on the counts.
So, if you were going to approach the problem this way, your numbers for the 32 possibile outcomes of checking for damage 5 times should have been:
16 will fail to do damage on the first tick (50 damage)
8 will do damage on the fist tick, but not the second (60 damage)
4 will do damage on the first and second tick, but not the third (70 damage)
2 will do damage on the first three ticks but not the 4th (80 damage)
1 will do damage on the first four ticks but not the 5th (90 damage)
1 will do damage on the first four ticks *and* the 5th (100 damage)
Comments
Further evedince of why game design has gone downhill in the last ten years. Real game design should be like art, the why should be more important than the how.
Computers can do math, game designers should be creating worlds not number crunching.
You guys need creative people that come up with NEW ways of doing things, not just leg humping "the way it is done" with cheesy insider math problems.
The soultion to this problem is: Why the heck are you making something so complicated that normal people can't figure out how it works? Game producers need to start following a rule that good musicians have been using for a long time: KISS. Keep It Simple Stupid.
IMHO anyhow.
It's a question of combinations verses permutations. The language of mathematics is specific.
If the original question is based on permutations, or slight variations based on object variations - it becomes a very easy problem indeed - not really even worth a question.
For example "Click Object"
Quest 1: Click bucket
Quest 2: Click water
Quest 3: Click tub
etc...
and if it is based on specific NPCs:
Quest 1: Kill (Biggest) Boar
Quest 2: Kill (Biggest) Bear
Quest 3: Kill (Biggest) Bandit
etc...
and if it's based on allowing chains as you suggest then you could do:
Quest 1: Click Club
Quest 2: Get Club and Kill Bandit
Quest 3: Get Club and Kill Bandit who drops spear (get spear)
Quest 4: Get Club and Kill Bandit who drops spear (get spear) and use spear to kill Knight.
etc...
All pretty uninspired stuff but that would meet the requirements of the question if it reads as you say... and if that's the case there is no challenge there?
Nothing says irony like spelling ideot wrong.
And who exactly writes the formulas that the computers execute later? Computers don't program themselves, you know. Waving your hands and saying "and then they should properly balance these skills" doesn't get it done. You have to code in explicit values for the game to use, and that means that you'd better have some idea of what the particular values that you're going to choose will do.
How exactly do you propose to determine when mobs or players die if not using formulas?
Programmers
A game designer can say "I want the Adept Wizard to be able to take down a Lesser Troll with three fireballs, on average."
Then the Programmer can do the math - and decide what sort of system works best to calculate the hows and wheres of where damage is allocated.
Bad analogy time: Do you drive a car? Do you know how to repair the engine or (on most modern cars) programme the fuel injection system?
Because when you drive a car - you point the thing in the direction you want and decide how fast to travel and when to slow down and stop.
You don't choose the brake system, or the engine parts, or the gear ratios - people who know far more about these things than you have already done that. And the guy who decided on the car body shape didn't do that either. He knew that certain features and space would be required then he worked with a whole bunch of other people to make it work. They do that based on general information about the sort of driving customers are likely to do. Most cars are designed to travel at about 100-120km/h comfortably these days. You may not drive at 120km/h today. You don't have to sit down and explicitly work out all the required parts to do that just to drive home from work.
Edit: Or maybe a Junior Designer(?) would do this work.... but it's number heavy and not so much a matter of design as making the numbers work. So it's not what I consider 'design' so much. In building this sort of work is done by Quantity Surveyors, who don't actually 'design' so much as manage.
Nothing says irony like spelling ideot wrong.
However, we have advanced to the point where you can write novels on a computer without having to program your own text editor. There are people who have a passion for creating worlds who don't have a passion for statistics. Alas there just aren't a lot of world-building toolkits designed with non-programmers in mind.
I don't work in the games industry but I do work in the software industry. Most programmers do not design the features of the product. They merely implement what has been specced by the product managers. However, that doesn't say they do not have a say so in how it should work, but they do not have 100 control on that.
It actually is rather inefficient to have a programmer design what the product should be, because that distracts them from well programming.
Ideas are easy, implementation is hard. If an employer has a choice between a creative person who can do math and a creative person who cannot do math, how do they judge whether the non-math person is bringing superior artistic ability to design that outweighs the fact that they will never be able to assign that person to the implementation team?
( perhaps another way to look at it is whether a game is better or worse for having strict seperation of roles in its creation - a topic of debate that I do notice pops up from time to time )
Fair point.
I have been trying to think of a better way to say what I mean with regard to what i consider 'design' as opposed to number crunching...
Then I thought of something I did years ago in the ol' Pen and Paper days... (Yeah, I am that old and a nerd):
I wanted a game that was Sci-Fi-ish and there wasn't a lot out there I liked.
There was Traveller but it didn't really capture what I wanted. Then I found Star Frontiers and sorta liked that too - and really liked the Knight Hawks mechanics. I also fond some other stuff with hover tanks (can't recall where from?) and found another game with mechanics I quite liked for melee and projectile combat.
So the next thing was to integrate all the parts I liked and 'balance' them. I took a lot of the elements from the Traveller game and converted them to work with Knight Hawks. This involved changing stats and working out what a Traveller Ship would cost in Knight Hawks Credits.
This was basically just data work. I do not consider anything I did here as 'design'. I could see what the actual Knight Hawk game designers had intended and I simply made Traveller ships 'fit' into that design. But I did not design anything.
Later however, I wanted a mechanic that allowed players to land (or crash) a damaged ship on a planet. None of the game systems had any mechanic for this - so I designed one.
The design principle was simple "Players make a roll based on Pilot Skill & Ship Damage & terrain to determine if they land or crash - and how severe the crash is. I want results varying from a perfect landing to disasterous crash."
And from there it was back to the numbers to make it 'balanced' so that players actually stood a chance. And to make it fun for my players it worked out that 95% of the time 100% of the player characters would survive so long as the pilot had some control. This is not realistic - but killing player characters every other day tends to upset players!
Later I redesigned the system to allow for a number of "Piloting Rolls" on the way down where results were cumulative - so players felt that they could "regain control" based on skill... or (as somtimes happened) lose control due to bad choices and failing skill. I also found that players are more forgiving when a character dies at the end of a chain of 10 bad rolls compared to a death due to one bad roll.
I also Designed solar systems. Placing planets, moons, cities and bases. This was done to create an atmosphere and setting. No real numbers involved here - more a setting based on the desired outcome. (i.e. a frontier system, lightly settled and lawless, with heavy mining corporation interest and pirates - as well as a secret military base.)
I hope that better explains my distiction between design and just number crunching and balancing?
Nothing says irony like spelling ideot wrong.
Because the history of art already tells you this. Einstein failed math remember? John Lennon claimed he was terrible at math and accounting, the list of highly creative types being really good at creativity, and not so good with technical skills is vast. There are far more creative genius that are good at one thing, and not the other. There is actually some pretty reputable brain science done on this, the type of thinking required to do math is vastly different that what creative types typically do, its almost two different systems. You get better at what you train. If you train creativity, you will be more creative, if you train math and technical skills you will be better at that. Can there be people that are good at both? Maybe, but they are likely not as good at either as someone specialized in one or the other.
The reality is our society doesn't really reward creative types until they suddenly appear out of nowhere, and then they are rock stars. Creative types are often odd, eccentric individuals that don't have the skills "normal" people do because they spend so much time on creative things. Math is creativity in a sense, so don't get me wrong, there are plenty of creative mathematicians, but the skill is a different one.
Music is my best example, because I know it best, but there are many technically advanced musicians that are perfect technically, but fail to move us emotionally when they play. They make better producers/engineers than actual musicians. Both are required to make a great album, but both have different skill sets.
Video game companies would be wise understand the difference if they want to see growth in their industry.
For the math question my method for solution is simple: look at the answers posted, find the most common one and assume it's right.
And BTW, Einstein didn't fail math, he excelled at it.
BTW - I was re-reading the thread and wanted to say that this answer is correct.
The alternate way to check this is to list all the possible "rolls" and consider the results.
For those not mathematical - sometimes it helps to visualise the results
The surprise is that there are in fact 32 possible outcomes (2x2x2x2x2) although many people don't initially realise this... still they are in great company - it took two great mathematical minds to find the solution that had confused people for years.
So - the possible outcomes ("Y" means roll succeeds, "+" means roll fails)
I have also shaded out the failed columns in the table
YYYYYYYYYYYYYYYY++++++++++++++++
YYYYYYYY++++++++YYYYYYYY++++++++
YYYY++++YYYY++++YYYY++++YYYY++++
YY++YY++YY++YY++YY++YY++YY++YY++
Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+Y+
(Edit - sorry doesn't line up properly once posted)
The obvious point people raise is "How can there be 16 'fail' results from after the first roll fails? You don't continue past that point!"
In short - that's how probability works. But that was the very thing that initially confused even Pascal and Fermat.
So the results are
16 x 50 points of damage (First roll fails)
8 x 60 points of damage (First roll succeeds and second roll fails)
4 x 70 points of damage (First and second roll succeed and third roll fails)
2 x 80 points of damage (First, second and third roll succeed and fourth roll fails)
1 x 90 points of damage (First, second, third and fourth roll succeed and fifth roll fails)
1 x 100 points of damage (First, second, third, fourth and fifth roll succeed)
So that is all 32 possible outcomes covered.
And as FrinkiacVII said there is actually an equal chance of doing 90 or 100 points of damage (1/32 each)
So the total damage over 32 rolls is 800 + 480 + 280 + 160 + 90 + 100 = 1910points
1910 / 32 = 59.69 points.
Nothing says irony like spelling ideot wrong.
On the subject of "math skill" vs. "creativity" I want to point out that you CAN have both, and I think it helps a lot. If nothing else, you want to determine from the hiring process what the applicant's strengths and weaknesses are in those regards. It's not that they we're only interested in one aspect of the job, they were kicking the tires on all of it, as they should. Look at the discussion I'm having on this board with Gyrus about combinatorics. A person framing a question about game design needs to have some clue whether what they're asking for is even possible given the constraints they're imposing. Otherwise you get people at the upper levels making impossible requests of programmers, and then acting like it's the programmer's fault when it doesn't ever come together. Similarly, a person desiging a superpower for a game needs to understand how powerful that power is in comparison to the other options. Is it the BEST power available for it's opportunity cost, and of so by what margin does it outshine the next best option? Is it the best for CERTAIN archetypes? Is it sub-par but able to fill a hole in my attack chain? Is it so bad that I would want to avoid it? Is it a reasonable amount of damage for a power in the first place? What should its endurance cost be? How long should it take to recharge? Do we need to balance it by tacking on a debuff to the person using it? These are all QUANTITATIVE questions which need to be addressed in the design process, and that requires math. I mean, sure beta testing will catch a lot of major mistakes, but you still need to get it somewhere CLOSE to right the first time, and you still need to design it with some faint clue as to how comparatively good or bad it is. So I think the math comes with the territory, like it or not. This is not to say that you JUST want numbercrunchers, you want creative people who can crunch numbers, there's a big difference there.
Going back to the combinations vs permutations argument, I think you have to cut the game design test some slack in the vocabulary. I mean, most people, when telling you to make 20 missions out of 4 objectives, aren't asking you that question to see whether you're capable of proving the theorem that says it's technically impossible, given the mathematician's technical definition of what a "combination" is as compared to a "permutation". At the end of the day they want to see the missions you come up with, they want them to be fun, and to avoid feeling repetitive. If they try to neg you on repeats, that's when you say "Well, TECHNICALLY the task you asked me to perform isn't even possible, and here's why, so I just did the best I could. I promise you that everyone else who took this test failed on that criterion, or else they didn't submit 20 missions. I may have bent or broken a rule there, but you gave me no choice." or maybe you note that in the submission as a disclaimer then make 20 of your most interesting missions anyway. Or you know what, who knows, maybe they did ask that question to see if anyoine would catch them that it wasn;t even possible. That's certainly a point of the whole math argument I'm making here. In any event, I think after some clarification or negotiation, they'd still want 20 good missions, even if we had to redefine what a combination is to get us there,
"Well sure, the FrinkiacVII looks impressive - DON'T TOUCH IT - but I predict that within 100 years computers will be TWICE as powerful, ten THOUSAND times larger, and so expensive that only the five richest kings of Europe will own them." -Prof. Frink
You don't need to know all of the internal details of how a car works in order to drive it, just like you don't need to know all of the internal details of how a game works in order to play it. But we're talking about hiring people to design games, not just play them. I wouldn't want to play a game designed by someone who has no clue what the game is doing. Would you want to drive a car designed by someone who doesn't know anything about brakes or engines, and hope that it doesn't spontaneously combust on you?
It's one thing to hire someone who doesn't have much of a math background to place trees and hills and buildings in a game world, or to write quest text. But writing damage formulas? Come on. It's one thing to flub a question because of the pressure of a job interview or the awkwardness of transmitting precise information over the phone. But given ample time and little pressure, someone who doesn't find the first two parts trivial and the third easy has no business writing the underlying formulas that make a game work.
If the game designer can't specify what he wants more precisely than that, then about the only sensible way for a programmer to interpret it is, "I have no clue what I'm talking about, so you can do whatever you want."
You do know that cars are designed by many people? The guy who designs the chassis is not the same guy who designs the engine.
That was my point.
Game 'designers' shouldn't try to be experts in everything. And these days they can't.
The questions about math and how many points of damage a spell can do are fine on one level of design I suppose.... but really nothing a programmer (or even a competent modder) couldn't do.
They don't help on all levels of design.
Nothing says irony like spelling ideot wrong.
Errr... careful there... I think you just described the "designers" at Games Workshop!
Nothing says irony like spelling ideot wrong.
BURN!
In the grim darkness of the far future, nobody can do their kids' math homework.
I can remember a discussion (YEARS ago) on a message board (I think it might have been actually on usenet, if not some really old website forum) where a guy posted an army list which included "Bionics" for his leader. This caused a discussion of whether or not Bionics was worth its points. The way Bionics worked at the time was if your leader failed a save and lost his last wound, normally he'd die and be taken off as a casualty, but the Bionics give him a 1 in 6 chance at surviving. After that, if he "died" again, you got another chance to roll a 6 and save him. Essentially, the argument revolved around how many more wounds you were effectively giving your leader when you bought Bionics. It turns out that even with assumption of infinite turns, the bionics are worth, on average, 1/5 of one wound (and that was arrived at by using a shortcut formula that involves taking a limit as n goes to infinity). The guys response was basically "Yeah, but I always seem to make my Bionics roll, so I like it:" to which we all replied "Then your dice are loaded." For what it's worth, I gotta believe that nobody at GW ever did the math to determine what the actual average value of the Bionics was in terms of army points, but at least they didnt make them so cheap that everyone took Bionics every time. Bad options can exist and not really hurt anything, they just make other options look better by comparison. That said, like EVERY leader model that looked at all cool had bionics. They were always a badass model option and almost never a worthwhile army build option. There's something to be said for making the visally appealing/impressive stuff in the game actually good in game terms too.
"Well sure, the FrinkiacVII looks impressive - DON'T TOUCH IT - but I predict that within 100 years computers will be TWICE as powerful, ten THOUSAND times larger, and so expensive that only the five richest kings of Europe will own them." -Prof. Frink
For the 20 mission test, I think they were primarily interested in seeing whether you could come up with 20 interesting and varied missions, not in how you interpret the non-repeat requirements.
-----
Choosing formulas that will give interesting gameplay is a type of creativity. It's different from being able to draw a pretty picture or compose music that sounds good, and someone who is good at one isn't necessarily good at another. But it's still a type of creativity, and it's one that is absolutely vital to game design. Whether your formulas give interesting gameplay is perhaps the single largest factor in determining whether a game is any good.
Furthermore, in many (most?) cases, deciding what the formula should be is most of the work in implementing it. Even a mediocre programmer should be readily able to implement any of the three formulas in a game. There are some situations where the way that you'd naturally describe a formula doesn't match the way that computers want it presented, such as pathfinding or collision detection. For those, yeah, you want a good programmer to do the implementation. Though in those cases, you might also need a programmer to come up with the formula, as someone with no programming experience might not understand that this formula is 100 times as much work to implement as that one.
But if you're choosing the underlying formulas of game mechanics, that's an additional level of abstraction. It's a lot harder than the plug-and-chug type of computations in the test. Well, choosing an arbitrary formula isn't hard; it's only hard if you want the formula to actually make for interesting gameplay--which hopefully you do. For that, you need to not just be able to do routine computations, but also to have good intuition about what sort of effects different formulas will have and what different effects you can get by varying the parameters.
Someone who doesn't understand formulas but tries to pick them anyway is counterproductive and worse than useless. A designer who wants to pick high level goals for the formulas without understanding the underlying math is also useless, as he's likely to pick things that are contradictory. (Politicians do this all the time: for example, we want to increase spending, cut taxes, and pay off the national debt.)
Now, choosing formulas is an important part of game design, but it's not the only part. Someone who doesn't know much math but can write really interesting quests may well be valuable. Just don't let him start tinkering with formulas--or choose the rewards for the quests he writes.
The 20 question quest series, a little dubious in its details as it may be I think would be a fun exercise.
The math question I love, most people assume that the programmers do all the math and the game designers do all the design outline, I imagine they still have to at least have a basic understanding of the way the system works in order to create good content.
For example you can be a computer programmer and not know HOW to do advanced math you just have to know how to tell the compiler to do advanced math. You still have to understand the concept behind the math though.
My answer for the math questions... since its a phone interview would be: 1) 100 assuming it lives through all ticks, 2) 75 again assuming it lived through all hits, 3) While Im sure this is meant to seem very complicated it starts with 50 damage, so the answer is 50:60>61 (read as fifty to sixty but less than sixty-one) since no two computations are going to be the same. Now off of a phone interview sure I could sit down and work out an actual average but on the phone Im just going to spitball it. Which I suspect the question is alot more about how do you handle pressure and a lot less about how are your math skills.
Look forward to the next, game programming and design is my first love Im sure I will end up a .net Software Engineer but its still my first love.
"Well sure, the FrinkiacVII looks impressive - DON'T TOUCH IT - but I predict that within 100 years computers will be TWICE as powerful, ten THOUSAND times larger, and so expensive that only the five richest kings of Europe will own them." -Prof. Frink
I'm not a fan of the themepark model, but it does allow quest design to be seperate from the mechanics of the verbs those quests use, The person creating the lore and the dialogue technically doesn't need to know anything about how the fights actually play out - those two layers could be done by completely different teams with different skill sets.
There is but a tiny flaw in your logic. 90 and 100 do not have the same chance of rolling. Once the 4th tick (90) occurs from that specific moment are both just as probable as the other BUT the base logic for this problem is the next tick has a 50% chance therefore each tick is twice as likely as the next. If you look at your beautiful color coded post you will see that you have debunked yourself because the Y in the previous row attribute to the 90 in the next row which is a fail roll for tick5. so i would allocate the points like so:
32x50 (all 32 rolls a 50 will occur)
16x60
8x70
4x80
2x90
1x100
(1600+960+560+320+180+100) / 63 = 59.04762
I believe you got momentarily mixed up on the which tick which of the numbers 80, 90. 100 refer to. If the damage stop on the 4th tick, it's 80 damage (50 + 3x10 + 0). If you get to the 5th tick, you are going to be doing either 90 ( 40 + 4x10 + 0) or 100 ( 50 + 4x10 + 10 ) damage, each equally likely. When looking at how you got to 90 or 100 damage, there is no difference in the number of rolls each possibility saw, which is where you got mixed up on the counts.
So, if you were going to approach the problem this way, your numbers for the 32 possibile outcomes of checking for damage 5 times should have been:
16 will fail to do damage on the first tick (50 damage)
8 will do damage on the fist tick, but not the second (60 damage)
4 will do damage on the first and second tick, but not the third (70 damage)
2 will do damage on the first three ticks but not the 4th (80 damage)
1 will do damage on the first four ticks but not the 5th (90 damage)
1 will do damage on the first four ticks *and* the 5th (100 damage)