About a year ago on a thread on Google Buzz (RIP) I wrote a quick definition of  ”positive feedback” and “negative feedback” in terms of their technical, systems design meaning. I figured I would repost it here, since every now and then someone asks me what it is and I search my email to copy/paste it. It’s pretty slapdash but it gets the point across, and people have found it useful. So… here you go, internet.

In short: negative feedback is a system that regulates itself. Think of a thermostat. You set it to a certain temperature T. If the house goes above T, it instructs the systems to cool the house. If the house goes below T, it instructs systems to heat the house.

Positive feedback is where things are reinforced and amplified. Imagine a thermostat that cranks the house hotter when the temperature is above T, and makes it cooler when it’s below T.

The main difference is that in the first example, the temperature will tend to remain at T. In the second example, it is highly unlikely the temperature will be T, and in fact it will trend towards either very hot or very cold.

The simplest example of negative versus positive feedback in game design that I can think of is possession rules in 1-on-1 pickup basketball. A negative feedback rule is something like, “If I score a basket, you get to start with the ball.” By giving an advantage to the loser, you’re evening the playing field a bit and bringing the temperature back down to T, so to speak. A positive feedback rule would be, “Winner keeps the ball.” This means winners tend to keep winning, making the house hotter and hotter.

Randy Smith likes to use Mario Kart as an example of a game with strong negative feedback: items like the Blue Shell cause people in the winning position to be at a disadvantage so those behind can catch up. This is also colloquially known as a “rubber banding” mechanic.

Mainly this is in stark contrast to the other way the terms “positive feedback” and “negative feedback” are used in game design: to signify something positive given to the player (reward) or something negative given to the player (punishment). “Feedback” in general can refer to either feedback loops like I describe, or to the general concept of “giving information to the player about the results of their actions.” I would vastly prefer if we started disambiguating the two usages. I’d like “feedback” to retain the meaning I sketch above, which is probably due to my bias as someone trained as an electrical engineer!

Any suggestions out there for a word other than “feedback” that would describe “giving information to the player about the results of their actions”? Or, hell, a different word for “systems whose outputs determine their future inputs” (which is what I describe in my examples above)?

(Edit: “reinforcement” has been variously suggested here and on Twitter for EITHER kind of feedback. See my comment below on why I think it’s only suitable for the “giving information” kind.)

I was planning to do this anyway, but then Zack Hiwiller beat me to it and I got all jealous. Here’s a list of some of my favorite games that came out in 2011 (or at least the ones I thought of on my lunch break).

• Murder Dog IV: Trial of the Murder Dog. I wrote at Paste Magazine about why I like it.
• Crime Zone. Another game by the creator of Murder Dog, this is primarily an exploration of the psychogeography of a member of a police squad that enforces the will of a totalitarian state. For real.
• Deus Ex: Human Revolution. It doesn’t innovate over the original Deus Ex. It’s pretty much the same game except not quite as good. I am completely okay with that because I’m a shameless DX fan.
• Skyrim. This took me by surprise. I found Oblivion really boring, but I very much liked Fallout 3. I typically hate fantasy genre stuff. But I’ve logged about 40-50 hours in Skyrim, and keep coming back to it.
• Vertex Dispenser. I wrote about this game as well. (It’s 50% off right now at Steam!)
• Frozen Synapse. It’s the squad based battle planning stuff I love from Jagged Alliance 2. Runs like a dream under Wine on Linux, too. I had fun with this.
• Soul Brother. Hands-down my favorite browser-based game of the year. Incredible soundtrack.

Unfortunately, most of the other games I enjoyed this year technically have not been released yet so I can’t talk about them here. Oh the trials of being an IGF judge and Indiecade-attending-person.

The unreleased game that stands out the most in my mind is Johann Sebastian Joust, which I played with my coworkers at our holiday party last weekend. Here’s a video of a test run:

Playing Joust at Bocoup from maryrosecook on Vimeo.

I spent $200 on four PS Move controllers to play this (I don’t own a PS3) and IT WAS TOTALLY WORTH IT.

I made a little game-like thing called “At Dawn” for the Boston Game Jams HTML5 game jam that ran this past weekend.

