- [Caveat] If you send a link, make sure your website is up and available. There’s nothing worse than going to view someone’s portfolio and getting a “this user needs to renew their account” message. An attachment is still better than a non-working website.

- Tell me what you’re applying for, especially if its a cold contact.

- If you have a video, use a codec you know is pre-installed on most computers -OR- provide a link to where the codec can be obtained from. A codec that’s pre-installed is the better of the two choices.

- On your reel, be specific about which parts are yours. This is especially important on group projects. A shot list is helpful.

- Ditto on code samples.

This is by no means a comprehensive guide, but if you’re looking for a job here are a few quick tips I can share from my own perspective from the hiring side. These are some of the top things, good and bad, that I see every day when I am evaluating potential candidates.

[Required disclaimer: This is just my personal opinion on hiring practices, not official policy for any company including my own! Different hiring managers use different criteria and techniques. Use your own best judgment when preparing your application.]

- Have a demo reel, portfolio or code sample. I can’t emphasize this enough. I’m going to be dead honest: I generally watch reels all the way through before I even open the attached resume. I may even watch your reel before I read your name. I don’t care how many years of experience you have if your reel is crappy… and vice versa, I’m more likely to give someone with little or no experience a shot if they have a really brilliant demo. In the end, we want to hire people who can produce a superior end product regardless of how you acquired your skills, and the best way to prove to me you can do that is to show me a great example of an end product.

- Your demo reel only needs to show what it needs to show. Or, to clarify: if you’re an animator, a reel with untextured characters or stock textures–as long as they are credited–is perfectly okay. If you’re a programmer, a well-written class file is enough. I don’t need to see a whole game or movie. I just need to get an idea of what you can do. In fact, this is especially true for programmers. Many programmers send compiled binaries and no source code. A compiled binary doesn’t tell me very much. I’d much rather have a sample of well-written code even if it doesn’t compile because the rest of the app is missing than a pretty demo with no source and no idea if it’s a rats nest under the hood.

- If you are a programmer, comment your code. An uncommented demo is an instant fail. If can’t bother to comment your demo why would I believe you would comment your actual source?

- Write a cover letter. It doesn’t have to be long or elegant; in fact, it’s better if it’s brief. Give me the “highlights reel” before I view your portfolio or resume. Tell me the one or two very best things about yourself that make you a better candidate for the position than anyone else. It gives me an idea of what you think I should focus on when I read your resume.

- Don’t call my desk line, but it’s okay to send me an e-mail even if we don’t have a job listing posted. It’s not that I don’t want to chat, it’s just that I’m much more likely to be frazzled and in the middle of something if you call me unexpectedly. [Edit: For clarification, I mean cold calling. Regular calling when I expect you might is okay, naturally.]

- Freelancers [sometimes] have better chances of getting work, especially if they aren’t looking for full-time. There are two reasons why freelancers are desirable: The games industry is very seasonal in nature with lots of ups and downs. We may not have enough work or the budget for a full-time employee, but we may have specific projects that need done. (And, oddly, small projects often have a way of leading to more work…) Secondly, hiring people is just darn hard. It’s heartbreaking (really) to hire someone who doesn’t work out, and nobody likes doing it. Contracting is often a good way for both parties to see if the other will be a good fit. If it turns out there’s a ton of work to do, you love what you’re doing, and we love your work, then when a full-time opportunity does present itself it’s a much easier jump. Now to be fair, I know contracting is not for everyone so it’s by no means a requirement, but if you were thinking of freelancing already it’s worth considering. ** This tip may or may not apply to certain companies. Some companies never hire freelancers. We use freelancers frequently.

- If you send your resume as an e-mail attachment, put your name or something identifiable in the file name. Don’t name it “resume.doc”. “jane_doe_resume.doc” is much better. Resumes always get saved off to disk before reading so they can be virus-scanned first. Putting your name in your resume file name makes it stand-out when someone is searching through the folder of virus-scanned resumes for yours.

