DanielWaechter.com

It’s been quite a long time since I’ve updated this blog, and let’s just say that a great deal has happened. If you’ll notice, my last entry (from almost four years ago!) explored my feelings about C++ and my desire to enter the game industry. Well…enter Carbine.

About a year and a half ago, in August 2010, my goal of moving from web development into games turned a corner when I landed a job at Carbine Studios.

Getting a job at Carbine was in some ways a lucky break. At the time, I had been doing freelance work for a year and a half, and business was…erratic. Circumstance combined with the economic downturn and other factors had sent my old employer out of business, and a lack of good options at the time left me in the position of looking for paid web work wherever I could. Some of it was good work, and I worked with some great clients, but the volatility of freelance work and my aversion to dealing with the business side of things meant that it would not be my final destination. I needed an employer.

And so, I kept sending my resume out.

Game Jobs Are Hard

Getting a job at a game company without industry experience is difficult to say the least. Your competition is stiff, particularly right now, and candidates with experience will always have a leg up on you. Brenda Brathwaite recently finished a book called “Breaking Into the Game Industry” on the subject that may be useful.

My experience in the industry is still limited, but here are some tips I’d give the even less experienced version of myself from my last post:

1. Know someone. Sadly, this is probably the single best way of getting a job in games. It certainly helped me. If you have contacts that work in the industry, have them forward your resume for you. At some companies this will put you at the top of the stack, and your friend may even get a bounty. If nothing else, it’s nice to have a friend already at a new company.
2. Demonstrate competence. Whether this means a portfolio or just talking up your relevant skills in a phone interview, communicate that you will be a skilled and valuable employee. With so many applicants, you need a way to stand out from the crowd. In my case, I talked about my how my freelance experience interfacing with clients was relevant to communicating with the designers I’d be supporting. I also emphasized the breadth and depth of my experience with relevant technologies.
3. Try. You’d be surprised at how many applicants just don’t try hard enough. Show that you’ll work hard to get the job. If there’s a pre-interview test, spend some time on it. Seriously, I’ve seen some tests that look like the applicant barely read them.
4. Be a gamer. This may seem obvious, but at least at my company most people are gamers to one degree or another. We play all kinds of games – and not just video games, either. I’ve been involved in three pen-and-paper groups with coworkers over the last year as well, and currently people are doing an MtG tournament.

And remember, I’m living evidence that it’s possible to go from an almost unrelated industry – in my case, web development – to games.

WildStar

For the first year at Carbine, I couldn’t really talk about our game since it had been unannounced. All I could tell people was that it was an “unannounced MMORPG”. This was enormously frustrating. I worked every day on what was turning out to be an awesome game, and…I couldn’t tell anyone about it!

Then, at GamesCom in August, 2011, WildStar was announced. And it was glorious.

I still can’t talk about details of WildStar other than what’s been announced, but at least I can tell people what I’ve been working on! I’m really excited about our game and the opportunity to work with awesome people on things I’ve wanted to do since I was a kid. And it’s only getting better.

Oh, and by the way – we’re still hiring.

Where I’m Coming From

I used to be very much a “C” guy. After learning BASIC and Pascal in my early teens, I cut my chops on C and – despite a few struggles – fell in love with it. The language felt right; it was close to the metal, but far enough away that programming it it could be pleasant. It helped me truly build a model of computation in my head which I think has served me well.

After getting into the web industry, however, I began to leave C behind. I coded in it less and less, since the industry outside of J2EE pretty much runs on dynamic languages (at that time, Perl – now PHP, ASP, Python, etc.). These languages always felt a little messy to me; I didn’t know what was really going on at the metal any more, like it felt like I did with C. Automatic memory management felt like a black box, and it always seemed I couldn’t optimize my data structures except at the algorithm level. And even then, who knew what the GC was doing in the background.

Over time, however, I came to embrace them – even to the point of spending a good deal of my free time playing in Lisp, Scheme, and SmallTalk. With processing power and memory becoming cheaper and cheaper, it was less necessary to worry about the overhead in dynamic languages, at least for my purposes. They tend to run plenty fast enough for web applications (where most performance problems are I/O- or DB-bound), and if they don’t then there’s always caching or throwing more hardware at the problem. If you know what you’re doing, the medium lends itself to the dynamic language programming style very well. It’s a common joke that PHP’s memory leaks don’t matter if a page request only lasts a second, and it’s basically true; who cares about optimizing a process that works to your needs? Reach the equilibrium between programmer time and project requirements, then move on to the next thing.

