A Real-Life Spy's Tale
Last night I attended a talk by Mike Ramsdell, author of "A Train to Potevka," and former U.S. intelligence operative stationed in Russia during the height of the cold war. My wife has been reading his book and telling me about it. His talk last night focused less on his experiences as an intelligence agent and more on the experiences leading up to it, and his experiences following the publication of the book. And, considering the venue, it was also a discussion of faith.

He admitted that he decided to get into the intel business after seeing the James Bond movie, "From Russia With Love." He thought it sounded awfully exciting, especially for a small-town farm boy from Bear River, Utah. But he notes in the book, "In reality, intelligence work is extremely serious, tedious, and unglamorous; done by balding, pudgy, middle-aged men - and there are seldom any buxom women."

A couple of thoughts I had that might be applicable here:

First of all, his book was a big success, now in its eighth printing, and is now in the process of being made into a movie. As far as he's concerned, he's living the dream. But he quit working on the book for four months after being convinced by his brothers that nobody would be interested in reading his story. They convinced him it was a waste of time, and that he'd only embarrass himself. Fortunately, his wife forced him to get cracking on it some more, and get it done. His first printing was from a fly-by-night printer in Tennessee who was willing to print 100 copies for $1000. He figured they had 50 relatives and 50 friends they could send the book to as Christmas and birthday presents, so they finished it and got it done.

And the change it brought about in his life is nothing less than phenomenal. So maybe this is a lesson for frustrated indie game developers out there. No, the movie isn't being made by a major motion picture studio, and no, I don't think he's gotten rich off his book. But that wasn't the point. The guy was just thrilled at how his life turned out. He said if you'd shown him a crystal ball in his youth - as a Utah farm-boy - which showed how his life would turn out: from being a secret agent in Russia to a book author to scouting out locations in Eastern Europe with movie producers for film based on his life - he'd have bet anything against it.

Another point I considered, as the RPG fan: Why don't we have any "secret agent" computer RPGs? Not realistic ones, though there are some fun elements to be drawn from that, too. But we've got plenty of ripe territory for drama, action, and excitement in the post-cold-war era. For example, Alias is a hit show, in spite of its volatile quality, and even mixes some fantasy and science fiction elements with modern-era action and intrigue. The Bourne movie series have been big hits, and the most recent James Bond movie (Casino Royale) cleverly rebooted the entire series and ditched the lamer elements of the formula - to great success.

And in these shows, there is plenty of action and ... yes... combat! Apparently fighting terrorist cells and evil overlords-to-be allows agents the luxury to rack up a body count unthinkable in any other "modern era" genre outside of a straight-up war story. Which would allow less imaginative game designers plenty of combat to make players happy. And it's been addressed in pen & paper RPGs, from the elderly "Top Secret" RPG from TSR back in the glory days to the more recent Spycraft RPG.

Could this hit a nerve and be successful?

