Answers To All The Questions I Asked As A Kid

When I was growing up and trying to figure out what was going on in this crazy planet I was born on, there were several important questions I asked that took many, many years to find answers to. What was frustrating is that almost every single answer was usually extremely obvious once I could just find someone who actually knew what they were talking about. So here are the answers to several simple life questions that always bugged me as a kid, based on my own life experiences. Many people will probably disagree with one or two things here, which is fine, because I don't care.

1. What is the purpose of Math?

Math is simply repeated abstraction and generalization. All of it. Every single formula and rule in mathematics is derived by generalizing a simpler concept, all the way down to the axioms of set theory. It was invented to make our lives easier by abstracting away annoying things. Why count from 2 to 6 when you can simply add 4? Adding is simply repeated counting, after all. But then, if you can add 4 to 2 and get 6, you should be able to generalize it so you can add 4 to 2.5 and get 6.5, and what about adding 2 to 4 over and over and over? Well that's just multiplication. What about multiplying 2 over and over and over? Well that's just exponentiation. What's that funky Gamma Function I see every now and then? That's simply the factorial ($5! = 5\cdot 4\cdot 3\cdot 2\cdot 1$) generalized to real and complex numbers, so it can evaluate 5.5!, its just written Γ(5.5 - 1) = Γ(4.5). Math is generalization.

Usually smart people figured all the generalizations out for you, so in some cases you can simply memorize a formula or look it up, but its much easier to simply remember the rules that the smart people figured out for you so you can rederive everything you need without having to memorize it. When you understand the rules (which are all carefully constructed to be consistent with each other), you can then use Mathematics as a language to express problems in. By abstracting the problem into mathematics, the answer becomes much easier to obtain. The only thing math does is make thing easier to do by abstracting them. That's all.

2. Why does college think high grades in math correspond to programming ability?

This is because programming is math. Programming is all about abstracting a problem to automate it. Think of it as a lingual descendant of Math. The problem is that in high school they teach you calculus and programming at the same time and try to tell you that they are related. They aren't. Calculus doesn't have anything to do with programming. Set Theory does. The mathematical constructs of logic are what programming derives from, not calculus. Naturally, they don't teach you any of that. Even though you can consider programming a sub-discipline of mathematics, ones programming ability is not connected to your test-taking abilities.

3. How do you compose music?

First, you come up with a melody. The best way to do this is to find a song you like, and figure out its melody. Knowing basic music theory will help, because then you know what a chord progression is, so you can find that too. Simply rip off all the common chord progressions you like - you'll come up with your own later. Rhythm is important too, so take note of that - be careful to focus on notes that seem to carry the beat.

Great, that was the easy part. But how do you make techno music? How do you record things? How does it get on a computer? All I have is this stupid electric piano I can record things off of, there has to be a better way! The answer is DAWs and VSTi, or Digital Audio Workstations and their virtual instrument plugins. A great DAW to start with is FL Studio, and there are a lot of free VSTi plugins floating around. VSTi plugins are simply synths or effects or other tools that you drop into your DAW and use to play notes or modify the sound. If you want natural sounding instruments, use samples. Soundfonts are widely supported, have an extension .sf2 and there are gigabytes upon gigabytes of free samples everywhere. You should try to hunt down an independent artist whose music you like, they'll often be willing to give on advice on how they create their style.

But now I've made a song, where do I post it? Soundcloud, newgrounds, last.fm, and bandcamp lets you sell it for moneys. Don't worry if you're terrible, just keep doing it over and over and over and paying attention to advice and constructive criticism.

4. How do you draw clean art?

Clean digital art is commonly done using vectorization and gradients. There are multiple photoshop techniques that can be combined with tablets to create very nice looking lines by doing fake-tapering and line adjustments, but more commonly the tablet is simply pressure sensitive. There are many different techniques for doing various styles, so its more appropriate to ask the artist themselves.

5. Why do adults kiss?

