Also, a new article I wrote for the Game Career Guide went up yesterday.  It’s an introduction to game engines for those of you that are unsure what they are. The article is located here.

One thing I’d like to elaborate on is the lack of specific recommendations of which engines or game makers to use.  You’ll notice that I even try to avoid mentioning specific engines, and the only provided links are to Wikipedia articles on the subject of game engines and open source game endings.  I did this on purpose because I feel like mentioning them or linking to them in an article like this, where I’m supposed to be the mentor, serves as an indirect recommendation of the product.  But, as much as I’d like to, I haven’t used 90% of the engines and game creators out there (even the free and open source ones), and I feel like it would be a disservice to my readers and the other engines if I showed any real favoritism.

My recommendation for people really interested in working with a free or open source game engine (which I can highly recommend) is visit the Wikipedia articles and get an idea of the capabilities of all of them.  Ask for advice on game development forums (GameDev.NET is perfect for this) and download the ones that come highly recommended.  In addition, look to see what engines your favorite free or indie games are using and try them out.  You’ll be supprised just how awesome some of those engines can be.

So, I read The Daily WTF. It’s a funny blog, and occasionally can give you insight into bad and good programming practices. Also, occasionally, the person who runs the site, Alex Papadimoulis, writes a rant about something in the computer industry. Now, Alex is a bright guy, but I frequently disagree with some of his Soapboxes. Today (well, yesterday) is no exception.

First, let me say I think he’s right on many levels. You should always plan for people to leave, and you shouldn’t make believe that everyone will spend their entire career at a given company. You should be upfront with new employees about them leaving, as well as the potentials for improvement and empowerment. Promote based on skill, not tenure, and for the love of god, do not promote people to lead positions that cannot (or choose not to) lead.

In addition, foster alumni relationships for former employees and keep it alive; don’t treat former employees as exiles who don’t deserve the time of day. Always welcome them into the office with open arms. They helped you, and if they left on good terms (which they usually should unless you fire them) you should be happy to see them.

Here’s the one place where I don’t agree with Alex: keeping people around is almost always better than letting them leave, regardless of price, and benefits are not the only way to keep them. People leave because they get bored or they are no longer learning anything. But there are ways to fix that easily, I think, that will actually make your company money, as opposed to random benefits, which only cost you money.

1. Encourage pet projects. Google’s 20% time here is awesome. Trust me, you can afford it. Even if you can’t always use the end result, it will keep your employees interested in their work, give you new products and / or tools, and in some cases will keep employees looking at new and educating themselves in interesting new technologies.
2. Encourage mobility. Allow people to switch projects at almost any time (of course, restricting movement near the end of project cycles). This will encourage people to look at the other projects people are working on, and will keep them interested. In some cases, this will also keep them educated because they’ll get to work with people of different expertise levels throughout the company (though this only works if you’re working with many different technologies).
3. Be agile with your process and listen to employee problems. If new (or old) employees don’t like their code review process, figure out why and try to fix it quickly. In many cases, employees may like what they’re working on, but don’t like the way things are being done, or how slowly change takes to complete. Be able to make process changes quickly or at least show that you are making progress on changing things.
4. Lastly, be able to recognize when people are being resistant to change just for the sake of being resistant to change. They like doing it “their way” for whatever reason, but don’t ignore modern research into what makes good software just because certain people believe their way is better. In many cases, research proves them wrong.

Yes, you’ll never be able to keep people from leaving, but if people are willing and able to fulfill 90% of their personal and academic curiosity in an agile environment, you should be able to keep them until they decide they what to move to, say, a different state or work on something that’s completely outside of the bounds of what you’re company does. By just saying “people will leave,” you create a culture where the problems aren’t actually solved, and you’ll always have mediocre talent. By creating an atmosphere where people aren’t afraid to leave, but have no reason to, you get the best of both worlds.

Brenda has a post on perception of meaningful choice which is very good (all Brenda’s posts are good, so if you’re not subscribed to her blog, you should correct this error).

In my own little design theory world, I tie this concept very closely to agency theory, since I’ve believe that in digital games there is no *actual* choice and you can’t *actually* affect the system.   All choices have been coded and all possible outcomes have been accounted for because the rules are very strict, so instead we create the illusion of meaningful choice.