The theme for the jam was “Dawn.” I didn’t have time to attend for the whole weekend, so instead of making a game I just messed around with building a pixelated sunrise. I built most of the thing in GameMaker HTML5 (which incidentally now has the non-obfuscated debug mode I was asking for!). I say “most of” because I put the music in by hand.

The music, by the way, is from the amazing DoKashiteru, and from the amazing website CCMixter, which is where I find a lot of the Creative Commons licensed music I use in my stuff.

Building the sunrise was fun. I searched for images of sunrise and dawn until I found one that I liked. I poked around and extracted 15 different colors that I wanted to use and put them in a palette:

It’s an ordered palette — my sunrise generator basically says “if you’re X distance from the sun, fill in this area with a random choice of colors 0-2″ and has some special case rules for what happens when the sun starts to peek up over the horizon. This creates a banding and dithering effect.

The last bit of the experience, where the screen starts to fill up with light, just came from me messing around with the algorithm and deciding that I liked what that particular effect evoked.

My latest Outsider Videogames column is up at Paste Magazine.

I review the IGF Pirate Kart, which if you don’t know what it is, well… read my article, I guess!

I’ve been working as a producer on the HTML5 port of the hit mobile tower defense game Fieldrunners for about 4 months now, and I’m happy to say the game is finally available! (Requires the Google Chrome web browser.)

Bocoup (my employer) worked with Gradient Studios to port the game, and Subatomic Studios (the original developer) built some great new maps, towers, and game modes for the HTML5 version.

I truly believe this is one of the first polished, professional HTML5 games to be made, and I’m super proud to have helped make it happen!

Go play it now!

Welcome to part 2 of my series on contract negotiation for mid-career game developers. Please also check out part 1, which provides a general overview.

A story

You’ve been interviewing with this game studio for two weeks now. Two months if you count time from your initial resume submission. They flew you out, paid for a great hotel and meals, and interrogated the hell out of you. It was a grueling, day-long process. You had to tell your current employer you had a family emergency to take care of. You couldn’t post to Twitter about the fact that you were out of town. You felt like a secret agent.

Turns out you passed muster. They like you. They offer you a job. You’ll be working on a new game that you’re super excited about, with an amazing team of people, some of whom you’ve respected for years. You’ll have a position that gives you more responsibilities, and more chance to make an impact on the final product. You’ve been looking for an opportunity like this forever.

Then you get the employment contract. It’s got some heavy language in it — some of it scary, some of it boring, some of it inscrutable. Stuff about “IP assignment” and non-competition and non-solicitation. You read through it and as best you can make out, you’re not going to be able to work on any side projects while employed there (at least not without the company owning your projects). You’re not going to be able to THINK UP any side projects while employed there — any ideas you come up with while employed belong to the company. And if you leave the company you won’t be able to work for another game studio for a year.

Well, that sucks! But it’s probably not as bad as it looks, right? They seemed like such nice people over there, even the executives. It’s the whole reason you want to work there! I mean, that clause about leaving the company — they wouldn’t REALLY just halt your career for a year after you leave, right? And you asked your hiring manager about the personal projects stuff. They assured you that nobody’s ever been busted for having side projects, as long as they’re not made on company time or resources.

It’s such a great job, and such a cool company, and they’re even offering you $25,000 more than you’re making now! It would be ungrateful to complain! I mean, you probably only barely passed that interview. If you asked them to remove stuff from the contract — stuff that probably a REALLY SMART and well-paid lawyer came up with — they might take their offer back!

You know what, this job is a once-in-a-lifetime opportunity. Best to just sign the contract; it probably won’t matter.

…

Fast-forward three years. You’ve shipped that awesome game. It was a hit. You’re mid way through working on the sequel now and frankly you’re fucking tired of it. You love your coworkers but if you have to have one more serious discussion about a space marine in power armor you’re going to kill someone.

You’ve got ideas for games of your own. You’ve discussed them with some friends at a different studio. You want to start your own studio with those friends and try your hand at a director-level position — this company was a great place to be a team lead, and the experience was invaluable, but there’s no room for a new director. They have all the directors they need and nobody’s going to be leaving those positions any time soon.