I say instinct but no one really knows yet (only 90% of humans kiss). Provided you are in a culture that does kiss, you'll grow up to be around 16-17 and suddenly you'll feel this inexplicable urge to kiss whomever you've fallen in love with for no apparent reason. It's theorized to have arisen due to needing to evaluate certain proteins in a potential partner, which requires physical contact, along with various other things. I say instinct because I always thought it wasn't instinct and I wouldn't fall for it and then why am I fantasizing about kissing girls CRAP.

6. Why do adults fall in love in the first place?

Instinct. By the time you are 20, if you haven't yet found an intimate partner, you will feel crushing loneliness regardless of how many friends you have. Do not underestimate just how badly Nature wants you to have babies. This is why people get desperate - the desire to be in an intimate, loving relationship can be extremely powerful. It also leaves a giant hole that often explains various other bizarre things adults do in apparent attempts to kill themselves in the most amusing way possible.

7. Why don't popular people respond to fan mail very often?

This usually only comes up if you are using a bad medium. Artists often want to talk to their non-retarded fans, but the majority of people are incredibly stupid (see below), and thus in certain cases the signal-to-noise ratio is so high they simply can't justify spending the time to find you in a sea of insane idiocy when they have better things to do, like be awesome. Some artists simply don't want to be bothered, and this is usually the result of being disillusioned with how utterly stupid most people are, so it's hard to blame them, but unfortunate. Usually there will be a way to at least throw a meaningful thank you to the artist, possibly by e-mail or twitter if you look hard enough, and they will always appreciate it if they can just find your message. Never assume an artist is too stuck up and full of themselves to answer you. They just can't find you. Although quite a few of them actually are assholes.

8. Why is everything I do always wrong?

Because people are idiots and have no idea what they're talking about. Only ever listen to someone telling you that you are doing something wrong if you know they have extensive experience in exactly what you are trying to do. Otherwise, take the advice with a mountain-sized lump of salt, because people in specialized professions almost always take advice out of context and inappropriately simplify it to the point of it actually being completely wrong. There is always a catch. This is taken up to eleven in programming - I once had someone who did networking tell me my choice of language for my graphics engine was completely wrong and insisted I was so bad at programming I should just stop, because it would make the world a better place. He is an asshole, and he is completely wrong. Don't listen to those people, ever.

9. Why does everyone call everyone else an idiot?

BECAUSE EVERYONE IS AN IDIOT. Trying to comprehend just how unbelievably stupid people can be is one of the most difficult things to learn while growing up. It's far too easy to disregard someone as evil when in fact they really are that dumb. "Never attribute to malice that which is adequately explained by stupidity" - Hanlon's Razor. The best you can hope to do is dedicate your life to not being an idiot in your choice of profession and don't think it makes you qualified to give advice on vaguely related fields (see networking programmer above).

10. Why do adults argue about everything?

Because they are 10-year-olds that have to pay taxes, and nobody really knows how to pay taxes properly. They don't know what they're doing. Common sense is not common, people are not rational, and people are idiots. They don't care if they're wrong, and they don't care if you're right. They just don't care, because life sucks, and life isn't fair, and they didn't get the memo until after they wasted their youth either being too drunk to remember anything, or studying in a library all day to get a useless scrap of paper.

Do something that matters to you, and know this: Life isn't fair, so you have to make it fair. You have to do things the hard way. You have to fail miserably hundreds of times and keep on trying because you aren't going to let life win. You have to do what matters to you, no matter what anyone else thinks. You have to fight for it, and you have from now until you die to win. Go.

Cheat Codes

1. If you don't know how to properly socialize with someone, ask them about themselves. There is nothing people love more than talking about themselves.
2. If you like programming, bury yourself in it. It is, by far, the most useful skill you can have right now.
3. Read the instructions.
4. Bunnies make everything better =:3

Properly Dreaming About Success

"We are what and where we are because we have first imagined it." - Donald Curtis

The wisdom of antiquity suggests that we must first imagine what we want to achieve if we are ever to succeed, but science has other ideas. A study demonstrated that visualizing yourself reaching a goal tricks your brain into thinking you actually did it, causing a relaxation response, which in turn robs you of ambition and energy.

