Tales of the Rampant Coyote
Ye Olde Archives. Visit the new blog at http://www.rampantgames.com/blog/ - and use the following feed: http://rampantgames.com/blog/wp-rss2.php


(  RSS Feed! | Games! | Forums! )

Sunday, February 27, 2005
 
The Five A.M. Hall of Fame
Last night saw me still playing a computer game at 5:00 in the morning. I'd lost track of time. There are very few games that can do that to me. Doom did it. Frontier: Elite 2 did it. X-Com and Master of Orion (I and II) did it. I think waaaaay back in the day Summer Games (by Epyx) for the C-64 did it - though it has to share the distinction with Forbidden Forest because BOTH games were being played alternately during the night - Summer Games was just the one that had been going for at least an hour before the sun came up and warned us what time it was. Civilization I did it. I vaguely recall some of the Ultima games doing that (notable 4 and 7).

I think few action games make this list because the intensity of the gameplay can be wearying. RPGs - especially the modern real-time oriented one - can have the same problem. Daggerfall made it to 3:00 AM multiple time, but then the breaks where you have to read and follow plot gave my fatigue a chance to catch up with my brain and tell it that I was going to pay a hard price the following day. Turn-based strategy games are my biggest vice... like a highly addictive drug, you can start a game thinking that you can play a few turns and quit whenever you want, but sooner you find yourself anticipating your next turn before your current one is finished, and you just need one or two more to see your current plans to fruition. Your "quick fix" turns into an eight-hour-long session, and you've kissed all hope of productivity or a good night's sleep goodbye.

And now, newly indoctrinated into that personal FIVE-A.M. Hall of Fame for me is: Galactic Civilizations, by Stardock. Hey, and it's an indie title to boot!

On the surface, it looks like Master of Orion. In fact, there's a lot of similarities - you could say this is what Master of Orion 3 should have been, if MOO3 hadn't been released as a highly polished bag of unplayable crap. Do I sound bitter? Good. I bought Master of Orion 3 a couple of years ago, INSTEAD of this game, because I was a nice, boring, loyal fan of the brand, even though few of the team members had anything to do with the original classics. I tried hard to like it, and even endured two very full, VERY long campaigns to give it a fair shake. We're talking 16-20 hours of gameplay here. If a game hasn't shown you it's good side in that much time, you may as well just stick a fork in it anyway, because it's very done.

Okay - moving away from that sad, sad topic. Galactic Civilizations + the Altarian Prophecy. I'm a latecomer --- GC2 is due out "soon." There's plenty of reviews archived out there for this game, so I won't try and review it. I'll just bullet-list some points that struck me as interesting - some good, some not so good, some just in-between.

* I really missed the ship-building and fleet-handling of the MOO series. This isn't necessarily a bad thing --- it was kind of a clunky side-game in the first Master of Orion, and it kept getting worse from there (to the point of unplayably horrible in MOO3). But I still miss it --- having unique technologies and seeing them play out in front of you were a lot of fun. In GC, the ships just automatically upgrade, and the battles are simple Civilization-style affairs... these ships battle these ships, ZAP-ZAP, next move.

* The game has a fun, informal sense of humor. I love that. The text messages aren't intended to be killer jokes, but they are obviously not intended to be taken seriously. It gives the game a fun personality. I nearly fell out of my chair when an enemy race that had brutally attacked me, but then been beaten back severaly, decided to negotiate a cease-fire. (The skilled diplomat began, "Hi. Um, how's it going? About this war..."

* The tech tree is suitably huge - I have YET to complete a game with a completed tech tree. I'm curious as to what happens if you do complete the tech tree.