But there’s that contract. You haven’t looked at it in ages, but it looms over you every day now. It’s true that your company’s never stopped someone from leaving and immediately starting a new studio, but as far as you know, nobody’s ever TRIED! And who could blame them, given the contract they had to sign? Your company has some pretty high powered lawyers, and if they came after you it’d make your life miserable for a year.

What if you managed to start a studio but your current employers found out you came up with your project while working for them? It wouldn’t be that hard to put two and two together. You’ve spent years here! What if they come after you and claim ownership of your game?

You think back to that day three years ago when you signed that contract and sigh. If only you’d negotiated.

You found out after the fact that your company was absolutely hurting for someone of your skills. You were the sixth person they’d interviewed for that job and it had been a long, costly process for the company. You didn’t know it at the time but you were in a good position to bargain. You could’ve easily had them modify the IP assignment clause so that it only applied to games that directly competed with the company’s space marine stuff. You could’ve had them drop that non-compete altogether.

But you didn’t, and now you’re in a world of stress that could have been avoided with another couple days of emails three years ago.

Don’t be afraid

The moral of the story is: don’t EVER be afraid to negotiate an employment contract. Do not fool yourself into thinking it’s not going to matter. Almost everyone I know does not negotiate these contracts, and almost everyone I know has an incredibly stressful time leaving their job.

Do not believe that the because the people you’ve met during the hiring process are nice, that they’re not going to be bastards when it comes down to the stuff laid out in the contract.

Relatedly, do not fall for the classic move where the person you’re talking to assures you that the company has never sued an ex-employee over the terms of the contract. I hate this move. It’s moronic. Fortunately, like all moronic strategies, there is an ironclad response.

Hiring manager: “Oh, we’ve never sued an employee over the non-compete. People go to new studios all the time; it’s really only there in case an executive leaves with a bunch of company secrets. We would never do that to you.”

You: “I believe that you would never do that to me — you seem super great and that’s why I want to work with you. But what happens if the company gets bought by someone else? My contract passes to them, and all of a sudden it’s a brand new board of directors and legal team that is in charge of enforcing the terms of my employment contract. For all I know, they’ll be extremely litigious. [Bonus counter move up next...] Since I’m not an executive, and as you say the clause is there for executives, then I guess it doesn’t apply to me. I would really feel more comfortable working for you without that clause in my contract.”

That usually shuts them up.

Above all, do not be afraid that trying to negotiate is going to make them retract their job offer. Let’s say you ask someone to modify something in your contract, and you give a perfectly reasonable explanation. For example: “This non-compete clause means that I won’t have a career for 365 days after leaving your company, and that is unacceptable.” Well 99% of the time, if they really want that clause in there, they will simply come back and say “No, that’s non-negotiable.” Which is totally fine — it means you understand what you’re getting yourself into and what kind of people you’re dealing with.

In maybe 1% of cases, they will retract their job offer because you had the audacity to look out for your own interests. Oh no! Worst case scenario, right? Actually it’s a great thing. That job retraction is the equivalent of them saying, “We are gigantic litigious assholes and we don’t want you working with us.” Well congratulations my friend, you just dodged a fucking bullet!

No matter who you are (except maybe a student fresh out of school), you should never feel like you’re too inexperienced or replaceable to negotiate an employment contract. The fact that they made you an offer means they really, really want you — and at this point you hold a TON of power in the relationship. You know how it’s draining to go through the interview process? It’s even more draining for a company. They’ve spent a ton of time and money making absolutely sure you’re right for them. They want you, and saying “no” might even mess up their project schedules — which at this point they’re probably already shifting around to make room for you.

When you receieve that contract, the ball is in your court. You have the power. Use it wisely and use it well, but above all, use it.

The rest of this employment contract negotiation series is going to cover how and when to use that power. But no matter what else I cover, this article will always be the most important one. It’s my sincere hope that you internalize what I’ve said here.

(DISCLAIMER: I am not a lawyer. The stuff I’m going to talk about is not to be construed as specific legal advice. I’m mostly sticking to the general principles of contract negotiation, and what to look out for in an employment contract. What I say here applies specifically to the United States, as I know nothing about the law or contract negotiation etiquette in other countries. What I say here may screw you over. This advice is for mid-career game developers: if it’s your first job out of school, I dunno, maybe you should just sign what you’re given to get that foot in the door! (But maybe not.) And finally: if you have any specific questions about the legality of something, CONSULT A LAWYER.)