The first plugin, Set Material by Crease Angle, sets the materials of a model based on the crease angle of the mesh. For each selected area, the plugin creates a new color in the palette and “flood-fills” the area until the angle between the surfaces exceeds the crease angle of the mesh. The result is that contiguous areas are all set with the same palette material, and a new material is applied wherever a discontinuity occurs. This allows you to easily break a model into sections along its creases for easier texture mapping, or many other purposes.

The second plugin, Planar Map by Material, actually includes three new commands.

The first command is Fit UV Coordinates to Map. This command is essentially the same as the “max” button in the TCE, forcing all UV coordinates into the 0-1 range, but unlike “max” this scales the map proportionally instead of independently on each axis.

The second command is Adjust UVs for Bilinear Filter. This is useful for game developers. This command scales your texture coordinates by a ratio of 240/256. The purpose is to create a small seam along the edge of the texture map so that if your game is using mipmapping with a bilinear or trilinear filter, the texture won’t bleed into its neighbors in your texture cache nor will it bleed into itself if you haven’t clamped the edges.

The last command, Planar Map by Surface Material, is probably the most useful of the three. Planar Map by Surface Material applies a “best fit” planar projection to all surfaces grouped by material in the current selection. If you section your model by material, this will treat each material color as a contiguous group and apply whichever planar projection fits it best in the TCE. You’ll still need to do some manual adjustment after you map it this way–especially texture packing, as this leaves plenty of room between areas so the surfaces aren’t too difficult to select–but it can save a lot of time in laying down a base mapping before you manually refine each area.

More information about each plugin is available in the readme.

Download the Material by Crease Angle plugin. (Requires Windows XP, AC3D 6.2 or above.)

Download the Planar Map by Material plugin. (Requires Windows XP, AC3D 6.2 or above.)

Yeah, I know, clearly I’ve had threads on the mind a little too much lately. I’ve been working on a major refactor of the engine at work and thread synchronization problems are tricky.

Usually when I have dreams like this I wake up in the morning and have a good laugh wondering what the heck I was thinking. This time, however, I think there may be something to it. Now, I’m not suggesting a design built literally on the model exactly as it is in the dream but I think there are elements that could be useful.

The part that is intriguing about the turret defense thread model is that you can guarantee completion (all units hit) without guaranteeing really very much at all about either the turrets or the units. The units are not synchronized with each other; in fact, in many tower games faster units can overtake slower ones. A unit does not guarantee a minimum speed–it may even be allowed to stop entirely on occasion–although it does guarantee a maximum speed. The turrets are not synchronized with each other, nor do they communicate any information to each. A turret does not guarantee a specific number of units hit, only that it will hit units at a specific rate. A turret also does not guarantee what order it will fire at units in. A unit likewise guarantees nothing about when or by whom it will be hit except that it can be hit when it is within a valid range.

Yet, with a sufficient number of correctly placed turrets all the units will be hit with none escaping. More importantly, most of the time you can have far fewer turrets than units and still complete successfully. The number of turrets required is a simple function of the maximum speed of the turret, the maximum speed of the unit, and the number of times the turret must hit the unit for completion. Placement is trickier, but with a thread model you could surely replicate that with signals.

Fascinating, isn’t it?

I’m not sure yet where to go with all this, but it seems like there’s a useful idea to be gleaned. It’s not that different that a traditional worker pool, but the lack of communication seems important. I’m sure there’s something useful that can be done with this.

1. For anyone who cares, the specific game seems to be Crystal Defenders, but with some elements of Bloons Tower Defense 3.

Somehow I was out-of-the-loop on that one, so the release caught me by surprise. I like to watch videos on the Wii sometimes. I don’t use the Wii for web surfing regularly, but now and again the comfort of flopping down on the couch instead of sitting in a desk chair at the computer more than makes up for the small screen resolution of the television. Today when I went to YouTube, however, I was greeted by an all new interface. Designed specifically for consoles such as the Wii and PS3, YouTube XL is a smaller, sleeker interface targeted specifically at television viewing.

