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! )

Tuesday, February 28, 2006
 
Attack of the (Game) Clones!
Allen Varney has apparently ruffled a few feathers already amongst the indie community with his latest article for the EXCELLENT online gaming journal, The Escapist, in his new article:

Attack of the Parasites

I highly recommend the article. Of course, what he's saying is nothing new. We've been dealing with cloning and out-and-out rip offs of videogames since Pong. I don't remember the Pong clones too well, but I do remember how there was HUNDREDS of Space Invaders knock-offs in the arcades and on home computers. Heck, I even worked on a couple of them myself.

There's good clones and bad clones, and Varney touches on it. The good clones become games like Galaxian (and later, the absolutely stellar classic Galaga). Or Unreal Tournament. You've got a derivative that doesn't just parrot the original gameplay, but layers on some innovation on top of that.

Sure, it'd be great to be completely innovative and come up with a game that's completely different from what's come before it, but not only is that very hard to do, but the audience tends to ignore those games completely. It's too alien. This is part of why Pong succeeded where Computer Space previously failed.

When I was at Infogrammes (now Atari), my producer told me of a meeting he had with one of the head marketing honchos about working on budget titles. Apparently, we were told that it was easy - all we had to do was make cheap knock-offs of anything Microsoft was publishing, and he'd create similar packaging and a confusing name and he'd sell over a hundred thousand copies, easy. So the problem has been alive and well in the retail game industry for some time.

I believe this problem is of a set of problems known as the "suboptimization problem" in game theory, AKA the "Tragedy of the Commons." What's good for the individual isn't good for the community as a whole. The way to combat this is for some authority (a leader, or the community as a whole) to exert some authority over the individual to disincentivize that behavior. The soldier has to believe that he's better off taking his chances on the front line than desertion. But the whole beauty of indie game development (and capitalism as a whole) is the absolute lack of centralized authority and the freedom it brings. Especially since the portals are encouraging copycat games, I don't see this being a solution in the near-term.

Is there a solution? I don't know that either, except as mentioned in the article of keeping your game "copy resistant" by staying one step ahead of the competition, or by injecting a lot of personality into the game which is difficult to ape in a quick-and-dirty knock-off.

Labels:


Monday, February 27, 2006
 
Music to Blast By
As part of my agreement with my brother for doing the Void War music on the cheap, we agreed he'd get to release them after 1 year on his website to promote his 1337 musician and composer abilities.

I still love the music, though it does remind me of a painful time in my life when I didn't get much SLEEP like.... ever.

Enjoy. Contract him for your musical needs (just don't get him so busy that I can't use him anymore...!)

LISTEN TO VOID WAR MUSIC

Labels:


Sunday, February 26, 2006
 
So How Do You Make A Game? Part 1
Subtle difference from my previous post (which was more about how you get hired in the industry). I've had a few people ask just about how you make a game, period. Often at work. I jokingly reply, "Well, you start with 'int main()'," if they are programmers. (If you are not a programmer - well, the joke sucks anyway, so don't worry about it).

I wrote an article last year about Hackenslash - that provides a little bit of insight, but that's not really the focus. There are several books on the subject which can go into more detail than I can here. But here's some hints from how I started. If these are useful - cool. If not, well, like I said, there are books on the subject.

I had the same question when I was 12 years old - when computers were still envisioned as gigantic room-filling monstrosities, except for arcade games which were now appearing in pizza parlors and pretty much anywhere else you looked (including, of course, arcades). I heard someone tell me that their uncle wrote those games, and I was fascinated. I was hooked on Asteroids at the time (among other games), and I was trying to imagine how you informed the arcade machine what the player's ship was supposed to look like, or how it knew to fire a bullet when the player hit the fire button.

My first computer (received later that year) was a Sinclair ZX80, which cost us less than $200 I think. This little machine had NO power whatsoever. I think there were pocket calculators at the time with more memory. There wasn't much I could do, but I did learn to program in BASIC on it. And somehow fit certain tiny programs into 1K of RAM. A little while later - once my dad figured that it was more than a passing interest, we got one of the very first Commodore 64's off the assembly line. I think it cost about $600. We had it on preorder for two or three months, and I think I literally DREAMED about that machine while I waited for it to arrive.

With all of 64k to work with (well, 48k of RAM), and a fully-featured basic, I went nuts. I had a couple of books of programs you could type in directly - very few would fit in the Sinclair (I think I made a total of three work, by stripping out all the comments and simplifying the output). But from these books - Basic Computer Games and More Basic Computer Games, I learned how to program games. (Side note - I still proudly own both of these books.)

These games wouldn't even be recognized as such by many of today's gamers. You didn't use a gamepad to control anything. They were all turn-based games. There were no graphics, unless you count ASCII character art. They were usually more fun to program and modify (for me, anyway) than they were to actually play. But I loved them.

From these examples, I learned the fundamental parts of a computer game:

Game State: All data pertaining to the game and the objects within it. Example parts of a Game State would be the current arrangement of the game board, the player's health level and position, and who's turn it is.
Input: The player's means of communicating and changing the game state
Output: The computer's communication back to the player of the game state.
Game Logic: Everything that dictates how the Game State changes from turn to turn (or moment to moment). If the player pushes the "left" button, his character moves to the left by so much if it's not blocked by certain other objects. A monster colliding with the player's bullet explodes. And so forth.

I also learned a common way to structure computer games, which is still kinda-sorta how I do things now. You have an initialization section, and then you've got your game "Main Loop".

Sometimes (well, almost always for modern games) the main loop can be broken into two loops. The outer loop is where you get the main menu or other global options, and the offer (at the end) to play another game. The inner loop is the actual game-playing loop where the real game occurs. It collected the player's input, performed the game logic to update the game state, and then output the results. You'd get some variation by switching to an event-driven architecture, but that's the fundamental structure for any game, be it tic-tac-toe, Guitar Hero, Bejeweled, Pac-Man, or Grand Theft Auto.

Once I graduated from typing in and modifying other people's games, my next step was creating my own games - usually based loosely on a game that I played and enjoyed. All of those games were pretty simple back then, so it wasn't too hard to emulate my favorites from the arcades --- except trying to make them run fast enough on the C-64's limited processing power. To improve things a bit, I eventually learned to program in Assembly language so I could optimize the slowest parts of games (usually the graphics) so that they'd run faster.

When I finally went off to college and started receiving formal training for computer programming, I created games as my projects whenever I had the option. We had to create program that implemented a stack. I thought of the Towers of Hanoi puzzle (where you stack disks), and created that game using three stacks. For a binary search tree, I created a game where the computer tried to guess what animal you were thinking of by asking a series of yes / no questions (and receiving new questions from you when it failed). Yeah - these little programs I worked on were way more complex than I needed to pass the course, and they weren't exactly sexy, portfolio-building games either. But they made programming FUN for me, kept me in practice making games, and kept me thinking about different ways of representing a game state.

Labels:


Friday, February 24, 2006
 