(UPDATE: Apparently, I missed Alpha Protocol's announcement last month. Last month was a blur of 80+ hour work-weeks anyway, I wasn't even sure what DAY it was half the time. But it sounds like I get my wish fulfilled this year. Sign me up! And for the PC version, thankyouverymuch, unless it's got that awful psychotic DRM issues...)


Vaguely related thinking too hard:
* Innovation in RPGs?
* RPG Design Seed Challenge
* The 16 Essential RPGs
.

Labels: productivity, Roleplaying Games

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

 
Tales of Crunch Survival...
It's almost 1:30 AM. I got home from work about forty minutes ago, after over fifteen hours straight. Around 9:30 tonight, the president of the company announced there was free ice cream and beer for everyone in the break room. And sodas, for those of us who don't drink.

Tomorrow is bound to be another repeat of today. I'm learning to hate certain game consoles I used to love. Bummer.

And here I am, at home, checking email, posting this blog, and ... working on my game. Trying to put at least an hour into it. I'll go in late tomorrow, anyway... my task-list is largely cleared out, mainly supporting the designers anyway.

I can't say it's unique to the games business. I've had weeks like this doing all kinds of software development in my career. And apparently, I'm so stupid that I impose it on myself by developing my own games until the wee hours of the night.

Ah, well. That's just the way it goes sometimes. Sometimes you just have to live life in the margins.

Labels: Biz, productivity

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

 
Can Playing RPGs Make You Rich?
I went to an "investors club" meeting of sorts tonight. It was founded in part by an old college buddy of mine - a fellow Dungeons & Dragons player and medievalist who got the bug up his butt about three years ago to get involved in real estate and other forms of investing, and has been doing that full time ever since. He has managed to do pretty well for himself and his family.

The event was... well, it was a whole 'nother world, folks. I was struggling to grasp the jargon at first, in spite of having some basic familiarity in other areas of investing (hey, I listen to some of these books-on-tape while commuting to The Day Job). They discusses strategies, taxes, threw around investment opportunities (many of which had minimum investment levels that were outside of my budget). They asked questions of each other I didn't know to ask, but by the end of the night I was getting a pretty good feel for things and understanding their answers.

In fact, I found it way more familiar than I expected. A weird realization hit me.

These guys are GAMERS.

Investing for Munchkins
No, maybe they didn't all spend their college or high-school years slinging dice next to miniatures like my friend and I did. Though apparently some of the people in the group, according to my friend, are avid video game players. But I found myself very familiar the tone of the discussion. I've been in enough game stores,RPG discussion forums, and on the periphery of World of Warcraft raid postmortems to recognize the familiar patterns in the discussions. The questions asked were new to me, the actual jargon was a learning experience, but if you change the words around these guys could have been powergamers (or, to use a less flattering term, munchkins) discussing their perfect character build or raid strategy.

In popular RPG terms, they were level 10 and I was a level 1. They slung around terms as carelessly as hardcore RPG players might sling around terms like "Armor Class," "DPS," "Drop Rate," and "Dex Bonus," which took me a little while to grasp.

They discussed opportunities. They argued risks, historical yields, comps, and the current state of the real estate market in Las Vegas (their term was "interesting," which I gathered was a euphemism for "don't touch it unless you know what you are doing.) They have figured out ways of making money regardless of what way the market goes - up, down, or sideways. Risky, but impressive. The opportunities were thrown around the room much like the stereotypical patron NPCs in stereotypical taverns would toss around quest and plot hooks for the next adventure.

And this made me think some more... could certain games - the stat-heavy RPGs and strategy games, in particular - be good training for the neural pathways, analytical skills, and behaviors necessary to succeed in the investment world? Are those annoying RPG munchkins actually best suited, with some education, to become real estate tycoons? Could those get-a-lifer raid leaders in World of Warcraft be suited to be get-a-lifer currency traders? Could the girl who just kicked your butt in Age of Empires also kick butt in the stock market for real-world stakes? Do those skills translate?

Gaming Skills = Getting Rich Skills?
Maybe. I asked my friend about this, and he agreed. He went over several things he learned from playing D&D (pen-and-paper) that he felt really helped prepare him for investing. He also said that this was the second time this week that someone asked him if Dungeons & Dragons has helped him in practical life.

"D&D is definitely where I gained my comfort with charts and calculations. I think from there I became a wiz at spreadsheets in corporate america. From there I used the same skill to create spreadsheets to evaluate properties once I had established my own Real Estate Strategy," he told me. He then went on how things like creating a character (we won't mention min/maxing here...oops, I just did) helped him both in investing, time management, and as a filmmaker in his previous career in terms of fitting things within budget, and reaching an optimum balance.

"At the same time I learned that absolute strict adherence to the rules could be too 'clinical' and while staying balanced with the rules of the game it was also possible to realize what didn't work for our particular situation and make appropriate adjustments as situations arise," he told me, possibly pulling from some "Dungeon Mastering" experience. "This obviously translated well to my investing techniques. I learned several different 'methods' of investing. Learned the balance of all of them. Then created my own 'techniques' talored to my situation while keeping in balance."

Leveling Up In the Real World
Obviously, it takes more than just playing video games and pen-and-paper RPGs or strategy games. It takes directing some of that passion into another focus. But hey, my friend still plays D&D - in fact, he has more time for it now than he did even back in college.

So, gamers: if you are one of those weirdos who like talking about your characters, game balance, build orders in popular RTS games, your best raid gear or character builds, optimum combat strategies for your party against a Pit Fiend, you may be primed to score the "phat l00t" for real. You may not only be trained to excel in these areas, but you may also find they match your particularly warped gamer sense of fun.


(Vaguely) related applications of my lack of l337 gaming skillz!
* The Secret of Success: It's All In Your Mind(set)!
* Playing to Crush With Life
* The Power of Vision

Labels: productivity, Roleplaying Games

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

 
Frequent Demos Kill Software Development
Okay, today's post is gonna be a little more on the technical / development side o' the fence, and not even game-specific. Sorry.

A friend of mine, who had served several years in the military, once told me, "No battle-ready unit ever passed inspection, and no inspection-ready unit ever passed battle." I have no idea if that's remotely true or not, but the point was that the traits that get measured in an inspection were very different - and perhaps even contrary to - the traits required to succeed in actual combat.

I wrote some time ago about the root of some of my tendencies to procrastinate, the "local maxima problem." The problem comes from the fact that many times, in programming, you have to break things to fix them. The "agile programming" folks like to invoke a technique called "refactoring" - you basically throw out the old code and make a whole new version. No big deal - or at least it shouldn't be. In fact, it should be happening all the time.

The problem is that during the time that this is happening, apparent progress might halt or even appear to go backwards. From the perspective of an outsider, at the end of two days of frantic labor, you've got something that looks exactly the same as it did before. Oh, sure, as a developer you know that this new, improved version is ten times faster, much easier to maintain, and got rid of four bugs that were practically insurmountable in the old code.

Now, as a programmer, I should be in that mindset. Totally. But I'm not. And some things happened at Ye Olde Day Job that reminded me of why I'm usually not... and may be the source of some of my development hangups.

You go like crazy to hit a demo milestone. This is true both in the games biz and much of pro software development. And this, I believe is a good thing. There's another saying in software (and I think hardware, too) that "if it weren't for trade shows we'd never get anything done." It forces an integration pass, acts as a huge motivator, and can really help a team get the important things done.

But in doing that, you may throw in some crap code for the demo that's pure prototype to help the end-user see all what you've been working on. Maybe it's some slapped-together front-end menu, or whatever. You show it to the powers that be - your own upper management, or maybe your publisher. You decide on changes. And then - ideally - you go back to your desk, and proceed to rip certain aspects of it apart to refine and refactor and improve the project as a whole.

But lo and behold, after a certain point in the project, said Powers That Be become a lot more demanding and random. They suddenly want to see the latest and greatest version ten days AFTER a milestone. This is sorta like them coming by for you to take them on a test drive in your car while you've got the engine pulled out and on the garage floor Yet Again.

And this makes your publisher or upper management people grouchy. What the heck are you doing? The software was working just fine a week and a half ago, why is everything crashing and broken now?

So you become paranoid about yanking anything - which means real progress slows down because you are afraid to make any move unless you are sure you can get it back into a demo-able state within two hours' notice.

Sure, one might say - there's CVS - or whatever source-control system you are working on. Just make sure that everything is working perfectly before you check it back in. Great idea. But often impractical in a collaborative effort with a whole bunch of cross-dependencies. Never mind the treacherousness of trying to make a build and run it untested on some other computer besides a dev box in the middle of development, without having done a reasonable integration pass (and if you happen to do automated integration testing every time someone checks code into source control, give yourself a gold star... but you are probably still painfully aware of how dangerous it can be even doing that).

So - yeah. Bottom line - if you want to shoot development progress, fill it full of lead, and leave it bleeding at the side of the road in a toxic pool of virulent disease-ridden slime, perform frequent spot-inspections and impromptu demos.

That little bit of aversion therapy lives with me still, even as an indie answerable to nobody. I still find myself paranoid about retreating from the dead-end of local maxima.


(Vaguely) related bits of ranting
* Fighting Procrastination: The Local Maxima Problem
* Productivity Tip: The List
* Embrace Code!

Labels: productivity, programming

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

 
Frayed Knights - The Stupid Stuff Takes Too Long
Tales of Frayed Knights, the comedic independent fantasy RPG coming from Rampant Games in the not-too-distant future. I hope.

It's friggin' midnight. And I just realized why my weapons are not responding properly to the armor level of the characters. Inside the character class file, I have a function that gets their armor level.

It looks something like this:

function Character::GetArmor(%this)
{
// Gets the total armor level, including current magical effects on the character.
// To Do: Everything. This is a stub.

return 0;
}

Great. Oh, well, I'm already in the middle working on equipped effects (things that happen to you while an item is equipped), so this isn't such a big deal. But it does explain a few things.

Writing Dialog. This is my favorite part of working on the game, but it isn't easy. And it is surprisingly time-consuming. Some of it works, some of it doesn't, and every single bit of it needs a major editing pass to make sure all the plot points are being hit, and that the appropriate dialogs have at least a subtle shade of humor and are speaking with the correct "voice."

Then there's allowing a "freelook" mode, but I want it to snap back to a particular pitch you are done looking around at the environment. Unfortunately, Torque doesn't give you any control over this with the Player or ShapeBase class, so I have to make a minor engine change. No big... but it takes time.

Then I spend about an hour and a half working with James to get the mount point working on his models so that the weapons aren't growing out of the back of their knuckles. James lives about 850 miles away, so much of the delay involves sending files back and forth. But part of this is just nailing down a process for us both for future content.

A crash when traveling between the dungeon and the village has me baffled. I try and trace it down in the debugger, and find it's something to do with player movement - before the level is fully loaded? It stumps me for a day. Realize that for me, a day means spending nine hours at the day job, plus a slow, snow-covered, slippy-slidey commute each way, plus an evening scheduled with other stuff that comes with having a life, not to mention a blog post, so we're really only talking about two or three hours of actual time spend working on the problem - between 2:00 AM one morning when I call it quits for the night, and 9:30 PM the following night when I get cracking again. But after a day, I realize a (possible) solution, having worked with Torque a little too long. I schedule the level load rather than calling it directly. Bam! The bad crash goes bye-bye, and everything suddenly works.

There are buttons that don't work anymore because they are properly calling the new UI manager, but I'd neglected to upgrade the call their container dialog, so it's still manually being brought into existance. The UI manager doesn't know anything about it, so the buttons aren't working. And then there are inexplicable slow-downs when certain dialogs are up. But it's bad! I need to find the problem and fix 'em.

Grumble.

While the entire first chapter is, as of last night, playable from beginning to end, there are a couple of major issues still outstanding. Like, oh, saved games. And trading. A new and improved inn. But for the most part, we're down t0 "stupid stuff," which takes almost as long as the big tasks. All those little details that might fall through the cracks. And there's a LOT of it. It's those stupid, little things that take so much time, paralyze apparent progress, and drive me crazy.

I hate this part. And it's not even in the serious bug-fixing stages yet. This is the point in the project where keeping an updated "to do" list is critical, and where you have to take satisfaction from seeing lots of little, stupid things marked off as "complete." Because it doesn't make great screenshots, and the players won't notice it at all unless it's not done right.


Forum Discussion, Because Misery Loves Company

Labels: Frayed Knights, productivity, programming

- posted by The Rampant Coyote @ 1:08 AM (Permalink) 4 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

 
Task Switching
One hindrance to my productivity that I've found is task-switching. When one task (usually programming, since that's both the day job and the side-job) is complete, I find myself either lingering overlong to "gold-plate" it, or seeking distractions, rather than moving on to the next job.

Am I spending too much time just patting myself on the back, or rewarding myself with distractions? Quite likely. I've noticed that with Frayed Knights, that between the Torque Game Engine / Torque Game Builder "Frankenengine" and the groundwork I've already laid in the game's architecture, a lot of the tasks I've set for myself actually take less time than I expect. When I get on a roll, I can cross off a lot of jobs off my list, and see enormous progress on the game.

Having that written list (which I've begun maintaining a lot more meticulously over the last week or so) is one of the keys to maintaining that productivity. I have found that I stall out a lot on "deciding what to do next." Being able to consult the list - particularly if it has already been prioritized - really helps remove this one mental block.

A trick I used during Void War's development - which I haven't yet implemented in Frayed Knights (though I may be fast approaching that stage) was to arrange the tasks in "triples" - a task I was really looking forward to doing, a task that really needed to be done to keep progress moving forward, and a major bug-fix that I really felt like putting off. The trick was that I couldn't do any other tasks (usually) until I finished all three of the "triplet." This meant I had to finish some annoying tasks before I could move back to a fun one.

Once I get going on a task, if I can get "in the zone," I do pretty well. It's just those naughty little transitions --- getting started on the next task --- that keeps tripping me up. Any ideas for how I could do to fix this?


(Vaguely) related yammering:
* Productivity Tip: The List
* Fighting Procrastination: The "Local Maxima" Problem
.

Labels: productivity

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

 
Frayed Knights Squeaks Into the Lead!
Frayed Knights is a contestant in the MyDreamRPG Game-In-A-Year competition, and the mid-contest tallies were reported late Friday evening. The results..?

Frayed Knights is in first place. By only 50 out of over 10,000 points. Talk about a narrow lead - less that 0.5%! The four other games in the top five positions include Pelorea, Isles of Midgard, Arcanoria, and Fantasci. Thus far, the contest has been rewarding process and communication more than the games themselves... which has caused a small amount of drama by teams that feel that their projects are superior. And they may well be correct.

Pelorea, in particular, seems to be particularly well-run. Of course, it all comes down to the game's release and how it is received. THAT is pretty key. All five of the front-runners could miss the release (to be honest, I am worried about Frayed Knights, too), which would kinda turn the whole contest on its ear.

There are several games in the middle of the pack that are looking really good, and if the contestents don't give up on them, they may do really well. I've mentioned Aegist Road before, partly because our own DrSlinky - AKA Greg Tedder - is heading up that one. B.R.A.V.E. is looking better and better.

I hope that this contest encourages a lot of indies to actually finish their games and get them to market. There's much too high of a failure rate in first-time indie game development (and second-time, too).

Labels: Frayed Knights, productivity

- posted by The Rampant Coyote @ 6:09 AM (Permalink) 8 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

 
The "Cool Cam"
You may recall the story I posted many moons ago about the "Cool Cam" in European Air War, and how that presentation saved the project. It's now gotten the "Worse Than Failure" treatment.

The Cool Cam

It's cool that the whole "presentation is reality" could be used for a force for good instead of evil once in a while. On the other hand... boy it gets annoying sometimes that it's all about the shiny.

Labels: Flight Sims, productivity, retro

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

 
Making a Game Out of Work.
I got this link from ~J (and GameSetWatch has now posted it) - a New York Times article which is rather progressive for mainstream media:

Why Work Is Looking More Like a Video Game

The article doesn't have many specifics, but the general idea is a Customer Relationship Management (CRM) tool that borrows some principles from gaming to make it a tool that employees want to use, and will actually encourage them to excel. In particular, they are pushing some very vaguely MMORPG-like principles to make the CRM tool more fun to use.

Having worked on CRM-style software in the past, I can say, "Good, they need SOMETHING!"

The article itself wasn't all that informative. But it did make me think about the concept a little bit. Yes, we're all familiar with management techniques designed to encourage "friendly" competition and raise morale. Unfortunately, competition (especially if bonuses are involved) can quickly become anything but friendly - and often destructive to the business. And too often the morale-building or "team-building" exercises backfire. Badly. Especially with highly educated, professional, experienced, and jaded team members. As anybody who follows Dilbert is keenly aware (it's so funny because it is true).

But it can and does work if done properly. The problems usually occur when the goals of management and labor are at odds. When people see the CEO get a bonus after doing a 10% headcount reduction, there just ain't much you can do there to stem the tide of cynicism and a rift 'twixt the two sides. But if things haven't gotten to that level, the suggestion here is an intriguing one.

One of the challenges management often faces getting employees to use productivity software is that it is NOT fun. It is of benefit to management, but not of benefit to the employees. NOBODY operates at 100% efficiency, all the time, and so the introduction of more tools that track their performance might be perceived as increasing their vulnerability to management. Then there's the problem of poor metrics - a problem in any company. Professionals are often concerned that they are going to be judged by criteria that are not an accurate representation of their true productivity and worth to the company - such as, for programmers, being judged by "lines of code."

But what about creating productivity tools that are not only truly useful to employees, but include "game" elements to help with motivation? Borrowing from MMO elements to show incremental progress, provide bragging rights, and some friendly (informal) competition? Tools that are "fun to use" and thus more likely to be used? Particularly tools that make tracking of progress more of an interactive, employee-based effort than a management watchdog trick?

For example - project tracking. I've had some practices that worked with project tracking. Seeing things ticked off the list --- that incremental progress feedback --- is something of a motivator. But how about tying it all in into something more game-like in a non-zero sum multiplayer game? What if the project tracking software showed tasks as mobs, with a difficulty rating assigned to them? Your score increases not only for slaying your task on time, but you get bonus points for beating it early, and additional bonus points for assisting a coworker on THEIR "mob." (Bonus points which do NOT detract from said coworkers score?)

How about - in the programming world - unit testing? Most programmers and software development managers love the concept of automated unit tests, but most are also reluctant to accept the short-term productivity hit. But what about turning the development, maintenance, and the successful passing-off of unit tests part of a game? More of a peer-based effort with minimal management oversight? Again, using unit tests as a sole measure of performance is an absolutely terrible idea, and you wouldn't want to go overboard on it. There's the need to actually - you know - get the software WRITTEN that you are writing unit tests for. But turning it into a game where having a certain number of unit tests working (and of sufficient quality) are worth some extra XP for the week in a fun little internal competition could lead to improved performance.

If combined with reasonable rewards from management (like a bonus to everyone on the team based on completing a project on time and with high quality... or even an extra bonus for exceeding total project goals), and if the metrics aren't taken too far or too seriously, it might help make the the workplace more fun AND more productive. Give the entire team an on-the-clock hour of Unreal Tournament or Starcraft 2 (when it comes out) if they manage to score a combined total of 200,000 XP for the week on the project. Whatever!

Now if you could actually convince management to buy off on something like that... convince them that tools that are fun to use have the advantage of BEING used.... Sorta like those old "Aim Toothpaste" commercials (if it tastes good, they might be brushing longer).

I wonder if this is an area where indie (and former-) game developers could really exploit in the future...?


(Vaguely) related buzzword-compliant paradigm shifts in the vertical space.
* Productivity Tip: The List!
* Playing the Game of Real Life
* Productivity Under Pressure

Comments in the Forums

Labels: Biz, productivity

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

 
The Secret Of Success? It's All In Your Mind(set)!
Charles Darwin and Leo Tolstoy were considered pretty average children. Ben Hogan was uncoordinated and graceless as a child, and his early golf career wasn't very impressive. Contrary to the movie, while Amadus Mozart was trained very young in music performance and composition, his early works weren't genius - they were often patched-together bits taken from other composers. Muhammed Ali was clearly NOT cut out to be a championship boxer. And Michael Jordan was cut from his varsity basketball team, because he just wasn't as good as the other players.

Good thing they all quit before embarassing themselves, huh?

It's All About Mindset
I read a book last week entitled "Mindset: The New Psychology of Success" by Carol S. Dweck, which was a pretty eye-opening experience. Not because anything in there was really mind-blowingly new, but rather that it summed up a great deal of my own experience and belief. Dweck is a professor of psychology at Stanford, and an expert in the field of human motivation and intelligence. Her book pretty handily demolishes a lot of popular (and deeply-held) myths about success, successful people, failure, human learning, and progression.

Dweck breaks everything down by mindset: The "fixed" mindset, and the "growth" mindset.

Fixed Mindset
The fixed mindset is of the belief that this is how a person is, that their qualities and talents (like intelligence, athletic ability, etc) are relatively fixed, and while they might develop some new skills, its limited by their aptitude and fixed characteristics. The fixed-mindset perception is that success is "easy" for those who are good at that kind of thing. That "naturals" will quickly rise to the top of the heap. This includes both their perception of themselves and others.

People exhibiting the fixed mindset tend to overestimate their skills, and they focus a great deal of energy to protecting their own self-esteem and hiding any deficiencies and "proving themselves" to others. They tend to shy away from challenges and instead focus on repeating what they already do well. And when things go wrong, they tend to search for places to put the blame.

Growth Mindset
The growth mindset believes that talents and abilities can be improved through passion and effort. Always. People with the growth mindset are less concerned about image in the short term, and more readily accept difficult problems that challenge themselves in hope of learning and growing.

The growth-mindset tends to look at deficiencies more openly and honestly, and then seek ways to overcome them rather than hiding them. It's committed to learning, to seeking out challenges in spite of the risk of failure.

Which Way Yields Success?
If you define success as never failing at what you do, then being a growth-mindset individual will lead to heartache. Because with it comes lots of failure. The fixed mindset tends to view success as something that "comes easy" to people who are good in their field. The growth mindset assumes that once something does "come easy," it's time to move on to bigger challenges.

Backed by plenty of research and anecdotal evidence, Dweck submits that the fixed mindset greatly inhibits success, and the growth mindset promotes it. In fact, her studies show that this mindset is an extremely strong indicator of future success in any endeavor.

Where Did We Go Wrong?
And it makes sense. We're all born with the growth mindset. Nobody comes out of the womb as an expert electrical engineer, brilliant guitarist, or a star basketball player. But society's views tend to favor the fixed mindset, and tends to comment on ability and performance rather than effort. We praise people by saying things like, "you must be really smart," or "you are amazingly talented," or "you are really good at this." In fact, when we do praise effort, its usually used as a way to hide criticism for a poor performance. After all, if someone was evaluating your work, and the first thing that came out of their mouth was, "Well, I can see that you really put a lot of work into this," what would you think?

Dweck has a great commentary about some of the popular children's parables in Western culture:

The story of the tortoise and the hare, in trying to put forward the power of effort, gave effort a bad name. It reinforced the image that effort is for the plodders and suggested that in rare instances, when talented people dropped the ball, the plodder could sneak through.

The little engine that could, the saggy, baggy elephant, and the scruffy tugboat - they were cute, they were often overmatched, and we were happy for them when they succeeded. In fact, to this day I remember how fond I was of those little creatures (or machines), but in no way did I identify with them. The message was: If you're unfortunate enough to be the runt of the litter - if you lack the endowment - you don't have to be an utter failure. You can be a sweet, adorable little slogger, and maybe (if you really work at it and withstand all the scornful onlookers) even a success.

Thank you very much, I'll take the endowment.

The problem was that these stories made it into an either-or. Either you have the ability or you expend effort. And this is part of the fixed mindset. Effort is for those who don't have the ability. People with the fixed mindset tell us, "If you have to work at something, you must not be good at it." They add, "Things come easily to people who are true geniuses."

It makes sense. According to Dweck, Michael Jordan might very appropriately have been dubbed the hardest-working basketball player in the NBA during his career. Even as age had its effect on some of his earlier trademark moves, he continued to learn and grow, eventually becoming one of the best-rounded players in the game. It didn't come easily to him. Yet can anyone say he wasn't a true genius of the game?

Self-Analysis
Dweck includes plenty of great info in the book on analyzing one's own mindset, and ways to escape the fixed mindset. She shows how it can be used in anything - in business and career, in artistic pursuits, in education - even in such things as dieting and overcoming bad habits (short version: Forget willpower or vows to oneself. That's fixed-mindset thinking and does not work. Instead think making and executing on alternatives to whatever those habits are).

One thing that kind of shocked me was where I found myself falling victim to the fixed mindset myself. I think I generally have a good view of my own potential for growth - though I may have been limiting myself even with my comments on how I aspire to "suck less" at something. But I have been putting some time in on "learning the ropes" in areas I previously knew very little about. Marketing, business, art, 3D modeling, blogging, running a website - these are all skills I have been enjoying learning, in spite of the fact that they can be exhausting to learn.

But one area where I was surprised to find I had a pretty fixed mindset on is my skill as a programmer. Particularly now that I am a "senior programmer" in my career, and I feel like I'm supposed to be this super-powered John Carmack-esque programming god. I'm not. And I have come to realize that I've been pretty fixed-mindset about it, not jumping into challenges and learning new stuff related to programming with the zeal I used to. Which could really be hampering my overall potential (okay, making it clear: According to Dweck's research, that attitude is killing me in a field I view as my specialty). I remember how much I enjoyed learning to program in Python when required by the job (and, since I was hired with the full knowledge that I didn't know the language, there was no expectation that I be an expert at it on day one). Obviously, the mindset needs to be changed. I've still got plenty to learn, and no excuse for sitting on my laurels.

Mindset is a pretty simple, straightforward idea. It's funny how something so simple could be so strongly linked to success or failure. I highly recommend checking out the book (I snagged it from the library after reading a review about it). Again - nothing in it was earth-shatteringly new - it made perfect sense to me, but it did help me look on my life and career with a new perspective.


(Vaguely) related proof I need all the help I can get:
* How Much Difference Does Preparation Make?
* The Power of Vision
* How to Sleep Less and Get More Done
* Playing To Crush With Life

Read or Post Comments on the Forum

Labels: productivity

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

 
Quality vs. Scope
Jamie Fristrom has just posted an article on GameDevBlog that ought to be required reading for anybody starting out on a game development project (indie or otherwise):

Manager In A Strange Land: Quality Vs. Scope

He makes some very interesting points:

* We're familiar with the triangle of cost, quality, and speed ("You can have it fast, you can have it cheap, or you can have it be of good quality. The problem is you can only pick two of the three.") But when referring to games, there's also the scope dimension (arguably an aspect of quality). So you can have rapid development, inexpensive development, a high-quality game, or a big game. Pick two. He notes some "big" games that were dogs... and that the mega-hits that were both high quality and large scope *all* slipped schedule (impacting both time and cost).

* He suggests that one of the reasons we keep allowing scope-creep is that its much easier to estimate schedule for features rather than quality. We can easily estimate the time it would take to get feature X implemented (take your best guess, and then multiply by four, right?), but we're very poor at estimating the amount of time it will take to fix, polish, and perfect all those features. As a result, the features go in, the polish... not always.

* He stumbles across an interesting point: Scope can usually be worded as "more" of something, and quality can usually be worded as "less / fewer" of something (less crashes, fewer texture seams... basically fewer problems).

Anyway - it's a fascinating article. Worth checking out for developers!


NOTE: Comments / Discussion on this can be found on the forums:

COMMENTS ON QUALITY VS. SCOPE

Thanks, DGM, for getting that started!

Labels: productivity, programming

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

 
$10K Game-In-A-Year Contest Judging Criteria Posted: Time to Level Up!
Today, Dave of MyDreamRPG.com posted the judging criteria for the game-in-a-year contest.

Points started accruing at the beginning of the month, so if you were dragging your feet (like me), it's time to get cracking right away.

According to Dave, the purpose of this contest is, in part:

"to get ...languishing projects to pull together and move it forward. There might be dozens of people who have projects laying around for a couple years of various states, experiments, etc. A project begins in the imagination, and in that case some people may have 20 year leads. There is virtually no such thing as a fresh start here.

Many people have designs, art, and a dream. That puts everyone in the same boat. Furthermore, a year is a mighty long time and levels the playing field. There's also the matter that the contest is not judged by end product alone, but by the completion of lots of requirements along the way. Design documents, rosters, scheduling, blogs, website, updating designs when features change, beta testing, etc. This means that theoretically a 1 man team could nail every point along the way and take the lead. So many factors go into this that it's a level playing field and a larger team is going to be in trouble if it's not managed well."

I think I may do very poorly in several categories. :) I'm already shy some points. But hey, it's all good fun - with a chance of a $10,000 prize at the end. That's quite a bit more money than I've made on Void War so far... so it's a very worthwhile goal. And I do think it's an intriguing approach. Based on these criteria, ANYBODY has a chance at the prize - whether you are a solo newbie or a veteran team-of-six. The contest is about hitting your deadlines, being accountable in your procedure, and GETTING THAT GAME DONE.

Labels: Frayed Knights, Indie Evangelism, productivity

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

 
Public Display of Game-Making? See Everything You Didn't Want To See!
Game development out in public? Where... PEOPLE... can... see *gasp*? Shamefulness!

One of the things I learned immediately upon getting a job in the videogame industry in *cough*1994*cough* was how very paranoid it was. There were NDAs (Non-Disclosure Agreements) to sign at interviews, any time you brought guests in, and any time two companies met together to discuss business. There was lots of legal butt-covering going on to make sure that we couldn't be sued by some kid claiming we "stole his idea" of ... say, having cars with guns. There are tons of reasons for keeping game development hidden behind a curtain, including the following (some of which even apply to indies).

Reasons To Stay In The Closet (With Game Development, I Mean...)
Protection of Ideas:
Now, as the old joke goes, it's not paranoia if they really are out to get you. And when you are talking major publishers and game companies, the level of mutual screwage going on even WITH the layers of protection really is astonishing. Oftentimes its in the "legal, but ethically ambiguous" territory - but it's there. In fact, I remember my team lead once reporting that the VP of marketing (I think) informed him that what we SHOULD be doing to make budget titles was to simply look at what Microsoft was doing, rip them off, and he'd package them in boxes that looked as close as he could legally get away with. Yessir, it took years for me to learn to give a marketer any amount of respect after that.

And companies at that level are in such a fierce state of competition that they are often pushing products that have to match their competition feature-by-feature. Getting a clue as to what new feature your competitor is throwing into next year's offering early enough to duplicate and add a new twist on it is huge.

Now, as an indie, there's not much reason for the paranoia. As Howard Aiken once put it, "Don't worry about people stealing your ideas. If you your ideas are any good, you'll have to ram them down people's throats." It's not like you are going to be launching a multimillion-dollar marketing effort that people could try and ride the coattails of. Sure, cloning will happen, but usually only after you have been proven successful.

Managing Expectations
One thing many developers have learned the hard way is that the merest hint of a particular feature in a hotly anticipated title can and will be given the full weight of a promise by the fans and press, and you will be held accountable for it by the fullest measure of punative actions your audience and journalists have the power to dish out.

As with most indies, a rabid pack of hardcore fans isn't exactly at the top of my list of problems.

Controlling The Hype
The PR and marketing people at big companies rely upon the careful doling out of information on your game as a way of building and controlling hype. With mainstream retail sales making most of their money during the first six to twelve weeks after release, it's all about making sure the hype peaks at the exact moment the game goes on sale. This means carefully measuring and controlling what information goes out about a game and when. If the hype peaks early, interest will have waned long before the game goes on sale.

Does this apply to an indie? Not so much. Sure, it's still a factor, but indies have a bigger problem getting ANYONE to pay attention to them. Ever. And indie games tend to have longer, slower lifecycles. Even if they do make it out onto the store shelves.

Embarassment
Game development is UGLY. I mean it. You have cancelled and back-burnered projects (I've had TWO since completing Void War). You have bad decisions that you later regret. You have really cool ideas that never make it into the game. You have even cooler ideas that get compromised down to a bastardized shell of their original concept. And you have long stretches of time during mid-development where progress just seems to slow down to a crawl and it's just... well.... BORING. Do you really want your customers and audience to see all the messy crap that goes on when making a game?

Are You Gonna Talk About It Or Do It?
Then there's the problem of spending so much time talking about your project that you never actually... you know, COMPLETE it. That's actually been a problem for me with this blog -I love talking about indie game development and the games industry and games in general, but it sure eats into the limited dev time I have at night. And there's the problem of falling victim to your own hype, and failing to see the reality that your project has become while you've been talking about how cool it is.

Newbie game developers fall into this trap ALL THE TIME. Without the motivating factor of, say, having a paycheck based on performance, its easy for talking about what you are going to be doing act as a psychological substitute for actually doing it. (Incidentally, I'm of a firm belief that this is a problem with people who keep pushing "business meetings" as well...)


Reasons To Let It All Come Out In The Open
The above are some very compelling reasons to follow the lead of our mainstream bretheren, to keep projects under wraps until it is time to do a Great Unveiling to the world and let them marvel at the finished product, and about how you make it look so easy. But could more be gained than risked by a small indie wanting to... er... expose themselves?

Sharing Is Good
I had a great experience many moons ago creating a "micro-project" and doing a write-up, documentary-style, called "How To Build a Game In a Week From Scratch With No Budget." I did it on a dare, and I've been pleased with the response. I've had a lot of people tell me that they learned a lot from it. Considering the failure rate with new game developers hitting the wall about 20% of the way into development, I think a lot of people could benefit from seeing how someone actually managed to plow through those difficult stages. Or maybe see how they floundered and be ready to avoid making the same mistakes.

Feedback Is Good
I had a really positive experience soliticing opinions about my Apocalypse Cow screenshot last week. It's kinda nice to solicit opinions BEFORE the game is "final" and you are asking people to shell out real money for it. There are several experienced indie developers with better eyes towards production values (and a greater disgust of the Comic Sans MS font) who had some great bits of advice. Not all perfectly useful at face value, but a lot of suggestions for new ways to look at things.

And it's really useful to have people to act as a sounding board when you are kicking ideas around. You lose that a lot when you are working on your own.

Its A Good Way To Learn
I'm not a productivity expert, or even a game development expert. Sure, I've done my time in the mainstream game industry, I've been making and selling indie games for a couple of years, and I've spent a lot of time (virtually) rubbing elbows with some really smart indie game developers and learning quite a bit from them. And I'm happy to pass what I've learned around. But the more I learn, the more I realize I still don't know.

One thing I have discovered is that when you talk about and explain what you are doing to other people, or when you teach other people something, the person who often learns the most is you. Any professional programmer can tell you experiences of how they figured how to fix a really frustrating bug only after they tried to explain to a coworker the nature of the bug in hopes of hearing a simple solution. In the process of explaining what's going on, the solution just dawns on you. It's fun being the coworker in this situation too, seeing the dawn of realization occur on the programmers face as they suddenly figure out the answer, when you STILL have no clue what they are talking about, and then just grinning and saying "Glad to help."

It Enhances Commitment
Steve Taylor once called this "throwing your hat over the fence." When you say you are going to do something, you are committing to something and you know you are going to be embarassed about it if you don't follow through. If you throw your hat over the fence, then you are committed to climb over the fence to retrieve it. This can help motivate you on those days you really feel like surfing the web or playing Fastcrawl instead of working. (Argh, what am I saying? Play Fastcrawl anyway!!! It only takes like twenty minutes!)

And... Aw, Shucks, It Sounds Like Fun
I'm not doing indie game development as a principle means of income. Maybe someday (yes, it is a goal), but not now. If I was totally in it for the money, I'd be doing somethig else far more valuable with my time. But I'm in it because - well, I love doing it. I love talking about it. It excites me. So if there's an opportunity to do something even more fun with it... I'm game.

Coming Soon: A Weekly Diary of Indie Game Development
Well, as an indie, I'm gonna say the pros have it over the cons. So I'm going to maintain a development diary of the making a commercial indie game from start to finish. Updated weekly. It'll be as interactive as you like. Feel free to offer suggestions, ask questions, hoot, jeer, whatever. I may not reveal everything (there's gotta be some surprises in the game itself, after all - it IS an RPG), but for the most part it will be kind of an "Anti-NDA" event. Developing right out in the open, where anyone interested can see it and comment on it.

Right now, I am imagining a format similar to what I used for the Hackenslash "Game In A Week" article. But it'll be more of a game-in-a-year project (appropriate, as I'm still considering that contest at MyDreamRPG.com. Though they haven't followed through on releasing the judging criteria yet.) Each week, I'll update you on what I have done, what I am doing, and where I think I'm going with it, and invite your participation and feedback.

I won't pretend this is like a totally revolutionary idea. Mike Hommel already mentioned in a comment earlier this week that he's already doing something like this too. And the great Sid Meier did it once for a game that ended up being cancelled (probably why he doesn't do it anymore). And lotsa folks have maintained public project updates. But this will be an interesting experiment (for me, at least) in really opening up the process to scrutiny and discussion.

This will not be slick marketing hype disguised as a development diary. It'll be embarassing. It'll show you just what a crappy game developer I am. It'll be full of wasted time and effort, bad judgement calls, shattered dreams, stupid ideas, dissapointments, confusion, and compromises. It'll be written as it happens, without the advantage of a post-mortem's hindsight. It might ruin my already questionable reputation. It may totally ruin the chances of the game selling a single copy.

And, probably, nobody will really care or pay attention to it.

But it kinda sounds like fun, doesn't it? Well, fun for me, at least in a self-flagellating kinda way. I hope it'll prove at least mildly entertaining, and enlightening (if only to reveal what not to do). While it won't be a community effort, I would love for it to be something of a collaborative exercise, as I bounce ideas off of people and get feedback on what I'm doing. And hopefully I'll learn more from the process than "this was a really bad idea."

I hope you enjoy the ride in spite of the bumps. There's bound to be a lot of 'em.


(Vaguely) related writings of less career-limiting nature:
* How To Build a Game In A Week From Scratch With No Budget
* Productivity Tip: The List!
* The First Playable Level
* Fitting Game Development Into a Full-Time Schedule
.

Labels: Biz, Frayed Knights, Indie Evangelism, productivity

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

 
$10,000 Game-In-A-Year Contest
Well. The indie game world just keeps heating up. A new contest geared towards indie game developers (particularly RPG and MMO developers) has been announced - this one with a $10,000 grand prize!

MyDreamRPG.com is running an "Dream Game in a year" contest that started yesterday. In spite of the odd contest start date, it's apparently no April Fool's Joke. The idea is to create an RPG in one year (actually 13 months, according to the contest rules).

The rules seem a little fuzzy, but also very broad and inclusive (IMO, overly so) --- with one major, telling exception: The game you make must be based on one of the four Torque game engines (the original TGE, the TGB 2D game engine, the new "TGEA" advanced-technology engine, or the XNA-based Torque-X).

What's very curious about this contest is the judging criteria. Apparently, its going to be based more on the actual development process than on your final game quality. While the final criteria haven't yet been announced (those have been promised to be announced in 2 weeks) - but Dave Young has provided a post which gives some idea of what they are going for. According to him, "We are going with a point based system this time around, with points being awarded for the completion of various milestone tasks. The idea behind this is that the contest is covering the whole game making process, and not just the final result. In the end, the point totals will determine the winners."

This makes me a little leery, as in his post he mentions things like "backing up smacktalk" (so you have to smacktalk to get those points?), adherance to design (You'd better make sure your design is perfect when you start, I guess, or they'll dock you for changes), and update blogs on the GarageGames site.

As for me, I don't think the timing could have been more perfect. I had already planned on beginning full production of the RPG this month, regardless of the status of Apocalypse Cow. I might be doing double-duty a little bit halfway into the month, but I'm finally seeing the light at the end of the tunnel for Apocalypse Cow. If I enter the contest, I'll have to spend at least two weeks pulling my scattered notes together into an actual design document anyway. And apparently I have to do some things to increase my visibility.

I really don't know if I have a prayer of finishing the RPG by the end of April 2008. But I've got nothing to lose by trying, right? After all, I've created a (lame) RPG in only a week, before, without any game engine or commercial tools at all. A year, plus a budget, plus a game engine... that all sounds like LUXURY.

So - if you were mulling over whether or not to take the plunge -- if you've been talking for YEARS about how you would make an RPG that was so much better than anything else out there.... well, now is your chance. There's a $10G reward for doing it, and apparently handling the production in a professional manner and hitting your deadlines. And whether you win a prize or not - the prizes are only the beginning. You'll have a (hopefully) sellable product at the end of the process, not to mention a ton of experience, your own IP, and... well, something worth MAJOR bragging rights.

If you have NEVER created a commercial game before, I strongly recommend taking a look at Torque Game Builder. It's far easier to use and learn than the 3D technology. If you have any doubts as to whether a 2D-based RPG is commercially viable, I invite you to take a look at Aveyond and Cute Knight - both are based on 2D gaming technology, and from what I have heard, both of them made some pretty serious money last year --- and continue to do so. Or take a look at GameTunnel's 2006 RPG of the year, FastCrawl. Which is also apparently selling pretty well. And all three are a heck of a lot of fun, to boot. There's still a lot of games waiting to be made that aren't dependent on the latest graphics processors.

And hey, I think the time is right for an Ultima VII-esque indie 2D RPG! Somebody get to it! I'll buy it!

Opportunity is staring you in the face.
[F]ight, [R]un, [T]alk, or [C]ast Spell?


UPDATE: While the organizing website is MyDreamRPG, and the community is focused on RPGs, it should be noted here (something that I overlooked, shame on me) that they have very pointedly avoided restricting game entries to Roleplaying Games - even calling it a "Dream Game" contest. So if you are starting ANY kind of Torque game project between now and the end of June, and you expect to be completed by April 2008, you've probably got nothing to lose by entering the contest.

(Vaguely) related shooting the breeze:
* Torque 2D Game Builder Quick Review
* Give 2D a Chance!
* RPG Design: The "Brute Force" Problem
* Interview With Amanda Fitch, Indie RPG Developer (Creator of Aveyond)
* Interview With Georgina Bensley, Creator of the Indie RPG Cute Knight
* Torque 1.5 and a Torque Wish-List
* Forrest Gump Meets the Avatar of Virtue
* How To Get Me To Buy Your Indie RPG
.

Labels: Frayed Knights, productivity, Roleplaying Games, Torque

- posted by The Rampant Coyote @ 7:50 AM (Permalink) 4 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

 
Twenty Hours to Level Up
I am trying something new.

Based upon my success (such as it was) creating an RPG from scratch in 40 hours, I'm going to be working on 20 hour iterations on Apocalypse Cow. While the 20 hours aren't going to be necessarily consecutive, the idea is to focus my time the same way I was able to focus it on that micro-project.

Every 20 hours, Apocalypse Cow is going to level up.

The idea is this: I'm going to start working in 20 (working) hour iterations. That's (theoretically) a week for a part-time indie like me. I am going to shoot for having a "release" for Apocalypse Cow at the end of every iteration. Now, "release" doesn't mean a final release to public, but it should be releasable for those working with me on testing. But I am going to be treating it as if it was a release candidate. I'm going to focus and plan out my time and project for every single hour with that goal in mind.

After all, that's the goal of iterative prototyping - with each completed cycle, you have a product that could be labeled "finished."

I'm jumping into some less-familiar territory at this stage due to the amount of work I have to do with content. While I'm getting third-party help for content, I still have to do a bit of it myself. I'm not much of an artist. It's quite possible I'm going to blow 10+ hours at a shot on a single low-polygon model or polishing up an interior level. But that's just what it has to take --- things