That’s not to say there is no such thing as emergent gameplay.  There are things designers can do to make the possibility space so large that there’s no way all possibilities to get from point A to point B could have been predicted by the designers.  Such designs usually follow strict willing suspension of freedom rules: a few rules that are very consistent that will have obvious outcomes, thus creating a system that gamers can experiment in.  However, despite the possibility space inside point A and B, those points almost always fixed.  That’s not really a problem, of course, depending on what type of agency you like in your games, but it is an inevitable outcome of how digital games work.

So, I don’t talk about it much, but since college, I’ve become increasingly enamored with board games.  I can actually (partially) blame the weekly board game group at Bethesda for this, but I was (sorta) the one who started us getting together in the first place, so I guess that’s a no go.  Whoever’s to blame, they’ve got me addicted.

Today, I was looking for some new ones to play, including Race for the Galaxy (which is freaking sold out everywhere), and thought I’d ask blog readers for some suggestions.  I pretty much have (or have played) most of the standards (Settlers, Carcassonne, Puerto Rico, Bang!, Caylus, etc.) so I’m looking for stuff that’s either new, or a little off the beaten track, but still good.  Additionally, does anyone have a board game news site they can suggest?  One that doesn’t spam with lots and lots of news (releases and reviews are about all I care about)?

In other news, apparently Hasbro / Wizards of the Coast has finally decided to republish Aquire.  If you have not played it, Acquire is a really awesome game.  I got the original 3M version of the game this year, and have played much since then.  I’m happy to see it out again.  I wonder if this bodes well for games like Betrayal, which were part of the same acquisition.  That said, the quality of the pieces of the new Acquire look terrible (see the official website here, compared to the Wikipedia picture of the Avalon Hill version).  I guess I shouldn’t be too shocked, but it doesn’t bode well for Betrayal, which had (count um) 291 tokens just for the scenarios.  Not to mention the room tiles, the double sided character cards and the character miniatures.

So, I’m kind of wondering if something like this exists. I currently have a set of tests that share common set up code which I only want to execute once for all of the tests, as well as some set up code that I want executed before each test. In addition, though, there are sets of tests that share test set up that I want to execute only once for that set of tests. Basically here’s what I want to happen

Parent Fixture Set Up
    Child Fixture Set Up
        Parent Set Up
        Child Set Up
            Test
        Child Tear Down
        Parent Tear Down

        Parent Set Up
        Child Set Up
            Test
        Child Tear Down
        Parent Tear Down

        (Etc…)
    Child Fixture Tear Down
    Child Fixture Set Up
        (Etc…)
    Child Fixture Tear Down
Parent Fixture Tear Town

There’s two ways I can see of doing this. One: through inheritance. Basically, the parent / child relationship is expressed through a base / derived relationship. NUnit may support this, but I haven’t tried it. I’m not really sure what happens when you provide two SetUp attributes for one class to NUnit (even if they are a base / derived relationship)

Second, and this is the method I would like to use, you could do it through a containment system. The parent contains the child, like so:

[TestFixture]
public class ParentFixture
{
	[FixtureSetUp]
	public void FixtureSetUp()
	{
	}
	[FixtureTearDown]
	public void FixtureTearDown()
	{
	}

	[TestFixture]
	public class ChildFixture
	{
             // etc.
	}
}

The only problem there is that in order to access, say, private data or methods of the parent class, you need to pass the parent class in as a parameter to the child. I’m pretty sure this is not supported by NUnit.

Does anyone know of an addin that might do this? Has anyone had a similar use case for any unit testing environment? How do you get around it?

This is a problem I think everyone has at some point when working with databases that can’t lose data, and specifically those that generated their database from another intermediary. The problem is this: when someone changes the source file from which the database is generated, how do you upgrade said database without losing any data? Or, losing as little data as possible.

In my mind, there are two approaches to this. The first is to attempt to run a diff between the new file and the old file, and generate an alter script that can be run on the database. The alter script contains the information to add new properties and delete old properties as needed, and can be stored in source control to run in sequence if required. These generated alter scripts are also nice, because if there’s a problem with one of them (say, a property is renamed and the diff believes it was a drop + add) you can fix it manually and still leave the rest of the script alone.

The problem with this solution is that it requires the old version of the file as well as the new version, causing some interesting workflow problems. For example, let’s say I’m a programmer that wants to add a new property to the database. Here’s what I want to do:

1. Open my XML
2. Add the property
3. Regenerate the code
4. Run the new scripts on the database

In actuality, here’s what I have to do:

1. Copy my old XML to a backup.
2. Add my property to my new XML
3. Run the generator with my old version and new version of my XML
4. Run the new scripts on the database.

So, now, I have my old version and new version, I test what I’ve done and find that I added the property wrong or I need an extra property. What do I do? I can’t revert the database. I have to produce *another* copy of the XML, change it and run the upgrade system… this leaves me with lots of old backed up XMLs… it’s just not pretty. Then what happens when another programmer wants to change things? Provided you’re not checking in your alter scripts (and, sometimes, even if you are) he has to hold on to his old XML, update to the new one, run the generator, run the alter script and now he can get working. That’s best case. What if he’s working when you check in? It’s just not pretty.

The other method (and I’ve seen this done) is to consult the database for its current state, and diff it against what the XML is expecting, then change the database accordingly. In this case, you could also, of course, just generate an alter script, but you run into the issue of, again, having lots of alter scripts for a single check-in. In addition, sometimes manipulation of the database (as mentioned before) can have unforeseen consequences. If your diffing system interprets a rename as a drop and re-add, you lose that data, and if you’re going directly to the db instead of an alter script, that’s bad.

The only solution here I can think of, which isn’t great, is to also have a “revert” script generated with your alter script, then write a shell script for your day to day workflow that does the following:

1. If it exists, run the revert script from your previous run of the upgrade generator (here, it would be nice to also be able to tell if this were actually necessary)
2. Use your version control system to check the version of the XML you are developing against and grab the pristine copy of that file to a temporary location (most source control allows you to do this, if only for diffing purposes).
3. Run the upgrade generator, which produces an alter and a revert script.
4. Run the alter script on the database.

Then, you can change your XML again (or merge with something another programmer did) and what you’d just done to the database is reverted before applying the new change. Problems? You have to remember to delete the revert script when you check in, so that whatever you checked in doesn’t get undone. I’m sure there are ways to check to see if you actually want to run the revert script, but generally, I can’t think of a good one.

Anyone found other ways to solve this problem?

So, I never really worked in an environment where unit testing was the norm. I’ve been trying to pick it up on my own for a while now and, in some respects, I think I’m doing a good job. I get the basic idea, but I’m not in tune will all of the tools and libraries that are actually available and heavily used out there in the real XP world.

So today I sort of stumbled upon and started looking at mock object libraries, mostly in Java (since I have a feeling that it’s the Java community that has the most robust and mature unit testing libraries), and I was impressed by the whole idea. It makes sense, so much so that I “implemented” it to test my generated code. But what I do a lot with a lot of custom code, logging and XML comparisons, they do with these mock objects, and they don’t need external files to do it. It’s all really, really cool.

So cool that, for a while today, I was thinking about replacing the XML logging system in my generated code tests with mock objects. But I still have an interesting problem. If I use mock objects, I can make the test code self contained, meaning that the generated tests can test the generated code and the pass / fail result tells me whether my generated code worked. But, this does not tell me whether or not my generated tests are testing everything I want them to, which results in a “testing the tests” problem. I’m not sure how to solve that one yet. For now I may just have to rely on my tests as they stand and try to figure out some way to make sure that I have at least key features tested in the unit tests.

In addition, to this, though, I was researching unit testing against databases (another thing I have to do frequently). Here, I got confused about best practices. Should I create a mock object for the database connection and test against that, or should I use something like DbUnitto connect to an actual database? My compromise, I think, is to do both. Test against the mock object to make sure that, from a unit perspective, the base library works and calls what I expect it to on the database. Then, use DbUnit to test against the actual target database platform (or platforms) to make sure that things get to where they’re supposed to go. This, of course, is a functional, not unit, test, but just as (if not more) necessary, since it actually tests what would happen in real world integration.

So, today just made me realize I have a lot to learn about unit testing. Any suggestions on where I can learn more?

(Note: The whole point of this post is to get you to join the IGDA Tools SIG, but I don’t get to that until below the fold, so I’ve decided to just push it up front here for those of you that don’t feel like reading my long tools rant. So, instead, please just go join here)

I’m a firm believer in tools.

I actually believe that good tools, provided both internal (from actual tools departments) and externally, are key to the success of any software development company, but especially game companies. I would go so far to say that 80% of any programmer’s job in a game development company is, or at least should be, making tools that make artists, designers, and other programmers happy. These are your engine programmers. They do good work, and they’re very important.

However, there should also be a good number of your programmers who’s *only* job is to keep your artists, designers, and programmers happy. These are your dedicated tools programmers, who do nothing but code and fix tools and process all day. If you don’t have these people, you’re missing out. Why? Think of all the places tools touch, or should touch, in game development and process that don’t actually involve working with your engine.

First, everyone benefits from a good build pipeline. Whether you’re doing continuous integration or not, having fast turnaround on art and code changes is always a good thing. Additionally, if everyone can grab changed assets quickly from central servers, that means work can get underway faster in the morning. The tools to do these types of things are usually available, but if you think an engine programmer (or worse, a producer) is going to go find them you are sorely mistaken. Of course, having that good build pipeline means also having good source control, and usually means having good integration between your source control and your tools for creating and exporting assets. And here, there aren’t usually tools available to you. You have to make them yourself, but the jump in productivity from this type of integration is enormous.

Additionally, programmers need tools themselves, but only the select few will think to make them, and usually only for themselves, on an ad-hoc basis. Deployment scripts, revision / code review change scripts, Visual Studio / WinMerge integration; these are all tools I’ve seen created by fellow programmers at game studios that never get passed around. But even then, there are tools that are incredibly useful that an engine programmer might never get around to. Memory inspectors, automatic bug reporters (and potentially bug collators), output filtering systems, external debug consoles, formal logging / metrics. All of these things are useful for programmers (and, in the case of formal logging, designers), but very few have (or will take) the time to really look into them as possibilities. Not My Job Syndrome.

Lastly, dedicated tools programmers have the time and ability, to keep up to date with the latest tool releases and technologies that people are using for tools in the game industry. This is key, because new concepts (like monkey testing, automatic crash reporting, formal logging / metrics, uses of XML / XSLT) pop up every day, and sometime lead to enormous gains in productivity. Without the time to look into them, engine programmers tend to lean on old technologies, with the “It’s not broke, don’t fix it” mentality. This is dangerous to your productivity, since sometimes it is broke, and your programmers just don’t realize it.

Now, if you feel like I do, or you want to learn more, I highly recommend joining the new(ish) IGDA Tools SIG. The SIG is dedicated to staying on top of best practices for tools development, posting about new tools that are becoming available, and hopefully (eventually) being a great educational and discussion resource for tools developers. If you are interested, I urge you to join. You will not regret it.

So a little while back I asked for your questions on the game industry. Bryan was kind enough to ask two very good questions, both of which are almost too advanced for a breaking in FAQ, and I felt were too important to be pushed to a comment, but they deserve answering, and I apologize for waiting this long to answer them.

The first question:

Some developers cite 60 hour, 6 day a week schedules like they are trying to drive people away from the industry. They speak as if this is acceptable and that only those with true passion for the work can hack it. Am I ignorant in thinking that someone - passionate or otherwise - could not possibly sustain quality output under these conditions? Is this an accurate snapshot of the industry?

This is a hard question to answer. At times, Bryan is absolutely right: it seems like developers cite their long hours in order to drive people away from the industry, and sometimes seem to wear their long hours and tough crunches as “badges of honor” (as one developer I know put it). This is a shame, as it drives perfectly talented individuals away from the industry.

But the question is, is this reality in the game industry, and I’m afraid that the answer is yes, especially if you are new to the industry. Though you don’t work those hours constantly, crunches can be pretty brutal, and can last for quite a long time (depending on the company and the game). There’s definitely a reason that the game industry has something like a forty percent burn out rate within five years. Think about it. That means if you’re sitting in a hall of developers new to the industry, look to your left, then look to your right, one of those people will not be in the industry in 5 years.

However, I will say that many companies and individuals are trying to correct this. Any company that has a CEO or lead developer on or active in the IGDA Quality of Life SIG is one where these types of hours will not be the norm. Some studios that run scrums do so because they want to avoid long periods of crunch. But, understandably, sometimes these studios are hard to get jobs at, because they attract some very talented individuals that understand, like you do, that these types of crunch to more to hurt productivity than help it. However, if you can join a company that knows how to avoid crunch, balancing the rest of your life becomes fairly easy.

As a final point, I will say that you absolutely need some sort of passion to be in the game industry, though not necessarily for games (you can be passionate just about writing really clean SPU code like some people I know), and not necessarily because of the long hours you’re going to have to work. Really, you need passion because 90% of the work in the game industry is just as tedious and monotonous as work in other high tech disciplines, except that your pay will be lower, your benefits will be lower and customers tend to be pretty ruthless. If you can ignore all of that, working in the game industry is pretty damn awesome.

