Testing, Testing...

[This blog post was written by Taylor Eshelman, one of our artists (and sometimes testers)]

My job description is "artist." I bill myself as a "technical artist" since I have a technologically savvy streak. I've even branched out into design here and there, most notably in an extracurricular collaboration project that's a variant of the "game in a day" that we did a while back. Today, though, I'm a tester.

Yessiree, I'm a QA drone. I've argued it before, and I'll do so again: Game testers don't get anywhere near enough credit for what they do.

In many ways, the QA (Quality Assurance) people are the last line of defense in game development. It's nearly impossible to ship a game with absolutely no bugs, but games that ship with egregious problems fail quickly and may never recover. Vanguard had a terrible launch, but has since been polished and refined into a much better game. Even so, that initial impression of a game that was literally broken in several ways has lingered, killing the early adopter buzz which can be so crucial for hitting sales targets. Gamers can be terribly fickle and judgmental, and a poor first impression (or a bad early review or two) can sink a game, whether that impression is well deserved or not, and whether or not real complaints are addressed adequately. As in so many other aspects of life, a "best foot forward" approach is crucial for games.

QA testers are the safety net for the game development process. There are so many cogs and fiddly bits that come together in any software project that there will almost inevitably be things that don't mesh well. The only way to find many of these problems is to play the game. Over and over. And over and over.

You see, game testing QA isn't very similar to the end user experience. QA people have to repeat the same procedures many times, trying to suss out how things might break. They actively try to break the game, which can include doing normal "gamer" things, and more, by doing really weird stuff. (You know that someone out there will do something so totally wacky with your game that they will break it in ways you never would have thought to test... but you still try to test as much as you can to head them off at the pass.)

That's inherently different from trying to "beat" a game. QA people do have to keep the concept of "fun" in the back of their mind, and notions like "balance" and "emergent gameplay," but for the most part, testing means actively trying to find *problems* in a product, not trying to find *fun*. That's why it's a job, and why it takes unique skills. That's not to say that "gamers" can't also be testers, just that the two aren't equivalent.

