Ask me anything
Recent Responses
-
-
What do you have against Starbucks? Just because they're a huge company doesn't mean necessarily that they don't know anything about coffee. They definitely do it better than most.
But that aside, I know what you're saying, as a coffee nut. And I don't have any recommendations around the area. I have some coffee I really love at home, but otherwise I'm personally cool with Starbucks when I'm out around town. I'm just happy that they don't burn the crap out of it. -
I don't listen to music at work. Although I do listen to music at home when I'm coding. I really don't like using headphones (although you didn't ask about that.)
I'll listen to just about anything, but I'm a huge pop fan. I consider what I do pop entertainment, and that's something that I have a passion for. Britney, Shakira and Paulina Rubio are on heavy rotation for me. My daughter got me into Billy Talent a couple of years ago. Oingo Boingo has been on my playlist forever. Depeche Mode is awesome. I also like KMFDM. Billy Idol, The Clash, The Ramones, Led Zeppelin. Shonen Knife are killer. Anyway, like I said, I like pop. -
I can't answer this question for you. What do you love exactly about game development? Where is your passion? What is your voice? What can you bring to the industry? You need to step back and figure out what your unique value is and focus on that.
Of course first you should ask yourself if you really hate programming or do you just hate your job and where you're at? But if you really do hate it, you should stop doing it now. You're doing a disservice to yourself and to everyone around you. You cannot do a good job here if you do not really enjoy doing the job. So please quit and make room for someone that does love what they do.
Then find out what you do love doing and do that. -
Honestly my real suggestion is to do some hardware design. That will beat some of the useless ideas out really quickly. There are a lot of cheap FPGAs now and they're an awesome platform for toying around with. But even in software you can look at other areas to expand your ideas and see where you're current approaches are broken - e.g. networking, big data sets, GPU programming, GPGPL, etc.
I haven't found a lot of good actual material that reflects the kind of message I'm trying to put out there. (Although, please send me any you do find.) Mostly, I think that's because the message is so simple that it doesn't really need a book or a name - it's really hard to get an academic grant for what amounts to what I think is a fairly common sense and pragmatic approach to programming.
I do love the book Hacker's Delight though. Hank Warren (the author) has a some other good stuff floating around too. And Sun's floating point paper, no doubt a classic. Mike Abrash has some really good writings from the old days too - he shares a lot of good lessons that can be applied regardless of the actual problem. -
Getting all the distractions out of the way. I'm in the zone when I can focus on a problem. Lots of people will tell you that I'm a fan of printfs and awk scripts. I like to dump out the data that I'm dealing with so that I can analyze it separately with some quick and dirty code and scripts that I can iterate on fast. For me, it's really about having a clear picture in my mind of what the problem *really* is that I'm trying to solve. Once I have that, I can chew on it.
-
You're asking about two different things here, right? STL and Boost, separately. But really, my answer is the same: There's nothing *wrong* with either one per se, but I discourage their use. Use of either encourages people to *fit* a solution to a problem rather than *finding* a solution to a problem. The solution should always be appropriate for the data at hand and the constraints of the hardware, etc. Both STL and Boost have an extremely narrow view of the "world" and their appropriate use is limited. Really, I discourage them because they lead programmers down the wrong direction right away, I often say if you feel like you need either one you probably don't really understand the problem that you're trying to solve.
-
*Really* understand the problem you're trying to solve. Don't add anything that doesn't directly contribute to solving that problem. Everything you do should be all business.
Always remember that a programmer's job is not to write code, a programmer's job is to always to transform data from one form into another.
Oh, and don't get caught up in "shoulds" (the compiler "should" do this, the hardware "should" be like that, etc.) -
I'm not sure if I'll participate or not. I really don't plan out my GDC schedule in advance.
But I can imagine what the discussion is going to be. I imagine it'll be largely about the wrong problem. C++, regardless of whatever issues I have with it as a language (mostly due to a lot of unnecessary constructs and bloat) is totally sufficient to describe the transformations that a game needs. Fundamentally, the problem is not the language, the problem is the focus on the language, or the code more specifically. And the fact that this roundtable is about the language and not about how to better describe, manage or organize the data required by game development tells me it's probably tackling the wrong problem.
But who knows, it could be awesome and I could be surprised. -
No. While the two industries have obvious similarities and share a lot more resources these days, they are fundamentally providing two completely different kinds of entertainment. There's always going to be room for the kind of non-interactive entertainment that film provides.
But I do hope that one day the AIAS awards are as big as the Oscars. :) -
I'm not sure if I'll participate or not. I really don't plan out my GDC schedule in advance.
But I can imagine what the discussion is going to be. I imagine it'll be largely about the wrong problem. C++, regardless of whatever issues I have with it as a language (mostly due to a lot of unnecessary constructs and bloat) is totally sufficient to describe the transformations that a game needs. Fundamentally, the problem is not the language, the problem is the focus on the language, or the code more specifically. And the fact that this roundtable is about the language and not about how to better describe, manage or organize the data required by game development tells me it's probably tackling the wrong problem.
But who knows, it could be awesome and I could be surprised. -
The most gratifying moments are when I'm surprised by someone doing something awesome way beyond my expectations. When someone can make something that I totally didn't anticipate and show me something new or innovative or just plain cool.
-
vi. I invested in learning it a long time ago and over the years I think it's paid off in spades.
-
Absolutely not! I've worked in games her whole life, so she definitely doesn't consider it anything particularly special. And she's disinclined to let her friends think otherwise as well. She'll be the first to tell them, "Seriously. He's so not cool. Don't tell him you play that game." :)
-
Oh, definitely! I really enjoy coding. Experimenting with different problems and solutions at home is great fun for me. Generally, at home I'll either code for PS3 Linux or one of my Linux or OSX boxes. I find I very rarely will do anything on Windows at home. Of course, I have a huge backlog of projects I want to finish up and document (one day!), but doesn't everyone?
-
It's a mix. Probably about what you'd expect: algebra, trigonometry, geometry, linear algebra, calculus, statistics. Although I'd say that data analysis and statistics have become increasingly important in recent years.
-
The obvious answer is to just do it. Build engines, make mistakes, do as much as you can.
As for advice, I'd say one of the most important things (and also one of the easiest to forget) is to constantly ask yourself "why am I doing this?" or "what value does this have?" - Everything you do should have some measurable benefit. It should all be "business" and not just there for some imaginary benefit or just because you read somewhere that it was "the right thing to do." If you're looking at graphics, for example, constantly question what are you actually trying to accomplish visually, not the algorithm, but what do you want to see and why. Why is it important, what's the value? For other systems, always try to step back and ask why you're transforming some particular data, what does it represent, what is the real *value* in it? And *just* concentrate on that. Always step back. Then step back again, until you run out of "whys" to ask. -
Hate is too strong a word. It's hard to hate a programming methodology, since there's very little *emotional* investment in them. But that's just semantics.
To the point: I don't believe it's Object-Oriented Programming or Object-Oriented Design is really an effective approach. I think it encourages programmers to consider the wrong problems and ignores the most important problems completely.
While OOP is certainly not the only methodology to do this, it's fundamentally concerned about the code itself, which should is not of primary importance. The most important thing is *always* the data - all code, all programs, and certainly the job of all programmers, is to manipulate data, to transform it from one form into another. Any method which does not consider that fact first is wrong-headed right from the get-go.
Unfortunately, there are a lot of programmers being taught OOP as "the" solution (as though there weren't others) and find it difficult to question the methods they've always used or been taught.
In short: I'm perfectly willing to say that OOP is bunk. -
As much as I possibly can. My daughter is the most important thing in the world to me. But as a teenager, she's not always inclined to spend time with me though! You know, because it's just not cool to hang with your dad. :)
-
Is this a roundabout way of trying to get me to confirm another Ratchet and Clank game? Well, I'm definitely not going to do that here!
But the question of whether we're going to 30fps as a studio isn't a rumor. You can read what I wrote about it here: http://tinyurl.com/yhfzu5e
The short of it is, yes, we believe that most of the fans would rather see that us put the emphasis, time, effort and most importantly the power of the machine, into other areas (such as graphics, but not just limited to that.)
I'm not saying that all games *should* be 30fps, but for the type of games we're doing I think it's the right choice given what the majority of our fans want.
Personally, I'm a huge fan of 60fps console games - I think most programmers are, actually - but I'm also not a typical gamer.
-
Mike Acton’s Bio
Burbank, CA
I'm the Engine Director at Insomniac Games. I talk about programming, games, family, and a lot of other random stuff.