Games As Porn Bill Passes House
http://biz.gamedaily.com/industry/feature/?id=11949

Crap, crap, crap. And I thought that bill was dead. I'm overwhelmed by the idiocy of my state government to pass this bill.

They've ammended it to define things EXTREMELY narrowly - which means you can't call me a pornographer yet. But I also know how certain extremists love to sneak in after the fact and make ammendments to laws (like they did with this one) and slowly mutate it. "Oh, we'll just change a couple of 'ands' back to 'ors' - that's not a big deal is it?"

I'm both embarassed by my state, and frustrated. And very angry.

I don't think hyper-violent games are things kids should be playing. NO KIDDING! I don't believe that they'll turn kids into violent sociopaths, any more than playing the board game, "Operation" will turn them into qualified surgeons. But I still don't want to expose my kids to that sort of thing. But I don't want the government regulating it with their usual ham-fisted (lack of) panache. HOPEFULLY this will not pass the Senate (but at a 56-8 victory in the House, I have lost all faith in the intelligence of my state leadership), but if it does, I have little doubt it will die horribly at the judicial level.

I just wanna know who's running against Representative Hogue in the next election, and how can I help his or her campaign?

Labels:


Thursday, February 23, 2006
 
So How Do You Start Making Games?
I have been some questions recently by a few people that I wanted to take a stab at answering. They basically boil down to this: How did you get started making games? How can I get started making games? How did you get a job in the videogame industry? And How Can I get a job in the videogame industry?

I'll answer the easiest and the toughest question first, though I'm afraid I might not have much of a useful answers. I'll answer the other two in a blog entry. This one will be about getting a job in the game business.

How did I get a job in the videogame industry? Preparation met with opportunity. I'd been writing little games while in college in my spare time. They weren't complete and syllable (that would have been a big plus), but they did show off some of my capabilities. I think the game that won me a job with Singletrac was this game I'd made for my networking class - a two-player 3D game called "Armorena" which really, really, REALLY sucked. It worked for the class because it was playable over the network. It worked for my job interview because of that, and because it showed that I did know how to do 3D graphics. Back in those days, you had to do the rasterization yourself (no such thing as 3D cards or DirectX), and I had flat-shaded, untextured, blocky polygons on tanks.

I'd also made a really crappy fighting game, and a conquer-the-world style strategy game that was incredibly incomplete and barely showable (but had a semi-nice interface with things like translucent windows). I also had a little Cyberpunk-style adventure / shooter game that I'm still pretty proud of. THAT one got me a job offer from another game company.

SingleTrac was also interested in my work in AI in college - making a game of Go that competed against other students' programs, for example. As I understand it, they hired me because of my experience programming games on the PC (there were plans to release both console and PC versions of our games), my experience with Artificial Intelligence, and the fact that I was well versed in so many games. SingleTrac was long on experienced engineers with extensive knowledge of developing 3D applications (mostly high-end simulators), but they had weaknesses in those areas where I had at least a small amount of experience.

My first day on the job I asked my boss about the plans for the PC versions of the games - for example, what graphics mode we'd be supporting (this was still the bad ol' DOS days... Windows 95 was barely on the horizon), and what our minimum machine spec was. He looked at me and said, "We want you to tell us." *GULP* No pressure!

I ended up working on the Playstation anyway, and more guys were hired to handle the PC end of things. Lucky me!

A lot of things have changed since then. But the basics of getting a job with a game studio (or any other professional career, for that matter) come down to the same things. It's not so much a matter of how cool you are, or what kind of amazing demos you have created. It's whether you fulfill a need (or multiple needs) that the company currently has. You may be an absolutely amazing 3D engine programmer --- but if the company already has more amazing 3D engine programmers than it really needs, they probably won't hire you. If they are looking for a junior programmer who has some experience doing UI programming, they'll take the UI dude.

In my case, the staff they had was overtaxed as it was, and they needed SOMEONE to take those jobs. I had some minimum understanding of what needed to be done, I apparently came off as being somewhat professional and easy to work with, and I was cheap.

In the end, I didn't end up doing quite what they hired me for. It turns out I had a good eye for game balance and crafting special effects algorithms to make things look visually cool and still play well. So they had me doing that sort of thing much of the time I was there.

The first trick is getting the interview, and I don't know if there are any magic incantations that can help you there. The best trick I can tell you is to customize your resume' to emphasize the elements that match the job description that they are advertising for. If they are looking for a DirectX programmer, it doesn't hurt to mention your mastery of OpenGL, but that should take second billing behind what you've done in DirectX. Assume that your resume' is going on a "slush pile" filtered out by a Human Resources person who doesn't know a pixel from a potato. They are scanning for keywords, and if you have one DirectX reference buried inside a bunch of stuff detailing what an OpenGL wizard you are, your resume may never get forwarded to the head of product development who will actually understand that all that OpenGL experience makes you a Well-Rounded Graphics Guru.

Do your homework on the company. Find out what kind of games they make. If you've cultivated any industry contacts, see if you can locate some friend-of-a-friend who works there who can tell you more about what the company is like, what they are working on (the industry is very secretive, so don't expect many details on this), and what sort of skills they are looking for.

Don't ever lie on the resume'. Not ever. The games industry is actually kinda small and inbred, and that kind of thing can poison your career permanently before it has even begun.

Once you get an interview, you are on your own. Hopefully you know your subject matter, and have developed some real people-skills when you weren't in front of your flat-screen. From my experience being on both sides of the interview in the games industry and in business app side of the fence, the folks interviewing you are trying to determine a handful of things:

#1 - How competent are you, REALLY? How well does what you have on your resume' really describe your abilities? Would you really be comfortable and capable if they threw you into the position you are interviewing for?

#2 - How professional are you? If you are given an assignment, would they need to babysit you on it the whole time, or would you be pro-active, disciplined, and effective at getting it done on time in a satisfactory manner?

#3 - How well would you fit in with the rest of the team? Would your skills, style, sense of humor, etc. fit in or compliment their own? Or would your mere presence drive the morale of the rest of the team down into the toilet? Do you communicate well in a team environment?

Okay - and maybe the last bit. SHOULD you go to work for one of these big, soulless publishers that I occasionally rant about on this site? Absolutely. I learned a TON during those six years that I'd have never figured out doing it on my own. I was taught by guys who were REALLY smart and knew their stuff inside and out. I was able to be in on the process of designing, developing, and actually releasing a game, and all the stages and challenges and dangers that go along with it. I learned the lingo, gained contacts and friendships that I still maintain, and picked up a lot of stories along the way.

It's a Good Thing. Good luck!
Wednesday, February 22, 2006
 
Fighting Procrastination: The Local Maxima Problem
I'm a big proponent of rapid prototyping, particularly the "evolutionary" prototype model of software development. Especially in games. I don't believe that you can design fun on paper, though I agree a good design document is important to server as a "paper prototype" when developing a game as a team.