This is a troubling counter-argument to age-old wisdom, but perhaps both sides can be right? I have been relentlessly pursuing the same goal for many years, and from my experience, it matters what you visualize just as much as if. In particular, one should imagine what you are actually trying to create, rather than what you would do with all your riches.

By coupling your imagination to your problem solving skills, you can draw a line between where you are now and what you need to do to make your vision come to life. This both solidifies your goals, highlights potential problem areas and outlines a clear plan of action, which helps prevent procrastination caused by not knowing what to do. Simply imagining that we are living the high life after hitting the big time, however, merely drains us of ambition by creating a false sense of accomplishment. You must visualize your finished creation, not the act of finishing it.

There is a marvelous, unspeakably beautiful thing that wanders around in my subconscious. Every now and then I am given another glimpse, or shown another spark of inspiration of this indescribable vision that seems so real and yet could not possibly be written about, because nothing like it has ever existed. It's like looking into a future that could arrive tomorrow if only I could bring it to life. Sometimes I wonder if I'm losing my way, only for something else to trigger another magnificent concept. It shows me why I can never give up, even it if takes me an eternity to craft my thoughts into a new reality.

Your imagination is a tool, and like any other, it can be used or abused. Wield it wisely.

Multithreading Problems In Game Design

A couple years ago, when I first started designing a game engine to unify Box2D and my graphics engine, I thought this was a superb opportunity to join all the cool kids and multithread it. I mean all the other game developers were talking about having a thread for graphics, a thread for physics, a thread for audio, etc. etc. etc. So I spent a lot of time teaching myself various lockless threading techniques and building quite a few iterations of various multithreading structures. Almost all of them failed spectacularly for various reasons, but in the end they were all too complicated.

I eventually settled on a single worker thread that was sent off to start working on the physics at the beginning of a frame render. Then at the beginning of each subsequent frame I would check to see if the physics were done, and if so sync the physics and graphics and start up another physics render iteration. It was a very clean solution, but fundamentally flawed. For one, it introduces an inescapable frame of input lag.

Single Thread Low Load
  FRAME 1   +----+
            |    |
. Input1 -> |    |
            |[__]| Physics  
            |[__]| Render    
. FRAME 2   +----+ INPUT 1 ON BACKBUFFER
. Input2 -> |    |
. Process ->|    |
            |[__]| Physics
. Input3 -> |[__]| Render
. FRAME 3   +----+ INPUT 2 ON BACKBUFFER, INPUT 1 VISIBLE
.           |    |
.           |    |
. Process ->|[__]| Physics
            |[__]| Render
  FRAME 4   +----+ INPUT 3 ON BACKBUFFER, INPUT 2 VISIBLE

Multi Thread Low Load
  FRAME 1   +----+
            |    |
            |    |
. Input1 -> |    |
.           |[__]| Render/Physics START  
. FRAME 2   +----+        
. Input2 -> |____| Physics END
.           |    |
.           |    |
. Input3 -> |[__]| Render/Physics START
. FRAME 3   +----+ INPUT 1 ON BACKBUFFER
.           |____|
.           |    | PHYSICS END
.           |    |
            |____| Render/Physics START
  FRAME 4   +----+ INPUT 2 ON BACKBUFFER, INPUT 1 VISIBLE

The multithreading, by definition, results in any given physics update only being reflected in the next rendered frame, because the entire point of multithreading is to immediately start rendering the current frame as soon as you start calculating physics. This causes a number of latency issues, but in addition it requires that one introduce a separated "physics update" function to be executed only during the physics/graphics sync. As I soon found out, this is a massive architectural complication, especially when you try to put in scripting or let other languages use your engine.

There is another, more subtle problem with dedicated threads for graphics/physics/audio/AI/anything. It doesn't scale. Let's say you have a platformer - AI will be contained inside the game logic, and the absolute vast majority of your CPU time will either be spent in graphics or physics, or possibly both. That means your game effectively only has two threads that are doing any meaningful amount of work. Modern processors have 8 logical cores¹, and the best one currently available has 12. You're using two of them. You introduced all this complexity and input lag just so you could use 16.6% of the processor instead of 8.3%.

