By Mike Acton and Daughter (Thanks: Ed Bartley)

You know those little icons on clothes tags? I sat down with Daughter and we worked out their meanings.

See: https://plus.google.com/105595823502776413734/posts/RUs5PQEPXgU

See also: http://www.textileaffairs.com/c-common.htm

I'll share some of them with you here. Some are obvious, some might be silly, but it wasn't until I stepped back a bit that I could really see them for what they were. In no particular order:

1. "Professional" Bias : Or what I'm also thinking of as "The Boring Bias." I have a deep love for games and how they can motivate us, give us room to create, pull us together as people, ignite our passions and provide a platform for fascinating ideas and technology and have fun, real joy, doing it. But I see myself all too often looking elsewhere when I want to accomplish those very same things in the context of development. When I look at management type stuff like Gallup studies, or books like "Good to Great" or methodologies like Agile I can see a commonality: They're all so freaking boring! Nothing has been able to motivate, inspire and bring together millions of people or all different cultures and backgrounds to build things and make things and share experiences together like games - and that's something I know something about! I'm now super excited to figure out how I can apply my own models of games to a lot more problems. And just have more fun in the process.
2. Education Bias : This is peculiarity of game development. Edutainment has been such god-awful crap for so long that just being associated with anything that might be considered "learning" is often avoided, at least overtly. And this bias has often caused me to forget that fundamentally, games are *about* learning. It's the one true universal language on this planet. We not only share game playing with other humans, we share it across species. Seriously, for the folks that say math is the universal language - I can't imagine doing math with a dog, but I can certainly imagine playing a game of fetch pretty easily. It's how a lot of of us higher Earth creatures learn best. And the very best games teach us deep and fundamental lessons that we can take with us our whole lives. Come on, how long have we been collectively studying chess or go? And if we look at games like WoW or even more recently FarmVille, we're talking about games that represent the some of largest live human experiments in economics and psychology the world has ever seen - the world is learning a lot from that. So I need to remind myself to ask what I can learn, what lessons I'm sharing, or what I'm experimenting with in everything I do.
3. Programmer Bias : Pretty much universally every single time I've said or thought, "you need a programmer to do that bit, really" I've been eventually proven wrong. I have this model in my mind of programmers: something like a mix of problem-solving, math and logical/analytical thinking skills with a bit of OCD thrown in. And I'm definitely biased to think of problems in those terms. But the truth is that everyone has these same skills at different levels, they just need the right tools (or games!) and the right information to leverage what they can do and know. Not everyone can do everything of course, and someone has to write those tools in the first place, but everyone *can* do way more than they're usually given credit for (especially by me.) In games, artists construct models out of triangles, which can certainly be seen as a form of programming (which is fundamentally just doing something that converts data from one form to another.) But we also see artists building shaders and animators building complex rigs which by any measure is exactly the same kind of thing. The examples are endless. I can imagine some alternative history where some "programmers" got together and said "Only programmers can make music! It requires complex math and deep analysis of the structure to get it right!" - when of course we can see that a whole lot of people who only know three cords and definitely don't deeply understand the structure or math behind music can create real works of art that resonate with millions of people. Now when I think to myself that only a programmer could do something, I need to think instead about what kind of engine would allow someone like Britney Spears to do it instead. (Which of course now, I realize the irony of using her as the example here after I write it. Which just goes to show how insidious it is.)
4. Negativity Bias : Part and parcel with having analytical work and being fascinated with models of completion (like programming!) is being over-critical. It's a crucial part of the process, of course. You make things better by looking at what problems exist and how they can be solved. It's when I take this too far that it becomes a real issue. It's when I forget that I'm looking for areas to *improve* and idea and not reasons to *kill* an idea that it gets in the way of creativity and shuts things down too early. It's easy to forget, especially in retrospect, that pretty much every good idea, and certainly every great idea, has holes in it. Sometimes big gaping ones. You just don't have all the answers up front. Especially when you're trying something new. You're not supposed to! Otherwise, it wouldn't be new! I have to imagine all the people that have changed the world, and all the (much larger number of) people that told them how it wouldn't work and think about which side of that equation I want to be on. For Pete's sake, I was one of the people that said "Sony doesn't know shit about games, I don't see how they can compete with Nintendo and Sega" when I first heard about the original Playstation project. This doesn't mean every idea *is* a good idea, of course. Or is practical. Or affordable. Or performant. Or whatever. But I does mean that I have to help build an idea up first and see how far it can go assuming it *can* meet the criteria for success. And explore it a lot further before deciding it's definitely not going to work.
5. Expert Bias : There are some areas that I consider myself an expert in. Which really just means these are topics I've dedicated huge amounts of time, energy and study to. They are topics that fascinate me and that I can apply to what I love doing. The bias is not that I consider myself an expert at some level (admittedly there's always someone out there that seems to know more than I do) - at best, it's just factual, at worst it's hubris. The bias is that I get so lost in these subjects that I fail to see the, what are often extremely obvious, connections. e.g. How I can apply what I do to other fields, or how I can apply expert knowledge from other fields to what I do. Recently, in talking to a couple of the engine programmers on my team at Insomniac, I mentioned how I thought their Super Power as more generalist programmers was to bring disparate ideas together. To see the connections between unrelated systems and build something new and better out of the parts. It's something I need to work harder on. I need to remind myself to occasionally step back and look at fresh and new topics, ideas and areas of study and see what *else* I can learn. I can probably use some work on the hubris thing too. But whatever. Not today. :)
6. Business Bias or Art Bias : I take turns with these in seemingly equal amounts. "It's about the business!" (Generally meaning sales, etc.) "It's about the art!" (Generally meaning a desire to express what's important to me as a creator.) It's neither one, exclusively of course. Famously recently Bobby Kotick of Activision pissed off a lot of people, both developers and players, when he said making games was exclusively about the money and really shouldn't be any fun. That's not only the road to soulless garbage in my opinion, it's simply and provably wrong. And Activision is quite lucky to have a lot of dedicated developers that bring their love and passion to development (and thus have made some great titles) regardless of what their CEO says to the company shareholders. On the flip side, it's not just about "the art" either. If I push toward some extreme end of experimental development, I'm very likely to exclude a huge majority of the potential audience. And it's that wider potential audience that (1) pays the bills, (2) gives me more people to connect with on some level, which is important to me and (3) gives me the opportunity, over time, to experiment with the ideas that I'm so interested in. It's why I love pop entertainment so much - it's a blending of business and art in a way that's both artistically compelling and sustainable. I just need to remind myself sometimes to have patience. There's lots of room for experimentation in a pop art, but you have to take the audience with you along the way. Take a look at music, punk and rap and rock-and-roll before them have completely transformed pop music. It just took some time and pressure. You know, like in Shawshank Redemption. 
7. Proximity Bias : This is one I find the strangest, but see it in myself all the time. I often take the opinion of someone completely outside of my social circle more seriously than someone I'm very close to. Even if the opinion is exactly the same! Perhaps I go to some conference like GDC or talk with some people from different development studio or just read something from some random guy on the internet and I think "Wow! That's a great idea. I want to use that." But then when I take that idea back and share it, I might have people tell me, "Goddammit, Mike! I've been telling you that for a couple of years now!" It almost certainly has to do with the internal psychological model of the people I know have in my head and I become blind to things that don't match that model. And the more I work with someone, or the longer I'm friends with them, the deeper entrenched that model becomes and the more blind I get. Even worse of course is when I bring the experience I have with the person as unfair and unrelated baggage and partially (at least subconsciously) judge the idea on that too. I need to remind myself when I hear an idea or any kind of feedback really, to imagine it in a much more neutral context to try and break this model of where it's coming from in my head.
8. Film Bias : This is another peculiarity of games. It's this idea that the film industry is the sort of big-brother to the video game industry and we often look to them as a model of how to do things or what we want to do. Well screw that! This one in particular pisses me off a lot when I see it in others and so very much more when I see it in myself. It's not that there's nothing to learn from film or the great studios, because there is (Pixar comes to mind and Ed Catmull in particular is a sort of personal hero of mine.) It's that games in particular have something fundamentally deep and different to bring to the world and that's what we need to explore! I love that I get to be a part of these moments in games because there is so much for us to explore and learn. It's my view that years from now video games are going to have such a profound impact on the way we live our lives that we're not even going to be able to imagine why we thought we'd want to be more like Hollywood and their lot. I need to remind myself that we have our own destiny and I get to be a part of that!
9. Productivity Bias : This is actually where this whole thing started. I was thinking that it's so easy for me personally to get lost in what I'm doing. In projects and tasks and milestones and bugs. In making sure that things are getting correctly and on time. It's so easy to forget why I'm doing this. It's so easy to lose the passion and sheer love of the work and the things I can bring to the world under the onslaught of everyday stuff. There's no question that the stuff needs to get done, but all the work that I've ever done that I thought was really good (or even great) came from an emotional core. It's because I believed, deeply, that it was important and that I could make some kind of impact (however small) on the world. I need to remember to take a step back more often and remind myself of why I'm here and how I can make a difference. Really, just to keep inspiring myself so that I can always do my best.
10. Success Bias : Man, this one sucks balls. When I'm successful at something, I want to keep doing more of that. On the surface, that seems fine, of course. But at some point it gets in the way of failure. I can find myself avoiding things that are different than that or that don't have the same chance of success. I can easily forget that in any way in which I've been successful, it's absolutely only because I failed in so many ways before that first. I know that I have to try lots of new things and fail at most of them to create anything really good. But it's so easy for me to forget. I need remember to ask myself every single day, how have I failed today? Because if I haven't failed, then I certainly haven't been trying hard enough. 
11. Completion Bias - I'm adding this one because I realized that it was this that was actually getting in the way of me writing this little article in the first place. I know this is the reason why I don't post to my blog or work on various hobby projects as often as I want to. I have a strong tendency to want to complete something. What "complete" means is fairly arbitrary, but if I don't feel like I can do something real justice I don't want to do it. I'm sure this has something to do with the old adage my dad pounded in my head as a youth. That "if something is worth doing, it's worth doing right." And I'm for sure obsessed with that. As I wrote this I asked myself questions like: "Have I written enough on these topics?" or "Have I missed anything important?" or "Did I make that point well enough?" or "Are there some better ways of categorizing these biases?" or "Is there some way I could more generalize this point?" or "Should I go back and rewrite this whole thing?" - And I needed to tell myself that what I wrote probably is imperfect in many ways but I have my entire lifetime to improve it and at the very least, trying to articulate these imperfect thoughts in some way will at least give me a good start.

I was inspired by this link that @jurgenappelo sent out this morning:

Last night, once again I noticed that there were a lot of people hanging around here at GDC in groups of people that they work with (or go to school with) every day. GDC and events like this are great opportunities to meet new people and catch up with old friends too! There are also a lot of other things you can do to make GDC a better experience and give a little bit back to those around you.

Here’s my list of 10* little things you can do at GDC to make it just that much better

*There’re only 10 things because I’m too lazy to make a list of 50 things. (I actually was going to make 20 things when I sat down to write this, but I got to ten and changed the number because damn, that took longer than I thought it would.)

1.      Compliment someone else’s game. Social media has changed the way we interact among ourselves and with other game players. A few voices can make a huge impact. Take a little time to walk around the expo, find a game that you’re excited about (that you didn’t make) and let people know about it. With just a quick tweet or facebook update you might be able to get some people interested in a game that might’ve never heard of it otherwise. And a lot of the small, indie games depend on word of mouth and you might be able to make a big difference.

2.      Be genuine. Have your own voice and say what you think. For example, if you meet someone that you admire, but you disagree with a choice that they’ve made in one of their games, go ahead and let them know. Don’t be a jackass, but gamedevs want (and need!) to hear constructive criticism, and the most constructive feedback comes from our peers that know the constraints of real development. Tell people what games you liked and didn’t like and don’t worry too much about who might be standing right behind you with a grimace or frown on their face. Don’t be afraid to say what you think.

3.      Listen and learn. This is what we’re all here to do in the end. Pay attention in the sessions. Take notes. But don’t just write down the slides – you can get those later. Write down the ideas that the speaker inspires in you, or the things you want to try when you get back home. Every session represents some hard earned lessons and we’re really doing ourselves a disservice if we don’t learn the most we can from those lessons so that we don’t have to pay the same price to avoid them. The same is true of individuals you talk with – there’s a lot of organizational knowledge here in the industry, stuff that isn’t written down and really just shared from person to person – ask questions of everyone you talk to and try to learn something. In just a few days I know I’ve learned a lot of good lessons from a lot of people and that is going to make a difference when I get back to work.

4.      Work on a presentation, panel or roundtable. Get inspired by what other people are presenting this year and think up some ideas for what you can present next year. The submission deadline is sometime in the summer, so now’s a good time to think about it. I’ve had quite a few people tell me that they “just don’t have anything useful to say” – That’s total bunk! It doesn’t matter how long you’ve been doing this or what your job is, you’re being constantly challenged in this industry and you learn hard lessons every year. Those lessons and discoveries are exactly the kind of thing that would interest everyone else. Not only that, but every one of us is standing here on the shoulders of giants and there is no good excuse for not returning that favor. If you’re uncomfortable standing in front of an audience, find some other way to give back – write an article, create a how-to or make a little video showing of a technique you use. If you really, truly have no lessons to share and nothing to give back then either you are in the wrong industry and you should leave or you are in a job that doesn’t challenge you to be better - in which case, I’ll point out that Insomniac is hiring! :)

5.      Be a mentor. There are a lot of students here. Even for those that are themselves students, there are those that are just starting out and haven’t gone through the same program you have or researched the same things you have. Take the time to talk to someone that you might be able to help. Encourage them to ask you questions and answer them as honestly as you can. Share some good stories about embarrassing things you’ve done or painful moments you’ve endured and offer some advice for how they can avoid the same traps.

6.      Venture outside of your comfort zone. Go to sessions that aren’t in your area of expertise. Talk to people that aren’t doing the same discipline. There are a lot of surprising lessons that can be applied to your work if you take the time to look around. It’s also critically important that we all try to understand the challenges that we each face and appreciate the goals and visions for how we can all best contribute to the games we’re making. Personally, I’ve spent a lot of this week in art and design sessions and I can tell you definitively that those sessions made a difference to me.

7.      Introduce people and talk to strangers. Put together a quick meetup or a coffee and gather a few people that haven’t met before and introduce them. We don’t work in a vacuum and it’s important that we make connections with others so that we can learn from them. Help others do the same whenever you can. If you’re standing in a group of folks and you see a couple of obviously shy folk standing around with badges, invite them in to your conversation and ask them what they think. It’s easy and people appreciate it when you include them. I know I do.

8.      Give speaker feedback. Seriously, it’s really helpful. Take a moment and fill out the form in any session you’re in and tell the speaker what you think. Imagine if you were up there – wouldn’t you want to know what everyone really thought about your presentation? Wouldn’t you want some feedback so that you could improve in the future?