* There are SEVERAL paths to victory - and you can control which ones will be enabled for any particular game (I think there's at least one that only the non-player races can reach). This adds something of a non-directly competitive race aspect to the game --- you can be closing in on the victory conditions in one area, but another race is doing the same in another area, and it's a question of who meets their criteria first. This keeps things very interesting.

* Possibly due to the multiple-paths-to-victory thing (and maybe it's because I've only been playing on the easier difficulty levels), but the other races don't seem to be as genocidal as other games. They actually act reasonably from time to time. In fact, they exhibit the unheard-of behavior of actually volunteering gifts to the player (!!!) - mainly if you are a potential warmongering bully and they are trying to buy you off. But it actually feels more like a boardgame between real players - you don't get the sense that all the AI are secretly collaborating to prevent you from winning. (MOO 1 felt this way too, most of the time).

* One thing I really don't like is how so much of the game is represented by just a handful of numbers. You find all this cool, exotic-sounding technology that could be very cool... and all it does is give you some extra bonuses. That's very unsatisfying. It would be nice if more of these technologies opened up new options to the player.

* It's also really hard to figure out where all those numbers come from over time... you end up with a bunch of insignificant bonuses (or penalties) that you don't notice, but they all add up over time. It's also hard comparing these numbers to see how they work --- but some of that may come with more time playing.

* There is a "good-evil" alignment in the game, as in an RPG. This effects how other races treat you, and your alignment can change based on your actions to several moral questions that appear during the game. These are really cool - you are given one of three choices. The "Evil" choice usually gives you a quick and significant bonus, while the "good" choice involves some kind of sacrifice. I like this, though it's a little unclear what the advantage is of being good - unless it makes it much easier to gain good alies (I haven't seen how well evil nations band together - though it's easy to imagine that they aren't the most loyal of allies in the game). It might also effect the economy and morale of the people (after all, that corruption's gonna trickle down...) I need to read up on this to understand it more. Assuming there are some real long-term benefits to being good, then this is a really cool and interesting mechanic.

* I really love the ability to gain bonuses to your ships by exploration. In most 4X games, you can gain a few bonuses or new technologies early in the game through exploration, but by mid-game that's all over. From what I can tell, these little space anomalies or pieces of junk keep spawning over time. While you may not be able to keep up with advancing technology through exploration alone, it is a viable "supplement" to the tech race. Of course, you can gain techs by espionage and conquest as well, so there are plenty of options if you don't want to focus too much budget into research.

* I wish there was more ability to bombard / blockade a planet from space. There's no opportunity to "soften them up" with bombardment before launching an invasion. Maybe that's not entirely unrealistic (I have heard that the "softening up" of German forces by air prior to D-Day had a negligable effect), but its still frustrating to have no real way to besiege a highly-populated system prior to invasion.

* There is a LOT of depth in the game, and a lot of factors you have to juggle. It's hard to win with just a single strategy, and except for the "cakewalk" difficulty level it's impossible to just be great at everything.

* Speaking of which - the difficulty factors (including new mods from the Alterian Prophecy expansion) show a really huge range of challenges. I really don't like games like this that make you feel like an idiot because you get clobbered your first few times at the easiest difficulty levels, when you are still learning, or that take such huge steps in difficulty that you find yourself helplessly stuck "between levels" as one is boringly easy and the next is frustratingly difficult. (I did play on "Masochistic" difficulty level briefly - it seems like it drops you into the middle of the mid-game with starting technology and little elbow room... ouch!)

Anyway, while I have plenty of nit-picks (more room for the sequel, I guess), overall it seems a worthy addition to the "Five A.M. Hall of Fame." Unfortunately, I have way too many things going on right now to indulge in much of that (ah, to be young and back in college where I could just blow of a class the next day if I was so weak...)
Tuesday, February 22, 2005
 
Computers playing Go
http://www.cs.unimaas.nl/~vanderwerf/5x5/5x5solved.html

This is actually pretty old news, but it was slashdotted today. Just goes to show that while information may be available instantly via the Internet, sifting through it all to find noteworthy items can take forever. Anyway - Go for a 5x5 board with an opening move in the center was "solved" by a computer program. Even knowing what I know, it hardly seems noteworthy.

When I was in college, a huge part of the grade for my second-semester AI class was Go. We had to learn the game well enough to play a competent game (I think that was worth 5% of our grade). Then we had to write a program to play Go.

The cool thing about the game of Go - which is to Asia as Chess is to the Western world - is that it is not reducable to the kind of "brute force" solution that Chess is. A pure search-tree (even with Alpha-Beta pruning and other optimizations) just won't work. At least not until we have quantum computers that are billions of times more powerful than our current machines. In Chess, you have a very limited number of moves at each turn. And many of those potential moves can be easily ignored because they'd clearly lead to very poor results (though how clearly is a good question for a chess program --- to a beginner, what seems like a bad move might actually be a great way to allow a game-winning opening). For the mid-game, Chess programs can just use a brute-force search to see many moves ahead and choose what seems to be the optimal result.

The opening game has a lot of move possibilities. All your pawns and knights have two possible moves each, for a total of 20 possible moves, which is fairly broad. Your opponent also has around 20 possible moves, and in all likelihood you'll have a similar number of potential moves for the first six moves or so. That's 20 x 20 x 20 x 20 x 20 moves to examine (before optimizations) to look just six moves ahead... that's 3,200,000 possibilities to explore. While that's doable (especially with optimizations) on modern machines, it doesn't begin to take the search to an interesting depth. So most chess programs use a library of "openings" rather than searching. They frequently also draw from a library of end-game situations to bring the match to a close.

Go, on the other hand, has an unbelievably broad range of potential moves for every turn. It's generally very difficult to determine if the move is 'good' or 'poor' in the short-term, so it's hard to weight the search tree for optimization. The first move has 361 possibilities... the second 360 possibilities... the third 359, the fourth 358, the fifth 357, the sixth 356 (the number goes down for a while, though in mid-game you'll start clearing out some stones and the number may spike up a little). So that same six-move-search is 2,122,781,978,399,040 moves. Way out of scope for modern machines, and it also doesn't begin to take things to an interesting depth. So it becomes more of a "real" AI problem, and you have to try more interesting approaches.

The really cool thing about this program we had to do for class was that our programs had to play each other. A big chunk of the mid-term grade was based on a tournament between our programs. The board was presented graphically on-screen on these creaky old HP-9000 minicomputers (these things were ancient even when I was in school). As spectators, we got to watch our games play each other - a real gut-wrenching experience when you realize that your grade depends heavily upon how much better you've taught your baby to play than everyone else.

This tournament was held twice - once around mid-term time, and once just before finals. My program dominated the first tournament, but it was also ridiculously slow - my moves were taking anywhere from 20 seconds to 4 minutes (!!!) to process. For the second tournament, the rules were changed (thanks to my program) to allow no more than 30 seconds per move.

Unfortunately, I ended up spending much of my time optimizing what I already had --- when I should have just started over from scratch. Besides optimizing, I basically put my entire program on a timer - I kept a record of the "best move so far", and when I ran out of time, I just returned that move. The end result, when all was said and done, is that the new version of my program was actually marginally less effective than the first one.

I got clobbered in the second tournament. Well, not totally clobbered - I did better than a couple of students if I recall correctly. But not only had I been forced to adapt my program to meet the new rules, but my program had turned out to be "The Program to Beat" during the first tournament - so everyone had optimized THEIR programs to beat mine. I'd become the target.

Ah, well. I still did well enough in the class to get hired on as a Teaching Assistant the following year --- and thereby meet people who were closely associated with group of people in a company-to-be that was eventually known as SingleTrac. That got me "in" to an interview (as soon as they had funding), and so that's how I got my first job in the videogame industry.

My take-aways from this experience:

Labels:


Thursday, February 17, 2005
 
More Fun With Torque!
My “quick and dirty Torque Learning Project” has expanded to become something not quite so quick or dirty, but it’s also evolved into something I’m really getting excited about as an actual product… eventually. Too much of it is still in the “Black Triangle” stage. There’s a big difference between getting a few objects to appear on the screen in a single mission, and creating a game’s ‘infrastructure.’ Much of the challenge and slow start has been the difficulty of getting through Torque’s steep learning curve.

Going through the scripting interface (which I’m trying to do as much as possible) is pretty easy, with a wealth of documentation available. But going through the source code to create new object classes derived from the more primitive classes is a bit less well-charted territory. There are plenty of “gotchas” that I’m discovering. I spent eight hours last week just trying to find out why an object of my new class wasn’t appearing on the screen. After a bit of hunting I discovered that yes, it did exist on the server, but wasn’t getting broadcast to the ‘client’ (a pain in a single-player game, but such is the architecture) because I hadn’t set a particular flag. I also neglected (after much hunting) to add it to the display list --- which is a rather embarrassing mistake. Especially since it was my second new class, and I ‘sorta’ solved these problems with the previous custom class. I should probably create a checklist of some kind to avoid repeating the same mistakes.

Working with Torque has also resulted in a very interesting situation where I have all kinds of features already in the game – like music, splash screens, sound effects, all kinds of nifty UI elements, and particle explosions – before much of the core gameplay is done. This is really a good thing, but after seeing such evolutionary progress in Void War (over many, many months) where so many of these features didn’t appear until the end of development, it feels strange.

I ended up going through a total of six different iterations on the control scheme before settling on the current one. I’d like to thank John Olsen and Steve Taylor for allowing me to annoy them with ideas and prototypes until I managed to simplify things down to something that feels “right.” Having some friends with extensive game-development experience to act as a sanity check is invaluable. Interestingly enough, the scheme I settled with was a bit closer to my original plan than some of the experiments I tried.

Within two weeks I intend to be out of the “Black Triangle” stage with a mostly full feature-set of gameplay and a working infrastructure (depending upon how psycho the Day Job gets… which must take first priority). Historically, this is where the 80/20 rule rears its ugly head… I’m anxious to see how much Torque helps getting through the slow, painful part of development of the 20% of the job that takes 80% of the time and effort.
Sunday, February 13, 2005
 
The Long Tail in Independent Games
In the retail market for games, it's very much a hit-driven business. A major publisher expects one or two hits a year to carry the rest of their titles - a couple more may break even or make a minor profit, but most games lose money. At least that's the story they tell. The truth is, the top 5% or 10% of the titles released in a year make some insane percentage of the money, and everything else sells a pathetic number of units.

There has been a lot of discussion in some forums about independent games suffering the same fate. The cool thing about being an indie is that you don't have to chase the "sure bets" of the big-business retail world. But nobody wants to put thousands of dollars and man-hours into creating a game that won't do anything but lose money, even on the small scale that most indies work on. Portals are reporting that if a game isn't on the front page, in the top 10 or top 15, it's never going to bring in much in the way of sales.

Wired magazine online published an article a few months ago that can be found at http://www.wired.com/wired/archive/12.10/tail.html which shows how places like Amazon and Netflix are changing this. Not that this changes the economics of things immensely - you still have the same curve in terms of sales. A top 10 game is still going to disproportionally outsell a game a few places lower in the rankings. But it means there's no "cut-off." These companies are making half (or more) of their money from products that just wouldn't be available otherwise.

From a games perspective, this could mean some small hope for the strange, niche-y games or some of the diamond-in-the-rough games out there.

So could a portal evolve that is the downloadable equivalent of Rhapsody? Maybe. It would have to feature a really solid means of guiding the customer to product that they might enjoy - something far beyond what's currently available. But there's a cost associated with computer games that could prevent this from happening - technical support. With MP3s, there's a very low overhead for supporting everything, due to the standards that are out there. But with computer games, a portal doesn't necessarily want to deal with customer service headaches associated with people trying to play a DOS game under Windows.

But is this a problem in the try-before-you-buy model of shareware? I don't know. It's an interesting thought, though, isn't it?

Labels:


Thursday, February 10, 2005
 
Keeping it Simple
Steve Taylor (of NinjaBee) and I got into a conversation a couple weeks ago about the "newbie approach to game design." Though it's also the marketer's approach to game design: Take your current favorite, coolest game. Change flavor. Add a ton of features. Viola. Instant game. Gee, that's not hard, ANYBODY can be a game designer.

Certainly, if you have the resources and expertise to pull it off, it sure helps marketing. You can always claim, "It's like last year's hit, only BIGGER!" And Bigger is Better, Right? If a game is already good, then adding additional features only improves it, right?

No way, no how. Witness any number of failed franchises in games or any other media due to an overload of crap that actually detracted from the otherwise outstanding focus of the product. All those extra features literally sucked the fun right out of it. And that's only if they managed to pull off a competent job of it. More often - from well-known game development studios as well as the never-ending horde of indie game development hopefuls - these "kitchen sink" designs collapse under their own weight long before the game even reaches a playable state. (Remember how proud the Ion Storm guys were of their gigantic design documents? They are so fun to pick on).

Indies don't have the luxury (unless they are very rich indies) of contemplating 'kitchen sink' designs to compete with modern, top-selling hits. We actually have to take a few steps back, stick fairly close to the basics, and work on presenting a really focused, entertaining experience. This was my principle for design on Void War, though I did allow a bit of "feature creep" to occur to the game as it evolved. I'm trying to do the same now as I'm working on my "next big thing." Well, it's NEXT, and it's definitely some kind of thing, but I'm not sure how big it is.

I'm knee-deep in prototyping, and we just came up with a concept that sounds silly and fun - and most importantly, it's generating TONS of ideas for entertaining gameplay. However, there's no way we can do all of them, and in fact it would probably be a poor idea if we did. With this game, unlike Void War, I'm approaching it with a little bit more market research instead of just feeding my own personal creative demons. So this means nuking a lot of otherwise cool ideas that make the experience too complicated, too confusing, too difficult to control, or otherwise detract from the focus of the gameplay.

But we also want to provide variety to keep the game interesting, so we have to choose things that enhance the 'core' experience, and make different demands of the player's skill. I've been spending a lot of time prototyping, trying out different control schemes, deciding what to keep and what to throw out. I think we've solidly identified the "core focus" of the game, and what will make the game fun and compelling, deep enough to keep playing, but simple enough that my wife would play (she wouldn't TOUCH Void War - though my 10-year old daughter got pretty good at it...)

Ah, but that's the fun and challenge of doing this. Being an indie ROCKS.

Sunday, February 06, 2005
 
Losing Your Limits Without Losing Your Mind
It was 1982, and anything was possible.

I had started programming at the age of twelve on the Singlair ZX80. That machine had all of 1K of RAM, and no "memory-mapped video" ... which meant the screen blanked out every time the CPU had to do something other than constantly refresh the screen. There was room for maybe one page of code, total. It made game programming pretty hard.

My dad pre-ordered the Commodore 64, which I dreamed about for weeks. I was designing videogames and adventure games on paper while I waited, anxious to get going during summer vacation on a games that were going to be equal or better to anything else out there. Unfortunately, by the time the C-64 was actually released, school had started. That didn't stop me from spending my evenings and weekends on the machine, learning how to harness the machine's incredible power. I'd go until late at night, the stereo next to my machine playing softly (to avoid my parent's wrath, and I usually didn't feel like wearing headphones).

My programming skill at the time was still pretty rudimentary. The ZX80's version of BASIC was pretty minimal - and you couldn't write more than a page of code for the thing anyway. While I was learning to put pictures on the screen, I was also learning to do string manipulation to do a text parser for an adventure game. I'd tried this on the ZX80, but the awful memory limitations prevented me from doing anything really interesting. But I had an idea of HOW I would do it, as soon as I had the machine with enough capability to meet my vision. In 1982, with the Commodore 64, these limitations were removed. Time to get going!

The problem was that I was still in spaghetti-code-ville writing in BASIC, and hadn't quite gotten the grasp of how to avoid hardcoding everything, or how to properly re-use code. So my attempts at adventure games were really ugly - every room effectively had it's own section of code that had to handle everything that might be done in the room. I did have the sense to break out my rudimentary text parser into a subroutine, so the rooms didn't have to repeat the parsing logic. But still my code looked something like this:

900 PRINT "YOU ARE IN A FIELD BY A BABBLING BROOK RUNNING"
910 PRINT "NORTH AND SOUTH. YOU CAN FOLLOW THE BROOK"
920 PRINT "OR FOLLOW A PATH EAST INTO THE WOODS."
930 IF LANTERNLOC=5 THEN PRINT "YOU SEE A LANTERN LAYING ON THE GROUND."
935 IF SWORDLOC=5 THEN PRINT "SOMEONE LEFT A SWORD HERE."
949 REM GET COMMAND ROUTINE
950 GOSUB 9000
960 IF CM$ = "GO NORTH" THEN GOTO 1100
962 IF CM$ = "GO SOUTH" THEN GOTO 1200
964 IF CM$ = "GO EAST" THEN GOTO 1300
966 IF CM$ = "GET LANTERN" AND LANTERNLOC=5 THEN GOSUB 9600
966 IF CM$ = "GET SWORD" AND ITEMLOC(1)=5 THEN GOSUB 9620
968 IF CM$ = "INVENTORY" THEN GOSUB 10000
970 IF CM$ = "LOOK" THEN GOTO 900
999 GOTO 950

It worked, and in theory I could have created an entire adventure game this way on the Commodore 64. There was enough memory to handle it, and CPU limits aren't exactly a bottleneck for text adventures. But just because I could do it didn't mean I should do it. Fortunately it was pretty clear to me that this was the wrong way to do things, and that I'd have a nightmare trying to make a game larger than eight rooms using this kind of programming.

A friend of mine, Kevin McCarthy, was staying the weekend with me. We were doing some "Midnight Programming" on adventure games that night (term cribbed from a book I'd already started to read by then, "The Soul of a New Machine"). Kevin was starting to lose it already, as it was pretty late. Then I had the little breakthrough in understanding of making the rooms data-driven so that one routine could handle all possible locations. A simple idea, but a pretty big step for a 13-year-old who was still a beginning programmer.

I turned the descriptions into an array of strings with an index into them based on room number. I also built an array of exit names, exit locations, and indexed them based on room number. I quickly whipped a map of about a dozen rooms and exits. Only the first six had any detail - the remaining rooms had one-line descriptions like, "THIS IS ROOM #9.". But I linked them together with exits, and wrote some code where rooms were handled with a single subroutine.

Kevin was only barely conscious by the time I ran the code. We had a couple of false starts where we encountered syntax errors, which we rapidly corrected. The radio started playing a song by Saga, "Wind Him Up" - curiously, a song about a compulsive gambler. And then... it all worked. It ALL worked. The song became victory music as we walked around our hastily-constructed map, finding that everything was working perfectly, and that making a change or adding a room took an insignificant change instead of the monstrous task it had been before. I had figured out how to create an adventure game. Kevin and I congratulated each other;I made a couple more tweaks to our proto-game and enjoyed a few more minutes of playing around in it. Then we saved our work, and got some sleep before beginning a great Saturday of hitting the local Arcade and playing some Dungeons & Dragons (it's funny how my view of what constitutes a great Saturday hasn't changed much).

The next few days had me furiously working on what was probably my first "complete" game, the adventure game with the vastly overused title, "Dungeons of Doom." It even had some sound effects, color, and some minor animation. I think it had somewhere around 40 rooms altogether. Next was "The Secret of Red Hill Pass", which clocked in at well over twice the size of Dungeons of Doom - not to mention a much smarter parser and many more advanced capabilities.

I bring all this up because I just heard that Saga song again, and it brought back the old memories. Nice motivation when I'm banging my head against the wall trying to learn the Torque engine (I'm a beginner again) while working on a cool new game. Of course, there's probably a point or two here somewhere. Here's my take:

It's now 2005, and anything is possible.

We live in an age now where the possibilities of computers for entertainment have far surpassed most of our wildest imaginations in 1982. Sure, we'll bump up against the limitations of our platform from time-to-time, but that's not the big issue anymore. Instead, we sometimes forge ahead so quickly to exploit the capabilities of the technology that we don't step back and question whether or not we should.

Sure - we can make our game fully 3D and give the player an unparalleled level of control and realism. But is that really the best way to go? Is it the best for the game and the gamer, or would 2D gameplay actually provide a better experience? You can now deliver a game to the user with 500 different weapons and 300 unique levels --- but do you have the tools, experience, and manpower to do it? And even if you do, is it really going to be better than a game with 5 weapons and 30 unique levels?

Step back, evaluate, simplify, and organize. Just because the old limits are gone doesn't mean you are you in any way obligated to go beyond them. It just means that now YOU are the one in charge of imposing your own constraints and framework to your games. Make sure you are doing the right thing, and doing it in the right way.

And if you find yourself hardcoding very similar chunks of code, think hard about whether or not it would actually save you time to make it data-driven.

Labels: , ,


Friday, February 04, 2005
 
What I've been playing lately
When Void War shipped, I thought I would have a ton of spare time to play all the games I'd not been able to even think about playing when I was knee-deep in development. Unfortunately, I didn't get to play them all - though I did get to dust off my copies of Unreal Tournament 2004 and Battlefield Vietnam and actually get some USE out of them. Besides dabbling in these two games, lately I've been playing:

Dance, Dance Revolution Extreme
Vampire the Masquerade: Bloodlines
Orbz
Ricochet: Lost Worlds
Neverwinter Nights (multiplayer, at least once a week!)
City of Heroes
Microsoft Pinball Arcade

Just this last week I've actually gone back and been playing a bit more of Diablo 2, with the Throne of Baal expansion pack. An oldie but goodie.

I should probably say something witty about them right now, but it's late and I'm tired. There are two indie games on the list - and I am getting more fun out of them than many larger retail games I've purchased in the last two years. But ah, well. I've been playing around with a few indie demos lately- Jeff Vogel's Blades of Avernum, the extremely pretty Air Strike 2, and a strategy / war game entitled "Slay."

But oh, well. Game development has gone back into full tilt now with the new month, so any game I can't jump into and get full enjoyment out of during a 15-minute break is probably not going to be played much for a while. Except maybe DDR extreme. But that's exercise, so it doesn't count.

Thursday, February 03, 2005
 
Lunch With Russell Carroll
I had lunch with the NinjaBee team and Russell Carroll (editor of Game Tunnel) yesterday. Besides some really tasty Mexican food courtesy of Lane (biz guy at NinjaBee / Wahoo), we had some really great conversation with Russell, and got his take on the indie game industry.

Russell brought up is his concern that his own actions as a review site might hurt the lifecycle of indie games. Right now, Indie games have kind of an advantage over retail in that we don't have the "Shelf Life" limits that the retail games have. Indie games can sell consistently well for years, even improving in sales from year to year. Will the temporal order of reviews influence purchasing decisions? Would independent game-players be dissuaded from buying a game if they check out a review site and find that it's actually an older title and there are newer, more 'current' games now available?

I don't really think so, but it's an interesting idea.

Russell also talked about the Game of the Year awards, and his appearance on G4's "Screensavers" show last week. The Game of the Year awards are by far the biggest draw for his site. Curiously enough, he says that the popular "Monthly Round-Up" is really only followed by developers themselves.

Russell is determined to make Game Tunnel THE indie game review site going forward. I wish him luck - and lots of attention. Independent games need all the attention we can get. I didn't even realize that a real 'independent games community' existed at ALL until the end of 2003. As far as shareware titles were concerned, I knew of a bunch of them from the early-to-mid 90's (the Apogee / id / Epic Megagames era), and I knew of Bejeweled. You'd think that a somewhat educated gamer like me would be in the know, but I was clueless. The community just doesn't have much of a presence even now outside the major portals.

It's not that the games aren't worthy of attention. There are some great ones out now - pretty much all of the nominees for Game of the Year in all categories at Game Tunnel are really excellent examples of what the independent game development community is doing right now, and continues to do. And it keeps getting better.

(Insert shameless plug for Void War and Outpost Kaloki here - both winners in their categories for Best Multiplayer Game and Best Sim Game, and Outpost Kaloki came in #4 for the overall Game of the Year award).

Another interesting problem that Russell has been dealing with- generating revenue. He discovered that it is VERY hard to find (or keep) reviewers that will do a professional job for free. So they cost money. He visits conferences like GDC to report on things like the IGF. That all costs money. Ttraditionally portals and magazines make their money off of advertising. That's all well and good - except that indie game developers typically don't have much money. Ultimately, Russell hopes to be able to get the bulk of the site's revenue via affiliate sales.

But that makes you wonder - if you get your money by selling games, does that put you under any kind of pressure to give them good reviews? Probably no more than the pressure to give good reviews to the guys who are buying the two-page ads in your magazine if you are a more traditional game review magazine. It's a tough balancing act, but I came away convinced of Russell's desire to make it work and to really promote the independent gaming movement.

Labels:



Powered by Blogger