With evolutionary prototyping, you don't "throw away" the prototype. You use parts of it, throw other parts away, but keep developing in a spiral model. At a certain stage in each iteration, you've got an improved prototype ready to demo, play with, get feedback on, and to act as a playground in which you can explore and refine your game's design. Each iteration and turn of the wheel brings you closer and closer to a finished game. But nothing beats having that playable prototype early in development.

There are some problems, of course. For one thing, it's harder to project when the iterations will come to an end and the project will be complete. Outsiders (and sometimes insiders) might have a mistaken opinion of how far the project really is, assuming you are "nearly done" when you have really only started and have only mock-ups available. And then there's another problem that I've been running into which I call the "local maxima" problem, which makes it harder to turn that wheel and begin the iterative cycle again. You get to a certain plateau, and realize that the only way to make progress is to lose some apparent progress. It goes like this:

You've got the "prototype" working nicely. But in order to get it to the next level, you have to break a lot of things. Rip out some simplistic, hardcoded crap that made the prototype work and spend some serious time doing it right. You need to do some massive refactoring of some ugly Frankensteinian code. It means taking a sledgehammer to your pretty, delicate prototype and moving it along to a not-so-pretty stage in the cycle of the spiral development process.

It's daunting. Your game will be taking a step or five backwards. It causes fear. In me, at least - I finally recognized it, and realized that it was causing me to procrastinate a lot of tasks, seek out distractions, and otherwise end up in a slump far too many evenings. Not a paralyzing fear or self-doubt, just a reluctance to put the pack back on and slog down from my plateau for a while to get back on the long path to the summit. I was more content to play around with new features that were only adding to the game rather than replacing things, or "chrome plate" features I'd just implemented.

Now, there are a couple of steps I could have taken to alleviate this problem, now that I recognized it. One possibility is to make a backup of your code (using source control REALLY helps there), so you have a safety net in case you screw things up. Another thing to do is to take a snapshot of the current stage of the game and use it for demo purposes. Both of these are common industry practices, actually, and I've been getting a little sloppy about that.

In this case, once I recongized the problem it was 90% solved. Armed with a ruthless desire to break as many eggs as I needed to in order to knock some top-priority items off my hit list, I went nuts. By the end of only three hours of serious development effort, I'd nailed EIGHT items on my "hit list." Considering I've been averaging about 1.5 hit-list items per night, this really felt like a victory. Now, some of these items were kinda low-hanging fruit, but it was still nice to go forward "kicking tail and making games."

And, curiously enough, by the end of the evening the game was looking and playing better than ever. I'd completed a "mini-cycle" of development in only a few hours! Why had I been so reluctant to take that plunge before? Why had so many high-priority items been sitting on my task list for so long? That was EASY! Let's do that again!

I don't know if this little story will help anyone else - or if I'm the only one who gets stuck on those local maxima. But I do wonder about all these indie games that seem to wither and die once they get to the point of being an impressive "tech demo," especially with inexperienced teams. Could it be they get paralyzed into a low-productivity state because they don't want to (or even realize they have to) go back before they can go forward?

Labels:


Tuesday, February 21, 2006
 
UK Gamer Study
Wow. I'm not from the UK, but this recent study of videogame players in the UK is extremely revealing... and I think that a lot of the findings there could apply equally to the U.S. and much of Europe (I don't know about Asia, but Japan and Korea in particular are big into videogames).

http://crystaltips.typepad.com/wonderland/files/bbc_uk_games_research_2005.pdf

I'm still digesting this information, but there are some interesting highlights:

* The PC is still a VERY strong platform in the UK, probably due to the prevalence of web-based games.

* According to the study, 59% of the nation has played videogames "within the last six months." The UK is "a nation of gamers," according to the document.

* The assumed gender bias in games is illusionary. While more males than females play games in all age categories, the difference is never very large.

* Ovar half of people 36-50 (51%) play videogames. I expect this number dips down steeply as age increases across this range, as only 18% of people age 51-65 play games. This makes perfect sense... the kids who were around when the videogame revolution hit are now entering this demographic. Our parents had Woodstock. We had Pac-Man!

* RPGs become increasingly popular amongst the older age groups. This is fascinating to me - partly because I'm working on an RPG with something of a more "grown up" slant.