9.      Know your limits. GDC is a fun atmosphere and there are a lot of parties. If you’re tired go to bed. If you’re drunk, stop drinking. It’s all fun and games until I get someone else’s puke on me. We all want to be able to talk to each other and have a good time, but you stop being interesting when you’ve obviously exceeded your limit. Although a video of you might get some hits on youtube.

10.   Share ideas. We can’t always share the projects that we’re working on and there is a lot of confidential information that is important that we keep secret, but that’s pretty finite. Share your thoughts and your ideas for making things better. Share your thoughts on the industry as a whole, some improvements to an algorithm or some game design concept. Whatever you can. That’s precisely why we’re here. Don’t be overprotective of your ideas. Sharing them and talking about them makes them better.

On a slight tangent, earlier this week I sat in on some of the indie game talks. In particular I noticed that there was this definite “them vs. us” feeling. My message to all of us (whether or not we call ourselves indie) is to remember that we all make our games with love and we all share a passion for making great games. So let’s not forget that we’re in this together and take opportunities like GDC to make everything a little bit better. Our shared goal should be to make all games better, because that’s better for the players and it’s better for all of us.

Mike.

PS: Please come to my presentation on Saturday morning at 9am! I’m going to be sharing some lessons that I’ve learned and that I’m passionate about related to how we’re fundamentally approaching programming wrong.  Even if you’re not a programmer, it might be helpful to get a perspective on some coding challenges. And I’d really be interested in feedback from people from all disciplines. Also, I’m not above a little bribery:

Here are the initial details for our GDC tweetups #gdcdrink and #gdcherf

Everyone is welcome. We are always looking for fresh meat... er, new friends!

No need to RSVP at this point. Just come by and we'll squeeze you in.

#gdcherf - Cigar smoking, drinking, sharing stories, general bitching.

• Wednesday, 8PM at 850 Montgomery cigar bar and grill.<- Reservation under Mike Acton.
• I'll post comments and updates to #gdcherf on twitter.

#gdcdrink - Same as above, but for our non-smoking friends.

• I picked a bar from Naty's list of recommendations...
• We'll meet at: The Clock Bar at the Westin St. Francis <- On Powell near the corner of Geary
• Tuesday 5-8 (Done. We had a great crowd!)
• Thursday 5-8 
• I'll update these on #gdcdrink

Let me know if you have any questions. You can email me at macton at gmail. (Shoot me a mail if you're coming and you want my cell number.)

Mike.

PS: If any party poopers decide to change your mind at the last minute, go ahead and come by! I'm sure that we'll be able to squeeze in one more.

Data used for different purposes (i.e. different and exclusive most-common transforms/operations) will have a different form. Data should be designed to fit the transformations and constraints being applied for the problem. Two different problems imply two different data designs.

This is intuitive at a high level. Text is clearly not the best format for reading and executing an instruction stream, however it is a good format for editing and describing one. That's why we write code in text and yet it's compiled (transformed) in to something more suitable for the exclusive use (reading and executing). Even short-cycle interpreted languages are simply less monolithic versions of the same logic (e.g. small sections of modified text are transformed in to another format, like a VM code or JIT native code.) This is done because these are exclusive and independent uses of the same essential data (instruction description/stream) and different formats are better suited to the different uses, and different parts of the data are often exclusively relevant to one transform or the other.

At a high-level, the same pattern is applied to the game (e.g. data from maya, intended for general-purpose editing, is converted to a runtime format, which is intended for game rendering, which has different goals, transformations and constraints.)

You can imagine many more examples that fit this essential pattern:

Let me repeat this point: Two different problems imply two different data designs. This is a fundamental of good data design.
 
However, Object-Oriented Design (OOD) and Object-Oriented Programming (OOP) have perpetuated this misguided belief that there is an ideal abstract data form where all transformations are given equal weight*.

THIS IS GARBAGE.

• It doesn't match the reality of what's happening.
• It's not intuitive at all. (Mostly because it doesn't match any reality.)
• It's harmful (by pretty much any metric - memory, performance, complexity, etc.)