Instead of trying to create a thread for each individual component, you need to go deeper. You have to parallelize each individual component separately, then tie them together in a single-threaded design. This has the added bonus of being vastly more friendly to single-threaded CPUs that can't thread things (like certain phones), because the parallization goes on at a lower level and is invisible to the overall architecture of the library. So instead of having a graphics thread and a physics thread, you simply call the physics update, then call the graphics update, and inside each physics and graphics update you spawn enough worker threads to match the number of cores you have to work with and concurrently process as much stuff as possible. This eliminates latency problems, complicated library designs, and it scales forever. Even if your initial implementation of concurrency won't handle 32 cores, because the concurrency is encapsulated inside the engine, you can just go back and change it later without ever having to modify any programs that use the graphics engine.

Consequently, don't try to multithread your games. It isn't worth it. Separately parallelize each individual component instead and write your game engine single-threaded; only use additional threads for asynchronous activities like resource loading.

¹ The processors actually only have 4 or 6 physical cores, but use hyperthreading techniques so that 8 or 12 logical cores are presented to the operating system. From a software point of view, however, this is immaterial.

IP Law Makes You an Asshole

I haven't had a very good relationship with IP law. My 2 favorite childhood game franchises - Descent and Freespace, were thrown into IP limbo after Interplay shot itself in the foot too many times and finally fell over. As a result, I have come to utterly despise the common practice of publishers simply taking the IP of the developers for themselves, and in a more broad sense, forcing artists to give up their ownership on everything they make for a company. This becomes especially painful when they aren't just making silly UI art, but creating a universe filled with lore and character and spirit, only to watch corporate meddling turn their idea into a wretched, free-to-play money-grubbing disaster.

What can the artist do? Exactly nothing. Under current IP law, the company usually owns all rights to everything the artist does for them, no matter what. If it doesn't, it's because the company screwed up its legal contracts, which is dangerous for both you and the company. There is essentially no middle ground. That means an artist can't sue the company for screwing up their idea, because it isn't their idea anymore. They can't take it to another studio or even work on their own idea without permission from the company. It makes about as much sense as a company saying they own the rights to your startup idea because you came up with it at work one day and wrote a prototype during break. That isn't just hypothetical, either, it's a disturbingly common problem.

This is not beneficial to companies, either. Artists are increasingly aware of how little control they have over their own work. A paranoid artist who gets a great idea will be unwilling to tell anyone at the company about it until after they've been working on it in secret, distracting them from what they're supposed to be working on and making them uncomfortable and stressed. They'll worry about what will happen if they try to take the idea somewhere else and no one likes it. They could lose their only job. But if they tell anyone about the idea inside their current company, they risk losing all rights to it and then having the company decide it doesn't like the idea and burying it forever, killing the artists brainchild without any hope of resuscitation. What's worse is that an artist is just about as far from a lawyer as you can get - they have absolutely no idea how any of this stuff works and what they can or cannot do, so they tend to either screw up immediately and lose all rights to their idea or tell no one about it, ever. Your company will essentially lose an employee for months as they succumb to stress, and you might never even know about their idea because they're too paranoid about you stealing it.

So what would good handling of IP be? A more fair agreement would give the company nonexclusive rights to use ideas the artist comes up with. The company only maintains nonexclusive rights to partially or completed work the artist created while employed at the company if the artist decides to quit, not the idea itself. It can even attempt to finish partially completed work, but the artist still retains the right to take his idea elsewhere. This is a compromise between ensuring a company can use everything an artist makes for them while employed without restriction, and ensuring that the artist can still walk out with his idea and bring it to life on his own or at another company. For game development companies, there would clearly need to be a clause protecting the companies right to finish a project if the lead designer leaves.

