masterzii

[masterzii]

Nipple removal.

[masterzii]

[masterzii]

[masterzii]

reuploading this cause the original vid got taken down but the spongebob musical does NOT play around when it comes to references

[masterzii]

Or 6 days...

Guilty

[masterzii]

You: seeing six crows is bad luck and an omen of death

Me, an intellectual: seeing six crows is great luck because you get to see six crows

[masterzii]

Asexual chemist aesthetic for @asphodellovely!

[masterzii]

domestication syndrome is one of the coolest findings from recent genetics

[masterzii]

GameDev

I periodically get emails from indie devs who are just getting started. They're looking for advice. Sometimes, their questions are so relevant to the kinds of things that I'm currently thinking about that I end up typing way too much in response to them. Seems like a waste of typing for just one person's benefit. I post what I typed here, hoping that it will benefit multiple people.

In this case, the person was looking for advice based on specific games that weren't total failures, but didn't sell as well as they were hoping. They were thinking about giving up, getting a job, etc.

The games in question are here:

Pillar (https://www.youtube.com/watch?v=0z7AAJbMFeU)

The Path of Motus (https://www.youtube.com/watch?v=WXEjMuZmVww)

It's a little weird to make a public example out of someone, but it's hard to understand what I wrote without this context. And furthermore, I think this particular designer is doing something pretty cool, and above-and-beyond what I usually see from first-time designers that email me. So I feel okay elevating the profile if this work while also dissecting it at the same time.

To summarize the question with condensed quote:

I've come to the conclusion that maybe my games just aren't appealing to the mass amount of gamers. Both titles are really strange conceptually... but then I see your games do very well and I feel that debunks my theory as your games also stand out conceptually. I also feel I've made a mistake in taking too long on my games. Perhaps I need to churn out games faster and work on building up more of a following. I'd appreciate hearing any thoughts or advice you have. What do you think helped your games have financial success?

Here's what I wrote in response:

Well, Step #1 is email me so that I watch your Pillar trailer and have my mind kinda blown by the vibe that it's giving me. :-)

Really complicated and haunting feeling. Reminds me of the feeling that I got years ago from "I Have No Mouth and I Must Scream."

Next step is read this Reddit post of mine:

https://www.reddit.com/r/gamedev/comments/7wnud8/note_i_didnt_make_any_money_until_game_14_if/

And gird your loins to keep failing and not give up yet.

That said, when I look at these games, I'm not at all shocked that they're not selling well. I can't put my finger on it.... but there's something about the presentation that feels a tad amateurish. I think part of it may be that you're overshooting your abilities in terms of content creation/animation/etc. You're trying for a "pro" polished look, but falling short. I mean, these games don't look as put-together as Braid, for example, but they're clearly shooting for something like that. Whereas, The Castle Doctrine achieves a cohesive "nu low-fi" look, and no one would try to compare the look to Braid.

I'm too close to One Hour One Life to judge it properly (I absolutely LOVE the way that it looks), but I think that other people describe it's look as "charming". Somehow, these simple cartoons "work" and are seen as cute. Again, the low aim disarms people a bit. It's not pixel art.... but it's like the hand-drawn equivalent of that. Doodles. My first non-pixel-art game in like a decade, but I somehow hit a different kind of sweet spot.

So that's the look component of it. The Pillar look is actually the better of the two. The only thing that feels slightly off on that one is the walking animations, but it almost works anyway.

Next: WTF are we doing in these games?

Weird new games need to be CRYSTAL CLEAR about how they are innovative. The trailers need to get people's gears turning, and make them understand exactly why they've never played a game like this before.

Take a look at the The Castle Doctrine trailer or the One Hour One Life trailer. After watching those, you really have a deep understanding of how these games work (the trailer is almost like a tutorial), and you can clearly see why there has never been a game like this before.

And that may be another canary in the coal mine moment for you. Even if your trailer did explain it better, would the core "what people are doing in the game" part be mind-blowing enough to even be included in the trailer?

"A game where you build security systems and then try to break through security systems designed by other people"

"A game where you're born as a helpless baby to another player as your mother, and you live an entire life in one hour"

Pretty much everyone I've ever told those elevator pitches to (even non-gamers) was instantly intrigued.

I often wait until I have that kind of idea before making my next game. A "Holy crap!" idea. An idea that is so obvious and perfect that I rush too Google, hoping that no one else has thought of it yet. An idea that will make everyone else say, "Why didn't I think of that?"

In the case of The Castle Doctrine, I had at least 5 designer friends of mine sheepishly admitted to me that they had been working on exactly the same game. So I was right to be nervous about someone else doing it first. Then I saw the movie The Purge. A lot of people were thinking along the same lines around that time....

And if you have that kind of idea, it's easier to communicate that in the trailer and get people really excited about it.

Finally: Value proposition

When people decide to plunk money down for a game, they are generally doing one of two things:

They are so overwhelmed by the emotions stirred up by the very idea of your game that it's an impulse buy. Games with extremely evocative visual styles can often pull this off. The Last Night is a great forthcoming example of this. It will make enough people scream HERE DAMMIT TAKE MY MONEY that it will sell well no matter what. Hyper Light Drifter is another. These are first-week games. These games are like Levitron Tops. The idea of a floating top on your coffee table is enough.

They conduct a careful research project about your game, and the math works out to them. This is a deep game that they could get into for a long time and reap many weeks/months/years of enjoyment out of. They kick the tires, pinch the fabric between their fingers, heft the thing in their hands.... yes, this is gonna be worth $20. These games are like backpacks. You spend some time finding just the right one. You're going to be wearing it on your back for a while. (Monkey-on-my-back metaphor is not lost on me here.)

Single-player games usually have to rely on #1 to sell well. There are a few exceptions---usually some kind of endless building games where what the player does is up to them (Stardew Valley, Factorio, Subnautica), or steep-curve rogue-likes (Spelunky, Nuclear Throne). Emergence and long-term replayability is key, either way.

Sadly, as a result, I think single-player games are kindof a dying breed in the modern ecosystem. We're not going to see many Braid or Fez type success stories these days. And the few that do succeed will do so on raw emotion alone (pure #1). But the road is currently littered with big-budget single-player indie failures that totally would have been successful five years ago. Also, we must keep in mind that even Braid- or Gone Home-level success is small potatoes next to Stardew Valley or Factorio.

Thus, I'm skeptical of the indie apocalypse. People are just generally playing different types of indie games now than they were before. The old guard is experiencing system-shock when their short, consumable, single-player games aren't selling like they used to, and first-time indie devs are experiencing the same thing for the same reasons (because first games are almost always short, consumable, single-player games). But indie games are making way more money now than they ever have made.

So, if you're making this kind of game.... you REALLY better be sure that you're punching #1 square in its impulse-buying heart. If your game's initial impression gives people pause, it's already over.

But it's much more viable to target #2.

Many people played The Castle Doctrine every day for 11 months straight. Many people have played One Hour One Life 900 hours over the past seven months. Can your game do that? If so, then it can fit into the #2 ecosystem.

These games are NOT first-week games. These are the types of games that have their biggest week a year after launch, when people collectively realize just how deep the value proposition of the game really is.

Multiplayer is the easiest way forward. But there are also single-player paths here, as mentioned above. But my first "hit" game (14 games in, Sleep is Death) just happened to be a multiplayer game....

Even so, you still have to have a tiny bit of #1 in there to get people intrigued enough in the first place that they conduct the research project and find the value proposition. But it doesn't have to punch them in the heart. It can also tickle their brain conceptually. If they walk away from the trailer musing about the game, that's the seed that will grown into a research project where they will eventually decide to buy it.

But most importantly, you're only two games in. You have a lot of learning to do, and you will keep getting better and better at designing and making and selling games. Go back and look at my second game, and imagine if I had given up there.

[masterzii]

"My Games Didn't Sell Well" --- Here's my advice for you.

I periodically get emails from indie devs who are just getting started. They're looking for advice. Sometimes, their questions are so relevant to the kinds of things that I'm currently thinking about that I end up typing way too much in response to them. Seems like a waste of typing for just one person's benefit. I post what I typed here, hoping that it will benefit multiple people.

In this case, the person was looking for advice based on specific games that weren't total failures, but didn't sell as well as they were hoping. They were thinking about giving up, getting a job, etc.

The games in question are here:

Pillar (https://www.youtube.com/watch?v=0z7AAJbMFeU)

The Path of Motus (https://www.youtube.com/watch?v=WXEjMuZmVww)

It's a little weird to make a public example out of someone, but it's hard to understand what I wrote without this context. And furthermore, I think this particular designer is doing something pretty cool, and above-and-beyond what I usually see from first-time designers that email me. So I feel okay elevating the profile if this work while also dissecting it at the same time.

To summarize the question with condensed quote:

I've come to the conclusion that maybe my games just aren't appealing to the mass amount of gamers. Both titles are really strange conceptually... but then I see your games do very well and I feel that debunks my theory as your games also stand out conceptually. I also feel I've made a mistake in taking too long on my games. Perhaps I need to churn out games faster and work on building up more of a following. I'd appreciate hearing any thoughts or advice you have. What do you think helped your games have financial success?

Here's what I wrote in response:

Well, Step #1 is email me so that I watch your Pillar trailer and have my mind kinda blown by the vibe that it's giving me. :-)

Really complicated and haunting feeling. Reminds me of the feeling that I got years ago from "I Have No Mouth and I Must Scream."

Next step is read this Reddit post of mine:

https://www.reddit.com/r/gamedev/comments/7wnud8/note_i_didnt_make_any_money_until_game_14_if/

And gird your loins to keep failing and not give up yet.

That said, when I look at these games, I'm not at all shocked that they're not selling well. I can't put my finger on it.... but there's something about the presentation that feels a tad amateurish. I think part of it may be that you're overshooting your abilities in terms of content creation/animation/etc. You're trying for a "pro" polished look, but falling short. I mean, these games don't look as put-together as Braid, for example, but they're clearly shooting for something like that. Whereas, The Castle Doctrine achieves a cohesive "nu low-fi" look, and no one would try to compare the look to Braid.

I'm too close to One Hour One Life to judge it properly (I absolutely LOVE the way that it looks), but I think that other people describe it's look as "charming". Somehow, these simple cartoons "work" and are seen as cute. Again, the low aim disarms people a bit. It's not pixel art.... but it's like the hand-drawn equivalent of that. Doodles. My first non-pixel-art game in like a decade, but I somehow hit a different kind of sweet spot.

So that's the look component of it. The Pillar look is actually the better of the two. The only thing that feels slightly off on that one is the walking animations, but it almost works anyway.

Next: WTF are we doing in these games?

Weird new games need to be CRYSTAL CLEAR about how they are innovative. The trailers need to get people's gears turning, and make them understand exactly why they've never played a game like this before.

Take a look at the The Castle Doctrine trailer or the One Hour One Life trailer. After watching those, you really have a deep understanding of how these games work (the trailer is almost like a tutorial), and you can clearly see why there has never been a game like this before.

And that may be another canary in the coal mine moment for you. Even if your trailer did explain it better, would the core "what people are doing in the game" part be mind-blowing enough to even be included in the trailer?

"A game where you build security systems and then try to break through security systems designed by other people"

"A game where you're born as a helpless baby to another player as your mother, and you live an entire life in one hour"

Pretty much everyone I've ever told those elevator pitches to (even non-gamers) was instantly intrigued.

I often wait until I have that kind of idea before making my next game. A "Holy crap!" idea. An idea that is so obvious and perfect that I rush too Google, hoping that no one else has thought of it yet. An idea that will make everyone else say, "Why didn't I think of that?"

In the case of The Castle Doctrine, I had at least 5 designer friends of mine sheepishly admitted to me that they had been working on exactly the same game. So I was right to be nervous about someone else doing it first. Then I saw the movie The Purge. A lot of people were thinking along the same lines around that time....

And if you have that kind of idea, it's easier to communicate that in the trailer and get people really excited about it.

Finally: Value proposition

When people decide to plunk money down for a game, they are generally doing one of two things:

They are so overwhelmed by the emotions stirred up by the very idea of your game that it's an impulse buy. Games with extremely evocative visual styles can often pull this off. The Last Night is a great forthcoming example of this. It will make enough people scream HERE DAMMIT TAKE MY MONEY that it will sell well no matter what. Hyper Light Drifter is another. These are first-week games. These games are like Levitron Tops. The idea of a floating top on your coffee table is enough.

They conduct a careful research project about your game, and the math works out to them. This is a deep game that they could get into for a long time and reap many weeks/months/years of enjoyment out of. They kick the tires, pinch the fabric between their fingers, heft the thing in their hands.... yes, this is gonna be worth $20. These games are like backpacks. You spend some time finding just the right one. You're going to be wearing it on your back for a while. (Monkey-on-my-back metaphor is not lost on me here.)

Single-player games usually have to rely on #1 to sell well. There are a few exceptions---usually some kind of endless building games where what the player does is up to them (Stardew Valley, Factorio, Subnautica), or steep-curve rogue-likes (Spelunky, Nuclear Throne). Emergence and long-term replayability is key, either way.

Sadly, as a result, I think single-player games are kindof a dying breed in the modern ecosystem. We're not going to see many Braid or Fez type success stories these days. And the few that do succeed will do so on raw emotion alone (pure #1). But the road is currently littered with big-budget single-player indie failures that totally would have been successful five years ago. Also, we must keep in mind that even Braid- or Gone Home-level success is small potatoes next to Stardew Valley or Factorio.

Thus, I'm skeptical of the indie apocalypse. People are just generally playing different types of indie games now than they were before. The old guard is experiencing system-shock when their short, consumable, single-player games aren't selling like they used to, and first-time indie devs are experiencing the same thing for the same reasons (because first games are almost always short, consumable, single-player games). But indie games are making way more money now than they ever have made.

So, if you're making this kind of game.... you REALLY better be sure that you're punching #1 square in its impulse-buying heart. If your game's initial impression gives people pause, it's already over.

But it's much more viable to target #2.

Many people played The Castle Doctrine every day for 11 months straight. Many people have played One Hour One Life 900 hours over the past seven months. Can your game do that? If so, then it can fit into the #2 ecosystem.

These games are NOT first-week games. These are the types of games that have their biggest week a year after launch, when people collectively realize just how deep the value proposition of the game really is.

Multiplayer is the easiest way forward. But there are also single-player paths here, as mentioned above. But my first "hit" game (14 games in, Sleep is Death) just happened to be a multiplayer game....

Even so, you still have to have a tiny bit of #1 in there to get people intrigued enough in the first place that they conduct the research project and find the value proposition. But it doesn't have to punch them in the heart. It can also tickle their brain conceptually. If they walk away from the trailer musing about the game, that's the seed that will grown into a research project where they will eventually decide to buy it.

But most importantly, you're only two games in. You have a lot of learning to do, and you will keep getting better and better at designing and making and selling games. Go back and look at my second game, and imagine if I had given up there.

https://www.reddit.com/r/gamedev/comments/9k8wsi/my_games_didnt_sell_well_heres_my_advice_for_you/

[masterzii]

Calc

Kinds of numbers. Fractions and decimals. We'll refer to integers (whole numbers, either positive, negative, or zero), rational and irrational numbers. The number line

◊ Conventions for arithmetic notation including order of operations (precedence), proper use of parentheses

◊ Expression manipulation. Distibutive laws, law of signs

◊ Exponents and laws for exponents

◊ Roots, laws for roots, rational exponents, rationalizing denominators

◊ Absolute value, order (less than, etc.), and their properties

Factorials (e.g., 5! is the product of the integers from 1 through 5)

◊ Pythagorean theorem

◊ Similar triangles

◊ Areas of triangles, circles, and other simple plane figures

◊ Perimeters of simple plane figures, circumference of circles

Volumes of spheres, cones, cylinders, pyramids

Surface areas of spheres and other simple solid figures

◊ Translating word problems into algebra

◊ Expression manipulation. Addition, subtraction, and multiplication of polynomials

Rational functions and their domains, least common denominators

◊ Techniques for simplifying algebraic expressions

◊ Factoring quadratic polynomials and other simple polynomials

◊ Techniques for solving linear equations in one unknown

◊ Solving quadratic equations in one unknown, completing the square, quadratic formula

◊ Solving linear equations in two or more unknowns

◊ Techniques for solving inequalities and both equations and inequalities involving absolute value

◊ The concept of function, functional notation and substitution, domain and range of a function

◊ Composition of functions

Sets, membership in sets, subsets, unions, intersections, empty set

Open and closed intervals and their notations

◊ Coordinates of points in the plane

◊ Linear equations. Slope-intercept form especially, but also other forms

◊ Distance between two points

◊ Equations of circles, especially the unit circle

◊ Slopes of straight lines, parallel lines

◊ Graphs of functions. Vertical line test

Symmetries of functions, even and odd functions. Transformation of functions

Graph of a quadratic function is a parabola

Graph of y = 1/x is a rectangular hyperbola

◊ Angle measurement, both degrees and radians, but radians are more important in calculus. Negative angles.

Length of an arc of a circle

◊ Understanding of trig functions of angles, especially sine, cosine, tangent, and secant. Trig functions and the unit circle

◊ Right triangles, trig functions sine, cosine, and tangent of acute angles. Values of these trig functions for standard angles of 0, π/6, π/4, π/3, π/2

◊ Solving right triangles

Obtuse triangles. Law of sines, law of cosines. Solving obtuse triangles

◊ Basic trig identities. Pythagorean identities, trig functions in terms of sines and cosines

Other trig identities. Double angle formulas for sine and cosine, addition formulas for sine and cosine

◊ Exponential functions. Growth of exponential function

◊ Laws for exponents. Manipulation of algebraic expressions involing exponents, solving equations involving exponents

◊ Logarithms and their relation to exponential functions

◊ Laws for logs. Manipulation of algebraic expressions involing logs, solving equations involving logs

[masterzii]

How to get 4.0 or at least 3.7 plus?

There is no _secret_ to getting good grades. Additionally, not everyone will get good grades. I wouldn't focus on getting the grades as much as I would focus on making the most of your time, and using it wisely. Some classes are really hard and not worth the time to get an A.

​

You could get a 4.0 by never taking any difficult classes that you don't have to, or you could load up and take 18 credit semesters and maybe not get a 4.0.

​

Manage your time effectively.

​

There are five super important things that you _must_ do for overall health and productivity.

​

Meditation, Exercise, Diet, Sleep (7-8 hours a night, almost always), and Social activity.

​

If you do those things and manage your time, that will be the best you can do.

​

Make sure to set aside some downtime for yourself in order to restore yourself, whether that be to go to parties, clubs, spend time hanging out with friends, reading, hobbies... etc.

​

Don't be too hard on yourself. If you are, you can become depressed, which is not only bad as a whole, but will make it harder to work on things, because you won't have the energy. It's okay to get bad grades. It's not good to linger on mistakes, figure out what you did wrong, and how you can prepare better for next time, or perform better on the assignments.

​

Also, find some clubs, and make lots of friends. Make friends with people who work hard, it'll rub off onto you, and it'll matter more who your friends are than your grades when you get into the real world, over the long run.

​

They may help pull you into good jobs, or act as references.

​

Also, thing about your long term goals (which you may not be certain about), grades matter more for some things than for others.

​

Finding the balances is tricky. You can only strive to do your best, and make the most of your time.

​

I seriously regret not spending more time with people in college, my mental health would've been better, and I would have likely had better grades as a result, hell maybe even a girlfriend, or some fun stories to tell.

​

You got this. I believe in you.

​

You _will_ make mistakes, but everyone does, focus on the goals.

​

And remember, life is about the journey, because every life ends in death.

​

Go to class, study, go to office hours, work with your friends in order to help each other out when you get stuck, and for company. Set schedules and study in advance, don't pull an all nighter before an exam, because it'll negatively affect your memory, and your ability to do simple tasks, so you'll make many more mistakes, and it probably won't be worth it, unless you knew nothing going into the exam.

​

Read the textbook, lecture notes. Make sure you know the content, rereading, and highlighting are probably not going to do anything to help you. Lots of study techniques are a waste of time, even though a lot of people spend hours doing them. Make sure you _understand_ the context, because it will make it easier to remember. Dumb songs, acronyms and other mnemonic techniques will make things easier to remember, even if they sound stupid.

​

If you have a question, fucking ask, people may judge you, but it doesn't matter what they think, it matters that you understand the content. Lots of people who seem like they understand probably don't.

​

Don't spend too much time comparing yourself to others, everyone has their limits, their priorities etc, focus on completing goals so you'll leave college happy with how you did, and _what_ you did.

​

Social accountability is another powerful tool that will help you. If you can get your friends to be disappointed in you when you don't study properly, or do something you're supposed to do, it will be a massive deterrent against doing things poorly.

​

If you're interested in learning to master your memory, check out "Moonwalking with Einstein". Anyone can train their memory to memorize lots of things quickly, which can be useful for some classes (and less useful for concept based classes).

​

Learn how everything in a class connects, if you can do that, instead of having memorized one piece of information you'll have a web of things and how they relate to each other, making everything easier to remember, and sometimes you can use this web to derive a missing piece of information. I did disproportionately well on many exams, and I believe it was due to me focusing on understanding, and not memorizing problem solutions. Don't memorize the solution to lots of problems, learn how to read a problem and come up with an approach to tackle it.

​

Lots of people will be stumped when a problem is not 100% exactly the same as it was in homework, don't let that happen to you.

​

On exams, I always would flip through exams, do as much as I could until I got stuck, and move onto the next problem. I'd come back to that problem after it had some time to sit in my brain.

​

Studying weeks in advance a little bit everyday is 10x better than cramming last minute.

​

Do your homework, homework is studying (if you do it right).

​

Also, more important than pure grades:

lab/research experience, programming skills for data analysis and automation, friends (connections), internships (10x more important than grades for getting a job), letters of recommendation for grad school (from working with professors)

Also, set a schedule, and stick to it as much as you can, but don't let it prevent you from doing unexpected things with friends. Make as many things as possible into a routine, so you don't have to actively think about them, planning will help you stay ahead of the game, so you don't need to figure out what to do, you just do it.

​

Use time between classes wisely.

​

Don't hang out with people who are going to get you to do stupid things, and who don't have any ambitions, they _will_ drag you down with them. It doesn't matter if they are good people at heart.

​

And once again, use your time in college wisely, if it takes 10 hours a week to get a 3.5, and 30 hours to get a 4.0, just take the 3.5 and use the 20 hours to do research, join academic type clubs that will improve skills you want, it will send you farther in life.

​

Figure out the possibilities for what you want to do, and try to design life around them. If you want to go to medical school, have a backup plan. Just studying biology will f*ck you over if you don't get in.

​

Also, make sure you won't be graduating with an amount of debt you can't handle, it will literally ruin your life.

​

It doesn't matter if you went to Harvard if you have 200k in debt, you'll be paying 20k+ a year for the next 20 years.

​

Generally speaking, don't go over 50k in debt unless you have a very good reason, and a way to pay it off.

​

An english degree is probably never going to make it easy to pay off 100k in debt no matter where you went.

​

Once again, don't be too hard on yourself, you are in a top school, everyone around is mostly just as smart as you are, you are no longer the cream of the crop. You will not do as well as you did in high school (In all likelihood). That's okay, as I said, do your best, and plan for post college (or grad school), your grades matter less than you think in the long run.

​

Also, I suggest figuring out every class you want to take, and figure out a plan to take them. Maybe you'll see if you can dual degree or double major, it's much easier to do now than in a few years. Classes will get harder (probably).

​

You might consider taking a few classes in different disciplines in order to make sure you want to stay in your major, it'll make switching easier if you have a few classes done.

​

Or, consider doubling down and finishing your classes a year early so you can graduate, or maybe start taking graduate classes and do lots of research.

​

Good luck! :)

https://www.reddit.com/r/college/comments/996efz/how_to_get_40_or_at_least_37_plus/

[masterzii]

1000+ Programming PDFs

Since the 40+ PDF post was popular, I thought I'd share this. This list has been compiled with the help of hundreds of contributors- if you have anything to add, please do! I had this list bookmarked throughout college and it was a big help.

https://github.com/EbookFoundation/free-programming-books/blob/master/free-programming-books.md

And here is a free courses list also:

https://github.com/EbookFoundation/free-programming-books/blob/master/free-courses-en.md

https://www.reddit.com/r/learnprogramming/comments/7zku7u/1000_programming_pdfs/

[masterzii]

If you are making an RPG, you need to know the Sigmoid function. (Also important for any game dealing with probability, or any game where you want to scale something in relation to something else.)

Pic showing what the sigmoid function does

So you're designing your RPG combat system, and you think "I want this character's dexterity to affect the likelihood of this arrow hitting the target." How do you go about modeling that? How do you balance it?

There are lots of ways to do it, but my favorite approach is with a custom sigmoid function. Start off like this:

RawOdds = (1 + Skill) / ((1 + Skill) + (1 + Difficulty))

That way, you have a range that goes from nearly 0 to nearly 1. If skill == difficulty, the odds are 0.5. That's what we're going to call our raw odds.

Now let's say that you want to set a threshold. If your skill is below that threshold then the difficulty is much harder, but if your skill is above that threshold then the difficulty is much easier. Now we make our sigmoid function based on the raw odds we calculated earlier.

Using a sigmoid function to get your adjusted odds basically does this:

AdjustedOdds = 1 / (1 + (e ^ ((RawOdds * Steepness) + Offset)))

For the picture I posted above, Steepness is -10 and Offset is 5. To tweak the sigmoid function for your own use, recreate these formulas in Excel, make a chart, and play with the Steepness and Offset variables for a range of Skill and Difficulty that makes sense for your game, until the adjusted odds look right.

I use sigmoids to tweak the likelihood of an attack being blocked or dodged. You can use a sigmoid function in a game like XCOM to adjust the likelihood of a UFO invasion based on the time since the last invasion, so that you don't hit your players with invasions two days in a row or bore them with weeks of calm. I don't know what other examples you might think of, but in general, if you want a custom curve, see if a sigmoid would work.

https://www.reddit.com/r/gamedev/comments/96f8jl/if_you_are_making_an_rpg_you_need_to_know_the/

[masterzii]

A Guide to "Low Level" programming: learning how to make games from scratch

This post is my opinion -> saves me from harsh criticism

-Preface-

Game programming can often be some of the most grueling programming there is to implement. Unlike most applications, game programming at its best can push pc performance and memory to its limits. It requires a fine understanding of low level computing and an inane amount of code optimization strategies. It is also one of the most rewarding things to program. Not only have you created a virtual world all on your own, you've essentially become a programming wizard who has the knowledge to manipulate your computer to do as you bid. This is a long and difficult journey, if your goal isn't to become a PC wizard but instead just to make a small little game to send to friends then pick up a game engine like unity. It's simple and gets you running towards game creation quickly, no shame in that. But if you want to truly understand game development at its core then this guide is for you.

-step 1: learn C++-

This is non-negotiable. As much as people say you can use any language you want, you can't. You absolutely need to understand memory management and concepts like * (pointers) and & (references). high level languages like java do memory management for you and it is often slow and unreliable for game programming. Is it possible to program a game in java? Yes, absolutely, but it isn't beneficial towards your learning experience. When you eventually start to care about performance (it's far in the future but it will happen) you'll quickly realize how little you actually know about how computers manage memory. While it may be a little harder to pick up C++ over java, it'll be worth the time and effort

"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows off your whole leg" -Bjarne Stroustrup the creator of C++

"In C++ you could shoot yourself in the foot, so Java's solution is to cut off your legs and walk for you" - Anon, former java user

resources:

www.cplusplus.com - great tutorial for the most important aspects of C++ and a good std library resource

the crash course youtube videos on computer science explains a ton of basic principles on which computing is based off of... and they're fun to watch!

-step 2: API's aren't cheating-

In modern computing everything needs a driver. To stay commercially successful you need to make a driver for your hardware that supports the newest and most popular OS's. So how can other programmers program these device's? through Application Programming Interfaces (API). These libraries do the super low level code so we can program the hardware without knowing 100% how it works. THIS IS OKAY. When I first started learning programming I was frustrated and confused when I found out I couldn't just put a pixel to the screen but instead I had to use someone else's library. Now I know that because a GPU involves millions upon millions of different transistors it would be a HUGE waste of time if I tried to write pure code to be read by the GPU, so API's are really a great thing and they won't limit you at all. But what API should you pick up first? A little library called SDL (2D focused game framework). Now this might be a bit of a cheat because this library is a framework, meaning it handles most of the rendering, window creation, and inputs so it's not really a driver more like an extra layer above the driver. The reason I recommend SDL is because the next step after learning C++ shouldn't be learning low level API's like DIRECTX or OPENGL. Instead this is where you should refine your coding structure, organization and techniques.

resources:

https://wiki.libsdl.org/APIByCategory just read the SDL functions and mess around with them (most important are SDL_Renderer and SDL_Window)

www.gameprogrammingpatterns.com This is a little online e-book that teach some amazing programming design techniques for not only speed but code organization (this one helped me out A TON)

-step 3: more API's-

this next step depends on you. There are a bunch of different API's to learn to get into more low level programming when you're ready to move on out of SDL and 2D game programming. First you need to pick up the basic OS API. for windows this is going to be WIN32 and for OSX it'll be Cocoa. These interfaces let you interact with the operating system to create windows, get inputs, and make basic event driven applications. once you have that done (and it doesn't really take too long) you can move on to the heavy hitters, 3D rendering API's. Technically you can also render 2D using these API's but there main focus is on efficient 3D rendering. Now, DO NOT START WITH DIRECTX12 OR VULKAN. these are really low level API's made for the pros. they are hard to learn and require a deep understanding of how 3D rendering works. We want to start off with something much more tame (but still crazy efficient), DIRECTX11 (DIRECT3D11 to be specific) and OPENGL. These bad boys were made with us beginners in mind (kind of, not really though). They still take a lot of patience and practice to get down but they aren't nearly as complex as the former 3D API's.

resources:

www.winprog.org is a great little win32 crash course. simple and easy

I don't like cocoa, just stick with SDL but use OpenGL for rendering instead of the standard SDL_Renderer

Directx is a pain to learn but it's slightly faster on windows compared to OpenGL on windows. A lot of resources are deprecated because they keep up bringing in new stuff to the API but Practical Rendering & Computation with Direct3D11 by Zink, Pettineo, and Hoxley is a great book (for the time being) to pick up somewhat current Direct3D

https://learnopengl.com is a great resource for getting into OpenGL and is super easy and shows quick results. FREE!

And that's my guide... kind of emaciated but programming is so broad that I can't lay everything out, here are just some top picks from personal experience. Hell I'm still going through this magical PC wizard journey and I'm still having trouble learning 3D rendering but hey, I'm sure some of my experience will help someone

TL;DR - this is a guide on learning programming: if you didn't have the patience to sit through the post then I can't really help ya any. sorry :(

note: as many people have mentioned in the comments, math and theory are king. this guide was more of a beginners guide to programming syntax and some theory. there is a lot of mathematics in computer programming (especially 3d rendering) so don't skimp out on 'em.

edit: spelling and grammar and note

https://www.reddit.com/r/gamedev/comments/96ce29/a_guide_to_low_level_programming_learning_how_to/

[masterzii]

What I really needed to know to get a job as C++ software developer on Linux

You have tried programming, and you’ve liked it. Now, you want to become a software developer, but you don’t know where to start or what to learn. You’ve asked and read forums, but everyone gives you different answers. They give you a huge list of operating systems (OS), languages, libraries, algorithms, databases, and tools. They use many acronyms most of which you haven’t even heard of. It is intimidating, and it is easy to end up overwhelmed and discouraged with no idea of how to proceed. Can you really go from learning C++ and Linux as a hobby to making a living as a software developer? Does it really take all of that knowledge?

I’m writing this post to help provide guidance as to what you actually need to know to get a job as a software developer based on my experience. I learned C++ and Linux as a hobby, and after deciding that I wanted to do it for a living, I made the transition and became a software developer. In this post, I concentrate on what I needed to know to get an entry-level job and to be successful at it. Armed with the basic knowledge listed here, you also should be able to get an entry-level job, perform it well, and continue to learn to advance your career, just as I did. People, companies, jobs, and situations are different, of course, so I can’t guarantee that anyone will get a job. I can only speak to my experience and what I believe helped me achieve my goal. With that said, here is what I actually needed to know:

C++

I needed to know C++, of course. However, C++ is a very extensive language, and there is a lot to know. The good news is that I didn’t need to know everything. I only needed to know key portions of the language, but I needed to know them well. First, I had to know the basics: types, declarations, pointers, arrays, expressions, statements, branching, loops, and functions. Particularly, I had to understand and be able to use pointers and arrays. Nowadays, they shouldn't be used much since smart pointers and containers from the C++ Standard Library should be used instead. However, you are likely to run into them in code from other developers, in legacy code, or in interview questions, so best be prepared as they can be a little intimidating at first, especially pointers. Then, I needed to know classes and polymorphism, not just their proper syntax, but also I had to understand when and how to use them. This implies some familiarity with Object Oriented Design and Programming (OOD/P), mainly a good understanding of what constitutes a good object, including orthogonal attributes and encapsulation. Understanding the importance of interfaces and encapsulation, not only for classes but for libraries as well, is very valuable. Knowing the different relationships between objects was also important, including inheritance and composition but also one-to-one, one-to-many, many-to-many, etc. As for the C++ Standard Library I needed to know containers (vector, list, map, etc.), iterators, and smart pointers. Additionally, familiarity with what algorithms are included in the library was important. I didn’t need to be familiar with each one, but I needed to know that they existed so that I could look them up when I needed them. Of course, I needed enough knowledge of templates to understand how to use what I just mentioned of the C++ Standard Library.

Basic data structures and algorithms

Programming is all about storing, searching, manipulating, and transferring data, and most programs depend on a few algorithms and data structures that have already been invented. The trick is to know what is available and how to choose among the alternatives. Different problems require algorithms and data structures with different characteristics, and it is very important to be able to select the most appropriate combination to solve a particular problem. These are the ones I needed to be familiar with: linear search, binary search, quicksort, growing arrays, lists, trees, and hash tables. Basic understanding of how they work and their properties was important, but in practice, I didn't need to program them since the C++ Standard Library provides excellent implementations.

Concurrency

Multithreading and synchronization were some of the most important concepts that not only were covered during the interview process, but were also used in just about every major product that I have worked on since. For this subject, I needed an understanding of the concepts as well as when and how to use them. I needed to know threads, their advantages and disadvantages, and synchronization mechanisms, mutexes and condition variables. In addition, I needed to know possible common problems related to threads: races, deadlocks, and priority inversion as well as how to avoid them. Also, concurrency features were introduced in C++11, so it is not longer required to become familiar with OS Thread APIs. It is only necessary to learn the C++ concurrency features already mentioned.

How to write programs to solve problems

Most companies ask to write at least one program during interviews. In fact, it is not uncommon to have to write three or more programs, so it is critical to develop good problem solving skills. Note that I used the word “develop,” because like any other skill, it can be learned and improved. Even if you are already good at it, practice is important since an interview is usually a high pressure environment with time constraints. It is a test, and like anyone who has taken a test knows, it is not just about knowing the material. It requires preparation because things like tools, time, and pressure affect performance.

Programming experience

Yes, I needed programming experience before getting a software developer job. How did I get it? I wrote code. I implemented many of the algorithms mentioned above from scratch. I created my own projects such as a program to page me when a stock reached a given price or a program to send data between two computers using Sockets. I came up with programs that used what I was learning or reading about. Sometimes they were useful but sometimes they were just for fun, like a chess clock, and sometimes their only purpose was to learn, like implementing a singly-linked list. Of course, a real project at work or for someone who needs it is even better, but even to get those you will need experience. Therefore, my advice is write code; write lots of programs. It is the only way to learn and to acquire the required experience.

Become involved and help others

Linux was first a hobby for me. Eventually, I started attending a Linux User Group. I helped create a Linux curriculum. Once a month, I would spend an evening helping people with anything from installing the OS and making drivers work to explaining the basic shell commands. I prepared and gave presentations on the weekly meetings, and I helped preparing educational material for the club’s website. The point is that by becoming involved in the community and helping others use and learn Linux, I learned even more myself. In fact, I became an expert while having lots of fun and getting to know great people many of whom were already working in the field and became friends and valuable connections.

Talk to developers

Talking to software developers was a great way to find out how their companies work and what technologies they were using. It helped me select what to focus on and what to improve. I recommend that you talk to developers at user groups, conferences, meetups, online or anywhere else you can find them. Ask questions and learn all you can about their companies, their work, and the technologies they use. This is also a good way to make valuable connections; it may even result in a job opportunity.

Showcase relevant skills

When I was searching for a job, I created a website in which I included programs and HOWTO articles that I had written, and I added the URL at the top of my resume. They were not many, but enough to showcase some of the relevant skills that I had. When I was hired, my manager mentioned that he had looked at my webpage, and it had influenced his decision to hire me. I recommend that you do something similar. Make sure your programs are well-written and easy to understand. Remember that prospective employers will be looking at them.

How to use the Linux programming environment

Finally, I had to know Linux day-to-day common commands, files and directories, file system (permissions and directory hierarchy), basics of using the shell, and a few filters: find, grep, sort, and sed. Having basic knowledge of Linux and its design, the kernel and the shell, how processes run and interact with each other, and how to monitor their resources, CPU and memory usage for example, provided me with an advantage and enabled me to design, code, and debug better and faster. The many free and powerful filters and data processing tools included with Linux helped easily automate tasks and analyze data. Knowing the Linux programming environment was important in getting my job done efficiently, and I believe that it was key to my success.

As I mentioned at the beginning, this illustrates only my experience, but I hope that it helps you on your quest to become a software developer and to enjoy it and prosper once you do. Good luck!

https://www.reddit.com/r/cpp/comments/655p69/what_i_really_needed_to_know_to_get_a_job_as_c/