* The average gaming session for the 25-36 year olds is about 2 hours on a console or PC, which drops down to about an hour and 40 minutes for the 36-50 demographic. Between both demographics, somewhere around 75% play at least once a week. So - anyone creating a game for this market SHOULD be making a game that should be VERY playable in increments of between 1.5 and 2 hours. (Note: Ever notice how the popular Japanese RPGs have entire sub-quests that are completed in somewhere between 1 and 2 hours? Somebody's done their homework!)

* Simulations and MMOGs seem to be the most "gender neutral" game categories (I guess we're talking more about Tycoon games and "The Sims" than flight simulators for the first category). RPGs and strategy games are slightly more male-dominated, but still pretty even.

Interesting stuff. Seems like the gamers are taking over. We've come a long way since the industry was mainly pre-teen boys on their Ataris. (*Sniff, sniff* - I never had one. I felt really deprived, until they day we got one of the first Commodore 64's, hot off the factory floor...)
Monday, February 20, 2006
 
I Guess I'm No Dummy
I recently purchased the book, "3D Game Animation for Dummies." It was the first time I'd ever purchased a "For Dummies" book. It may be the last.

A more proper title for the book would have been, "Introduction To a Bunch of Widgets in Maya Personal Edition." It pays lip service to providing principles useful for other modeling packages, but half the book consists of step-by-step procedures on which buttons to push in Maya without ever explaining what is actually being done (or why). This makes it hard to extend this knowledge to other modeling packages.

Even worse, the book doesn't even go into animation until beyond the halfway point. There are about 377 numbered pages in the book, but only about 90 of them talk about, you know, ANIMATION. And about half of those are only talking about animation from inside Maya for things like cut scenes - nothing that would be applicable to real-time game animation. Stuff like using Maya's built-in physics systems to make balls bounce.

I guess I was seeking something more along the lines of, "Creating keyframes for realistic walking animation", or "how to rig up a face so for better facial animation." Though there is a chapter of eight pages on this latter topic, showing how to make a horrible-looking face smile. That's SOMETHING I guess. Though the information is less than I could glean from an average, free tutorial on the Internet, it at least brings some value to the book.

I guess the back of the book should have been a tip-off... if I'd seen it before buying it (I got it from Amazon). It brags, "Gain the skills that will get you into game design." So it's really catering to the same audience that Westwood College seeks with its "Be A Game Designer" television ads. ("I can't believe we got jobs doing this!")

The book spends 40 pages prior to the appendices (about as much pagecount as it spends covering real-time 3D game animation) talking about the Game Industry, and how to get a job in it. It insultingly (to me, at least) talks about the "creative jobs" in the industry, but mentions that there are jobs "on the other side of the aisle that includes game programmers." Yeah - those game programmers aren't creative at all. Nor do they create anything. Or something.

Anyway, I am a pretty awful n00b when it comes to modeling (FEAR my Flying Cows!) and even moreso with animation. But I guess I'm not a "dummy," so this book is pretty useless to me. I really can't recommend the book to anyone who has access to the far superior (and free) tutorials available on the Web.
Saturday, February 18, 2006
 
Game Moments #9: Ultima Underworld
Ultima Underworld predated Doom as a the first first-person-perspective with a (somewhat) non-orthoganal world. In fact, it came out at the same time as the Wolfenstein 3D, Doom's direct ancestor. The demo of Wolf3D came out a few days before Ultima Underworld hit the store shelves, and stole some of its thunder.

But Ultima Underworld was a roleplaying game (with action elements), and it was far more immersive to me than Wolfenstein 3D. Though Wolf3D had that famous "achtung" moment in the shareware version which was just one of those things that you HAD to experience for the first time in a game. I heard from one guy how his sister literally fell out of her chair on that one. But I digress...

In addition to the (for the time) impressively immersive graphics, Ultima Underworld also included some realistic elements - I hesitate to call it "physics," but it worked. Things felt consistent, and the monsters had to follow the same rules as the player. If you couldn't find the key to a locked door, you could pick the lock. If you couldn't pick the lock, you could break it by beating on it repeatedly (preferably with your bare fist, as it would damage your weapons). You could, if you tried hard enough, knock a monster off a ledge.

On one particular occasion (late at night, of course), I was delving somewhere on the second or third level, completely immersed in this game. I found what I thought was a mistake in the texture mapping on the wall - a little visual bug. Initially I was dissapointed that a bug like that had slipped through QA. Then I began to wonder if it was really a bug. After a bit of experimentation clicking on the wall, I discovered that it was actually a secret door. Impressed with my own cleverness, I opened the door, and walked down the sloping passage on the other side.

The passage ended at a locked door. Apparently I'd made a bit too much noise, because a monster on the other side of the door heard me and began pounding on the door, attempting to get through. There was a sprite "spark" visible where the door was being hit to show it was being hit high on the door. Whatever was behind the door was BIG. And angry. And desperately wanted to get to me, pounding on the door relentlessly to get to me.

There's something about having some unknown creature literally smashing itself against a door trying to get to you that can be really intimidating. Particularly when it's late at night, you are tired, and you are playing with the lights turned out. It freaked me out. Maybe it was because I hadn't saved in a while - yeah, that's the ticket - but I ran. I fled the scene, back up the stairs, and shut the secret door behind me.

Oh, yeah, and I saved the game.

It took a few minutes for me to get the courage to descend back down the sloped corridor. But once I was so emboldened (mainly by my knowledge that the game was now saved), I ventured back into the darkness.

Again, the monster flung itself at the door in an effort to bust it open and get to me. I draw my blade - a really crappy scrounged weapon that had been found amongst the scrap that littered the dungeon - and prepared for the inevitable onslaught. After a few moments, I realized the door was holding (for now), so I opted to accelerate the process. I picked the lock, re-drew my sword, and opened the door.

What emerged was not what I was expecting. It was a little imp-like creature with bat wings - similar to a mongbat. It flew, which was the reason why its impacts against the door were so high. The battle was short, somewhat challenging but nothing compared to what I was anticipating.

But for a few brief minutes, the game scared me. Er, freaked me out. I mean, made me really worried about losing save progress. Ri-i-i-ight. But those few minutes still live on in my memory.

Labels:


Thursday, February 16, 2006
 
Australian Governmental Book-Burning (er, Banning)
Is it just me, or are government officials completely missing the irony of a national government BANNING a game that's about fighting an oppressive totalitarian government?

http://www.smh.com.au/news/breaking/graffiti-game-banned/2006/02/15/1139890798010.html?page=fullpage#contentSwap1

All this anti-videogame legislation (and lawsuits) really just comes down to the book-burning mentality finding a brand-new target. It's no longer politically correct to burn books these days. But videogames don't yet have the connection with knowledge and ideas that books have. So hey, let's build ourselves a pyre and have at it without all the political ramifications!!!! Bring hot dogs and marshmallows!

On the flip side, you just can't BUY publicity like this. I hadn't even HEARD about this game before today, but now I feel a strong desire to at least check it out. Maybe it'll make me feel all subversive and stuff.

Labels:


Wednesday, February 15, 2006
 
Fitting in Game Development in a Full-Time Schedule
I had to get my car inspected this morning. I was stuck at a Jiffy Lube for about forty minutes, so I whipped out the laptop and began working on game development. Doing art / modeling tasks with a touchpad does NOT sound like fun. So opened up my list and looked at programming tasks remaining.

Ah-hah. The game needed an "invulnerable" mode ("god mode") for development and testing. Even though I'm getting pretty good at dodging the virtual bullets in the game, it's better to not have to worry about it when I'm actually trying to make sure animations are firing or whatnot.

I finished about five minutes before the mechanic came in to tell me my car was ready. One more task taken off the (long) list! I even included a HUD indicator to tell you when you are invincible, and tracked down a minor bug in my damage handling routine.

I'm not a productivity expert (perish the thought!), but if you are going to do part-time game development, the ONLY WAY you are going to make it work is to force it into your schedule everywhere it will fit. Steve Taylor has a blog about the "Ten Minute Method" (almost the only blog entry he's done, durn him! He's too busy writing games I guess) and I'd suggest this as a corollary.

Break your tasks up into things that CAN be done in only ten minutes. Or twenty. Or thirty. And work on them any chance you get. If for some reason your time runs out before you are done, take an extra thirty seconds to make a note to yourself as to where you left off - either as a comment in your code, or a "virtual sticky note" in the form of a text file on your desktop. Don't put off doing development work because you "don't have enough time." No, it's not going to be as productive as a big three-day-weekend game development binge, but still it is PROGRESS. And progress tends to yield more progress.

When I was working on Void War, I even took the little "spare" three or five minutes to just work on my task list, set goals, or maybe look up a subject online related to whatever I was working on (BSP trees, DirectX error messages, whatever). Granted, MOST of my development effort was done in big 4-hour blocks at night when the rest of the family had gone to bed. But every little bit counts.

Take advantage of those little bits.

Labels:


Tuesday, February 14, 2006
 
Void War Ch-ch-ch-changes
I'm working on a new release of Void War (believe it or not) - mostly doing some clean up and bug-fixing, as well as doing some integration with some third-party tools that may FINALLY help those people who are wanting to play it online but have trouble finding other players.

Anyway - there's not a lot of time to add new features or anything like that, but I did want to ask the community (well, the two people who read this blog...) if they have any suggestions. Even if it doesn't make it in this rev, it could go into place in the future (or in a sequel!).

Please let me know at

feedback
---
at
---
rampantgames.com

Thanks folks!

Labels:


Sunday, February 12, 2006
 
Kicking Tail and Making Games, pt 1
I didn't have much time for game development this weekend, but what I did have allowed me to get "in the zone" for a few hours. This is by far some of the most productive time to be had. I cleared a ton of items off of my hit list for ... this game.

I also fixed a bug that I believed for two weeks to be a problem with Torque. Turns out it was an uninitialized variable, but it was something that would never appear in Debug mode, only in the retail build. Don't you hate that?

I've been spending some of my time over the last couple of weeks pretending to be a modeler. I'm kinda-sorta lucky in that this abominable travesty of a game I'm working on right now - inspired no doubt by some kind of trauma I've now repressed and cannot remember - is only going to show a very limited number of objects at close range. In fact, the screenshots below show WAY more detail than can usually be seen. The camera distance hides a multitude of errors and sloppiness on my part, but it also demands more skill than I currently possess to make the objects recognizeable at that range.

But I keep plugging away, and it is nice noting how much my skills have improved over the last several weeks / months. I used to joke that I could model a pretty good cube. I'm not much past that now, but I am at least past that.

And now I leave you with some screenshots (a bit closer than they actually appear in-game), and a poem...

Birdy, birdy, in the sky...
Why'd you do that in my eye?
Now I won't fuss and I won't cry.
But I'm sure glad that cows can't fly!









OR CAN THEY?!?!?!?

Saturday, February 11, 2006
 
Responsible Glitchiness
My first Game Developer's Conference was in 1995. This was when it was still called the "Computer Game Developer's Conference" (CGDC), and it was the last year it tried to act "small." There was rampant recruiting taking place (something which was downplayed in later years - probably because game development companies started getting reluctant to send their people there in fear of them getting snatched up by the competition). It was a great experience for me, new to the business of game development.

One of the most educational sessions I ever sat in on was from that first conference. It was a roundtable on "Simulations and Simulators." There were guys from Lucasarts, SSI, and several other companies in attendance, but it was still a small enough crowd (maybe 20 people?) that everyone who had something to say seemed to be able to say it. The moderator didn't have much to do, because the discussion was lively.

It was fairly eye-opening for me as a newcomer to an industry that I'd only seen from the consumer side for fifteen years. It drove home a lot of issues that I perhaps understood in principle, but had never been exposed to concrete examples. Things like dealing with customers, marketing, the tradeoffs you need to make in your design to maximize appeal (realizing that you are never going to please everyone all of the time), the issues relating to sequels in certain genres (a lesson that has apparenly been forgotten by most publishers these days), and so forth.

Hamumu's comments on my "Casual vs. Hardcore" article a couple of days ago reminded me of one topic that was brought up at that roundtable eleven years ago - and about how to blend the two.

The problem that these guys were facing (I think it was a developer from SSI who had worked on the "Panzer General" series) is that they were really trying to satisfy two markets at once - the hardcore "wargamer" and the far more "normal" player. You have to be careful not to upset the hardcore group, we were warned, because they form your "opinion leaders." They go out on the Internet (back then it was mostly newslists and Bulletin Boards rather than the World Wide Web and forums) and will spout off about how much a game sucks or rules. Less knowledgeable players won't want to argue with the experts, and so sales will depend upon the opinions of this group that really only represents 20% (or less) of your players.

I don't remember if it was the guy from SSI who threw out the term or not, but the partial solution was something he termed, "Responsible Glitchiness." The goal was to create a game for normal players (what we'd call "more casual" players today), which the hardcore complainers would gripe about ENDLESSLY, but in the end they'd have to admit that in spite of their nitpicking, they had a blast playing it. Just because you REALLY have to stretch to figure out how an army of pikemen could sink a steel battleship doesn't stop you from loving Civilization.