The idea that all transforms are essentially equal, and a data format is an opaque abstraction that provides the union of all information needed for all transformations equally, is just wrong. Nothing could be further from the truth, but the value of each transform, both independently and in exclusive groups, and the impact on the data design is not considered in traditional OOD. See also: Three big lies

* It doesn't matter whether or not this pattern or belief is inherent in OOD. The fact is that it is most commonly applied this way in practice. And you know it.

Take for example, this bit of code:

class AlignedBox
{
public:
  Vector3 minimum;
  Vector3 maximum;
  bool seeded; <-- Take a moment: What do you think this is for?

...

That field exists because these transformations (methods) have been included in this class:

Vector3 Test(Vector3 vertex);void Merge(const AlignedBox& box);void Merge(const Vector3& position);

You can see, for example from the Test method below that these transformations are designed to edit the AlignedBox. And that the "seeded" value is used simply as a test to see if an initial point has already been transformed by the method into extents of the box.

Vector3 AlignedBox::Test(Vector3 vertex)
{
if (!seeded)
{
seeded = true;
minimum = vertex;
maximum = vertex;
return vertex;
}

if (vertex.x > maximum.x)
maximum.x = vertex.x;

if (vertex.x < minimum.x)
minimum.x = vertex.x;

if (vertex.y > maximum.y)
maximum.y = vertex.y;

if (vertex.y < minimum.y)
minimum.y = vertex.y;

if (vertex.z > maximum.z)
maximum.z = vertex.z;

if (vertex.z < minimum.z)
minimum.z = vertex.z;

return vertex;
}

Now without getting in to the data field seeded itself, at whether or not it's actually necessary (it's not at all - you can almost certainly know in context whether or not you're creating a new AlignedBox. Not only that, it implies that points are being added arbitrary and individually with no consideration of their data design. Which in turn implies that the data design of the parent, or calling system is poor.)

Note another set of methods that exist in this class:

bool IntersectsSphere( const Vector3& pos, const f32 radius ) const;
bool IntersectsBox( const AlignedBox& box ) const;

Clearly these two sets of transformations are independent. The pattern should also be familiar (see diagram above). The data is "edited" by the Test and Merge methods, and is later transformed by the Intersects* methods. Certainly we may expect the AlignedBox to be edited again in the future, but in the same way that we expect code to be re-edited. These are exclusive and independent data transformations, and as such, we should expect their solutions (data forms) to be different, depending on their most common uses.

In fact if you looked at the data usage for the Intersects* methods in the system, you would very likely be able to reduce the most common pattern in to cases like the following:

And the data design you would create for solving this problem would be very different from the design you would create for solving the editing problem above. As it is with text and code.

Most people do intuitively know there is something wrong with this design. Although they may not know what. Take the Intersects* methods again, for example.

This function is completely defined in the cpp file, in that it actually does the transformation/test.
bool AlignedBox::IntersectsSphere( const Vector3& pos, const f32 radius ) const;

However, can you guess what Sphere::IntersectsAlignedBox looks like? How to handle these kinds of cases invariably leads to a confused OOD. Why? Because the model makes no sense. The fact of the matter is that these methods do not belong in this class because this is not the class of data that they act upon. The only "class" that these transformations belong to are a class of data that match their transformation patterns (which may look like the image above, or whatever the most common context they're applied in the application happens to look like.)

But note, even in the above case you would be careful not to over-generalize the data pattern, or you would simply end up switching on every pair of data types possible in the input streams. You need to analyze the data itself to see which pairs are likely combinations and should be handled as such. It's exceedingly unlikely that all pairs are equally likely and that no similar pairs are ready to be transformed within the same latency window.

In a similar way, AlignedBox also includes the following methods:

void GetVertices(V_Vector3& vertices) const;
static void GetWireframe(const V_Vector3& vertices, V_Vector3& lineList, bool clear = true);
static void GetTriangulated(const V_Vector3& vertices, V_Vector3& triangleList, bool clear = true);

Which belong to an entirely different class of transformations! To which you would need to ask similar questions - How are the transformations applied? When are they applied? What are the latency constraints? What is the necessary throughput? etc.

While it may be said that I "cherry-picked" a particularly poorly designed example to pick on, the flaws themselves and the lack of consideration for data flow and design, are very typical. And there is a lot you can infer about the system as a whole by just looking at the data design of a single part.

Mike.

Recently I've been doing some presentations as well as just general sketches of some things I've been thinking about regarding optimization, concurrency and data design. I've been posting them on Twitter to gather feedback from my pals there. A couple have caused a little controversy, but remember that all of them are given in the simple spirit of sharing ideas among peers. And don't forget it's all in good fun!