On Friday, Joystiq published an article that got people angry, including me. It commented on a news item about a 46-year-old man who was taunted by a 13-year-old while playing CoD: Black Ops. If you haven’t read it yet, I guess you should go do so, otherwise you won’t understand the rest of this blog post. (The original post did not have the editor’s note at the bottom.)

The article uses hyperbolic language to laud the actions of a man who stalked and then choked a boy over a videogame. The article did not initially appear to me to be satire, and even as a work of satire it is weak and serves no purpose except to make Joystiq’s enlightened commenters miss the point.

People thought I was naive or stupid for not seeing the satire there. Justin McElroy (the author) and his editors at Joystiq make the argument that the use of hyperbolic language obviously and immediately telegraphs that a piece of writing is satire. For example, McElroy told me on Twitter that the phrase “we’re preparing a banquet in your honor when you get out of the clink” is a mark of satire. In the editor’s note that was latter appended to the article, the editor claims that a phrase like “Choke-a-Cola” means it must be satire, or at least a humor piece.

The problem with that argument is that people speak in hyperbole all the time, but hyperbole itself does not indicate irony or criticism. I can say, “I am so excited about Spelunky on XBLA that I will prepare a banquet in Derek Yu’s honor on release day.” That sentence is essentially the same as “That kid-choking guy is so awesome I will prepare a banquet for him when he gets out of jail.” Yet in the first sentence, the first clause is something that I truly mean. In the second sentence (which I’ve paraphrased from the article), the first clause is meant to be understood as false. Hyperbolic language itself tells us precisely nothing about whether or not a statement is ironic. It’s the overall context of the article that establishes irony, not specific hyperbolic language.

So the hyperbole argument is a red herring. We’re back to square one: the article was intended to be received as satire, so why didn’t I get it? Several people on Twitter told me, “Well of course he doesn’t support the choking of a child!” Again, the editor’s note tells us that the article’s satiric bent is “most obviously denoted by its support of a 46-year-old man who choked a 13-year-old child”. This ties into another argument I heard on Twitter: if Jonathan Swift’s A Modest Proposal is clearly satire, then surely McElroy’s article is equally clearly satire.

The problem with that argument is that A Modest Proposal puts forth a proposal that poor Irish should eat their own children sell their children as food to the rich [my bad, thanks @cawthraven] as a solution to their population problem. It’s obviously satire because people don’t and won’t eat children — cannibalism itself is an incredibly rare phenomenon (especially in the context of 18th century Europe), and cannibalism of children is even more rare. Eating children is obviously outlandish.

On the other hand, a 46-year-old man choking a 13-year-old child because of a multiplayer match is not outlandish. You know why? Because it actually happened, because that is the entire premise of the article in the first place. You know, it being a news article, filed under news on a videogame news website. There are clearly tons of people who support adults choking kids who misbehave, because grown adults assault and abuse children all the damn time. Again, read the comments if you want to see some particularly wretched examples.

Lastly, I take issue at the author and his editor hiding behind the shield of satire. The article is not satire. Satire needs to criticize something, and there’s no criticism in that article: there is only hyperbolic language that we are intended to take as meaning the opposite of what it says.

In other words, the article isn’t satire: it’s sarcasm.

But since satire is understood to be something culturally worthwhile, calling the article satire makes Joystiq able to convince a few people that they are beleaguered first amendment champions. Can you imagine if the response was not, “It’s satire, you’re missing the point” but rather, “We were being sarcastic, come on!” If the author and editor called their article what it actually is, they would have been instantly unmasked as juvenile (no, not Juvenal) hacks.

In early 2010 I made my first plane jam game called AF 337. I loaded it into GameMaker HTML5, pressed a button, and it was working in the browser, no extra effort required! I think it’s running a little slower than the native version, but I’m pretty pleased with the performance of a completely unoptimized port!

Play the game here!

Granted, this is a VERY simple game. I tried the “one button port” approach with 9 of my GameMaker games, and only this one managed to be as simple as just pressing a button. I hope to report on more of the issues I’m having, but some of it so far has to do with Z-indexing and perhaps how it interrelates with code in the Draw event. I think. On the other hand, they’re fixing bugs daily, so maybe when I try again later it’ll work.