Hamumu also mention the game, "Slay." While it may not be as deeply satisfying to a hardcore wargamer as a really deep, ASL-style wargame, its hard to imagine that they would not get a kick out of Slay.

More importantly - a player who tries out Slay or Advance Wars, and enjoys it, could very conceivably move on to something a little more deep or complex that gives them that same level of enjoyment. Progressing through titles, could they then move on to an intermediate "Beer & Pretzels" style wargame, and then one day become an "Advance Squad Leader" afficianado? Could it be that the death of wargames as a genre - once a staple of commercial computer games - could be attributed to a dearth of "entry level" or more casual titles in the genre? If we had more games like Slay, or Advance Wars, or Panzer General, could the wargaming 'genre' could be revived? One of the things mentioned in that roundtable was that the market for wargames (with notable exceptions, like Panzer General) was around 50,000 players. Pretty much the same group of players. It wasn't growing.

Maybe not. Panzer General didn't pave the way for a new generation of wargamers. Games like Command & Conquer and Warcraft might have stolen away that opportunity with flashier but still simple-to-play real-time gameplay for that audience.

(As a side note - wargames have gone indie, and still seem to be holding their own - not growing much, but still hanging in there. )

Anyway - interesting food for thought, anyway. If you are working on a game that is designed beyond a strict casual market, remember to include "responsible glitchiness" in your design!

Labels: ,


Thursday, February 09, 2006
 
Guitar Hero Tidbits
I got the latest issue of Game Developer magazine today. This is one of the better issues I've seen in a while. First off, Outpost Kaloki X (The version of Outpost Kaloki for Live Arcade for the XBox 360) was featured as the "A Thousand Words" section. Serious congrats to Ninjabee!

Also, there's an interesting article on the Casual Games industry, including some quotes about the role of the XBox 360 Live Arcade as a platform for casual games. Good quotes from industry leaders, and some numbers that might surprise people. The "casual" and downloadable side of the industry is growing by leaps and bounds. But then, you already knew that :)

Finally, there was a postmortem on my current-favorite-game, Guitar Hero. This is one of the more interesting postmortems I've read. Some juicy little bits of trivia pulled from the article:

Guitar Hero was developed on an extremely tight schedule of only 9 months. A "practice mode" was originally planned for the game, but cut at the end for lack of development time - because their focus group testing made them decide that it wasn't so important (since then, it has become a heavily-requested feature). They put a lot of time and effort into a "Freestyle" mode so players could do their own solos, but in the end it was too problematic, and they had to cut it.

They were very upset about not having any AC/DC songs... they TRIED, but, they state, "there were acts that were beyond our financial reach or simply weren't interested in participating. No need to list them, you know who they are."

*Cough*Led Zeppelin*Cough*

Labels:


Wednesday, February 08, 2006
 
I'd Like More Casual In My Hardcore, Please.
A few weeks ago I wrote a little article asking "What Kind Of Gamer Are You?" focusing on the undefined group sitting somewhere between the "Casual" and the "Hardcore" gamers. Like those marketing noodleheads I liked to mock. The ones who insisted that everything must be put in its category. "So, is this an FPS, or an RTS, or a sports simulation?" You try and explain that it's something totally different and doesn't really FIT inside one of the eight boxed they liked to stuff everything inside of, and they got really confused.