My old self would scoff at that attitude. It seems lazy, and it is. It still makes me uncomfortable. But it’s the way the web industry is built; the seat-of-the-pants, fly-by-night, hack-it-till-you-make-it attitude.

Where I’d Like To Go

However, I’ve got a bit of a problem. A long-time goal of mine has been to get into the PC game industry, ever since I wrote my first “Hello, World” in BASIC when I was 12. A kid getting into programming to write games is almost cliche, but it’s true; there are few teenagers that dream about writing database software or eCommerce sites. When we grow up our tastes often change, but sometimes they don’t. Case in point: after a decade in the web industry, I still want to work on real, wide-release, 3d games for a living.

There’s a small problem with moving to the game industry after the web industry, however. The programming culture is almost entirely different. The dynamic languages that I’ve mostly been immersed in at work – except for C# – are relegated to scripting in the game industry. Real developer positions, for the foreseeable future, have one almost ubiquitous language: C++.

That’s changing, somewhat, of course. Some development houses I understand are moving to C#, especially Xbox developers. Microsoft is pushing XNA, which runs on .NET. Then there are other enterprising folks who refuse to conform. But for most places, C++ still seems to be the language of choice for PC games.

So, basically, I made a choice. A while ago, I started sharpening my C++ skills again.

The Long Road Ahead

Now, in the hierarchy of languages that I enjoy coding in, C++ ranks somewhere above COBOL but below Logo; it is a complicated beast of a thing, with so many gotchas and corner cases that I’m sure it would make a Pharisee sweat. I actually derive real pleasure from the rantings of Yossi Kreinin in his C++ FQA Lite; even when I think he’s being somewhat unfair to the C++ FAQ authors, and even when I disagree with him on substantive issues, he still usually has interesting criticisms.

So, if I am so critical of C++, why am I studying it? Very simply – because C++ is still the industry language for game development. This is true just as much for historical reasons as it is for practical ones; arguably, there are better languages than C++ at the same level, without turning to dynamic or managed languages. But industry standard is industry standard, and until that tide turns, those of us who’d like to work with that industry have to tag along.

Now, I consider myself fairly proficient with C++ for someone who hasn’t shipped anything in it (it’s not exactly number one in my current field). I have most of the important bits of the language in my head, and I’m aware of things like RAII and how to implement patterns, etc. I’ve read Scott Meyer’s two books (though I haven’t fully internalized it all), and I’ve even built stuff in the language.

That said, it easily takes me up to two to ten times longer to implement and debug C++ code than in a dynamic language like Ruby or Lisp, depending on the complexity. Part of that is, of course, the language (and implementations) – no lexical closures (yet), no first-class functions (yet) (function pointers don’t count), no multiple dispatch (if you’ve never used it, it is unbelievably useful), gratuitous overloading of C keywords (like “static”), no standard ABI, private variables stored in header files (I understand why, and it can be avoided with pimpl, but it still bothers me), cryptic error messages (especially for templates, but other times as well), slow compilation…I can go on. One of the more irritating things is the default copy-constructors, and these days I just throw boost::noncopyable onto my classes unless I know consumers will need it (which is less often than you may think).

C++0x has some improvements. For example, I can’t wait for type inference; if the compiler can figure out what type I want, then why should I spell it out every time (though there are some limitations¹)? Even better, we’re going to have real lambdas and closures! But who knows how long it’ll take to implement – we’re still waiting for C99. Hopefully we’ll at least get early uptake of the most important features. TR1 is already available for VC9.

Qiān Lǐ Zhī Háng, Shǐ Yú Zú Xià²

I still have a ways to go. I’m in the playing around with various projects in C++, trying to be idiomatic rather than cute or clever. At the same time, I’m going through Sutter’s Exceptional C++ and C++ Coding Standards, internalizing good habits. It’s a little tough returning to the world of static typing, (semi-)manual memory management, and complex builds after such a long hiatus, but it’s worth the rewards. A longtime dream realized—becoming a real game developer.

I welcome the challenge.

So I upgraded WordPress to 2.5.1 today. I heard vague rumors a while ago about WordPress vulnerabilities, and while I don’t think I was actually vulnerable (the one I heard about was in the registration feature, which I had disabled), I figured it was time anyway. When I did, I looked around to see if my plugins or themes were broken; they didn’t seem to be, but I understand that there are some features of 2.5 that they might not cover so I looked into upgrading. I’d been using the “SpotLight Fluid” theme by Sadish Bala, which was quite nice, but it was time for a change; I hunted around and found ColdBlue, which suits my tastes for now. I’ve already seen some things with it that I’d like to tweak, of course, but, I’ll let it be for now.