The writers over at the Elder Game blog rightfully point out that QA isn't something that is best done in a vacuum. Testers need to know how the game is expected to work, in order to try to break it. That may seem obvious, but it's an application of the "thinking outside of the box" cliche: in order to try to stretch an idea or game outside of its box, you have to know where the box is in the first place. The Elder Game article describes this in more depth, so I highly recommend popping over there to see what they have to say. Long story short, the designers, engineers and artists need to work with the QA department to make sure they have the tools and expectations to properly put the game through its paces. (The old "It's a feature, not a bug!" argument after the fact doesn't work all that well.)

Yes, ultimately it's the engineers and artists that create the content and string it all together into a coherent package, but they will inevitably mess something up. We aren't perfect. We're relying on testers to catch the things that we missed. We certainly self-test a fair dose of things, but sometimes bugs don't even show up until things start coming together. The project that I've been working on has unique bugs that show up when the code goes from the PC where I worked on the content to the final game platform (a different bit of hardware). I'll never see certain problems testing things on the PC, despite doing all I can as an artist to make things correctly and test them before committing changes to the database.

Even in an age of "ship now, patch later", good QA is vital to getting things as right as possible for the initial release. Games are such transient bits of entertainment that a buggy product can totally miss the window of opportunity on the market, even if it's fixed later. As such, good testers are often a key component to financial success (between content creation/coding and marketing), which, at the end of the day, is what keeps food on the table.

Game development is an organic process with a lot of give and take. QA is a crucial component of that refinement process, and I, for one, find a great deal of responsibility in the role, and a great deal of appreciation for those intrepid souls who do it day in and day out, often toiling with little recognition.

-Tesh

Intro to 3D Studio Max Class

[This post was written by one of our designers, Mike Nielson. Thanks Mike!]



The teacher for this class was the lovely Shannon Blitz, one of our artists. Basically, NinjaBee decided to do this class, per Shannon’s request, as a response to designers and programmers ALWAYS having to ask artists to make temp art for them when the artists have better things to do. In Shannon’s own words, “laziness” was the motivation for this class.

The class basically covered the basics of how to create simple 3D objects in 3D Studio Max. We started by talking about how to create what are called “standard primitives” – shapes like boxes, cones, cylinders, etc. Next we talked about how to edit said shapes. This included rotating, moving, sizing, distorting, mirroring, etc. We also talked about how to attach simple objects together to make more complex objects.

The next phase of the class was a low-level rundown of how to texture (apply color to) an object. We pulled out the materials editor, unwrapped our UVWs and went to town. It was most informative.

Finally we discussed how to export objects from Max into game projects. She showed us step-by-step how to export objects from max using the NinjaBee exporters. She also walked through how to put .png textures into projects and how to get objects showing up in the game viewer.

It was a pretty awesome class for designers, programmers, and others that have had little exposure to the labyrinthine miasma that is called 3D Studio Max. The basics were covered nicely and I think that I and my fellow designers/programmers are much closer to creating ugly temp art of our very own to be used in future games.

Texture Optimization Class

Last Friday one of our artists, Taylor Eshelman, gave an excellent, in-depth class on texture mapping using 3DS Max and how to optimize it for a production pipeline. For those who are interested, here are the basic speaking points from his class (written by him):

1. Plan Ahead: Without a fairly clear idea of where you're going to want to wind up, you will waste a lot of time, and will probably wind up wasting vertices, pixels or both.

2. Reduce, Reuse, Recycle: We can and should recycle art assets when working in CG, not only because we can, but because it can reduce development time, asset generation and maintenance, and project data footprint. We should use the idea of "object oriented" texturing where possible.


3. Making the Most of Assets: A consistent philosophy of optimization will often mean the difference between high polish and "good enough", especially if you can squeeze in that last cool visual because your optimization strategy made room for it.

4. Vertex Count vs. Pixel Count and Tileability: Making the most out of assets will often mean finding ways to use the model, texture and vertex color (and maybe normals) together to produce effects that might otherwise be done independently, and more expensively. Tiling textures may get a lot more mileage with careful modeling. Every pixel and vertex needs a reason for existing.

5. Waste vs. Warp: Warping things this way can reduce the waste that comes from UV mapping anything more complex than a cube. That said, it's still best to minimize warp by "normalizing" the UV space for polygons, counterwarping the polygons into the UV interstitial spaces.

6. Decal vs. Wallpaper: Some UV layouts present the model as a series of "shells" that each have unique UV space. Contrary to that idea is the wallpaper method, where a texture is designed as a purely tiling bit of art, usable across any of the UV boundaries.

7. Detail vs. Budget: This is especially important if your texture will need to be used by more than one Level of Detail. Low resolution models often have different UV limitations, and the layout will change. Making textures that can be used by varied UV layouts will sacrifice some detail, but will extend usability, lowering processor, footprint and dev budgets.


8. Prerender vs. Pipeline: Even games can benefit from some prerendering, at least when it comes to baking lighting into vertex coloring. Any preprocessing that we can do will aid the game engine.

9. Schedule vs. Polish: Repeatable textures that get used in many different models (with clever cheats to disguise the reuse) means the asset management and art direction are often easier to work with, since things are centralized. (That's the object-oriented model again.)

The Golden Path: There isn't one! The concepts here are just guidelines that will inevitably need adjusting for each project. Even working for a consistent hardware platform doesn't ensure consistency, as the software engine you use may change over time. What I hope to give here is a toolset and principles rather than a blueprint that will inevitably be outmoded.

Art Class

In the past, we have held art classes to improve our artists' abilities and let other people in the company learn new skills. We hadn't done any for a while, so last Friday we started it up again with a figure drawing class taught by Jamin, who was our lead artist on A Kingdom for Keflings.



He brought in some materials to serve as a refresher course on the basics of figure drawing. He also showed us how to use a knitting needle to measure proportions.



Here's our lovely model, Shelly....



...and here are some drawings in progress: