Well I was playing around... And two hours later I have a lesson built. I can very well imagine this turning into an annual thing so here I go. I made them in Mathematica, so to read them you have to download the COMPLETELY FREE reader found here. Yes you have to sign up for it, but it isn't bad.

My qualifications: I've had a pretty prolific career in math, being considered the top student in it through all my classes. I've completely mastered Algebra and have a firm grasp on basic calculus. All in all, I know what I'm doing with all of this stuff.
TL; DR version: I completed my last math exam in 15 minutes and got a perfect score, next person done took an hour. I know what I'm doing.

Lesson 1: Upgrades - This deals with upgrades and how effective they are as they grow in number. If you thought all upgrades had to do with was linear progress you might want to take a look at this.

1-1: Basics


Lesson 2: Resource Gathering (next week) - Ever wondered the total mathematical breakdown of resources? Well here's your chance. This lesson will discuss all aspects of resource gathering. Includes theoretical and practical examples


I am taking requests for more lessons. What do you want to see next? I'll fully breakdown any mathematical component of StarCraft.

Post has been edited 3 time(s), last time on Jun 9 2010, 12:55 am by Sacrieur.

I would like to see a breakdown of mining and the returns of creating an expansion, as well as the mining speed of the workers on mineral patches at the following locations with respect to the nexus (since mining speed differs for every location and for each worker). Knowing this allows the "value" of a mineral formation to be precisely evaluated for each race.



Why is this important? Simple:

You should do these for starcraft 2 since it is going to take over soon here. I'm downloading your thing right now along with that program.

[EDIT]
Started reading it and the first line...is a typo "I mean, obviously adding 1 to 6 isn't as big of a change as adding 1 to 8"

So far looks good though, I'll edit again when I get through it all.

Post has been edited 1 time(s), last time on Jun 3 2010, 9:59 pm by JB4times4.

Yeah, reading through it again myself I realize I'm going to have to do a lot of corrections. I was more focused on the math than the writing.

@ SC2, if I could run SC2 I would, but I can't.

EDIT: There will be videos explaining it up soon.

Post has been edited 1 time(s), last time on Jun 4 2010, 2:14 am by Sacrieur.

So I read through it all and it's pretty interesting. Can't wait to see your others.

There's no need to on SC2. There's a nice chart that shows resource rpm and you should be able to see the difference easily after you compare nat and non-nat, or exp or non-exp.
Well. One could still take the liberty, I suppose.

Post has been edited 1 time(s), last time on Jun 4 2010, 2:49 pm by BeDazed.

I'd just like to point out that mining speed is not completely dependant on workers. All three have equal speeds. Try swapping each center and worker.

- Command Center with Probe
- Command Center with SCV
- Command Center with Drone
- Nexus with Probe
- Nexus with SCV
- Nexus with Drone
- Hatchery with Probe
- Hatchery with SCV
- Hatchery with Drone

Lair and Hive are the same size as the Hatchery, so the behaviour doesn't really change there.

EDIT: It appears workers mining on the left side of a Nexus will gather faster than on the right side of a nexus.
All 3 workers are completely equal when it comes to mining.
A hatchery will receive the same income on both sides.
Workers mining on the right side of a Command Center will gather faster than the left side.

Post has been edited 3 time(s), last time on Jun 4 2010, 7:25 pm by Heinermann.

Thanks, these will all be looked into .

EDIT: Also, I updated Lesson 1. It is now better and improved.

Post has been edited 1 time(s), last time on Jun 4 2010, 8:13 pm by Sacrieur.

There's still a lot of mystery regarding a unit's size/position and behaviour in relation to their size/position.

In theory, the order of fastest mining should be as follows in relation to the size of the main structure:
Command Center (Largest)
Nexus
Hatchery/Lair/Hive
Start Location (Smallest)