It seems reasonable to approximate this by assigning permanent nonexclusive rights to the company instead of exclusive rights, but things get complicated very quickly. If you don't own all the rights to a copyrighted material, you can get sued if you modify the original even if you have permission to use it. It's possible such situations could also occur with IP assignments, especially when you are specifically allocating certain nonexclusive rights in certain circumstances but not in others, or revoking certain rights upon termination. If an artist leaves a company in the middle of making a game, they shouldn't be able to sue the resulting game because it used their old art, or even created new art based off their old art. Likewise, a company shouldn't be able to sue an artist if they leave and create a game on their own using their idea even if the company had already released a game based on it. How one would achieve this, I have no idea. It gets even murkier when an idea is the collaborative effort of multiple people. Who owns what part? If one person leaves, the company must still retain the right to use his ideas and ideas based off his ideas, and he should only retain the right to use his own ideas, but not everyone else's ideas or ideas based off everyone else's ideas. What happens when they live in another country?

Because of the vast complexity of this issue, most companies say "fuck it" and simply assign all rights to themselves. This is standard advice from lawyers. The mentality is that you don't have time to worry about silly little legal issues with artists. The problem is that it erodes artists' rights, which are already disturbingly emancipated. This is unacceptable.

I'm not a lawyer. I don't know how to fix this. I don't know if it can be fixed. I don't even know how to properly assign IP to my own company or write a contract. All I know is that artists are getting screwed over because IP law makes everyone an asshole.

Obligatory legal crap: The information provided in this blog is not intended as legal advice.

Stop Following The Rules

The fact that math, for most people, is about a set of rules, exemplifies how terrible our attempts at teaching it are. A disturbing amount of programming education is also spent hammering proper coding guidelines into students' heads. Describing someone as a cowboy programmer is often derisive, and wars between standards, rules and languages rage like everlasting fires. It is into these fires we throw the burnt-out husks that were once our imaginations. We have taken our holy texts and turned them into weapons to crush any remnants of creativity that might have survived our childhood's educational incarceration.

Math and programming are not sets of rules to be followed. Math is a language - an incredibly dense, powerful way of conveying ideas about abstraction and generalization taken to truly astonishing levels. Each theorem is another note added to a chord, and as the chords play one after another, they build on each other, across instruments, to form a grand symphony. Math, in the right hands, is the language of problem solving. Most people know enough math to get by. It's like knowing enough French to say hello, order food, and call a taxi. You don't really know the language, you're just repeating phrases to accomplish basic tasks. Only when you have mastered a certain amount of fluency can you construct your own epigraphs, and taste the feeling of putting thoughts into words.

With the proper background, Math becomes a box of legos. Sometimes you use the legos to solve problems. Other times you just start playing around and see what you can come up with. Like any language, Math can do simple things, like talk about the weather. Or, you can write a beautiful novel with words that soar through the reader's imagination. There are many ways to say things in Math. Perhaps you want to derive the formula for the volume of a sphere? You can use geometry, or perhaps calculus, or maybe it would be easier with spherical coordinates. Math even has dialects, there being many ways of writing a derivative, or even a partial derivative (one of my professors once managed to use three in a single lecture). As our mathematical vocabulary grows, we can construct more and more elegant sentences and paragraphs, refining the overall structure of our abstract essay.

Programming too, is just a language, one of concurrency, functions and flow-control. Programming could be considered a lingual descendant of Math. Just as English is Latin-based, so is programming a Math-based language. We can use it to express many arcane designs in an efficient manner. Each problem has many different solutions in many different dialects. There's functional programming and procedural programming and object-oriented programming. But the programming community is obsessed with solving boring problems and writing proper code. Too overly concerned about maintainability, naming conventions and source control. What constitutes "common sense" varies wildly depending on your chosen venue, and then everyone starts arguing about semicolons.

Creativity finds little support in modern programming. Anything not adhering to strict protocols is considered useless at best, and potentially damaging at worst. Programming education is infused with corporate policy, designed to teach students how to behave and not get into trouble. Even then, its terribly inconsistent, with multiple factions warring with each other over whose corporate policies are superior. Programming languages are treated more like religions than tools.