A really big issue I’m having right now is that sometimes a game will work in Windows, but in HTML5 it’ll just crash immediately. The problem is I have no way to really debug it when this happens. The code is all minified, so errors come back like “Undefined variable ‘kv’”, which isn’t helpful at all. What I’d like is a debug mode where I have access to the unminified JavaScript so I can use the great Webkit debug tools to track down issues. I spoke with Russell Kay of YoYoGames on Twitter about it and he said that there might be something coming soon to help with debugging.

(Note on 11/23/11: The above issue is now fixed in GameMaker HTML5. Woo!)

These are my notes from Brandon Jones’ onGameStart session on WebGL. Brandon’s the author of the awesome glmatrix. Any mistakes or misinterpretations are my own. My notes are in square brackets.

[I came in a little late to this session. Brandon built a Quake 3 level renderer.] Q3 demo had no serverside stuff. All clientside. It’s a horrible idea, not something you want to do with a real game because there are a lot of calcs that don’t have to happen on the client because you’re slowing things down. But I wanted it to be a “view source” type of educational resource so I built it that way.

To make the clientside parsing nicer, we do parsing in a Web Worker — same with the movement system. It’s a simple trace through the BSP tree in Quake where you pass off your position test vector to the Web Worker. I’m sending the raw BSP format directly to the browser — bad idea, but again, it’s for educational purposes. Normalized all the BMPs and PNGs to PNGs. Normalized textures to powers of two since it’s OpenGLES, not OpenGL. Shaders are parsed from the Q3 material format and parsed to GLSL on the fly.

There’s no geometry culling AT ALL in the demo. We render every triangle in every frame. At the time (Chrome 6) I couldn’t find a way to do culling fast enough that it didn’t kill the frame rate. There is now. But since everything is sorted by material on the scene and we do a single draw call on each material type. It’s very effective and so I didn’t need to cull.

The original game uses a test-and-failback system for their textures. The system tries to hit the hard drive multiple times to see if a “lava” texture is “lava.png” or “lava.bmp”. We don’t want to do that on the web, so we made everything PNG. Since we’re pulling down from the internet, we put all the materials into a single file by hand to reduce http requests.

Shader format was designed to do everything as multi-pass effects. We could get better performance if we took multipass effects and rendered them in one go using our modern hardware.

So what about the next demo? I was drawn to mobile games. They share a lot of the same limitations that we see on the web. The demo I ended up doing was the iOS version of Id Software’s RAGE. [Shows a WebGL demo of the iPhone RAGE running, shows that it uses the texture atlas technology. Video of the demo here.] RAGE is a really good example of the type of things that our early WebGL games need to be trying for. It knows its limitations and plays to its strengths. All the rendering and all the gameplay are built with mobile in mind. The controls are built to embrace the platform. The gameplay sessions are quick and gratifying.

I will make an admission: the RAGE demo is running on localhost. Pulling in all the texture atlases will not perform well on the web!

When talking about file formats for WebGL, you have two semi-competing goals: you want to download them fast, but you also want to be able to parse them fast. As far as fast downloads goes, the Google Body team has done a great job with their WebGL-Loader project. They compress the vertex stream in UTF-8 that creates some very small files that stream down to the file very quickly. There’s a great million-triangle demo out there.

But if you want better parsing performance, we recently gained a request for a typed array from an XHR request. [Holy crap!] For any model format you can break it down into a big vertex buffer, an index buffer, and some bone/materials info. But the big buffers take the most time to parse usually. You’re looking through a JSON file or whatever, and you have to loop and parse things individually. With the binary buffer that now comes back from the XHR request, we’re in a position where we can get all of our vertex data and index data into the GPU just using some subarray calls. Grab your data, bind it directly to gl.Bufferdata, etc. But that requires raw numbers. For non-binary data (elements that aren’t simple arrays of numbers), use JSON, it’s just better for handling that.

It should be theoretically possible to download everything as a compressed format, unload to the Filesystem API in uncompressed format, and load from Filesystem.

Please use requestAnimationFrame! Pretty please! Don’t use setTimeout. (For one thing, requestAnimationFrame pauses rendering when you’re not on that tab!)