But that may not be the case (I don't quite remember, but I think the Command Center has some exception).

Interesting. I have a lot of testing ahead of me.

I didn't look at your math notes because they were in some weird format, and I'm not going to spend my time downloading and installing things. Next time just take some screenshots of your math notes and post them up here if you want more people to participate.

Did you ever mention that some units deal damage with two hits, making foes with higher armor more effective at defending? For example in zvp the zerg should upgrade their ground carapace first to better combat +1 attack zealots, because zealots deal damage with two sequential hits. Since zealot hits are twofold, the zerg carapace armor gets accounted for twice.

Practical melee examples would make your notes stronger for sure, in case you didn't add things like this.

Ty for the criticisms.

Yeah, I need to finish a video on it, I'm being a lazy bum. But I promise it'll be up today. Specific in-game examples will be included for sure.

You'd think that things like zealot attack would factor into upgrade effectiveness at first look, but after doing the math it doesn't turn out that way. If you write the expression for zealot damage upgrade effectiveness you get 2/(16 + 2x). Now, anyone who has taken algebra can note that this will simplify to 1/(8 + x), which is the same as if we were to take one zealot attack and find its effectiveness.

Armor is strange. Most units start off with 0 armor, so a 1 increase will have a 1/x effectiveness expression. This means that it is impossible to tell how effective it is to upgrade from 0 to 1 since the expression is undefined at 0. However, if we were to analyze the graph it would tell us that upgrading from 0 to 1 it is a very epic change. Like, hitting a wall at light speed type of epic; can anyone say splat?

Zerg carapace on zerglings of +1 will minus one damage from each zealot attack hitting the zergling. Instead of the standard 16 total, (it's 16, right?), the zealot would do 14 damage since the zealots deals two hits of 8. This allows zerglings to last one entire round of hits from a zealot with +1 attack than without the carapace, and is a big deal during a melee match.

2/(16 + 2x) isn't the equation, it's two equations of 1/(8 + x), which is why the zerg carapace in my previous example would be applied twice.

Instead of graphing the effectiveness of armor and armor alone it would be better to use specific examples so you don't get 1/0. For example, take the total health of mutalisk being hit by a corsair, then compare that to a mutalisk being hit by a corsair with +1 attack. Since there are high numbers of corsair attacks a mutalisk carapace upgrade would be more effective in combating corsairs than an attack upgrade.

Post has been edited 1 time(s), last time on Jun 8 2010, 8:03 pm by CecilSunkure.

The first lesson applies more to UMS games with 255 upgrades than anything else; and to be honest, it was effectively plaintext with LaTeX and some images thrown in, not using Mathematica's more advanced features. Add it to a personal blog or something O.o

You have to realize that upgrading in SC is not as much about the DPS as making your units kill enemies in fewer hits. +1 zealots make a much higher difference than your lesson suggests, and +2 on archons make a vastly greater difference than +1. You should probably focus more on the gameplay impact than the abstract mathematics.

Will do, I may revise the lesson a lot and include a lot in the video. The plan is that I'll use the power of Mathematica in future lessons so you guys can play around with stuff too, soon as I learn it all.

*bump*

First video is up. Next will deal with applications.

Heh. Not even sure you're running this thread any more, but heck - doesn't hurt to try.

I need an equation that will determine amounts of experience for levelups. Essentially, the equation should work based on the output of the last time it was run, with a base number of 100 or so. I would like each number to be significantly larger than the last, such that players cannot continue to grind on low-leveled foes and expect swift results. World of Warcraft accomplishes this effectively by preventing the acquisition of experience from any kill that is more than 5 levels lower than the player, but since I don't know how to accomplish this for SC2, I'm resorting to dynamic levelup experience requirements.

It would also help if you help me understand how you arrive at whatever equation you come up with.

Thanks in advance.

^ Necromancer alert.

But yeah, interesting shit. Don't mean to be offensive but I completely suck at mathematics and while your first video explained in detail that 6 + x is exponential. I thought that was pretty self explanatory? If I can increase 7+1 to give me x, and I can increase x+1 an infinite number of times, it is apparent that the increases will lose effectiveness and thus produce a graph like yours?

While, don't get me wrong the maths behind it all is fascinating.

You should apply this knowledge of mathematica to Starcraft 2. Specifically Voidray damage with and without upgrades, Siege Tank damage output (sieged vs non-sieged) taking into account Armoured and Light targets. Marine damage output in a ball formation... etc...

Would be a lot more valid.

Imageo, a very simple and easy to implement system that was used back in Diablo:

Each monster has a base EXP level, say 700, a monster level (MLVL), and an experience increment. Then, for each character level (CLVL) above the MLVL, you deduct the increment from the base experience.

Example (completely made up numbers):
Fallen one base EXP: 600
Fallen one EXP modifier: 150
Fallen one MLVL: 4
When you are clvl x, you earn: y
Clvl 1: 600
Clvl 2: 600
Clvl 3: 600
Clvl 4: 600
Clvl 5: 450
Clvl 6: 300
Clvl 7: 150
Clvl 8: 0
Clvl 9: 0

Basically the formula is like this:
if clvl > mlvl, then EXP = BASE - ((clvl - mlvl) * modifier), else EXP = BASE

So for clvl 3, clvl < mlvl, so EXP = BASE
For clvl 6, clvl > mlvl, so EXP = 600 - ((6 - 4) * 150) = 600 - 300 = 300.

This is a very simple system, and lets you have different drop-off rates for different monsters - maybe some monsters have really high base EXP, so if you kill them when you're a much lower level, you get a lot of EXP, but they also have very high modifiers, so maybe when you're 3 levels higher, they give very little or no experience. You could have monsters with low base exp but also low modifiers, so they keep giving some EXP for a time after.

If you want to throw in a hard 5 level cap, then simply do this:
if clvl > mlvl + 5 then EXP = 0
else if clvl < mlvl, then EXP = BASE
else EXP = BASE - ((clvl - mlvl) * modifier)

Or you could just scale the experience based on a polynomial or exponential equation.

In my map, level 1 is like 100 exp and monsters give ~60 exp, but level 50 (max level) is 1,000,000 exp, based on something like Exp Required = c1*Level^3 + c2*Level^2 + c3*Level + 50 or something like that, where c1,c2,c3 are just numbers to make the equation give me nice even numbers like 1500 and stuff for level requirements. That way, sure theoretically you could sit in 1 area and leave the computer on for a day or two and level right up to 50 in the first area, but if you actually want to play the game you have to move on to beat monsters that give 1000's of exp, or 10,000's ect.