I keep reading articles where people try to define casual games by genre (color-matching games, card games...) or demographic (40+ year old women), budget ("games made for under $100,000"), or even medium ("small, downloadable" or "web-based" games). You know what? That's just so much crapola.

It's like someone in 1912 describing "airplanes" as "wooden vehicles with two sets of wings and a propeller in the back, which can carry a pilot and sometimes one other passenger to altitudes of nearly 1,000 feet." Sure, that was probably an adequate description of most if not all airplanes of the day, but if you restricted yourself to that definition, we'd have no more airplanes flying in the air today than we had in 1912.

What's a casual game? It's a videogame designed for an audience that doesn't play a lot of videogames. You could call them "Beginner," "Introductory," "Newbie Friendly," or "Entry Level" games, but those imply a level of progression from casual to hardcore that may not exist. Grandma may really dig Bejeweled 2 and Snood, but that doesn't mean that two years from now she's gonna be laying the smack down in Unreal Tournament. Maybe she will, maybe she wont. She might still be playing Bejeweled 2 and Snood.

Casual is an adjective, not a category.

The first commercial "casual" videogame was Pong. Nolan Bushnell started out the the geek favorite "Space War," and it failed. Apparently only science and engineering students really got into battling rockets in space on one of these new-fangled machines. So Bushnell created the much more casual-friendly game "Pong" - which was very similar to ping-pong, tennis, and other games most players already had some familiarity with. It was comfortable for beginners - they instinctively understood the rules of the game because it had a familiar (and relatively popular) metaphor. It was excruciatingly easy to understand - you only had a paddle that could be turned one way or another. It was still playable after a couple of beers. Nobody had to work very hard to enjoy the game.

And the rest is history. For a while, videogames pretty much meant PONG, because everybody was busy copying everyone else's success. Then people started getting a little bit creative, a little LESS "casual-friendly" because a market of people already familiar with videogames had emerged. It was only a nudge out of their comfort zone to go from Pong to a game about a shark, or a racing game, or a maze game, or a pong-style game where you knock bricks out of a wall. In 1979 (I think) Asteroids came out, and became a huge classic. Not Pac-Man huge, but still big. It was able to borrow some of the gameplay and ideas from Bushnell's first attempt, "Computer Space," only this time the ideas "took."

Was "Pac-Man" a casual game? I dunno, but I think so. It attracted a bunch of new players (including women) to the medium, so I think it counts. Would it have succeeded in 1974, without Pong? Who knows.

Now fast forward to today. Could someone who never played a videogame at all (let alone a First-Person Shooter) handle a game like Unreal Tournament or F.E.A.R.? Not without a heck of a lot of work and frustration. They'll start with basic questions, like looking at approaching enemies and asking, "So which one of those is me?" The standard control schemes that are second nature to some of us (WASD, number keys to switch weapons, and now which button do I press to jump?) are only slowly acquired by this new player. Even after going through the tutorial and starting on "Easy" difficulty, the new player is likely to be intimidated at best, and likely overwhelmed. These games are made with the experienced, veteran gamer in mind - the type of player who would be BORED revisiting basic FPS territory. They are looking for a game that will challenge the skills that they have honed over the course of many months or years and many different games.

That is hardcore.

You may end up seeing some "hardcore" games in those genres that are typically labeled "casual" - like the action / puzzle genre (home of those loveable match-three games). Bejeweled 2 and Big Kahuna Reef are clearly deeper, more challenging experiences than their predecessors. Are they less accessible to beginners? Arguably, yes --- but not by much. The designers have been careful to keep the user interactions pretty simple. The number of choices (or, to be more specific, the RANGE of their choices) aren't significantly increased --- it's just that they've been made harder with more variables to consider. Bejeweled 2 is as simple to "get into" and play as it's prequel, but mastery of the game requires more thinking ahead.

Will we get to the point that these genres of games typically associated with casual gaming are no longer casual? Maybe. Solitaire is the quintessential "casual" game type. I know there are some versions of Solitaire out there that intimidate me to the point where I won't even try. Somewhere, some grandma who "doesn't play games" is out there laughing at me because of this. She has mastered five hundred solitaire variants, and I'm left saying, "Okay, now what can I do with the three of spades? Is this a good card?"

