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.