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
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
Monday, January 24, 2005
Pac Man Fever!
In the news of the really weird, Martoon over at the indiegamer boards pointed out this... incredibly bizarre link to ambient arcade sounds of the 1980s. All that is missing is a few token pinball games, loud exclamations of profanity, and 80's music piping in in the background. Well, and the smell of smoke drifting in from outside, and the scent of stale pizza. There's the Internet for you - you can get almost anything online, including memories.
I listened to that cacophonous mixture for a few minutes, and it really did bring back a bunch of memories. It was pretty amazing, actually. It really did sound a lot like an arcade of the day - complete with occasional half-heard mumblings of conversations - and the whole sense-memory thing kicked in. See, arcade games got me started programming in the first place. I'd blow my whole allowance in the local arcade (or, if unavailable, over at the local Pizza Hut or other establishment where video games were as common in nearly any public establishment as slot machines in Las Vegas.) Asteroids, Pac-Man, Galaga, Qix, QBert, Phoenix, Starfire, Defender, Missile Command, Star Wars, Dig-Dug, Frogger, Turbo, Pole Position, Scrambles, Galaxian, Satan's Hollow, Tron, Disks of Tron, Starcastle, Berzerk, Gorf, Ms. Pac Man, Lunar Lander, Tempest, Reactor, Battlezone, Space Invaders, Donkey Kong - these were my early influences.
The arcades - noisy, dark dens with lots of flashing lights to call your quarters (Berzerk would even announce, "Coin Detected In Pocket!") - introduced me to what computers could be about. They weren't just big number-crunching machines capable of doing complex accounting, tax, artillery, or astrogation calculations. They could do these fun, adrenaline-pumping GAMES that provided an experience completely unlike anything seen a few years earlier.
Unfortunately, I was shorter on money than I was on imagination. So my $5, $7, or $10 would go VERY quickly. Once I got a computer, I would try and replicated these experiences on my own. At first, we had a Sinclair ZX80 - which was almost useless for replicating anything (1K of memory, and it couldn't run calculations and display things on the screen at the same time). Later I got a Commodore 64, and taught myself machine language to speed up certain graphics routines where BASIC was too slow. My games stank, for the most part, but it was a great learning experience. I taught myself programming for the express purpose of making games.
The coolest thing was that back at this time, there were no horizons - no established "genres" (though a few fuzzy boundaries had evolved separating 'arcade games' from 'roleplaying games' and 'adventure games' - though the boundary between those two categories was pretty thin by itself). There were some fairly interesting game concepts that never really took off to become established 'genres' - I mean, how would you categorize Joust, Dig-Dug, Reactor, Qix, or Frogger? It was pretty much "Anything Goes" - and granted, a lot of things went - and nobody mourned them when it was gone. There was an awful lot of crappy ideas, but that comes with rampant creativity. The arcades often felt like a brainstorm given light and sound.
Today, when people talk about game design, it's instantly categorized even before it is fleshed out. You'll hear people talking about wanting to create "a first-person shooter" or a "real-time strategy game." Categories provide useful semantic shortcuts, but they are too often used as limitations on what can or should be done. That's B.S.
I've read that Sid Meier's approach to game design is to come up with an overall theme or concept... such as a game about pirates. Then he comes up with ideas of what sort of activities one could do within that concept that would be fun. I think Shigeru Miyamoto goes through a similar process for his games. Richard Garriott's earlier games very clearly came from this same mentality.
So as I listened to the sounds of a bygone era (that sure sounds a lot more poetic than the reality, doesn't it?), this is what I thought of. I know how hard it is nowadays to achieve market acceptance with truly innovative design. A lot of these old videogames failed for the same reason back in the day, while 'maze-chasers' and 'top-down-shooters' dominated the arcades. But I find myself really wanting to recapture some of the pioneering spirit of that time period - something that dissapeared not because the frontier vanished, but because too many developers became very comfortable with where they settled.
Sunday, January 23, 2005
So for this next project in the post-Void War world, I decided to use Torque as my game engine. Why not continue using the homebrew engine I developed for Void War?
A couple of reasons:
#1 - Cross-platform capability. Void War's engine was extremely heavily tied to DirectX. When I first started on it, I tried very hard to keep it platform-independent, and keep all the Direct-X specific stuff in one place. As time went on, I became lazy (well, actually, just SLOPPY due to intense development efforts). Next thing you know, I have DirectX-related bits throughout much of my code. I learned too late what kind of market there is for indie games for the Mac, and I started kicking myself. So this time I wanted something that had already been built and tested on the Mac. (And Linux too, which is a cool benefit even though it doesn't represent a huge market for games yet).
#2 - Maturity. While this can have bad connotations too (a 'mature' engine might not look as sparkley and hot as a 'new' engine), it also means it's well understood, a lot of its bugs have already been ironed out, and there's also a TON of support already out there for it --- like exporters for tools! Supporting a tools pipeline for a game engine isn't exactly the sexiest part of game programming - I'd really rather work on the game.
#3 - Features: If you are doing an engine for a single game, you are going to be hard-pressed to support those features that only that one game requires. However, if you already have a feature-rich engine to start with, you may be able to take advantage of some the features that you can get "for free" with that engine that you wouldn't consider otherwise.
Shortly after I got into the business, the rule of thumb was that it was creating your own engine from scratch was really no harder than learning someone else's engine. In 1997, with 3D hardware just starting to hit mainstream usage, this was true. Nowadays, it's not just about pushing a bunch of single-texture polygons out with lightmaps over the top of them, and things like collision detection, line-of-sight detection and other issues are a couple of orders of magnitude more significant. With the wealth of engines available for use out there that are even well within the price range of an indie developer, it just makes sense.
I still recommend writing your own 3D engine as an exercise - it's good practice. Because you will need to know all you can when you open up the hood and start ripping out the guts of whatever engine you decide to use so you can customize / optimize it for your own use. The Void War engine had some support for character animation (believe it or not), multitexturing (a requirement these days), a portalling system (which, like the animation system, wasn't used in Void War), particles (another given), and a few other goodies. It still has some hardware compatability issues that drive me nuts to this day - some machines just don't like it. Ah, well.
I opted for Torque for several reasons. The biggest was the built-in terrain engine which actually looks GOOD, and of course Mac compatability (I was also seriously impressed with Ogre3D and Irrlicht, both of which are free). In the end the built-in Torque features won out. The ongoing work on TSE (Torque Shader Engine) means a clear upgrade path to keep games from looking like they are mired in a turn-of-the-century look. Torque has good tool support (and some nice built-in tools), a thriving community (including many professionals). And a friend of mine - John Olsen, who did some programming work on Void War - already owned a license of the engine, which means I could potentially still beg him for help on another project... :)
I also have a future project in mind that could REALLY take advantage of a lot of Torques features. So while I could have easily gone elsewhere (even stuck with Void War's engine) for this current project, I made the choice with an eye for the future. The seamless integeration of indoor & outdoor environments was a pretty big deal.
Of course, having this really cool, fully featured engine and actually being able to do anything productive with it are totally different beasts. If you keep your game well within the established capabilities of the engine, it's a piece of cake. But who wants to do that? It's extremely well-suited to first-person shooters with vehicles, but I've not come up with a really compelling FPS idea yet. So I have to get down and dirty with extending and modifying the engine.
So I'm down in the guts of the engine - not too deep, but still deep enough to give me a headache. Just learning how Torque likes to do things - with it's inherent client-server model - is frustrating. I think I'm almost over that first hurdle, however. I'm now on my third pass on creating a new object in the game system - now incorporated with pieces of the new RTS starter kit. The first two seemed cool in my mind, but I wasn't satisfied with how they played. Hopefully this third time will be the charm. It's getting easier now - I understand more of the pitfalls and tricks to making sure Torque behaves itself.
I will really be glad when I finally understand the inner workings of the engine half as well as I do my own engine, however. That should make development TONS faster.
Wednesday, January 19, 2005
Friday night started out as a little bit of a dissapointment. The wife and I went to go see the movie, "Electra." We weren't expecting much, and the movie pretty much met our expectations. It wasn't bad. It just wasn't very good. - I'd give the director a "B" for effort, maybe, but he just didn't have the skill to execute. Too many characters and relationships to explain, the pacing was off, it moved too slowly - particularly during action scenes. I'd say it's a worthy rental if you are fond of superhero flicks - I've seen far worse. If you thought Daredevil was good, then you'll probably like it.
ANYWAY - after the movie we went home feeling kind of 'blah'. But we'd taped the new Battlestar Galactica - the two premier episodes - and spent another two hours of passive entertainment watching them. I really enjoyed the miniseries, and so far the episodes seem to share the same high quality. The blahs went away.
If you haven't seen them at all - it's worth getting the sci fi channel for. But besides the names, the theme of the ship design, some of the setting, and the core concept, it doesn't bear a whole lot of resemblance to the old 1979 / 1980 series. Which is a good thing - though I loved the original series as a fourth-grader, the cheese level makes it more of a comedy as an adult.
First off, the cosmetic changes. The next-gen Cylons are cyborgs that appear - and feel - human. Starbuck and Boomer are girls. Colonel Ty is a balding white guy, and an alcoholic. The semi-anonymous pencil-neck council (quorum?) of the twelve have been replaced by a single President representing the civilian government - Mary McDonnell plays the former secretary of education, sworn in as President as the highest ranking survivor of the cylon attack who was in the chain of succession. And of course, the ships and special effects are MUCH cooler.
The show is dark. The first episode opens just days after the miniseries ended, as they have been pursued relentlessly by the cylons. Every 33 minutes, the cylons reappear. Nobody has gotten any sleep in five days - nerves are raw, ship FTL drives are starting to fail, the human race has a total population of approximately 50,000 people and dropping. People are starting to make bad decisions, and there's suspicion that the cylons have human-appearing infiltrators among them that are broadcasting their position and preventing an escape. The survivors are very much in mourning over the nearly complete destruction of their race, tempered by the realization that they barely staying a few inches from death themselves.
You've got a major cast member who is actually a cylon and doesn't realize it (though the individual suspects by the second episode). You have a cowardly, self-serving and possibly insane Baltar who betrayed all of humanity without realizing it, but now continues to betray them in fear that the truth about him will be discovered. You have strained relationships between Adama and his son, sexual tension between Apollo and Starbuck (I can't even thinking of that without thinking of Dirk Benedict, and that makes me CRINGE), difficult negotiation between military and civilian government, and the gradually increasing terror that anybody - even one's best friend or lover - could be a Cylon infiltrator. The acting, dialog, and overall direction is stellar - I'm totally hooked on the series in a way that only a few shows have ever done.
They've also done a good job of making the technology believable. While the physics of space combat are still not 100% accurate, they ships still have inertia and flit around more like rockets than jet fighters. In the miniseries, when the Cyclons knock out a squadron of vipers with a virus to their computer systems, the ships continue to move forward (though they do start to tumble). The ships behave very organically. Players of Void War ought to feel right at home.
I do have one nitpick with the second episode. Without giving anything away that isn't revealed in the first three minutes of the episode, a cylon infiltrator destroys half the water supply of the Galactica - which has near 100% water reclamation and is providing water for half the fleet. The water freezes and dramatically flies off into space in billions of frozen chunks. So then they have to scour the sector looking for water, while riots start to break out over water rationing. Here's my question - after they repaired the water tanks, why didn't they just fly off into space and just start scooping the water back up again? It's not like it WENT anywhere. Even reclaiming only 33% of it would have made a big difference, right?
Ah, well. Guess you can't get it right all the time. Nitpickiness aside, the series rocks. With Babylon 5 and Firefly gone, I was worried about whether or not we'd see another worthy space-opera TV series. (I did TRY to get into Enterprise - I really did.) Now I think we've got it.
Monday, January 17, 2005
Viva la Revolucion!
Okay, I'm about the last gamer on the planet to get hooked on the "Dance Dance Revolution" thing. But now I'm hooked. The last time I felt myself compelled to go "one more time" to get my exercise, I was in a fairly expensive fencing club (the kind with the foils and sabers and masks - not partitioning real estate).
My wife and I played the game a few times in the arcades (a dissapearing fixture... sigh...), but never enough to actually be competent at it (or actually finish a song). When the first machine appeared at the local Nickle-Cade, we tried playing it a little more - got a little better at it - but there was a lot of people waiting to play, so we still didn't play much. I had read stories in the late '90s of kids lining up to compete on these machines, limbering up --- men and women. I thought, "Oh, how nice, they are getting their exercise playing video games. That's cool."
The last time we got a chance to play one in the arcade - I think it was in October - my wife asked, "Do they have this game for the Playstation 2?" I vaguely recalled seeing dance pad controllers for sale at the local Game Stop, so I mumbled something to that effect. She said, "That would really be great exercise - lots more fun than exercise tapes."
For Christmas I got her DDR Extreme for the Playstation 2, and the Ignition dance controller - a nice $100 number that was recommended to me. I was worried she wouldn't like it.
Well, she got hooked. I got hooked. Our friends got hooked. The game is WAY more fun than it deserves to be, and I'm not happy until my calves are aching and I've burned off at least 300 calories playing it.
Last week an article appeared on CNN about some forthcoming 'exercise videogames' at CES - including Konami's existing DDR offering. It's an interesting read. I say: BRING 'EM ON! If they are as fun as DDR, I can't think of a more enjoyable way to stay in shape. The article is here:
Now I just need to find a videogame to make my weight-lifting more exciting.
Labels: Mainstream Games
Friday, January 14, 2005
Rules of Game Design, Part 1
I have no idea how far this will go, and I know Noah Fahlstein is currently assembling a list like this, but here's a bit of jotting down some of the rules I've accumulated - either from hard-earned experience, or cribbed from designers much smarter and more experienced than I. Here are a few. These are specific to computer game & videogame development, but they may be applicable to other forms of gaming.
These are in the form of a brain-dump, so their order doesn't matter whatsoever. And all rules are made to be broken - these are no exception.
#1 - The First Few Minutes are ALL-important.
I've heard the this referred to as the first five minutes, the first ten minutes, and the first fifteen minutes rule. I guess it depends upon the attention span and circumstances of the player. As a game developer, you have a really tiny window of opportunity to strut your stuff and convince the player that your game is worthwhile. Even if they have already purchased your game, their initial opinions from the first few minutes will be the foundation upon which the rest of their experience will be based. It's absolutely critical to rock here - don't save all the cool stuff to the end. And make sure that the game is accessible enough that the player is feeling comfortable and reasonably competent on the controls within this time period.
#2 - The Player Shouldn't Have to RTFM
Kind of a corollary to #1 - Do you want your player spending their first few minutes with your game playing, or reading a dry documentation explaining what obscure key combos they need to hit to open the first door? Your game should be as self-explanatory as possible. This isn't to say that manual isn't important or useful - you MUST have it, and it can go into details and hints that may improve the player's experience. But it should be completely optional to the player.
#3 - The Bad Guys Always Have the Advantage
This is more important in strategy and action games, but make sure the player doesn't have the advantage of both mobility AND range over his opponents. That results in a very basic, cheap strategy that players WILL exploit. This is mitigated if the enemy has the advantage of numbers and will use it intelligently to circle around or box in the player (such as in a sniper game). But you just never want to end up in a situation where the player can win the level by just hanging out and shooting from a safe distance.
#4 - Provide plenty of feedback to the player!
One of the most frustrating and infuriating things to experience in a game is a lack of response to player commands. This could be as simple as not highlighting a button that the player is hovering over or showing it getting pressed - to something more significant like not providing a clear visual to show whether or not the player is doing damage to an object he is shooting. This may be difficult as a developer / designer, as you understand what's happening 'under the hood' - but remember your player doesn't, and he's going to need things spelled out to him (preferably with lots of cool special effects and satisfying noises).
#5 - Subtlety is usually lost on players
In a nutshell, if the player didn't notice it, it didn't happen. This is true everywhere - from creating differences between stats on weapons, to showing emotion from the NPCs, to giving players power-ups.
#6 - (Cribbed from Greg Costikyan) Imperceptible causes are meaningless and frustrating.
Sort of a corollary to #4 and #5, above - the player must always be able to determine cause and effect. If it's a cluttered, horrible combination of factors (as in a detailed strategy game), you need to enumerate them and show exactly how they are playing into changing the game state.
#7 - Cut out anything that doesn't serve the core gameplay
Rather than thinking of what you can add to a game, think about what you can take away. So many games suffer from 'feature-itis' that the parts that are supposed to make the game FUN are lost underneath a ton of 'added value' features. Cut out everything that doesn't make your game GREAT. Focus on features that enhance and reinforce the core game.
Sometimes this rule appears to be violated, but really isn't. X-Com is a classic example - the 'macro' game might at first appear to be separate and 'needless clutter' to the core gameplay (which was the tactical combat). But it did several things. First of all, it provided context - a meaning for otherwise meaningless battles. It provided a little break between missions. It provided a clear progression path for missions, and unique player-created sub-goals for missions (such as, "capture one of the aliens alive for study!"). And finally, it provided the player with some measure of control over what missions he was going to be involved in, and set his own level of challenge and resources.
#8 - The Interface Should NEVER be Part of the Challenge
The player should be challenged by your game. That's a big part of the fun. What shouldn't challenge the player is the interface. Ideally, your game should be able to play the same if your player's brain was directly hooked up to the machine. Forcing the player to "learn" the controls isn't fun. Now - mastery of the controls to pull off tricky maneuvers --- that's all well and good. Hitting A and B in combination with a move up to pull off a uppercut is fine - as is trying to complete a complex step it Dance Dance Revolution. But forcing the player to go all over the keyboard to perform a basic action is bad design.
Well, that's all I have time for now. More soon!
Labels: Game Design