The issue is that solving new problems, by definition, requires creative thinking. Corporate policy designed to stamp out anything not adhering to "best practices" is shooting itself in the foot, because it is incapable of solving new classes of problems that didn't exist 5 years ago. Companies that finally succeed in beating the last drop of creativity out of their employees suddenly need to hire college graduates to solve new problems they don't know how to deal with, and the cycle starts again. We become so obsessed with enforcing proper code etiquette that we forget how to play with the language. We think we're doing ourselves a favor by ruthlessly enforcing strict coding guidelines, only to realize our code has already become irrelevant.

We need to separate our mathematical language from the proof. Just as there is more to English than writing technical specifications, there is more to Math than formal research papers, and more to programming than writing mission-critical production code. Rules and standards are part of a healthy programming diet, but we must remember to take everything in moderation. We can't be so obsessed with writing standardized code that we forget to teach students all the wonderful obscurities of the language. We can't be telling people to never use a feature of a programming language because they'll never use it properly. Of course they won't use it properly if they can't even try! We should not only be teaching programmers the importance of formality, but where it's important, and where it's not. We should encourage less stringent rules on non-critical code and small side projects.

In mathematics, one never writes a proof from beginning to finish. Often you will work backwards, or take shortcuts, until you finally refine it to a point where you can write out the formal specification. When messy code is put into production, it's not the programmer's fault for being creative, it's the idiot who didn't refactor it first. Solving this by removing all creativity from the entire pipeline is like banning cars to lower the accident rate.

Corporate policy is for corporate code, not experimental features. Don't let your creativity die. Stop following the rules.

The Standards Problem

When people leave the software industry citing all the horrors of programming, it confuses me when they blame software development itself as the cause of the problems. Programming is very similar to architecture - both an art and a science. The comparison, however, falls apart when you complain about architecture and buildings having all these well-established best practices. The art of making buildings hasn't really changed all that much in the past 50 years. Programming didn't exist 50 years ago.

The fact is, we've been building buildings for thousands of years. We've been writing programs for around 40, and in that period we have gone from computers the size of rooms to computers the size of watches. The instant we establish any sort of good practice, it's bulldozed by new technology. Many modern functional programming languages had to be updated to elegantly handle concurrency at all, and we've only just barely established the concept of worker threads for efficiently utilizing 4-8 cores as we step into the realm of CPU/GPU collision and the advent of massively parallel processing on a large scale, which once again renders standard concepts of programming obsolete. The fact that software runs at all is, quite simply, astonishing. Windows still has old DOS code dating back to the 1980s having repercussions in Windows 7 (You can't name a folder "con" because it was a reserved device name in DOS). If they were to completely rewrite the operating system now, it'll be completely obsolete in 20 years anyway and we'd be complaining about NT's lingering 32-bit compatibility issues and old functions not being threadsafe on a 128 core processor and problems I can't even predict.

Standards can't exist if we can't agree on the right way to do things, and in software development, we can't agree on the right way to do things because nobody knows (and if someone tells you they know, they're lying). Just as we all begin to start settling down on good practices, new technology changes the rules again. This further complicates things because we often forget exactly which parts of the technology are changing. There's a reason you write a kernel in C and not F#. Our processor architecture is the same fundamental concept it was almost 30 years ago. Ideally we would have moved away from complex instruction sets now that nobody uses them anymore, but we haven't even done that. Language fanboys forget this and insist that everything should be written in whatever their favorite language is, without having any idea what they're talking about. This results in a giant mess, with literally everyone telling everyone else they're doing it wrong.

That's the software industry today. It's where everyone says everyone else is wrong, because we have no goddamn idea what software development should be, because what software development should be keeps changing, and its changing so rapidly we can barely keep up, let alone actually settle on a bunch of standards. Instead, individual groups standardize themselves and you get a bunch of competing ecosystems each insisting they are right, without observing that they are all right at the same time - each standard is built to match the demands of not only where, but when it is being used.

Luckily, I don't program because I want to write programs all day. I program because I want to build something magnificent. If you make a living programming for a bunch of clients that try to tell you what to do and always say it should be faster and cheaper, well, welcome to being an artist.