Let me know if you see any problems.

So I’ve been playing with Smalltalk, specifically Squeak, for a while now, and I’ve been trying to come up with a project. I’ve decided ultimately to build a simple Paint-by-Number game (example), just to see how it works out. I’m going to use TDD and continuous refactoring, after the fashion of this excellent tutorial, and I’m going to build off of Damien Cassou’s squeak-dev image.

This should be interesting. Before encountering (Smalltalk-inspired) Objective-C a few years ago and then (also Smalltalk-inspired) Ruby, my primary experience with OOP had been C++ and Java – both of which had left a rather sour taste in my mouth. Sure, I could see a few advantages, but they didn’t seem worth it – and now I realize why. Most development in those languages is really OINO – OOP In Name Only. People actually program procedurally, and create just as much (sometimes more!) spaghetti code as in traditional procedural languages!

One thing about Smalltalk that I think encourages “true” OOP development is the way that the development environment works. In C++ and Java, the file and class are the units of account – but in Smalltalk, all you see is one method at a time. I think this is an important observation; it actually encourages the developer to think more granularly, developing smaller and more targeted methods. Methods are visually separated from the class definition from each other – even instance and class methods are completely visually separated. My hypothesis is that this has a valuable psychological impact on design.

Interestingly, though, Ruby and Python developers still seem to do this. Perhaps not with the tenacity that Smalltalk programmers seem to, but I don’t seem to find ridiculously long procedures-masquerading-as-methods in their applications as often. Maybe it’s because of the nature of the communities, or maybe I just don’t have a large enough sampling of code. In any case, it’s an observation.

So, we’ll see how I do with this little project. I don’t imagine it should be too terribly difficult – the problem seems easily solved, at least from a distance. But now my first decision – how do I store puzzles?

This may not be as trivial as it sounds. The old-style Perl programmer in me wants to store it as a packed string. The C programmer wants a multi-dimensional array. The Lisper wants perhaps an array, perhaps a list of lists. But what’s the Smalltalk Way? A multi-dimensional array of “Cell” objects?

I’ve updated the blog to use WordPress; Typo just isn’t ready for prime time. I didn’t migrate comments, just articles – but most comments were spam anyway. Also, thanks to the wp-syntax plugin, I’ve got syntax highlighting, yay!

Now to find a better theme. This one (Spotlight) isn’t bad, but I think I could find (or build, if I have time) better.

Semi-related to last week’s Java mini-rant, I completely related to this comic (?) by killnine. Check it out.

Update: It appears killnine.com is long gone, so here’s a wayback machine mirror.

So lately, I have been stretching my legs in a “new” framework – Ruby on Rails. While it is not so new in Internet terms, it’s still maturing and slowly gaining new users. I may not be contributing anything particularly new with this blog entry, but I needed a place to organize my thoughts on the subject.

Rails Philosophy

So, the primary Rails philosophy is “Convention over Configuration”. This is the biggest selling point for any domain-specific application framework, to me – how much boiler-plate do I have to write before I can start mucking with actual logic? Some of the nicest parts of Rails are the things that it Just Does out of the box. Database access and abstraction, file structure organization, standards for separation of concerns and unit tests – all of these normal tasks that affect every web application are taken care of for you ahead of time. That is a remarkably powerful tool.

Of course, this alone is nothing unique or original with Rails. One of the things I liked the most about the Fusebox framework for ColdFusion was that it provides several of these abstractions out of the box. Now, Fusebox isn’t nearly as complex of a framework as Rails – it doesn’t begin to approach things like ORM, pluggable modules, AJAX support, etc. Even its handling of templates is pretty rudimentary by comparison. But it does have “opinions” about software development, and those made it a joy to architect in versus something like raw ColdFusion, PHP, or ASP.

A Java Interlude

Compare this with “Hello World” in J2EE. Look at the steps involved for a “typical distributed J2EE application”:

1. Create the EJB project and the HelloWorldEntity container-managed entity bean (CMP)
2. Create the EJB to RDB mapping using Cloudscape for the HelloWorldEntity CMP
3. Create a HelloWorldSession stateless session bean
4. Generate WebSphere deployed code
5. Create a server project
6. Binding the datasource to the HelloWorldEntity CMP
7. Create a data source and Cloudscape database tables
8. Creating a Java application client project and implementation
9. Create the Web project and a simple Java bean to read and write properties
10. Create the HelloWorldServlet servlet
11. Create the HTML home page
12. Create the JSP for final presentation to the user
13. Create a reference to the EJB session bean
14. Run the full application on the server

Does this really provide so much more than Rails and its ilk to be worth it? I’m not seeing it.

While J2EE certainly has some conventions, they are at a very low level of abstraction. This may provide flexibility for producing any sort of application you want. But at the same time, that much time spent writing boiler-plate in every app has to be a pain. I will admit that I am no expert in J2EE (I’ve never written anything serious in it), so if this is an unfair characterization, let me know. But it seems to me that any J2EE web application would take at least twice as long to write as a simple scripting language like PHP, and probably an order of magnitude longer to write than something in Rails or Django. Even with static typing, code generators, and IntelliJ, there seems that so much complexity can only complicate matters and ultimately introduce errors (or bad practices) in all but the most careful teams.

But enough dumping on Java. The truth is, as a language, I like it better than a lot of others. And I have a lot of respect for Guy Steele when he writes:

“And you’re right: we were not out to win over the Lisp programmers;
we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren’t you happy?”

But at least from afar, the whole Java web application world seems ridiculous.

Back to Rails

Another thing I like about Rails is the Ruby language itself. It definitely has the feel of a Smalltalk-Lisp-Perl hybrid – with its emphasis on “everything-is-an-object” and blocks, combined with a seat-of-your-pants, “static typing? what’s that?” scripting language feel. Look at some of these little snippets:

Using ActiveSupport’s Symbol#to_proc:

[1, 2, 3].map(&:to_s) #=> ["1", "2", "3"]

Array shuffling:

class Array
  def shuffle
    n = []
    while !empty?
      n < < delete_at(rand(size))
    end
    n
  end
end
 
# Usage
[1,2,3,4,5].shuffle #=> [2, 4, 5, 1, 3]

MethodFinder, in particular, kind of blew me away:

irb> MethodFinder.show( "hello", 5 )
"hello".length == 5
"hello".size == 5
=> ["length", "size"]
 
irb> MethodFinder.show( "foo", "foobar", "bar" )
"foo".< <("bar") == "foobar"
"foo".concat("bar") == "foobar"
"foo".+("bar") == "foobar"
=> ["< <", "concat", "+"]
irb> MethodFinder.show( 3.14159, 3 )
3.14159.round == 3
3.14159.truncate == 3
3.14159.to_i == 3
3.14159.prec_i == 3
3.14159.floor == 3
3.14159.to_int == 3
=> ["round", "truncate", "to_i", "prec_i", "floor", "to_int"]

(though of course, this could be extremely dangerous in the wrong hands)

(HT: Coda Hale, Concentration Studios, and Andrew Birkett)

Clearly, Ruby has inherited much of the power of its Smalltalk heritage. When developer coding time is a priority, anonymous message passing with a method_missing handler is a Good Thing.

In general, dynamic, weakly typed languages – with all of their drawbacks – have always been my favorite coding environment. I’ve rarely felt too much enforcement of type safety to be worth the costs, though trust me that I do understand the reasons for it. It is rare that I find an object’s type to be ambiguous outside of classic ASP.

Conclusions

Though I’ve been playing with Rails on the side for a few months, I’m really only just getting my feet wet. I’m sure that there are aspects of the framework which will put me off; its Unicode support is poor (though that has gotten better in 1.2), raw performance is very poor (fingers crossed that a VM will be completed sooner rather than later), and DHH will probably continue to attempt to push away the enterprise market. But at the same time, I’m looking forward to getting my hands dirty in what is really still a very new framework, despite being over two years old. Thinking about architecture with the new CRUD features and ActiveResource alone should keep my mind occupied in between SICP and Latin.

Howdy. This site is going to be under some construction for a while (of course, what on the web is not under construction?), I’m going to be using it for some development and hopefully build out a For Real This Time™ personal site. Playing with Ruby on Rails should be fun.

By the way, by way of introduction, I am a programmer in southern California. Right now I work largely as a web programmer and IT Guy for a small web design company in Fullerton. I am an arm-chair philosopher, a card-carrying geek, and a non-card-carrying libertarian.