For optimization, everything is pretty much the same as you have on the PC. The main difference is that the difference between GPU and Javascript is a little bit bigger than in, say, C++/GPU, so it can help a little more to push to the GPU. However, browsers get better and better (for example, I can now cull in JavaScript just fine). Also, you want to change state as little as possible. Sort draws by material as a pre-process if possible, reduce your total number of passes, pack multiple meshes into a singe buffer, draw everything that uses the same material/texture in a single call.

Don’t break up your draw calls based on visibility! In a lot of cases with WebGL, it’s cheaper to accept overdraw, and instead just reduce the number of draw calls you have to make.

Generally, you’re probably not going to be GPU limited. You can take advantage of spare GPU cycles instead of having a JS bottleneck. For example, if antialiasing is available on your platform, just go ahead and use it. You probably won’t lose performance. Don’t bother turning off texture filtering. Once anisotropic filtering becomes available in browsers, leave them on and crank it up. (Of course, benchmark any of this stuff as your mileage may vary.)

And offline precomputations you can do, do them! Make sure your file format already presorts objects by state, for example.

When you’re talking about cross platform support, we’re in a unique scenario, we’re trying to get things that run on desktop, iPad, iPhone. There’s competing limitations. It’s a unique opportunity that in most of the time with a standard desktop game it’ll send down tons of resources, and the machine picks at runtime how much detail to render. On the web we know what the client looks like (“you’re a mobile phone”) so we can then send only the appropriate data for the platform. Don’t send anything to the client they don’t strictluy need.

A good artist is always going to be more effective than any of the shaders that you’re ever going to have. Good art direction will make more difference in your game than all the performance in the world.

There are a couple things that make WebGL different from standard desktop. Uploading large sets of data (textures, vertex buffers, etc) to the GPU is expensive. For example, pushing a big texture to the GPU would block for a few frames because the texture was bigger than the command buffer. You need to be careful — if you’ll push large data, do it as a preprocess or in small chunks. Bandwidth is a valuable resource! A lot of internet connections are capped, you don’t want to abuse your users’ bandwidth.

JS does make it easy to build inefficient data structures. Your data locality can be all over the place with even a simple tree. It can be worthwhile to store all your data in a TypedArray, which will have good data locality and you can iterate quickly. Don’t go crazy with abstraction layers (long prototype chains, callbacks, recursion). My demos are fast because the render loop is a simple for loop over every material in the game.

[Ended it with a crazy demo. Showed TwoFort from Team Fortress 2, rendered in a browser at 60 FPS! It apparently can run as fast as 120 FPS.] What you’re seeing on screen is an accumulation of 1.2 million triangles for this level, approximately 200 MB of resources that get thrown to the browser. Realistically that’s not feasible for a web game, for now, but it is possible! We were talking yesterday about ‘when do we get to do hardcore games in the browser?’ I can say that rendering is not the limitation for the web. The real bottleneck is going to be getting the content to the player.

So the plane jam game I made the other day was made in GameMaker. Today, YoYo Games released GameMaker HTML5, which I purchased sight unseen because I’m that kinda guy.

Here’s the port, play it in your browser!

I was unable to do my background scrolling effect, but that’s because it was a horrible horrible hack that I put in because I was optimizing for speed of coding rather than good code (it being a plane jam and all). Overall I am very impressed with it so far! (For starters, check out the awesome texture packing it does to reduce http requests.) Of course, I love GameMaker in general, so I’m predisposed to like it, but it seems like they’re doing the right things as far as JavaScript and web dev is concerned.

It took me about 10 minutes of getting familiar with how the new tool works, and about 3o minutes of figuring out that the way I was abusing Views in GameMaker 8.1 wouldn’t fly with HTML5. But 40 minutes for a port is great!

It did take me a while to figure out where the game put the rendered HTML/JS files. I’m still not sure this is exactly where it was supposed to be, but when you compile to HTML5 on Windows 7 it’ll show you something like:

Saving HTML5 file... C:\Users\USERNAME\AppData\Local\Temp\gm_ttt_97380\html5game\Project1.js

And then just head over to that location (you want the \gm_____\ folder and everything in it), grab it and upload it!

Never mind: just go to File->Create Application. It says you’re going to make an EXE but it actually makes an HTML app instead!