Frayed Knights and 3D Worlds - More Trouble Than They Are Worth?
I keep ranting about the same subject, I guess. I keep re-discovering how painfully slow even fairly simple level / interior creation can be. Even for a simple, low-detail RPG like Frayed Knights. I get really jealous of those tile-based games where an entire map can be put together in hours.

I've gained some speed and, I think, quality as I keep working on things (I'm kinda embarrassed about the Tower of Almost Certain Death now...). But it's still astonishing to have worked on a relatively small part of the map - wall piece by wall piece, basically - and then look at the clock and realize that over TWO HOURS have passed by, On a map I thought I could "whip out" in only six or eight hours, total. Yeah. Time to multiply my estimate by at least four.

And that's not including going back later to make that sucker look GOOD. For flexible definitions of good.

You think I'd learn.

I'm trying to imagine how, in my wildest dreams (which maybe aren't wild enough), this game could possibly turn enough of a profit to even earn minimum wage (and we'll go by minimum wage a couple years ago, not even the new minimum wage now) on the time I've put into it. Let alone the time my fellow team members have put into it. I would love to be surprised and have my world rocked, but in all likelihood - it ain't gonna happen.

We've tried a few things to speed things up - like creating more pre-made pieces - but so far it's just not given us the time and effort savings we hoped for.

There's a reason indie game development is a labor of love. And I really do have a lot of fun doing it. I just wish I could figure out how to get it done... faster.

Labels: Frayed Knights, game art

- posted by The Rampant Coyote @ 4:59 AM (Permalink) 14 comments links to this post

 
Top Ten Texturing Tips
An experienced vet passes on his accumulated knowledge on good 3D texturing:

Top Ten Texturing Tips

Had tip to Edward Maurina (author of the Game Programmer's Guide to Torque) for the link!

Labels: game art

- posted by The Rampant Coyote @ 7:12 PM (Permalink) 1 comments links to this post

 
RPG Design: Somebody Call the Dungeon Architect!
You know, it was a lot easier back in the 80's when I was just making dungeons with pencil and graph paper.

Back in '88 or so, I was at a science fiction and fantasy symposium with Tracy Hickman, co-author of the Dragonlance novels (among many others), as well as the famed Ravenloft module for Dungeons & Dragons. He gave a few talks both on writing and publishing, and on role-playing games. Though he's nowhere close to being my favorite author, his comments were very valuable and enlightening.

Among his many topics, he talked about creating maps for the players. He said, "Have you ever tried to actually to envision or model one of the maps from the earlier modules in 3D? Like any of the castles? If you do, one thing you'll discover very quickly is that they are dumpy! Very squat and flat. That's not very realistic."

Apparently, that was part of his goal with Ravenloft, which includes a very tall castle with a lot of use of vertical space. "If you want to confuse your players," he explained, "give them a lot of vertical movement. They'll inevitably get mapping errors, and become convinced that they've run into some kind of teleport trap because nothing is lining up right."

That's mainly because the maps were done on plain ol' graph paper, encouraging a very flat, top-down design. In fact, the use of vertical movement was such a special case that in the early editions of dice & paper Dungeons & Dragons, difficulty (and treasure) was based almost entirely on how many stairs you had descended - your "dungeon level."

The CRPGs I fell in love with in the early days of the hobby often used a player-eye (or mouse-eye?) perspective of dungeon maps in sort of a fake 3D view. Not too unlike the perspective indie RPG Cute Knight Deluxe offers. But again, the dungeons were flat maps in 2D space. Stairways, ladders, pits, and so forth were simply objects that appeared that took you to different levels. The encounters generally became a little harder with each level you descended. Just like old-school D&D. Even the Ultima series, with it's top-down perspective through much of the world, used the mouse-eye view of the flat dungeon levels (of which, if I recall correctly, there were exactly 8 for each dungeon in Ultima III and IV).

Now we move to the modern era, where it almost as easy to render a dungeon in "true" 3D as it is to render those old 2D mouse-eye views. In fact, indie RPG Devil Whiskey limits movement and view to the four cardinal directions as these old-school games (it is heavily inspired by the original Bard's Tale games), but renders the view in true 3D. Ditto for the now-defunct Dungeon Maker engine. That's certainly an option. And there are some nifty things you can do with modern 3D rendering that faking it in the 2D world couldn't offer to make the world look better, including escaping the old 10' x 10' block and 90-degree turn restrictions of the older games.

But when you can really take advantage of the vertical element with 3D views and realistic architecture (and lighting, bump-mapping, or whatever else sounds good), it kinda feels like a waste to wander around a "dumpy", mostly flat world. Things that looked cool on graph paper may not translate to excitement on the game's screen.

Old-school RPG editors (Bard's Tale Construction Set, Forgotten Realms Unlimited Adventures, etc.) were pretty close to what you see with Dungeon Crafter. Fill in the floors, set the doors and walls, and away you go. Yeah, you didn't have many choices to deal with, but it was fast. But good luck figuring out a way to make these maps interesting. There's only so much you can do with flat levels of 10' x 10' squares.

So now we have all kinds of power to make virtually anything we can imagine within the constraints of the engine and the target computer's ability to render your ideas in real-time. But with this flexibility comes vastly increased complexity - by an exponential factor. Sure, you can impose some constraints on your design to speed creation time - I've got some "tiles" under construction right now which I'm going to be using to speed development of some areas. But disposing of the old, simple graph-paper grid can make things like just making sure floors and walls line up properly kinda tricky. Because, of course, sometimes you may not want them to line up. With all those options means lots of choices, and more complicated tools to accomodate those choices.

One issue I've run into in the development of Frayed Knights is lighting. Really cool lighting covers a multitude of sins, I've learned. But, with the engine I'm using, lighting can be really nice and really cheap, but it's also pretty finicky thing. The human brain relies heavily upon light, and so realistic lighting gives us all kinds of signals that help us make-believe that a picture on little flat-screen monitor is actually a window into another world. But squirrely lighting jars us out of that illusion just as easily, and causes frustration because things don't behave the way they look like they should. And then of course, there are problems with a level being too dark, too bright and washed out, or... both, as in the picture to the right. (That's all stand-in texturing, I should note... as are all the Frayed Knights pictures in this post. We're trying to crank along on geometry right now.)

Finding and fixing lighting bugs can also be a major chore. Texturing is another one. I'm not even gonna go there - entire books have been devoted to that subject.

Yet another challenge is more basic - how do you make a good 3D gaming environment? One book I own, "Beginning Game Level Design," suggests picking up some textbooks on architecture. Knowledge of architecture, set design, interior decoration, and 2D art composition skills are just as important here as game design, creativity, and technical competency with tools. In many ways, the design task is closer to that of a theatrical or cinematic set designer, as the builder not only has to satisfy the demands of style and function for the fictional creators of the environment, but also satisfy the aesthetics of the game and the demands of the mechanics.

Additionally, those really cool, visually appealing environments can play hell with the AI pathfinding and successful player navigation.

Regardless of technology, for the kind of RPG I'm interested in (and interested in making), these environments need to satisfy several requirements:

#1 - Exploration is a big deal in RPGs, so a good "level" should provide an interesting environment to explore. It should provide hints for interesting things to come. A good dungeon level should promise hidden secrets, give you glimpses of currently unattainable goals, and something new and different as you progress.

#2 - Since combat provides the meat of most RPG gameplay, the environment should provide some interesting tactical challenges - if that is a feature of the game.

#3 - A dungeon level should provide some interesting spatial/navigational puzzles. This is more appropriate for 3D environments with restricted vertical movement, but even the old dice-and-paper games had things like notorious chessboard floors and similar puzzles or "tricks" involving navigating the environment.

#4 - A good dungeon level should be visually appealing. Easier said than done, sometimes. This comes from a combination of interesting geometry, good texturing, and lighting. It should at least look plausible given the constraints of the world. Huge, flat ceilings without arches or supports look wrong. Stark transitions between material types can look bad. Bad color combinations look bad. Too much repetition of texture looks bad. Too much contrast looks bad. Too little contrast looks bad. There are probably a zillion other things that detract from the looks of things, and I won't even recognize them when I see them.

There may be a lot more science to it than I understand. There is a lot to it. So much, that it gets a little intimidating for a guy like me, for whom the term "programmer art" is something of a compliment. Nevertheless, there's something incredibly satisfying about learning to go from the old graph paper maps of my childhood to making 3D dungeons in my... um, later childhood.

(Images come from Frayed Knights, Might & Magic 1, and Wishbone's Dungeon Maker alpha version)

Labels: Frayed Knights, game art, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 7:14 AM (Permalink) 3 comments links to this post

 
Programmer Art
Curiously enough, today I planned to talk about my pathetic efforts to create art assets for my game. Interestingly enough, Gareth Fouche had the same plan. And some very pretty attractive art assets to show off. I'm jealous. If you are curious about the process, you can see it in action here:

Scars of War Blog: From Concept to Game Asset

I think Gareth and I have acquired licenses to much of the same texture and 3d model assets - there may be a bit of similarity in our content, in spite of radically different generations of game engine. But you know - that doesn't really bug me. TV shows and movies often re-use props, costume elements, set pieces, and especially sound effects (and the Wilhelm Scream). Indies cannot afford to keep reinventing the wheel.

But for people interested in creating art content for games, here are some tools I use and resources I have found useful:

Blender 3D
I am a convert to the cult of Blender. Now, to be honest, my experience in other 3D modeling packages has been limited. I've only tinkered with Multigen, Maya, and Wings 3D, and while I did a bit more work in Milkshape, I was never as proficient as I am in Blender. I still have a lot to learn across the board, but it's an extremely powerful 3D modeling package.

To get you started, here's Nygel Symes' video tutorials on Blender were really what got me over my hurdles of using Blender, coupled with some of the tutorials over at LowPolyCoop. Also, check out Psionic 3D Game Resources, especially the Zombie Tutorials for making a low-poly model. It uses Milkshape 3D, and some texture unwrapping packages that aren't even available anymore, but the information and process is incredibly useful regardless of what 3D modeling packages you are using.

GiMP
The Gimp (GNU Image Manipulation Program) is open-source (free!) 2D art software. It lacks some of the whistles and bells of its bigger (and expensive) siblings like Photoshop, but there are a bunch of downloadable plugins out there for it that help fill the gap nicely. It's a pretty dang sophisticated and powerful piece of software. And the price can't be beat!

Here are some Gimp tutorials to get you started.

Quark (Quake Army Knife) & Torque Constructor
These are getting a little bit old-school, now, as Constructive Solid Geometry (CSG) levels are becoming a little passe for modern game engines. But not for me, right now. I have finally been weaned off Quark in favor of Constructor - which has become reasonably solid (finally). There are a few nifty video tutorials available for Torque Constructor now. QuArK has a lot more of a broad base of support, but in both cases there is no substitute for experience.

Genetica
Genetica is a seamless texture generator. In all honesty, the final results aren't anything you couldn't create in Gimp or Photoshop once you really know what you are doing and all the "tricks" of the trade. But Genetica streamlines and pipelines the whole process, making it pretty fast and easy. More importantly, it allows you to make a small change earlier in the process without having to repeat all the subsequent steps manually - you can see almost instantly the difference changing the noise function in step 3 would have down the line at around step 17.

The results are pretty impressive. And seamless, allowing them to be tiled and repeated / tessellated easily.

Labels: game art

- posted by The Rampant Coyote @ 7:30 PM (Permalink) 1 comments links to this post

 
Blender Torque Exporter Update
With the redesign of the GarageGames website, the forums dedicated to particular tools have vanished - with apparently no intent to break them out into separate threads again.

To help preserve the community of Blender / Torque users (though it also separates the community a bit), Joseph Greenawalt, the guy who has been maintaining the exporter for Blender for many moons now, has effectively moved that forum & community to his own site, and is looking to find out who is still interested.

I'll just direct you to the shoutout thread here:

Post Here If You Are Using (Or Plan To Use) the Torque Exporter for Blender

I think this might be of interest to exactly TWO people here, but if you are a regular here you already know that I'm a big fan of Blender. It's an open-source, FREE, professional-quality 3D modeling package that is frankly about 100x more powerful than *I* really need. The inset art in the upper right here is called "Sign of the Juggernaut" by Derek Watts, created and rendered within Blender. It's a really powerful tool, but it is known for having an interface that deviates from that of the popular commercial competition. You can check it out at Blender.org. I think it's a great tool, and the price is more than right for indie game development.

I wish I had some kinda clue as to where GarageGames is going these days. I've been a fan of what they've been trying to do over the years, even if I've been frustrated from time to time with their engines. But it's a different crew now, and a different mandate. We'll just have to see what happens.

Labels: game art

- posted by The Rampant Coyote @ 10:31 PM (Permalink) 2 comments links to this post

 
"Blender For Dummies" Available For Pre-Order
I guess the open-source modeling package Blender has finally "arrived." It now has (or very soon will have) a "...For Dummies" book.

Blender For Dummies Available For Pre-Order

Author Jason Van Gumster expresses his hope that the book was to dispel "the myth that Blender is difficult to understand."

I'd personally recommend Blender for any indie on a tight budget wanting to get involved in 3D modeling. Yeah, it's not the easiest package to use - though I found that, over time, it was easier for me to use than Milkshape (which is also a pretty cool modeling tool for indie game development - but not nearly as feature-rich). The only big problem I've found - and it may be because I've not searched too hard for the answer - is the lack of animation compatibility between Blender and other popular modeling tools.

Labels: game art

- posted by The Rampant Coyote @ 2:38 AM (Permalink) 4 comments links to this post

 
Free Texture Sites
For those game developers / artists among us:

List of Free Texture Sites

Hat tip to BlenderNation for the link.

Labels: game art

- posted by The Rampant Coyote @ 11:40 AM (Permalink) 1 comments links to this post

 
Vespers 3D Development Update
Maybe it's just a case of misery liking company - but I really enjoy Mike Rubin's updates on Vepers 3D development. His October post is up now:

The End of October Vespers Thing

One of the issues he's dealing with in this article is the less-than-perfect handling of interiors and culling of objects / polygons by the engine - in this case, the Torque Game Engine, which I am also using. His headaches sound amazingly familiar. We made some assumptions when working on the Frayed Knights pilot that the engine would handle culling a lot like the Quake engine. We were wrong. We had to make some of the same kinds of manual optimizations with LOD, and we'll be making more in the future. We've got a big "Dracula's Castle" thing coming up (I still have to get pen & paper maps finished and sent off to Kevin, dang it!) which is going to make the Temple of Pokmor Xang and the monestary in Vespers look puny by comparison - I don't see any way of doing it besides breaking it up into multiple pieces with different LODs the way Mike has done.

The portal thing is another big headache that I've never quite gotten my brain entirely around - at least not how to use it correctly. This post helps.

I should also note here that these kinds of "work-arounds" are the sorts of things we've done as professionals in every game company I've worked - even with our own custom, homebrewed engine. Developing games usually involves a heck of a lot of problem-solving that usually involves an incredible amount of contortionism on the part of both code and content. And for every two problems you fix, you create one new one.

I don't know of anybody who'd do this if they didn't love it.

Labels: Adventure Games, game art

- posted by The Rampant Coyote @ 4:24 AM (Permalink) 5 comments links to this post

 
The Uncanny Valley: Give It Up Already
Jeff Tunnell, co-founder of Dynamix and GarageGames, designer and producer of about a bajillion critically acclaimed and successful games, has made a powerful point about the trend towards photorealism in games. That point being that since even movies - with painstakingly non-realtime-rendered computer graphics - still can't do it right and cross the "uncanny valley," why do we persist in trying to make games do the same thing.

For those who don't know and haven't clicked the link, the uncanny valley is a coin termed from robotics, originating with Masahiro Mori in 1970, which notes that human response improves as a robot (or in our case, computer-generated characters) becomes more lifelike, but only up until a point - after which it drops substantially. The tiny inaccuracies, the failure of certain elements to blend together correctly in a way that we don't even comprehend, become a really big deal. Our minds reject the image as being a person, and there's an automatic response to recoil, like seeing a corpse (or, in the case of an animated character, a zombie).

It's "creepy."

This isn't just a problem with human characters. Years ago, when I was working at SingleTrac, several veterans of the simulation industry who worked there remarked that in their previous field, they ran into problems as their simulations became more realistic. Pilots started complaining about things that were never an issue before, such as the airfield lights being the incorrect shade of blue. The more like lifelike the graphics, the more your mind will set off alarms that something "just ain't right."

It's probably some kind of self-preservation instrinct. I mean, if some grasses are looking wrong on the savannah and not blowing properly in the wind, that could mean that you have only seconds to act before you take a trip down a tiger's digestive tract. Your brain is hardwired to scream those alarms at you, and suppressing those feelings takes effort.

The solution many games have adopted is to drop the player into alien scenes and covering humans with so much battle-armor that you can't tell they are people anyway. Or bashing zombies, which are supposed to be all "creepifying." There's a stiffness and strangeness to it which still works okay in a first-person shooter, but fails in a game that would require more human interaction.

Tunnell questions why the video game industry still keeps trying to brute-force its way across that valley when we have clearly reached a point where things are going to get worse before they get better. This applies double for indie developers, who don't have the budget or manpower to achieve even the results the mainstream industry struggles to maintain.

But this brings up another issue - which is the need for really brilliant art direction. Photorealistic isn't easy, but it is a lazy approach compared to producing quality, consistent stylized graphics. But that's a whole 'nother topic, and one I don't feel qualified to talk about right now.

Make It Big In Games: If Robert Zemeckis Can’t Cross the Uncanny Valley, What Makes Us Think We Can?

Labels: game art

- posted by The Rampant Coyote @ 7:22 AM (Permalink) 6 comments links to this post

 
Level-Building: More Addicting Than Games?
I have posted before about a number of games that have caused me to lose track of time, and kept me up until the wee hours of the morning without realizing how much time has passed.

I have discovered over the last couple of weeks that building levels has the same effect on me. Instead of saying, "Just one more turn," I find myself saying, "Just one more detail!" or "One more test!" The next thing I know, another half-hour has passed. I wish I could say that's always how game development is for me, but in all honesty it is sometimes pretty sleep-inducing.

Unfortunately, progress isn't fast. It just makes time fly as if it was.

One issue I have found recently with Torque Constructor is that ramps sometimes get their collision hosed. This is true of ramps built as static meshes and imported into the level as well as ramps build directly via brushes. While lighting doesn't work quite right, if I bring a static mesh (with collision) directly into the level - the old-school-way - it works just fine. It just doesn't work if it is "baked into" the interior data. Alas - the lighting doesn't look as cool this way, so it's not without a cost. But cool lighting is

I have also learned some new texturing tricks in Blender that I was unaware of before. I'm actually a little embarrassed about not realizing I could do a UV unwrap with a cube projection - but it sure makes things simple when simply trying to tessellate a simple stone texture across a structure.

Labels: game art

- posted by The Rampant Coyote @ 6:04 AM (Permalink) 2 comments links to this post

 
From Text to 3D Character
Over at The Monk's Brew, Rubes (Mike Rubin) has the third part of his ongoing saga to bring text IF (Interactive Fiction) characters to life as animated, 3D characters in Vespers 3D. In this case, it's the character of Brother Ignatious, who was described very simply in the original text adventure as follows:

"A fiery man, whose devotion to God is rivalled only by his devotion to protecting God's people, Brother Ignatius was a soldier before joining Saint Cuthbert's. After losing an eye against the Turks in Nicaea, he came back to Italy, and started fighting for God in the only way he could now: with prayer."

Mike goes through the process, including concept art, 3D modeling, animation, and finding the right actor to provide the voice-overs for Brother Ignatious.

Awesome stuff, if you are interested in taking a peek inside the sausage factory.

Adventures with NPCs IV: Ignatious at Monk's Brew

P.S. - He's also got a very awesome retrospective on Atari's Adventure worth taking a look at, too.

Labels: Adventure Games, game art

- posted by The Rampant Coyote @ 11:06 AM (Permalink) 2 comments links to this post

 
Frayed Knights - Font Wars
Okay, okay, I get the hint. Comic Sans is not well-loved, even as a placeholder font for Frayed Knights. I guess I'm a complete font idiot. So... I've been trying to find more fonts that are playful and readable for the whole game. Probably. Here are two candidates, though I'm not sure one of them is even available for a (reasonable) commercial license. Click on 'em to get the bigger version (or just go immediately to the poll thread to see 'em both in full glory).

Font Candidate #1:


Font Candidate #2:



Even if you don't like either of them, please give me some suggestions on which ones I *SHOULD* check out. Just don't point me in the direction of a font that will cost me hundreds of dollars to license, because I'm on an indie budget.

Here's a poll so I can easily track the responses:

FRAYED KNIGHTS FONT WARS #1 POLL

Thank you kindly in advance for your suggestions!

Labels: Frayed Knights, game art

- posted by The Rampant Coyote @ 12:57 AM (Permalink) 9 comments links to this post

 
On Making 3D
I have come to the realization that, after Gutenberg's little gizmo put them out of work copying and illuminating documents, the medieval European monks might have found 3D texture art to have been a perfect match for their skills. Assuming 3D modeling was in line with their religious beliefs. And assuming they had 21st century computers at their disposal in the 15th.

In elementary school, I learned about why the different projections of a 2D map of the world were flawed, and how Greenland really wasn't as big as all of North America. But aside from that, I thought it was largely an academic exercise. Then I tried to keep straight lines straight on a (simulated) curvy object. Suddenly that third-grade geography lesson takes on a whole new meaning.

Two things I have discovered (repeatedly) is that:

#1 - Creating 3D content (or good 2D art, for that matter) is not easy.

#2 - The stylistic differences in off-the-shelf content packs render them almost totally incompatible. In case you haven't seen what I meant from the Frayed Knights screen shots, here's what I mean:


These guys look great on their own, but just cannot dwell on the same screen together. Unless it's Roger Rabbit World. This yields the inevitable conclusion:

#3 - If you are making a 3D game with a lot of content requirements, you are pretty much hosed.

Which is where I sit. I keep spending time trying to massage content instead of coding, trying to tweak textures, lighting, and models enough to make things not quite so eye-searingly bad.

And I continue to bump into my own limitations as a game developer. Yes, I've got 'em. Not just in content creation, but in coding too. This weekend I spent several hours in a forced education about Torque's animation system. All this just to get a character to cross a room and say something to the player. I tell myself it's black triangle work. Even this far into the project, there are black triangles to be drawn.

The bottom line is that creating a game is hard work, and if anybody goes into it already knowing everything there is to know, for which it is all a piece of cake, I've not met them. I've been at this for years, now, and some days I still feel like I am fighting for every five minutes of gameplay.

Incidentally - getting any of the above models and then spending some time on them in the modeling package of your choice, learning how really skilled artists built it, laid out the textures, and rigged the thing is a fascinating and extremely educational exercise. I recommend it if you have the slightest interest.

Labels: Frayed Knights, game art, productivity

- posted by The Rampant Coyote @ 6:13 AM (Permalink) 14 comments links to this post

 
How To Bootstrap Your Indie Art Needs
DanC has another outstanding article for game developers on The Lost Garden:

How To Boostrap Your Indie Art Needs

It's a quick how-to for programmers who have no clue how to get art for their games - with lots of suggestions. And an admonition to get over yourself, you aren't Blizzard and aren't gonna make a game that looks like Blizzard's.

He does restrict the discussion of ways that work to using free graphics, and hiring an artist to do custom work for you. There is (kind of) a third option, which is to license non-free content packs. This is sort of in the same boat as the free graphics content, but it's ... uh... not free. However, in many cases (at least, so they TELL me), the content pack creator may be willing to do some customization for you at a reasonable fee. So you may be able to get a little bit of the best of both worlds... a lot of content for cheap, and some customization for your game.

A fourth option is to learn the mad arts skillz yourself. This is a long-term plan. My own skills still suck, but I've definitely found that they suck less over time. Now, this probably won't make you capable of doing it all yourself without need of artists, but even so it can help you in several ways:

#1 - Allows you to better customize existing art without ruining it.

#2 - Enables easier communication with artists

#3 - Allows you to build stand-in content without having to wait for artists

#4 - You may be able to create some non-critical content all by yourself where needed (though it may not be the best use of your time if you are a l337 programmer).

I wish I had a magic formula for getting all the art I need instantly at no cost and of the quality I need. But while I'm wishing, I may as well wish for a million dollars, too. Getting art for my games has been a huge challenge from the beginning, and I don't expect that problem to go away.

Labels: game art

- posted by The Rampant Coyote @ 6:05 AM (Permalink) 0 comments links to this post

 
Gimp 2.4 Released
While this may be of particular interest to indie game developers (since we're notorious cheapskates), anybody who uses The Gimp as the low-cost (that is, FREE) alternative to Photoshop may be interested in this news:

The Gimp 2.4 Has Been Released.

You can read the Release Notes for more details.

Or you can just download the new version of Gimp.

Labels: game art

- posted by The Rampant Coyote @ 9:39 AM (Permalink) 0 comments links to this post

 
Why Realistic 3D Graphics May Be Bad For You...
Staying with the whole game art / 2d vs 3d theme from yesterday... Some may say realistic graphics are better, but now... now I know better. And my nightmares will remind me. And every time I watch anime, I will shudder. Just a little, as the memory crawls briefly to the surface like some Lovecraftian haunting.

Sometimes, the abstraction of cartoon-like art is just a much safer, better place.

We Don't Want To See It Made Real.

I'm retreating back to my happy place, now.

Labels: game art

- posted by The Rampant Coyote @ 9:36 AM (Permalink) 3 comments links to this post

 
How Long Does It Take To Build 3D Models?
Scott Hsu-Storaker, the "Thousander Club" guy, runs the Low Poly Cooperative (a totally awesome "open source" content site with a focus on Blender and Torque --- check it out, enjoy, take advantage of the free content and tutorials, and by all means contribute if / when you can). Anyway, he has written a somewhat lengthy article breaking down the average amount of time it has taken him to create all the models in the "Gilman Street Project."

Now, GSP was - as I understand it at least - something of a learning experience for him. So maybe a more experienced modeler could cut these times down. But measuring his times, he came up with the following breakdown:

Average time to create a completed model: 7 Hours.
1.5 hours -- Modelling and unwrapping
3 hours -- Texturing
1 hour -- Exporting and file wrangling
1.5 hours -- Management (of project and other contributors), finding source materials, and miscellaneous.

Note that Scott didn't have to work on rigging and animating at all with this project. THAT can be a time-sink. But we're talking nicely textured but simple everyday items. Like the pictured floodlight.

So for 3D game devs out there trying to estimate (guesstimate) budgets for creating all the 3D assets in your game... this may be some useful data to chew on.

Read Scott's full article here: "How Long Does It Take Anyways?"


(Vaguely) related tales of my own miserable failures:
* A Blender Journey
* Getting Better 1,198 Polygons At A Time
* The Joy of Tex(turing)
.

Labels: game art, productivity

- posted by The Rampant Coyote @ 6:00 AM (Permalink) 5 comments links to this post

 
Frayed Knights Poll: Chloe Versus Chloe
Okay, ignoring (if possible) the difference between a professional artist's coloring-and-shading versus my quick-and-dirty flat-color job, which color scheme works better for Chloe? The pink "Disney Princess" on the left, or the purple-and-blue "Cyndi Lauper" version on the right? Vote and tell me what you think...

Labels: Frayed Knights, game art

- posted by The Rampant Coyote @ 5:00 AM (Permalink) links to this post

 
Coloring
I get to color!

I'm not much of an artist. There are jokes about "programmer art" that are very true. I think one reason I'm nostalgic for the early 8-bit days is because back then, the difference between programmer art and professional art wasn't nearly as pronounced. But since I'm all about maintaining a "growth mindset" and stuff these days, I'm trying to learn.

So I'm coloring some black & white sketches for the Frayed Knights characters. It's kinda like being back in second grade again. Except this time, I get to color with The Gimp, and use layers and things like undo commands to fix mistakes as I make them. Man, I only WISH I had had access to that kind of stuff in second grade!

The original artist who drew the sketches was able to color some of them, and so I'm using his examples (he did the one to the left). He makes it look so easy! I'm not sure if my end result is passable or not. It's still a work in progress. And I'm highly reliant on reducing them down to 128 x 128 to hide a bunch of flaws. I'll keep working on it.

But it's fun to color!


(Vaguely) related stuff:
* The Secret of Success? It's All In the Mind(set)!
* Frayed Knights Dev Diary: Frayed Knights Gets a Makeover
* Getting Better 1,198 Polygons At a Time
.

Labels: Frayed Knights, game art

- posted by The Rampant Coyote @ 10:00 AM (Permalink) 0 comments links to this post

 
Walk Cycle Resources
For those who find themselves working on animation for games (which might just be me): BlenderNation has a few links to some nifty walk-cycle resources on the web. Some of these could also be useful to people working on 2D sprite animations.

Labels: game art

- posted by The Rampant Coyote @ 4:55 PM (Permalink) 4 comments links to this post

 
A Blender Journey
Igor Križanovskij has done with Blender what I did with my "Game In A Week" article (and the Frayed Knights articles) - he's made public his journey to learn Blender. He starts with 2.35, and with his second online notebook he moves on to version 2.43 and 2.44. It's not a tutorial so much as riding shotgun with him and seeing what he did to learn the tool (and a collection of notes, tricks, and hotkeys).

The links and summary can be found at BlenderNation.

Labels: game art

- posted by The Rampant Coyote @ 5:57 PM (Permalink) 4 comments links to this post

 
Blender 2.44 Is Released!
Wow - doesn't seem that long ago that Blender 2.43 was released... but now the new latest & greatest is version 2.44, just released today.

I haven't tried it out yet, but of interest to us indie game developers (emphasizing low-poly, exportable models):

* Bug fixes to make it 64-bit compatible (again)
* Bug fixes for meshes
* New "Torus" mesh
* Hide & Unhide are now available in Object Mode
* Various other UI changes

Nothing too earth-shattering, here. It's a minor release, but it's nice to see it continuing to evolve.

Labels: game art

- posted by The Rampant Coyote @ 10:36 PM (Permalink) 0 comments links to this post

 
Blender and Gimp Together In a Tutorial
Courtesy of this BlenderNation post, I was directed to this detailed tutorial by "Oto the Cleaner" on texturing and unwrapping in Blender with the Gimp. The BlenderNation post has several additional links to more articles and tutorials - several apparently by Oto the Cleaner. I haven't begun to plow through them all, but I will.

We're talking two very powerful tools, both more than capable of doing professional, commercial-quality work, that don't cost a dime. Kinda cool if you are starting out as an indie game developer on a shoestring.

I'd also recommend visiting the Low Poly Cooperative - in particular, the Help Center which holds several tutorials. The whole site is awesome though, with lots of advice and free models. I'm particularly fond of their Daggerfall Art Remake section...

Worth Reading, if you are following that particular path...

Labels: game art

- posted by The Rampant Coyote @ 1:00 AM (Permalink) 0 comments links to this post

 
Playing With Torque Constructor: A Quick Take on GarageGames' New Game Development Tool
Torque Constructor was launched to the public a few hours earlier than the previously announced April 9th release date. This tool is free to all licensees of the Torque Game Engine, or Torque Game Engine Advanced. (CORRECTION: It is apparently free to all those with a garagegames.com account, not just those with a Torque engine license). While it is intended as a tool for Torque, it can save models in the .map format common to many game engines.

Background
Now, my own experience with other Constuctive Solid Geometry (CSG) editors has been limited. I've used QuArK, a variant of WorldGen (I think that was the name) that shipped with Vampire the Masquerade: Redemption, and UnrealEd. And now, I've gotten a couple of hours of playing around with Constructor under my belt. Hardly enough to render a verdict - especially as I am NOT what you'd call a "power user" of any of these tools. I'm still pretty much a beginner, but that never got me to shut up about a subject before, so why start now? So I thought I'd share my experiences.

I have REALLY been looking forward to Constructor. As I've said before my experience with QuArK (Quake Army Knife) has been troublesome. I feel like I've made some level of peace with the editor, but it's strictly a relationship of convenience. I'm not a power-user of that tool, so I've no doubt I've been missing some major conveniences in that package out of sheer ignorance. But I've put hours somewhere in the mid-double-digits into the tool and used it in practice to create real (though not particularly masterful or pretty) levels for Apocalypse Cow.

QuArK is really sharp and useful and capable in some areas, and annoyingly lacking and stupid in others. The interface has always been a little bit clumsy and ... klugey... to me. It might be my ignorance, but managing textures was always a pain in QuArK. And, finally, there was the little matter of setting it up for use with Torque whenever you upgraded to a new version, making sure all the export paths were set properly, and... ugh. And then there were the bugs. The really nasty, I-just-munged-whole-level-lets-restart-without-saving type bugs*. I was never sure if they were because I was doing something wrong, or if it was just one of those issues you just had to learn to avoid.

Torque Constructor: The Good
By comparison, Constructor feels like it has a much more polished interface (I hesitate to call it intuitive... there really is no such thing when dealing with this kind of tool). It is a little less bewildering to a beginner, I think. It's far easier to get into it and start making useful stuff, with a more gentle learning curve. With only about two or three hours of usage, I already felt competent enough to do everything I could do in QuArK (plus a bit more). Of course, it's already set up for Torque. Exporting a DIF file (Torque's proprietary format) is naturally a piece of cake. Constructor allows you to save files in both .MAP format (the text-format standard developed by id Software, used by many similar editors), as well as a new "CSX" format.


I really like the "Free Cam" mode that allows you to fly your camera around the model very freely. The UI layout is also very flexible and easy to configure. While I haven't played with it, Constructor also has the Torque Lighting System built into it, allowing you to see how your creation will look when fully and properly lit. Some really minor but appreciated elements include a grid size scaled more for Torque-sized objects (approximately 2.5 units for the default humanoid character), and the fact that upon loading a large map file, the camera automatically zooms out to encompass the entire level. Small conveniences, but nice. I've got some gargantuan interior levels in Apocalypse Cow, and when I brought them into Torque Constructor for the first time, except for some missing textures I had to correct, they acted as if they belonged there.

Another great option is the ability to bring in Torque models (DTS objects) as reference objects to compare scale.

Constructor also offers several very nice ways of manipulating, slicing, and dicing a brush. From standard CSG subtraction, and making hollow (easily enough done in QuArK as well), there's also the ability to rotate brushes with a fine level of control (down to actually inputting the exact positions and rotation values by hand). Then there's the knife tool, the slice tool, and a clipping tool. Since the knife is one of my most-used tools in Blender, I was pretty excited about this one. I expect these to be pretty handy when developing cave-like levels or levels with more organic topography.

Duplication of brushes is easily supported. Creating a spiral staircase is apparently a snap. You can change a particular brush from being a structural element to a detail brush, or collision volume, portal, trigger, or some other type of object by simply clicking a radio button in its properties. Basic Torque entities are supported, including lights, paths, and mirrored surfaces (though that's not entirely functional yet - see below). There are also things like custom workplanes, that allow you to work off-axis, and little convenient tools like automatically dropping the brush (or even a vertex) to the ground.

I haven't touched it yet, but Constructor - as a tool built using Torque - fully supports TorqueScript plug-ins. Adding to the prefab library is also practically trivial. I imagine that within a few weeks, there will be a ton of community-driven support for these features. I understand that there's built-in concavity detection as well, to make finding of bugs a lot easier.

Torque Constructor: The ... Different
Constructor has its own quirks. For example, creating a new brush is a two-step process. First there's "virtually" creating the brush, by "Activating" a primitive. In this state, much about its core geometry can be changed directly (such as, for a cylinder, how many sides it has, or the beveling on a cube). Once satisfied with the brush (or the cloning parameters), you "make" the brush, and it goes from being a virtual brush to a real, in-game brush. At that point, some features of editing it becomes a little less flexible, though you then have tighter control over, say, the actual vertices. . This can be done deliberately by pressing the "Make" or "Make and Continue" buttons, or it may happen if you accidentally click somewhere else in the scene.
Torque Constructor: The Not-So Good
The documentation on Constructor is fairly skeletal at this point, though that will only improve over time. In return, however, we're getting a lot of time from the developers during this first week directly in the forums.

Constructor has some problems with its initial release, which is unfortunate, though not unexpected.

First of all, portals, zones, and mirrors are not scheduled to be supported until version 1.0.1. If you are just doing small buildings, and don't care if (for now) the interiors are lit by sunlight and the outside ambient light, that may not be such a big deal. But if you are doing big larger, Quake-style interior levels mixed with outdoor terrain, this means you have to save your file as a .MAP file, and then bring it back into the CSG modeler you've already been using, and then export it to a DIF file from there. That's not a crippling step - I imagine I will be doing most of my principle modeling in Constructor for here on out, but it's a painful extra step I'd rather not have to deal with.

Another problem is that you cannot rename brushes, or put them in groups like you can in, say, QuArK. Now, you can group them into selection sets --- but that only gets saved out in the .CSX files, not .MAP files. Again, not a big deal, but since I'm having to save these things as .MAP files anyway to get QuArK to export them with portalling information, that's Yet Another Step.

Texture management is pretty straightforward, with a lot of great tools for manipulating the texture coordinates (including some automated UV grids), save one major one - the ability to use the mouse or keyboard to scroll around the texture coordinates directly on a face. This is a real time-saver when trying to line up textures on adjacent brush faces. Trying to fine-tune this by hand was a real pain. I tried using the texture unification, which supposedly makes this a lot easier, but it didn't work well for me. More experimentation will be required here.

There are a lot of other little conveniences that are common enough that they are missed in this package. The lack of automated "snap-to-grid" functionality on vertices, for example (though the ease of manually edit the coordinates directly makes up for it, for me). I also couldn't directly select occluded objects. In QuArK, repeated clicking in the same area would cycle through all brushes under the cursor. In Constructor, as far as I can tell, it involves either selecting it via the perspective view by moving the camera close to it (which is pretty convenient to do, really, thanks to the camera control capability), or hiding all the occluding brushes. Again, not a big deal, but it would be a time saver.

And as usual with a 1.0 release, there are a number of small bugs, performance issues, and the occasional crash that users are discovering. Trying use the area-select tool on the cathedral caused Constructor to hang on me on one system. The cathedral example provided with Constructor is one such example - it's a really big, resource-hoggy extreme, and people are finding a number of issues with it on various systems.

Torque Constructor: Preliminary Verdict
Three hours or so with the tool is hardly enough to say anything definitive about the tool. But I've enjoyed playing with it, and it seems to give me almost all the functionality I've come to depend on in other BSP-style level-building tools. Unfortunately it may be a couple of revisions before I blow QuArK off my system entirely, as there are still some things which it does better than Constructor (or does AT ALL that Constructor doesn't). And it's not a bad tool. But I am going to start moving all of my primary level-building development over to Constructor effective immediately - even in that short time, it's become clear that its easier to use.

At least for me, the non-power user who only pretends to know what he's doing.

But I will appeal to a more experienced authority on this. In the few days Constructor has been out, Adam Wilson managed to figure it out and posted this picture of a church he built with the tool:

He offered no word on how long that took him, and I understand the interior is unfinished. But I'm gonna call Constructor "Very Promising" at this point.

Now I just have to get back to coding instead of playing with it...


* UPDATE (7/1/2007) - I was contacted this morning by DanielPharos, currently on the QuArK development team. The latest version I worked with was 6.5 alpha (and much of my experience was with prior versions.) He told me that since QuArK 6.5.0 Beta, they have made great strides in fixing memory leaks and silent access violations. According to him, "I know the older versions of QuArK are really crashy, but in my opinion we've done a major improvement with this new version." Definitely good news!


(Vaguely) related stuff:
* Torque Modeling Tool Available Free Next Week
* Raising a Barn
* A Metric for Scoping Games?
.

Labels: game art, Torque

- posted by The Rampant Coyote @ 7:00 AM (Permalink) 12 comments links to this post

 
Torque Modeling Tool Available FREE Next Week
Jussincase you are all ready to take the plunge and create a prize-winning RPG... here's something to help.

GarageGames just announced that their long-awaited Torque Constructor will be available at the beginning of next week. Pricing will be something to everyone's liking... they will be offering the product as a free download.

Torque Constructor is a brush-based CSG (Constructive Solid Geometry) interior-level design tool, comparable (we believe) to tools like the Quake Army Knife (QuArK), Valve's Hammer, or 3D World Studio. The advantage for Torque developers is that it is written in Torque itself, giving more of a "What You See Is What You Get" (WYSIWYG) experience, along with better support for many of Torque's unique features. In theory, it should be a lot easier to work with, should really improve the art pipeline for Torque, and has been developed to appeal to users conventional 3D modeling tools like 3D Studio Max.

And it works on the Mac.

Not that Torque Constructor is supposed to replace high-end modeling packages... it is exclusively (AFAICT) for doing CSG-based objects... read "interiors" for Torque. Quake-style levels. Dungeons. Taverns. Stuff like that, where complex collision detection and rendering management must be optimized.

Why free? Tools have been a shortcoming in the Torque Game Engine for years. They've been reliant upon third-party tools (and upon the community providing exporters for the third-party tools) for a very long time, and it hurts when they get compared to some of the other 3D game engines out there. GarageGames is pretty frank about the rationale on the product page: "Torque Constructor improves TGE and TGEA in an area which has been in need of improvement for some time: the art pipeline. We recognize that, and are making Constructor free not only to thank those of you who have supported GarageGames and the Torque Technologies for the past seven years, but also to increase the value of our 3D engines for new users. Hopefully, releasing Constructor for free will encourage more artists to consider Torque a viable and attractive engine to create art for."

Well, here's hoping it rocks. I've spent some time with QuArK --- not enough to come to love it, but enough to at least come to an uneasy truce where I agree not to swear at it too much and it agrees not to eat my maps very often. I think this might be a perfect time for an amicable departure.

Labels: game art, Torque

- posted by The Rampant Coyote @ 9:17 AM (Permalink) 5 comments links to this post

 
Getting Better 1,198 Polygons At a Time
I read in a book recently that the best way to increase your earning potential is to become the best in your field. And the way the author suggested doing that was to create a list of the main 5-9 skills needed in your profession, and then do a thoughtful self-analysis and rate those skills within yourself. Going by rule of thumb that a chain is only as strong as its weakest link, address your weakest skill. It's probably the one thing you like doing the least. Work on it until it's no longer your weakest skill. And then move on to the next weakest.

How do you "address" a weakness? Education is part of it. Especially in high-tech industries, our knowledge is constantly acquiring gaps that need to be addressed. With as much knowledge as is available at the speed of Google these days, there's not much excuse for remaining in ignorance.

But what it usually comes down to is practice. Lots of practice. Scott Hsu-Storaker had a pretty interesting challenge for himself back in 2006 (which he is continuing this year). Given the idea that experience and practice is just as important as talent, and that after spending a thousand hours doing something, you ought to be able to start getting pretty good at it. GBGames has been doggedly posting his updates every Monday morning for the last year and change as he's been pushing to increase his game development skills by putting in 1,000 hours of development time over the course of a year.

I figure I'm pretty dang good at wasting time by now. Too bad that's not one of my skillsets for being the top in my professional field. Or for making the top-selling indie games on the market.

Unfortunately, as an indie game developer, that list of skills is extremely large. Even though I've been a professional programmer for *cough*overadecade*cough* now, I've still got some gaping holes in my skill sets. And since an indie needs to wear so many hats, that's only a drop in the bucket. (Hmm... maybe figuring out how to finance and deligate so I don't have to wear so many hats might be a good start, huh?)

So I have a lot of things I suck at that I've been working on to make them not suck.

Part of my objective with Apocalypse Cow was to spend some time learning the artistic side of game development a little better. Now, I'm nowhere near 1,000 hours modeling and texturing with Blender (and Gimp), but my latest undertaking is a helicopter, originally modeled by George McEwan and subsequently modified all to hades by myself. It currently has 1,198 polygon faces for me to texture - yes, two shy of an even 1,200 - that's taking me several hours (well into my second 20-hour "leveling up" process). While I'm not individually hand-painting all of those 1,198 faces, it sure feels that way.

I've gotten to the point where I can do a passable job (kind of) on pure geometric modeling. I can confidently say at this point that I suck much less at 3D modeling. I don't think it means I "don't suck" yet, but sucking less is progress. Texturing is still a bear for me. And animation is a giant mutant bear with cybernetic legs and adamantium claws. But I figure the best way to learn is to practice, right? And Apocalypse Cow is offering me a ton of practice.

It's just frustrating when I want to get the game out the door.

If anybody knows of any nice tutorials on good texturing techniques / methodologies, I'd like to hear about them. I think I've got many of the basics understood --- but it's still a nightmare of unwrapping, assembling together puzzle-pieces of polygons, exporting the mesh layout, trying to do SOMETHING resembling a non-heinous job of drawing the textures to match the polygon layout, then working with more puzzle pieces for the symmetrical opposite side, etc. I'm sure I'm doing some things... well, sub-optimally.

Labels: game art

- posted by The Rampant Coyote @ 8:00 AM (Permalink) 1 comments links to this post

 
The Joy of Tex (turing)
As a do-it-yourselfer game developer, about half of my 20-hour venture (sadly, it WILL take more than a week to get to 20 hours) is devoted to generating content. I do have help for some some of the more visible elements and 2D art, but a lot of my effort is still put into making my own visuals look good. Which is no small trick - I'm not very good.

I've been getting the hang of Blender over many moons of off-and-on effort. I'm still no expert at it, but I can get some halfway useable geometry out of it much of the time. But my crucial challenge is texturing. My respect for artists skilled at 3D modeling has gone up significantly since my first attempt to slap some photographed texture onto the side of a cube and call it an apartment building. There is a lot of art and science in the process, and while it might not be quite as technical as programming, it's still a technically intensive process as well as an artistic one.

And I've learned that UV Unwrapping is your friend.

Since neither touched-up photographs nor my poor attempts at hand-drawn textures (read: Stick Figures with scribbles) are completely adequate for what I'll be working on, I've had to get some help.

The first was a very awesome book called "The Dark Side of Game Texturing," by David Franson. The emphasis in this book is on using photographic references and procedural texturing techniques in Photoship to construct game textures. Lots of layering images, using beveling and burning tools. and so forth. He doesn't go into too much detail about the actual process of applying the textures to models - mainly the creation of the textures themselves. If you are a rank beginner (like me), this book will be a very helpful resource.

Unfortunately, I use "Poor Man's Photoshop," The Gimp. Almost everything that Franson talks about in his book is doable in Gimp, but I had to spend a lot of time translating his Photoshop instructions into Gimp-ese. I still don't know if its possible to do an "inner bevel" in Gimp (probably through an external plug-in), but I've been able to do about everything else in the book, though I had to guess at the equivalent settings in Gimp.

Another little tool I've been delighted with is Genetica, a seamless texture generator that is in the indie price range (the standard license is only $130). It was particularly interesting to me in that it takes most of the steps and tricks in The Dark Side of Game Texturing and automates them into a node-based operation. It's almost like the high-tech, digital equivalent of spray paint art, but it works very well.

For example, I needed something that looked a little like textured siding where the paint had gradually eroded. I found a preset that sorta resembled the right texture I wanted (with the noise generation and so forth), which I played with to give it the right kind of "feel". Then I found a node that resembled the overlayed siding, and played with beveling and depth levels to get me something that vaguely related what I had in mind. Not bad for ten minutes' work with a tool I am just barely learning to use!

All textures are created to be fully seamless - meaning they tile effortlessly. And unlike photographic base textures, they tend not to have blemishes or noticeable patterns that can draw the eye to the repetition in the scene (there's another tool I bought some time back called the "Seamless Texture Generator" which helps with making seamless textures from photo references).

When you create a texture or pattern, you can also add it to the list of presets to use it as a base for another texture - again with full control on down the pipeline. The program keeps track of the primitives elements used to create the texture, not the texture itself, so if some point down the line you want, say, the base color to be black instead of steel-gray, or you want to add some little bit of green weeds poking up through the cracked cement between the tiles, you can change it.

Here's kind of an example of it in action for one of the pre-sets that has a round air vent with warning stripes on either side.

Here's the primitives to create the basic vent:

And this is then layered into with another texture and masks to create the tile:


Which is now close to the finished product on the left of the "lab," ready to be rendered out at any resolution.

Anyway, I don't know if it's a huge boost to my productivity, but its fun to play with. But it really does seem like an easy way to produce a TON of nice-looking base textures, useable as-is, or dirtied up by hand in Photoshop or The Gimp to give it a bit more character.

While the examples I used here are man-made, it also makes good rock, alien skin, lava, and even fur.

(Vaguely) related whazzis:
* Sucking Slightly less
* Raising a Barn
* Learning to Draw!

.

Labels: game art, productivity

- posted by The Rampant Coyote @ 7:05 AM (Permalink) 4 comments links to this post