The second question:

How does it start for most developers? Specifically people today. Obviously we have not been making games for our Commodore since we were 8. Do most come from other disciplines with experience in related fields? Are most newbies (to the industry) today fresh out of college, eager to show their talents?

So, interesting story. I’ve been talking with my co-workers and other Boston game industry people for a while and they like telling stories about some of the geeky things they did when they were younger (from programming to electrical engineering, to whatever). Now, I’ve always been interested in games, but I didn’t really get into programming until late high school, and I didn’t really make a game until college. So, I’m evidence that you don’t necessarily have to program the Commodore since you were 8 to become a productive member of the game industry. That said, I wish I had some of those stories (a failed RPG maker game is about as cool as my stories get).

However, now more than ever, you have to start looking early for game industry jobs, because entry level jobs become more and more rare as time goes on. When you hit college, you should start networking, get to know people, and start feeling your way around the industry. Additionally, start making games, and (if you can) find other people to make games with, especially if you’re not at a college or university that has a games program (this is common advice that I give to everyone). If you wait to start networking and wait to start actually making games, it will be harder to find a game industry job as a “newbie.” If you take a job elsewhere, you’ll find it hard to make the time to make games after college, and, even if you do, you may find it harder to adjust to the inevitable pay drop (note this pay drop is programmer centric, artists I’m told get paid very well in the game industry compared to other industries). Basically, the idea is to take the time when you have it (in college) and take the risks when you’re young. Show that you are interested in the game industry early. By waiting, you just make it harder for yourself.

Hopefully that helps with your question. If you have any more, please feel free to post them!

So, I spent this weekend moving. Literally down the street from my old place, but still, regardless of how far you go, you always have to put things in boxes and you always end up throwing a lot of stuff out. In m y case, I actually ended up throwing out a lot of t-shirts that I’d gotten from GDC and other computer related events (I actually still had my two shirts from when I was on programming team in college. That’s right, I was on programming team). It led me to this piece of advice for students and others going to GDC.

Don’t waste your time swag hunting.

Darius probably has this mentioned somewhere on his blog, but your time is better spent elsewhere. This is my 6th year at GDC, and I will tell you right now that, after this move, I will have kept the following items from all 6 years at GDC.

• 3 large blue PlayStation cups, snagged during booth crawl
• 1 nVidia cup, also snagged during booth crawl.
• 1 deck of cards from ILM / Lucas Arts
• 4 IGDA shirts (from the past 4 years, I got rid of the other 2)
• 3 GDC shirts, the ones that actually come in your bag. I discarded the rest, including my shirts the year I was a CA
• 2 branded shirts, one for LoTRO, and one for Maya (which is completely black and on the back says “> south You have entered a dark place. You are likely to be eaten by a grue. >”, and on the front says “Maya: Can you imagine”)
• 1 (broken) Microsoft DirectX backpack and the accompanying organizer that went with it.

That’s it, and it should be mentioned that only the top three items were “swag” in the traditional sense (meaning I got them on the expo floor). And I didn’t have to hunt for it. The cups are filled with beer during the booth crawl. Stop by 2 or three booths, grab the cups you want. If you’re like me, you just go to the front of the line and grab a cup, since the beer is usually pretty cheap anyway. All the other stuff you can get from attending specific events or being a member of an organization, and hunting for it will do you no good.

So what did I throw away? Tons, and some of it before I even left San Jose / San Francisco. Until you actually do the rounds at the GDC expo, you have no idea how much crap swag hunting will generate for you. As soon as you step foot on the expo floor, you will be bombarded with mints, shirts, pens, puzzle boxes, demo CDs, rulers, key chains, silly putty, stress balls, bouncy balls, chap stick, boomerangs, rockets, calendars, pads, little gel creatures, silly putty, decks of cards, Slinkys (that don’t work), magazines, bags, and maybe (if you’re lucky) something that might actually be useful for you some day.

Now, I know that you’ll do the swag hunt. You have this big bag, and you want to fill it with stuff. Especially “cool” stuff like rockets you can fling at people and crazy t-shirts. But while you’re doing that, just remember there are people there, handing out swag, that probably have interesting things to say. More interesting than what they’re trying to give you anyway.