Category: Game Development

I’m feeling really bad because the first contractor I hired for my company is turning out to be untrainable. I have no recourse at this point but to fire him and find someone else. Part of me feels shamed for taking this guy away from his current job and then having to fire him right away. Part of me embarrassed – how crappy of an interviewer can I be to hire someone like this?

The straw that broke the camel’s back was when after 4 days of just trying to build the game, he told me yet again that it wouldn’t run because of missing DLLs. I’ve told him to copy the DLLs at least 5 times, and have walked him through that exact problem twice already. Honestly, I shouldn’t have had to tell him at all. The game is still in its infancy, there aren’t that many directories, and if you were to just open the 3rdParty directory you would see a DLL directory right there. So I told him “Copy the DLLs from c:\engine\dlls to your game directory” He said it still wouldn’t run with the same missing DLL problem. So I told him where to click, how to load a DOS prompt, what to type, how to copy/paste from the DOS prompt, and to give me the output of the dir command on that directory. Sure enough, the DLLs were not there. I got exasperated and (still politely) asked him if he really had the two years of experience he claimed during his interview, because one of those years he claimed was on Windows and even non-programmers should understand how to copy files, especially if told the same thing 5 times over 4 days, even including written setup instructions.

Earlier that same day he complained to me that he didn’t have permissions to check out files when I asked him to download the latest from source control. He didn’t have permission because two days ago I had to remove his permissions because he kept checking out the entire source tree exclusively. Eventually, although it took 4 days, I realized he didn’t understand the meaning of check-in, check-out, get latest, etc. He didn’t know how to use source control and never bothered looking up the terminology or reading the help, despite the lead programmer and I telling him 5 times to stop doing exclusive checkouts. I mean come on, if someone is telling you over and over not to do something, and you don’t understand the words they are using, maybe it makes sense to ask or to look it up. The information is out there.

After writing all that I feel annoyed enough I’m not so shamed anymore. I think the reason I hired him is because he was still so much better than the other 700 candidates before him. Even quartz looks good to a diamond hunter if they are in a coal mine. At least he could sort-of speak English, could sort-of answer questions, and claimed 2 years of experience. Because of the last point, I gave him the benefit of the doubt, which turned out to be wrong.

One on hand I could say the lesson I’ve learned is to be a hardass and to reject anyone at the slightest hint they might not be suitable. But that’s not really the case – for example my lead programmer is great and yet I didn’t get an overwhelming feeling of how good he was during the interview. It was too hard to understand him so I couldn’t cover technical questions very well. It’s questionable if I would have hired him for lead programmer if I didn’t give some benefit of the doubt. Maybe the lesson to learn here is when hiring in foreign countries, it’s best to have someone there on-site to help you, because without an understanding of the culture, language, and technical terminology they use (including degrees) it’s hard to judge talent.

One problem with a business that hires telecommuter is that telecommuters are harder to keep motivated and working. It’s harder to tell if someone is working and an instant message isn’t as big of a motivator as the boss coming by and giving you a pat on the shoulder. To be clear, I’m not one of those kind of bosses to stand over your shoulder and watch you work. If you have nothing to do, hey go kick back. If you aren’t in the mood to program and want to take a couple of days of rest, please do it. If you work in crunch, 7 days a week, for 3 months and want to take a week or even two to play games you deserve it (I did this myself at my first job). What I do want to avoid is the guy who get paid on Friday so routinely works on Thursday and Friday and no other days. Or the guy who works one month out of a 9 month project (this also happened at my first job).

You can avoid much of this problem with due diligence. I believe that bosses should stop by the worker’s desk every day and ask “How are things coming along? Are there any questions I can answer? Any problems I can help you solve?” Speaking from personal experience, this is not seen as micromanagement but as a lead helping you do your job.

You can also avoid the problem by hiring self-motivated people to begin with. The problem I described is far less prevalent among educated professionals but all people need a boost from time to time to keep them going in the right direction.

My business owner friend suggested using performance based bonuses every paycheck. Paying either weekly or bi-weekly, you monitor the employees performance on a day to day basis. Based on their performance, quality, and drive that day you give them some kind of rating. When it’s time to pay, you say something like “You hit these three goals and wowed me on this feature. I’m going to throw in a bonus of X dollars on top of your paycheck.” The important thing is not to do this so often that the employee takes it for granted (at which point it’s a negative not to give a bonus rather than a positive to give one). It’s also important to avoid the appearance of unfairness or favoritism. So it should be clearly cause and effect. “I scheduled you to do X in 5 days, you did it in 3 days. That’s really impressive. I’m going to throw in a bonus in your next paycheck. While I won’t give you a bonus every time you beat a deadline, I am this time and as long as you work this hard the rewards will keep coming.”

Similarly, my friend suggested starting new employees at a slightly lower pay for X months. The problem with most people is that their enthusiasm wanes after a month. I’ve seen this when I managed reviewers who do a great job on their first review, an OK job on their second, and simply not do the third. A new hire costs you a lot more than an existing hire because of training. So it’s fair that they make less at first and fair that they make more after they have proven they can work over the long haul. It’s a way to keep costs down from bad hires as well as is an incentive to work harder. It’s similar to a regular rate of promotion, except it’s performance based and shouldn’t be expected.

One problem I’ve always had at my current job is trying to get work done on the poor hardware made available to us. On a regular basis I encounter:

• 10 seconds lockups to open a new file
• Compiler crashes
• 15 seconds to open firefox
• 1 FPS in debug
• 10-30 seconds to bring up the visual assist file index
• 5-12 minute compiles, even with Incredibuild
• Something like 50 KBPS on our shared internet connection

The problem is twofold: First, you lose the time actually spent waiting. Second, because it’s so distracting you may lose your train of thought and go read The Onion instead. Because it takes so much longer to make changes, you have fewer iterations of the code total. This discourages experimentation, reducing the final quality of the code.

Lets look at the same problem for artists. You ever notice how old games are often more fun than their modern equivalents, despite the old games having a minuscule fraction of the budget of their modern counterparts. I believe this is because of the large iteration time involved with changing assets and code in modern games.

Suppose in my 3D level I have a small town. It turns out the town is the funnest part of the level, with places to hide and more strategy than the surrounding forest. I want to add 4 more towns. In a modern 3D game this is a HUGE amount of work. Man-months by several level designers. In old games, it may be as simple as clicking on the town tile, setting a couple of properties, and trying it out. Suppose it turns out now that 5 towns total wasn’t fun – we should have had 2 instead. Again, with the old game it’s a 5 minute job to adjust the map. In the new game this takes several weeks (have to place trees in place of the old town). Plus, due to the sunk cost fallacy, we may leave the towns in anyway just because it was so much work to put it in in the first place. Maybe rather than removing them the artists just tweak them a bit.

This is why in shooters you don’t see fun levels like in the original Doom anymore. In the original editor I could move a wall in a couple of minutes. In a modern level, this takes 10 times as long.

Fortunately, I think there are ways to mitigate this problem.

First, there is absolutely no excuse for not always working on top-of-the-line equipment. Suppose an employee loses 10 minutes a day due to hardware. This is roughly 40 hours a year, or one week’s pay. At least at my wage this is the cost of the absolute best computer on the market. I currently lose about 2 hours a day due to hardware.

Artists should create levels using only the default Maya objects. Trees should be pillars. Mountains should be triangles. Walls should be cubes. The game should be playable and fun before ever creating a detailed asset. Some final work can be done of course. For example, the character’s model is far less likely to change than a level layout. So it’s not like you have idle artists. Just keep the things that will probably change flexible.

Gameplay programmers should either have a way to very quickly change and link code (such as linking with DLLs) or else use debuggable scripts reloadable at runtime. If using code, it is critical to have a mechanism to change run-time values at run-time, such as debug command console.

Anyway, as I’m soon going into business for myself I’m going to put these ideas into practice.

If I’m lucky I’ll soon have enough work with RakNet that I wouldn’t be able to handle the workload by myself anymore. That means I’ll be in the hiring market for a bright graduate, someone talented, trainable, and willing to work cheap, at least until business is at a point where I can afford a raise.

Anyway, I’ve been debating internally how many checks and structure to give to a remote employee.

At one end, there’s my own first job out of college as a telecommuter. There was essentially no structure. I didn’t have to write reports. I had a very high level task (write the networking) but never had to write design documents or anything like that. I essentially decided on my own tasks, when I wanted to do them. I even used my own data structures and such in my own code, even though the code base already had data structures.

At the other end I could impose structure similar to my job now. Daily reports. Meetings. When you get a major task you are generally expected to write a design document first. What you work on is given to you in a schedule. (This is still very lax compared to some other places.)

The problem with the first approach is that you need someone who is very good and self-motivated. It would be of no benefit to me to hire someone who made a mess of things and I had to go back and have them redo it, or do it myself. In both cases neither of us will be happy. Similarly, without daily interaction and deadline pressures it’s easy to just have your telecommuter just do nothing, which is wasted money. However, when it works it works great. I considered that the best job in the world, except for the pay.

The problem with the second approach is that it’s essentially a waste of time – all that structure is designed to keep bad programmers from doing bad things and not working. At best it’s annoying to a good programmer and not motivating at all to work on something you don’t want to. You bleed programmers who think the grass is greener on the other side. However, since you always know what your people are working on you don’t get slackers who do as little as possible for years (which also happened at my first job).

This may change with time and experience, but I think the best approach may be to hire the best and trust them to do their best. Guide, rather than force, people to your goals through proper motivations such as giving them options on what to work on (and all the options are useful to you). Explaining why things need to be done rather than telling them to do it. Giving them freedom to make important decisions, both in programming and in game design. I think intrinsic motivations (the desire to do a good job) are more important than extrinsic motivations (money, bonuses) and it’s important to motivate people using the former, while still having the latter as a bonus for a job-well done.

Ogre 3D doesn’t have native functionality to display debug text. So I spent a half day adding a layer to their overlay system to make it easier to use. You can now do the exact same thing with half the lines of code, no loss of functionality, and with greater safety, including automatic memory handling. This is essentially free in terms of speed.

I now got text showing up and fading out over time. But then I found out Ogre3D also doesn’t have the ability to do automatic line wraps… Or positioning of multiple lines of text.

It looks like the way to go if you want debug text in ogre 3D is to use CEGUI. It already handles line wrapping and I’m pretty sure it also handles multiple lines of text. If it doesn’t do what I need I can write my own text positioning system in a day or so.

I’m at the point where I need to design the high level architecture for my game. What classes will there be? What operations will they perform? How will they relate to other classes?

The problem is that my answer is usually “I don’t know” or “I don’t know very well.” I can roughly say that “It’s an MMOG game so it will have a client and a server.” That’s true, except it’s not very useful information. For example, it’s wrong to say I have “a server” because for scalablility I plan to use server clustering. And what is a client? There is a game client for sure, but there are or may be remote administration clients or logging clients as well.

So I can’t really design the whole game architecture on paper right out. The human mind just can’t explore every possible detail in advance. So how about extreme programming? In XP you have a shipping product pretty much every week. And you build on that project from week to week. This isn’t a bad approach and it’s certainly better for motivation. At the same time you can’t totally ignore high level goals. If I were to do that using a simple minded approach I would hardcode it to have just one server, which means eventually I will have to go back and change code I’ve already written, wasting time. Changing old work that already works tends to be harder and more buggy than writing work the right way to begin with too.

So what’s the solution? For me, it’s an extension of the design principle I already use, which is “Don’t make decisions that have exceptions.” In this case it’s more like “Don’t make decisions I’m not absolutely sure of.” That’s a good starting point because it gives me code to work from. Some things I’m sure of:

1. I’ll need the ability to enter text into windows for chatting.
2. There will be at least 3 systems – a game client, a game router, and a game server
3. For ease of testing I want to be able to run a server locally in the background from a client.
4. I don’t want to include most of the server code when I release clients

So this actually gives me something to work from right away. I can create 3 classes, I can design those classes for code exclusion, and I can write a chatting system in the game.

Based on those modules I can think more about the problem and design other modules.

The positive results of this system are first that I don’t get paralyzed trying to think of what to do. Second, I’m unlikely to waste or redo work. Third, and most importantly, it forces me to carefully think about my systems and not gloss over details.

This is what works for me. Feel free to post your own ideas.

I have 4 systems running now. I need to integrate RakVoice with fmod next.

I would have had all this done yesterday except that I spent a huge amount of time trying to get Ogre to work from source, instead of using their framework. Eventually I gave up on that idea.

I thought it would be a simple matter to get the GUI on the screen but it seems like that’s one of the hardest things to do of all. I think I’m going to have to write a wrapper for Crazy Eddie’s GUI system because there’s a ton of code involved to do things that should have been automated. For example, mouseover and mouseoff highlights, setting callbacks for various operations, and such. You have to load the textures yourself even. With as much as you have to do yourself I’m not sure what functionality Crazy Eddie’s system even provides.

The system I had in Irrlicht was much better. It was one line of code to add a GUI element and it did everything else for you. Rather than having to create a class and then setting and writing callbacks for each button I just handled an event in a switch / case.

I build Ogre + dependencies into a static lib in Visual Studio 2005. The resulting .lib was 1,445,853,944 bytes. In fact I had to use a special flag /expectedoutputsize:50000000 or else the compiler incorrectly reported “LNK1106: invalid file or disk full: cannot seek to 0x76364” It also took minutes to link.

The same thing, built as a DLL was 7,921,664 bytes and the lib was 2,983,094 bytes. It took less than a second to link.

fmod is the RakNet of the audio world.

From looking at the website to getting it running in my game was 15 minutes.

It compiled and ran as I expected the first time.

It was documented.

The sample actually worked and was easy to follow.

I didn’t even have to write a wrapper!

$5000 is pretty steep for a commercial license but the shareware license at $100 is well worth it. I’ll be registering.

OpenAL has to be the worst packaged library I’ve ever used.

The distributions are different between the SVN, the downloadable installer, and the source download.
There is a downloadable installer for a library to begin with, which makes no sense.
The license terms for the downloadable installer are draconian.
The library is split among 4 projects, each with different settings, which output to 2 .libs with no explanation as to why or what the differences are. The actual library takes 2-3 .libs depending on which one you download, which in turn takes 1-2 dlls, again depending on which one you download.
None of the three dowloads work without modifications.
Each of the three downloads only contain a subset of the code, meaning you have to download all 3 anyway and then figure out how to put them together.
The tutorials don’t run because they require a DLL that isn’t included in any of the distributions.
You can’t build static libraries or directly include the source without modifying the code.
Version 1.1 is utterly incompatible with older versions and in fact seems to have less features.
The documentation is so out of date that it is flat out useless for that functions that it does cover, which is only a minor fraction of the actual functions.
The code does not include useful user documentation in the headers so you have to just guess what the functions do.


/* Create Source objects */
AL_API void AL_APIENTRY alGenSources( ALsizei n, ALuint* sources );


Um thanks…

Out of all the libraries I’m including in my game engine, by far I’ve spent the most time trying to get OpenAL working. I’m about to just say screw it and use fmod instead, even though fmod isn’t free.