I must say, I found YouTube XL a big improvement for game console-based video browsing. It seems many of the early reviews are mixed; many reviewers seem to be complaining about some of the missing features such as comments. Honestly as someone who actually uses YouTube on a game console on a semi-regular basis I think the new UI is far more practical. Certainly there are some missing features, such as comments, but I can’t really imagine tapping out a comment with a joystick anyway. Frankly I even avoid the search box when I can. (Thank goodness for auto-complete the rest of the time.) The far improved use of screen real estate plus larger, easier to target buttons made for a much more pleasant viewing experience. The new YouTube XL isn’t a replacement for PC-based video surfing, but it’s a nice alternative when a comfortable seat on the couch beckons. I vote thumbs up.

In a nutshell: the problem is you can’t tape a cupholder to a formula one race car and declare it street legal. It still doesn’t have any bumpers, it’s too low to be safe around other cars, and if you aren’t an expert driver you still shouldn’t be driving it. A cupholder doesn’t change that.

So what? A cupholder is still an improvement… right? Who doesn’t want a cupholder? Imagine for a moment that having the cupholder suddenly disqualified you from a number of races. You couldn’t run that race if you have a cupholder. It also slowed down your car–not a lot, but a tiny fraction of a second. Maybe it doesn’t slow it down enough to matter, but in those few races won by hundredths… well, maybe it does. Suddenly that cupholder doesn’t seem so nice.

To be clear, I’m not suggesting giving up on attempts to improve memory management and prevent buffer overruns. I just question if this exact approach was the best one.

Memcpy_s is basically a race car with a cupholder. While memcpy_s will certainly prevent some bugs, the same people who got one parameter wrong are just as likely to get two parameters wrong… and cause all new bugs in the process. Garbage In = Garbage Out. It doesn’t matter what the calling convention is.

On two occasions I have been asked,—”Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” … I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.”

— Charles Babbage, 1864
discussing the first mechanical computer

The change also comes with a price: it breaks cross-compatibility with other compilers, including older compilers on the same operating system as well as other platforms. This means the same code can’t cross-compile anymore if you use memcpy_s. Someone with Microsoft suggested that GCC should pick up the change as well. Perhaps, but that assumes that GCC is the only other compiler that matters. Certainly, it’s the most popular other compiler that matters, but it’s far from the only one especially if you do embedded systems work or anything running on “exotic” hardware. And let’s be honest–if you’re not writing something that’s fast or exotic, you’re probably not writing it in C. The exception, of course, being legacy code… but surely that’s even less likely to be changed. The whole point of legacy code is that you don’t have the time\budget to update it, otherwise you wouldn’t be running it at all. These are the guys who will wrap memcpy_s in a macro named memcpy, defeating it entirely. Sigh.

As for that speed difference I mentioned? We’re obviously only talking about an extra comparison operator and perhaps a branch or two here. I know an extra comparison operator seems trivial, but if an extra comparison operator didn’t matter ASSERT macros wouldn’t exist. The speed difference is nominal, but it’s very, very real. On a lark I timed it. Copying 32 bytes 100,000 times with memcpy took on average 3952 counts, or about 0.001104 seconds, measured to nanosecond accuracy with QueryPerformanceCounter. Performing the identical operation with memcpy_s took on average 9706 counts, or about 0.002712 seconds. This was in “release mode” using Visual Studio 2008. (For the curious, in debug mode the difference averaged 8028 counts to 11340 counts, but you shouldn’t be shipping your code in debug mode anyway!)

Now hopefully you’ve done everything you can to avoid memcpy in your inner loop in the first place, but we all know there are rare occasions where it’s unavoidable. This all brings me back to my earlier point: if you’re not writing something that’s fast or exotic, you’re probably not writing it in C. Yes, you can write your own memcpy that’s probably faster than the system memcpy if you’re really worried about speed, but now we’re back to the portability issue. In short, I’m certain that to the people where the choice of language matters, those few clock cycles matter too. We’re talking folks writing device drivers here, not business applications.

Nobody is twisting anyone’s arm to use memcpy_s. You can easily disable the compiler warnings and continue to use memcpy all you like. But hopefully you see where I’m going with this: A lot of the reason that people continue to use C for certain projects has to do with performance and portability. This change sacrifices both for dubious return. If the change is not going to have tangible benefits that outweigh the problems, why do it at all?