"Casual" is an adjective, a fuzzy little collection of virtues that makes a game suitable to 'non-gamers.' I think those are virtues that need to be embraced by more games (not all games - there's always a need for games that challenge the skills of experienced players) in order to keep growing the market and bridging the gap between casual and hardcore.

Labels: ,


Tuesday, February 07, 2006
 
The Indie Games Industry is Growing...
Real Networks just purchased another “Casual” game portal, this time Zylom. There’s an article in the Financial Times here:

http://news.ft.com/cms/s/eb5a4e8a-9745-11da-82b7-0000779e2340.html

So this is the third company they’ve bought in the last… what, 18 months? There’s some serious money getting thrown around here. “Casual” games (maybe I should say here – not just casual games, but “non-hardcore” games… including most indie games) are becoming big business.

While that’s news, I was most interested in these three paragraphs:

“Michael Schutzler, vice president of RealNetworks global gaming
operations, estimates that the casual gaming market is worth around $2bn to $3bn
globally compared to the $25bn total games market.

“In the third quarter, the games business was the fastest-growing
business division at RealNetworks, with revenues up more than 60 per cent at
$14.7m.

“Casual gaming is also one of the more high-margin areas of the games
market. Console games can typically cost $10m to develop and are highly
dependent on becoming best-sellers in order to recoup investment. In contrast,
casual games can be developed for around $100,000 and are less dependent on
becoming hits."


That should stop game developers AND game players in their tracks right there. The casual market (extremely loosely defined) is worth approximately 10% of the overall games market. It’s less hit-dependent (it’s still hit-driven, don’t get me wrong – the top 10% of the games still make 90% of the money), which is a really big deal for an industry where most of the “mainstream” games actually LOSE money.

But it gets even better. RealNetwork’s gaming revenues were up 60% this year. I don’t know how much the “Hardcore” market is growing. There have even been indicators that it has been shrinking, though this always happens when you transition to a new generation of consoles. I don’t know if ALL of the casual / indie market is growing at this rate, or if it’s just RealNetworks grabbing an increasing size of the pie. But from anecdotal evidence I see, it sure sounds like it growing across most of the board. (Not so much on MY SITE, unfortunately… anybody care to buy a game and help me out? *grin*).

Downloadable games are here to stay.

Labels:


Monday, February 06, 2006
 
Advanced Torque Game Engine Manual
On Saturday I received my copy of "Advanced 3D Game Programming All In One," by Ken Finney. This is a companion book to "3D Game Progamming All In One." The titles of the books are kind of misnomers - substitute the word "Torque" for "3D" in both titles. And while we're at it - if it's in two volumes, is it REALLY "All In One?"

So this really appears to be more of an "Advanced Torque Game Engine Manual."

If you've chatted with me before about Torque, you'll know I have something of a love-hate relationship with that 3D game engine.

On the one hand, it's got an awesome feature-set that you normally only find in much more expensive game engines. It has one of the better terrain engines I've ever played with, as well as a pretty slick system of handling water bodies and a really clean integration with 3D, BSP-based "interiors." The network code is really robust. The engine works on Linux and Mac OSX, it supports OpenGL and DirectX, and it has a really detailed built-in scripting language.

Unfortunately, it's also kind of a pain in the butt to work with. While the documentation is improving, it still seems as though a lot of the ins and outs of the system are known only by "tribal knowledge" of the community. Bugs remain even after many years, and the development of the engine seems to go very slowly (particularly if you are an "early adopter" of the Torque Shader Engine, which has been in EA stage for going on two years now). And the robust network code that is core to the architecture of the system can be a BEAR to deal with in a single-player game, when you have to deal with all of the headaches of a multiplayer game ("Gee, is this a bug on the server, on the client, or in the communication layer between the two?") in addition to creating a compelling single-player experience.

The 3DGPAI1 series (with two books, it's now a series, I guess) serves to alleviate the latter problems. It takes a lot of the information that can only be obtained through a lot of hunting through source code or old forum posts and turns it into a fairly easy-to-digest, easy-to-play-with format. I consider the first book a "must have" for game developers new to Torque. Some of the information may be extraneous - if you are using Photoshop, 3DSMax, and level-building software other than QuArK as your content-creation tools, a third of the book will be practically useless to you. But it's still an extremely handy reference.

I'm still early into this new book, but I've done a bit of browsing through the topics, trying to get the gist of what's going on. About half of the new material is devoted to handling AI (artificial intelligence) in Torque. There is a 33-page chapter on using vector and matrix math in Torquescript, which a new game programmer must understand if he or she is gonna do AI in a 3D world.

The last hundred-or-so pages are reference materiasl for Torque. From a cursory glance, it looks nearly identical to the same material in the first book. Nothing new there.

Most of the rest of the book is devoted to material that I really thought should be in the first book. Maybe it got cut for space to fit in the chapter on doing animation in Milkshape (while it's technically possible, at least the last version of Milkshape I used had texturing and animation tools that could only be described as "technically functional" - like certain plants might be termed "technically edible."). Things like setting up replicators for vegitation in a scene, using the profiler and debugger in Torquescript, creating interactive objects like moving doors and breakable objects, using portals in interiors and "Level of Detail" in models and interiors, and dynamic texture swapping on models. There's also a nice chapter about how to import real-world terrain information into Torque.

Unfortunately, the book doesn't touch on the "guts" of Torque - the underlying source code. Something like that would undoubtably have some licensing issues, but I think that's a book the community desperately needs. Just having a better understanding of the network model somewhere between the 30,000-foot overview and the line-by-line tracking of a single object's lifespan as synched up between the server and client machines. That limitation also means the book is limited to talking about games using the "default" first-person-shooter and racing game objects exposed to Torquescript through the engine. If you attempt to derive an object from "ShapeBase," there's a big checklist of things you need to take care of in order for it to appear and update properly on the client machines, but that information is currently scattered across multiple documents and forum posts.

But I don't want to complain about what the book is not. As it stands, it looks like there is some useful information to be gleaned by new and intermediate users of the Torque Game Engine (I put myself firmly in the "intermediate" camp), but unless I'm really surprised when I dig deeper, I don't think it'll be quite the "must have" of the original.

Labels: ,


Saturday, February 04, 2006
 
3D Engine Reevaluation
It had been a while since I last looked at two free 3D engines on the market I seriously considered using for future games. Last night I figured I'd take a look at their progress and see how things were going. Part of this was fueled by the frustrations I've been having with the sometimes Byzantine architecture of Torque's source code.

I only spent a couple of hours taking a peek at them, which consistend of reading up on recent news, screenshots, browsing through some overviews, and playing around with demos. So naturally these are not in-depth evaluations... just kind of a "Quick Review" of engines I feel have promise, but still aren't quite ready for "prime time" (well, at least not for the projects *I* am working on).

Irrlicht
Irrlicht is most impressive because it is principally the effort of one person. Unfortunately, that means that the latest version (0.14) isn't too different on the surface from the last version I really looked at (version 0.8 or so). Development has really started to slow down - which is unfortunate - but a lot of the engine is already "there" in a lot of ways. So if it provides you with what you need already, you are golden. Otherwise, I'd not hold my breath for new features.

The biggest changes from the original releases that I played with include shader support and material support for things like bump maps and so forth. This looks SHARP (as always). A few new formats are supported. Mac support is still not there yet, though it is planned. The terrain engine still appears to be more of an afterthought, unfortunately, and I don't know how well it integrates with BSP-style interiors (which is the principle focus of the engine). Irrlicht supports OpenGL as well as multiple flavors of DirectX (a big plus).

A couple of problems I noticed included a lot of "cracking at the seams" in the 3D geometry that I never noticed in earlier versions. The animation still seems jerky, as if interpolation between keyframes isn't cleanly implemented. The sound didn't work in the demo I played (though it has in the past). And one of the biggest thing that seems missing, still, is tools paths.

But if you are looking for a FREE Quake 3 - style 3D engine with shader effects, Irrlicht could be a good match. It has a VERY open license, so there's no reason to be concerned about using the engine.

Ogre3D
Ogre3D is an LGPL engine - which means the license comes with some strict requirements, but it's not nearly so intrusive as full-blown GPL. What this comes down to is that if you dynamically link in the library, you don't need to release your source code for free. However, any changes you make to the library itself need to be returned back to the community. Which seems perfectly fair in my book.

I saw a terrain demo, but it was non-repeating, so once again I'm not certain how well the engine handles a more open environment as in an RPG (especially a MMORPG). There was also nothing showing how seamlessly a BSP-style interior could be combined with terrain (one of the key features of Torque, in my book). The shader support makes for absolutely beautiful scenes.

Ogre3D supports Windows, OSX, and Linux, which is a big plus. It also has a much more robust tools path. The only thing that really blew it for me was a horrible tools path for handling BSP interiors. Right now, it's dependant upon using tools and formats encumbered by IP rights, which means a serious commercial game can't really consider using it unless they want to roll their own.

I don't know if Ogre has a suite of pre-built UI widgets.

From my perspective, Ogre 3D needs a bit more work done to make it truly viable as a "commercial" graphics engine. It's got some great built-in capabilities. If they could get a tools path that doesn't rely on proprietary tools & formats for handling BSP trees, and a solid suite of 2D graphics tools (particularly UI), and a good "open" terrain system in place, it could be a real contender in the future.

*********** UPDATE: *************************
So I was fixing up links in this post, and discovered that only a few short hours ago, the Mac OSX port of Irrlicht became available. So that's one of the strikes against Irrlicht GONE. For those who think that porting to the Mac (or at least maintaining that as an option) is important. And if you are an indie game developer, you should.

Of course, both of these engines presented here are simply 3D engines, not "Game Engines" - Game Engines include Torque, the Quake 3 engine, or the totally-out-of-the-price-range-of-indies Unreal 3 engine.

Oh - and I didn't mention it, but BIG Kudos to both Ogre3D and Irrlicht for having PYTHON BINDINGS! Have I mentioned that I love Python?

****** UPDATE # 2 ******************
I finally stumbled across the GUI demo for Ogre3D. So there are some basic UI tools there for scroll bars, drop-downs, editable text windows, etc. About the same as Irrlicht. Not quite as fancy as what you get in Torque, but a solid set of basics.
Thursday, February 02, 2006
 
Twisted Metal Trivia
Okay - little trip down memory lane to eleven years ago - when SingleTrac was developing one of our two initial games for the then-semi-secret Sony Playstation. Nobody heard of it, and everyone was talking about whether Nintendo or Sega would win the upcoming console wars for the next generation. I was a new "hotshot" college grad with a love of games and a desire to prove myself. I found myself surrounded by engineers and artists who admitted they had no clue how to make videogames, but they were extremely BRILLIANT bunch and they knew fun when they experienced it. And of course we were in communication with the guys from Sony - in particular David Jaffe and Mike Giam.

So here's some bizarro tales from creating the first Twisted Metal game. Remember - nobody knew if it would flop, or even if the Playstation would flop. And almost none of us at SingleTrac had ever worked on creating a commercial videogame before. It was about as risky and unexplored territory as you could be in. Fortunately, we were pretty successful on all counts, and Twisted Metal became a "signature" Playstation title. I am not privy to what my old coworkers are doing in downtown Salt Lake City, but I'd not be surprised if there's another Twisted Metal for the Playstation 3 in the works.

There's a dog in Twisted Metal 1 that cannot be killed in one of the city levels (I think it's the second level). Why not? Well, as we were finishing up the game in beta test or so, preparing for submission --- and wired as all with caffeine and lack of sleep --- we came across a Sony rule that stated that in order for a game to be approved, it cannot show violence or cruelty to animals. We thought this was really funny, as violence against PEOPLE was all fine and dandy, but violence to animals was a no-no. Now, we probably could have gotten away with allowing the player to kill the dog that was crossing the street. But we thought it would be funny if, in compliance with Sony rules, the dog was somehow miraculously immune to tires, bumpers, missiles, and bullets. And so it was.

Originally, the second level was an absolutely HUGE world that was about three times its final size. It included the highway from level 3 (I think there are some barriers in level 2 across accessways that originally allowed you to go on to the freeway). We built it, we played it --- and it SUCKED. It was too big. You'd spend five minutes just finding the other cars. So we broke it up, shrank things down, and thus you have the smaller levels of Twisted Metal.

I think I mentioned in a previous blog how the cars in Twisted Metal used to gang up on you - and it was No Fun. The game was most fun when it was always moving, so we made all but two cars purposefully avoid you. And even the ones currently engaged with you would often flee from you, firing all kinds of rear-mounted attacks.

The wild explosion physics that became a signature for the series was actually a bug. I was programmer assigned to do weapon logic, and I had a long-standing bug where a lot of weapons would incorrectly be identified as the "catapult" weapon (a weapon which turned out to be Not Much Fun and never appeared in later Twisted Metal Games, as far as I know). The catapult would hurl you in the air, and hopefully over your opponent and into the range of his guns (or at least into a wall). I had the bug in the code forever, but fixing it hadn't been high on my list of priorities. Finally I got around to doing it, and EVERYONE COMPLAINED. The whole getting tossed into the air thing by nearly every weapon except bullets was a tremendous part of the fun. I was commanded to put it back in the game - albeit toned down a bit. I ended up making it based on the amount of damage a weapon did.

Oh - in most (all?) the levels in Twisted Metal 1, there are two unmarked, completely secret spots that if you line up your car EXACTLY right in the right spot, you will be fully healed up. These spots are only usable once per match. These little cheat spots were put in by Steve Paulson, the guy who did the physics and AI for the cars, because he was sick of getting beaten by the other people around the office when we had impromptu matches (which happened a lot - sometimes just to keep us AWAKE in the long hours of development).

There was a technical reason that we couldn't have same-car matches in Twisted Metal. Our engine supported instancing, but not state differences between instances of the same object type. There was some talk of creating completely separate cars that resembled each other, there was too much coded into the engine that would have had to be revamped to allow Specter to fight against Specter or Sweet Tooth versus another Sweet Tooth, so schedule prevented us from doing that.

There were end-level movies that were filmed for Twisted Metal. I think Sony spent a good deal of money on them, and I know Sandi Geary (our audio & video superwoman) spent a good deal of time processing those videos. They were extremely cheesey (about as cheesey as the MST-3K-worthy Warhawk videos, which ended up staying in). I think there was some mildly offensive material in one or two of them, so someone up refused to put them in. Since there was no time or money to re-shoot the missing endings, we pulled all of them out. I don't know if they still exist anymore. Maybe David Jaffe still has them in Beta format out at Sony.

Oh, and speaking of Dave Jaffe - if memory serves, the drivers of Hammerhead , the green Monster Truck, were named "Dave and Mike," after Dave Jaffe and Mike Giam. Dave also makes a cameo in Twisted Metal 2, as a pedestrian who can be blown up, shot, or run over. I think he's the guy cheering on the competition waving the penants around.

Well, that's all I can think of right now. If I think of any more, I'll be sure and post 'em. It's been a long time, but it was an extremely intense time in my life. The pain and lack of sleep have faded, leaving me with a lot of fond memories of the time.

Labels:


Wednesday, February 01, 2006
 
A Live Arcade for the Playstation 3?
According to the March issue of Playstation Magazine, Sony has committed to duplicate - and surpass - the XBox 360's "XBox Live" system. Currently unnamed, they promised the following (to stem the tide of gamers defecting to the 360, no doubt):

"They are committed to matching Xbox Live [on the 360] feature for feature and then some," says one anonymous developer.

So the obvious question comes up: One of the most talked-about features of XBox Live for the 360 is Live Arcade, where downloadable games may be had for a fraction of the cost of a new, major title. If Sony is truly committed to matching the XBox Live feature for feature, then would a "Playstation Online Arcade" also be in the works?

If so, I've n0t heard about it. But it's possible. The success of XBLA has frankly taken nearly everyone by surprise. It would be a great opportunity for indies if Sony opens up their system for small, downloadable titles. It wouldn't be unheard of. After all, back in 1997, Sony did come out with the "Net Yaroze" for hobbyist game developers to create games for the Playstation. I don't think the program was s big success, which is perhaps why we've had nothing of the sort for the PS2.

I won't hold my breath or anything, especially not as a launch feature, but it seems that it is at least a possibility.

For slightly more information (and much more speculation), check it out at:
http://www.joystiq.com/2006/01/31/sony-declares-full-on-assault-on-xbox-live/

Labels:



Powered by Blogger