Sooner or later, you need to trust that the programmer knows what they are doing. If the programmer can’t manage memory responsibly, you’ve got a bigger problem than an extra parameter is going to fix. To be honest, while a lot of people don’t like to admit it programmers sometimes leak or botch memory even in managed languages. There’s certainly a thesis paper or two in “possible alternatives” to the approach taken–perhaps checking the block size by querying the allocator instead of asking the programmer which would be even slower but more reliable, borrowing ideas from double entry accounting, etc, etc.–although the “real” fix surely involves more intelligent ways of thinking about memory, which realistically means a fundamental change in constructs, not a patched function.

As always, XKCD sums it up best (panel #2):

Ah, I wait for the day…

Making a sculpted prim wine glass for Second Life is equally fun. In fact, it’s almost exactly the same except you need to UV map it before you upload it. A simple cylindrical map will do. Here’s a video to show you how using AC3D.

Click to download video

Here are the UV map settings I used.

When you import it into SL, be sure to set your mapping mode to cylindrical. If you don’t, the top and bottom of the glass will be solid instead of hollow.

Set the Stitching Type to Cylinder.

Download the model here.

Either the PZ3 or the OBJ can be used for importing a model into Poser.

The PZ3 is “pre-rigged” using the AC3D hierarchy as the skeleton and the AC3D object centres as the joint pivots. The PZ3 allows you to see working joints right away, but obviously the joints won’t be weighted as nicely as if you did it by hand. For this reason, I’d recommend starting with the OBJ file and building your skeleton in the Poser setup room instead unless your final output is a game engine or something else where Poser’s blend weights don’t matter. Like the Milkshape plugin, the Poser plugin supports null pivots. Any mesh in AC3D named “NULL_[whatever]” is treated as a null pivot so you can do “fancy” rigs if you need to. There are additional instructions in the readme.txt included with the plugin.

Download the plugin. (Requires Windows XP, AC3D 6.2 or above, Poser 6.0 or above.)

I’ve also built a sample file in case you need a working example of how to build your model.

Download the sample model.

In the sample, I’ve taken the perfume atomizer that comes in the AC3D stock model library. (You can load the original by clicking File > Library inside of AC3D and loading it from the samples folder.) I’ve re-rigged the atomizer so it can animate, then exported it using the Poser plugin. After import into Poser, I applied my materials, set the lights and tweaked the skeleton. All of the files are included so you can see each step.

• atomizer-rigged.ac – the rigged version of the atomizer from the AC3D library.
• antomizer-rigged.pz3 – the unedited poser file exported by the plugin (yes, I realized belatedly I spelled it wrong, but I didn’t want to fix all the file links, doh)
• atomizer-final.pz3 – the final file in poser, with materials applied and joint limits, etc., set

If you’re into building Poser models in AC3D, I would also recommend Dennis’s Poser Morph Target Assistant. The morph target assistant, as the name implies, will allow you to add morph targets to your Poser figures.

Enjoy!

[If you're waiting for a reply from me on something, I promise I haven't forgotten you. I'm still re-installing and it's going to take me a few more days to dig my way out.]

While I don’t subscribe to nearly as many newsletters as I used to — most of my news-ish stuff comes in the form of RSS feeds these days — I still subscribe to a few. Here are some tips if you’re writing a newsletter that will decrease the odds that I’ll delete it without reading it:

• Don’t change your “from” address. I white-list only those newsletters I want. If you change your address without telling me first, your newsletter will be deleted as spam and I won’t even know it.
• If you must change your e-mail address, tell me before you change it. Sending me a “we’ve changed our address” message from your new address is an instant FAIL. I’ll miss it because your new address isn’t white-listed. I can’t believe how many people don’t think about this one.
• A unique per-user ID in the subject line helps me tell your newsletter apart from phishes that look just like it. If I get too many phishes impersonating your newsletter, I’ll probably just unsubscribe it. I know it’s not your fault, but I don’t have the time to spend sorting out the fakes. A unique per-user ID in the subject is a very fast, easy way to make it obvious which messages are probably real and which are almost certainly fake.

I just read two fantastic essays describing programming as a dream-like state. I’d never thought of it this way before, but I’d have to say that’s the most dead-on accurate description I’ve ever heard.

Now, imagine you were in deep sleep, dreaming away about apples at 3am, and I came bashing into your room and said “Sorry, but we need you to dream about bananas now.” Do you think you could go straight back to sleep in a few seconds, dream about bananas for a bit, and then jump back to your original dream about apples? No, of course not, but this is what managers expect when they throw new tasks at us while we’re busy coding the first one. When this happens we’ve lost the hours we’ve spent on the first dream, we’re completely lost for half an hour, and then we eventually manage to get into the new dream.

–How Software Developers Work

This is very true. It takes a little while to “shift gears”. For small programs, it’s not so bad, because you can conceptualize the whole thing in a few minutes or seconds. For large systems it takes longer to get yourself back into the right frame of mind. You have to think about all the things you were thinking about when you put it down last, and this is often a lot harder than it sounds. There’s a small time penalty that’s paid every time a programmer sits down to work, but it’s only paid once per session. This is why a lot of programmers prefer to work in one long stretch instead of several short ones. In six 30 minute stretches, zero code will get written–zero good code, anyway–because you spend the entire time just getting started. In one three hour stretch, however, you might just compose a masterpiece.

I can sit down and start coding right away, but I don’t really “hit my groove” for an hour or two. Sometimes I try to accelerate that by leaving myself a thread the day before. I’ll intentionally not finish a block of code I was working on, but I’ll leave myself copious notes on how to write it so that when I sit down in the morning I can start right away on that block. In the morning I don’t really have to think about the block too much because the answer is right there, but by-and-by as I code it up the thoughts start rushing back to me. By the time I’ve finished writing the block, my head is where it needs to be and I can pick it up from there. Sometimes if the code is very complex I just keep thinking about the code until morning. Most programmers can and will do this, too. Some perhaps can’t hold onto the code for days or weeks, but virtually all can for a few minutes or even a couple of hours.

I know it sounds strange, but think of it this way: Have you ever had a dream that lingered? You know, when you have a nightmare or other intense dream, and it keeps coming back to you while your doing other things throughout the day? Your mind is still dreaming the dream even though you are awake, and you can feel it back there drifting around. Keeping code in your head feels very much the same way.

There’s a right and a wrong way to interrupt a programmer. The best answer is “don’t”. But if you must… If you think about programming like dreaming, you’ll realize that programmers remember more if you interrupt them gently than if you barrage them. If someone wakes you out of bed and starts shouting a long list of things at you to remember, you’ll almost certainly forget what you were dreaming. However, if someone shakes you gently and gives you a few seconds to open your eyes and look around before they start talking, it’s a lot easier to remember the dream for later. The same works for programmers. If you just walk into their office and start talking, one of two things will happen: they’ll completely forget what they were coding, or they won’t really be paying attention to you. However, if you quietly walk up to them and let them know you are there but say nothing until they are ready, the programmer can come to the end of the thought they are on. Once they’ve finished their thought, it will be easier for them to pick up next time and still pay attention to what you have to say.

Let’s take a maze for example. There is a task for the programmer to come up with an algorithm of finding the way out of the maze. When a programmer is working on this task he isn’t just a God’s Finger showing the directions to a little girl lost in a great maze. He isn’t that girl or the walls of a labyrinth either. He is actually all of that in a same time. In order to solve the task he must BECOME the labyrinth, the walls, the lost little girl and whatever else may just came along with it. It is not a figure of the speech – the programmer is literally SLEEPING and DREAMING that all in his mind.

–Don’t Wake Up the Programmer

My brother contends that it is this same phenomena that makes programmers so bad at estimates. The problem is, as he says, that the programmer already knows everything that needs to be written. When you have it all in your mind, it seems like it should be easy to write it all down. But it’s not. The physical act of writing the code takes a long time. But more importantly, your mind never thinks about all the “meaningless” details. It knows how to code them so well it doesn’t even need consider their existence anymore. Unfortunately, the computer still needs them. It can’t infer. All those loose ends, niggling details and corner cases end up eating a great deal of time… sometimes more than the rest of the program.

How does programming feel to you? What is your experience like?