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
Friday, June 30, 2006
Forrest Gump Meets The Avatar of Virtue
The Avatar of Ultima VII now has a new party member...
Yeah, this is a silly bit of Forrest Gump-ery. Though I did a little bit more than just photoshop an image in (or manipilate Richard Nixon's lips).
As many horrible ideas do, it began with the question, "How Hard Would It Be...?" If you are an indie game developer, these questions could lead to many months of painstaking labor, so they are dangerous to ask. But I'd been wanting to play around with the full-release version of Torque Game Builder Pro, and I hadn't had a chance since my "first impression" review a month ago.
So the horrible idea was, "How hard would it be to create an Ultima 7 - style engine with 3D animated characters in TGB?" It's a question that will likely never be answered, but I wanted to get it out of my system. Finding myself with a few minutes before going to see "Superman Returns" (and a couple of hours afterwards), I threw together a new project in TGB to test out some ideas. I called it "Hackenslash 2" after one of my horrible ideas from last year - whipping out an RPG from scratch in only one week. Hey, you never know!
I used Exult and my old Ultima 7 games (yep, still got 'em, and proud of 'em!) to rip the graphics so I could try and get the 3D model to match the perspective of the Ultima VII games. I used Cubix Studio's female content pack (one of the BEST DEALS in indie gaming content packs BTW; I recommend it highly!) . I thought it would be fun to get the camo-clad lady running around in Brittania.
3D shapes are still missing a bit of functionality in TGB, but I still consider them to be one of the great strengths of the engine. They are also incredibly easy to use, and can be mixed freely with 2D imagery. My initial attempt to drop her into some Ultima 7 imagery didn't work well, because mere 3D rotations wouldn't do the trick. I could get her facing north just fine, but walking around never looked right. Part of the reason why is that the perspective in Ultima VII is not "perspective correct" - every object is displayed as if the camera was looking about a foot or two to the right of the center of EVERY object. Naturally, in a true 3D world, the camera is looking at only one spot at a time. It's very slightly M.C. Escher-esque, but that's always the case of 2D games trying to represent a 3D world with a simulation of angles.
So I had to force the 3D shapes to behave incorrectly. To do this, I recalled a little-used tool called a shear (or skew) matrix. I had to look up how to do it in Moller and Haines' excellent book, "Real-Time Rendering." It was trivial to set up the matrix, but I once again had to dig into the C++ source code under TGB's hood to add this functionality. So I have a "local projection" matrix added to the t2dShape3D object, which is disabled by default. I added console functions accessible via TorqueScript for enabling, rotating, and adding shear to this matrix. At render time, the object's true rotation matrix is multiplied by the local projection matrix and the result is concatenated to the rendering matrix chain.
The first time I tried it, the female character got twisted all over the place, because I'd multiplied the matrices in the wrong order. I do that ALL the time. It was the bane of my existance when I was working on Void War's engine. I try to pretend to be a genius coder and all that, but when it comes to 3D I really do tend to program by Braille. I keep a copy of Real-Time Rendering handy and just keep fiddling with things until they behave correctly.
By the end of the night (time that SHOULD have been spent working on Apocalypse Cow, if I'd had any sense at all), I had camo-girl running around looking like she belonged in Brittania circa 1991. Okay, so her animation was about 1000 times better, and she doesn't have the black outline (I could do that by doubling her poly count, but that wasn't the POINT). But I bet she could kick the Guardian's butt any day! Especially if I outfitted her with a magical M-16.... VAS CORP that, sucker!
So that's part 1 of what will likely be a 100-part engine if I move any further on it. Tiles of different sizes, layered tiles for different elevations, a seamless "full world," a conversation system, an inventory system, a quest system, combat, stats, massive game-state tracking... all fun, busy projects. Not to mention trying to produce REAL art assets instead of borrowing from one of the best PC RPGs of all time. But this was an amusing, nostalgic little diversion.
BTW, having never finished Ultima 8 or even ever playing Ultima 9 --- can someone tell me if the Guardian finally got what was coming to him? He was an awesome villain in Ultima 7, and I regretted never being able to kick his stony butt once and for all.
Incidentally: Superman Returns? My wife really liked it, but I thought it was dissapointing. I didn't dislike it, but I didn't think it was in the same league as Batman Begins or Spiderman 2. I found myself more interested in Richard White's character (dude, stick with Lois Lane --- because getting involved with the Dark Phoenix will lead to nothing but pain!) than any of the principles.
Thursday, June 29, 2006
How To Avoid Making Money Making Indie Games
So I'm not much of an expert on making money making indie games, though I have it on good authority that it's possible. But between my own mistakes and learning from others, I know a bit about how to NOT make money at this. I was really good at that one without even trying!
So if you want to AVOID making money making games, here's a bunch of tricks to doing just that. There are no guarantees, of course.... it's certainly possible that you might accidentally generate some revenue this way. But it's less likely.
#1 - Don't Complete A Game
Once you get your game to a level that "looks" 80% done (which means it's really closer to 20% complete), it's time to abandon that project and move on to bigger and better things. Rinse and repeat!
#2 - Wait For the Perfect Moment to Start
One day you'll have a team, or that awesome publisher contract, and THEN you can get started on your killer game.
#3 - Make a Generic Clone In a Crowded Genre
Because what the world needs now isn't love, sweet lovel. It's yet another generic WWII shooter! Yeah! Or a vanilla Aquanoid clone! Yeah! Or, hey, Bejewelled - but with gumdrops instead of jewels! Watch 'em flock to your door to buy something that's no better and no different from a hundred other competing products.
#4 - Don't Polish It
Players don't care about polish or consistent interfaces or minor irritating bugs or cruddy programmer art - they just want the gameplay. Hey, that was Ed Wood's attitude about movies, and he made some CLASSICS!
#5 - Don't Market It! If You Build It They Will Come!
Don't market or try to INFORM people of your product. Don't go out to everywhere potential customers might be and give them the message that there's something they might actually enjoy playing out there for them to try. Let them figure it out by divine inspiration or Googling the exact name of your product and stumbling across your website.
#6 - Ignore Player and Reviewer Feedback
Who cares what they players or reviewers say? If they don't get it, it's because they just lack the mental capacity to appreciate the artistic genius of the designer!
#7 - Don't Try To Sell The Full Version In The Demo
You don't want to be seen as pushy or money-grubbing. So don't even MENTION that the player can buy the full version of the game in the demo. If they really wanted it, they'd scour your website for hours trying to find a way to send you money.
#8 - Don't Package Your Game With An Installer And Uninstaller
All your game needs to have is a zip file, and players can just drop it and run it from the directory of their choice - they are all expert computer users, right? And they should be able to figure out how to uninstall it. It was good enough for the DOS days, it should be good enough for today.
#9 - Don't Show Off the Game's Best Features in the Demo!
Don't let those freeloaders experience the best your game has to offer! You worked hard for that - they should PAY to see what they are missing!
#10 - It's Okay That the Game Takes Forty-Five Minutes to Get Into
Gamers have nothing better to do with their time than to struggle through a half-hour or more of frustrating tutorials and opaque interfaces ... because by THEN the game really starts to get fun, and they'll be hooked!
#11 - Ignore New Opportunities, Just Do It the Way It's Always Been Done
It worked for those guys back in 1998 when the Internet was new and technology was different - you should be able to copy exactly what they did and take it to the bank, right? Lightning always strikes multiple times in the same place.
#12 - If At First You Don't Succeed, QUIT! (And don't take up parachuting!)
Okay, so your first game sold a total of TWO copies, and both of those were to relatives who felt sorry for you. Maybe it was because you followed some of the advice in this blog article. It's okay - you didn't do anything wrong, it's just that the market is totally different from how it was five years ago, and now it's impossible for indies to succeed. Forget everything you learned from this experience, don't try to improve, just call it quits and move on to a less time-consuming hobby.
Okay, that about does it for my week of posting lists of stuff for indie developers to work on. I hope it's been amusing, and possibly even informative! And if you are a game-player and not a game developer, I hope it has been an entertaining insight into the world of game design and development.
Wednesday, June 28, 2006
20 Ways To Make Money Making Indie Games
Since I'm on a roll for providing lists of ... stuff, here's something more original:
Newcomers to the indie game development scene often limit themselves to only two possibilities when it comes to selling their game: Either they try to find a publisher to sell it for them, or to follow the old "shareware" model and release the game on their own website. Recently, portals have become a major alternative. That's pretty much it for options, isn't it?
Not even close. I keep harping on all the opportunities that I have discovered in my own limited forays into the world of independent game development. People are coming up with new ways to market and distribute games every week! I wanted to share a few examples.
Don't forget --- unless you choose an exclusive option, you may be able to mix and match SEVERAL distribution methods. There's rarely a need to put all your eggs in one basket... but if you do, make sure you have some guarantees on that basket! And one opportunity often leads to others. For example, the original relase of the PC version of Outpost Kaloki was an "okay" seller, but it led to an opportunity to become a HIT GAME on the XBox 360. It found its audience there.
So here's a bunch of ways to make money making independent games. And no, none of these come with any guarantees.
#1 - Get A Domestic Publishing Deal
A lot of new people to the indie game scene think that what you need is a publishing deal. Create a game good enough that a publisher will pick it up and sell it for you at Wal*Mart. Nice idea --- and it occasionally happens. But whatever you do, do NOT make this your end goal! There are all kinds of war stories floating around about game developers who got one of these deals, thought they had it made, and happily signed over all rights and their games' future for a pathetic advance (if that), and then never saw or heard from that publisher again.
#2 - Sell it on a Portal or through an Online Publisher
Another popular option is to sell it on a games portal. These include RealArcade, Big Fish Games, GarageGames, Arcade Town, RealArcade, Matrix Games, Shrapnel Games, Manifesto Games, and Oberon (which handles sales on MSN and Yahoo). Valve and"Steam" is another new option. Sometimes these CAN lead to "box deals" for retail stores. Just remember that these sites cater to different audiences, and this may effect your sales. Oberon, RealArcade, and BigFish emphasize the very casual, usually female audience. GarageGames has a following in the Apple community. Matrix and Shrapnel focus on war and strategy games. Some of these companies prefer an exclusive publishing deal, and others are happy (and prefer) a non-exclusive deal.
#3 - Sell It Yourself on Your Own Site
Always a popular option. This takes the most work, but it's also one of the most rewarding. I think I've sold more copies of Void War on my own site than any of the portals.
#4 - Affiliate Sales
There may be other indies out there pursuing option #3 - and they may have a similar target marget to your own. Let them sell your game, too!
#5- Foreign Distribution Opportunities
There are some foreign distributors / publishers that are looking for content to release for cheap in their markets, if you can work with them on localization. Sure, you might only get $0.25 or $0.50 per CD-ROM, but if they can push 10k-40k of your game, that's some nice supplemental revenue.
#6 - OEM Deals
These may bring less money than #5, but if you can partner with a hardware manufacturer, you may be able to get a few pennies per game by bundling your game with their hardware.
#7 - Consoles
Sure, everyone's talking about the XBox 360 LiveArcade, but don't limit yourself to that. Don't even limit yourself to the two other major consoles that may or may not have downloadable indie games as an option. Or the ever-vaporware Phantom console. There are also opportunities like the Linux-based GP2X handheld. The owner of the "Arcade-In-A-Box" emulation system is also looking for new, retro-style content to offer for sale to his customers.
#8 - Cell Phones / PDAs
My personal take on Cell Phone gaming is that it was locked up and settled by distributors long before most indies had a chance... not to mention over-hyped as an opportunity. But it REMAINS an opportunity, and shouldn't be ignored.
#9 - Unusual Platforms
I was once contacted by a gentlemen asking for a bid to do a version of Void War for a motion-based platform that he was selling. I didn't win the bid, but those kinds of opportunities are out there.
#10 - AdverGaming
I don't know much about this one - but this one has potential to be the next big frontier. I mean HUGE, if we can figure out how to best exploit it. The cost of your game is subsidized by advertising products in-game.
Note: Do not confuse this with "Adware" bundling, which is a despicable practice of bundling malware with your game: this could very well DESTROY downloadable gaming as people learn to distrust anything they download off the Internet.
#11 - Release For Free, and Request Donations
A tried and true practice, far older than this technology. Independent "street" musicians have done this for ages.
#12 - "Serious Games"
There is a whole conference and at least one book on the subject of doing "serious games" - games designed to educate, simulate, and/or train rather than purely entertain. You might create a game from the ground up on contract as a serious game, or you may find an opportunity to adapt an existing title. This is growing really fast, too.
#13 - Use Your Game as a Centerpiece For A Book
Okay, there's a zillion books out there on writing games... but people still buy 'em, so there may be room for a zillion and one. Besides, very few have a commercial-quality game included with full source code!
#14 - Cross-Sell With Related Products
There's at least one company out there that sells both a board and computer version of a game, and cross-market the two.
#15 - Contests
There are several videogame development contests that happen every year, the IGF being one of the most notable. These prizes of these competitions range from cash to publication offers to free hardware and games - or a combination of any of these. They also come with some level of recognition and free press, which is always a good thing.
#16 - Release Free, Support With Advertising On Your Website
There are a bunch of Flash Game sites that do this. The games are free, but they encourage you to click on advertising links.
#17 - Mail-Order CD-ROMs
Sure, it's old school. But you could do on-demand manufacturing of CD-ROMS, and include free demos on the discs for your other games. Just a thought.
#18 - Bundled Collections
Okay, so these are often called "Shovelware" and may not always be good options - but opportunities do crop up from time to time to bundle your game with other, similar titles in a retail "box" release. It may make sense.
#19 - Free (Online) Game, Pay For Premium Content
Another model that is proving very popular right now: You offer an online game for free, but allow players to pay a fee (often a one-time fee, but a subscription may work) for preferred access and premium content. It could be a single layer of premium access, or you could give them piecemeal access to a never-ending supply of cool goodies. If it's a multiplayer game with a good community, your premium players may be your best salesmen.
#20 - Subscription Game Sales
This was an old-school idea from the late 80's and early 90's, as seen with SoftDisc ... the previous employer of much of the core id Software gang. It was temporarily resurrected by TotalGaming recently, but isn't being used anymore. It's still being seen in MMO's to some degree. The idea is that people pay a regular subscription for a constant influx of new games (or new content). This COULD be made to work with episodic content, in theory, but just like offering new games --- they'd have to be of consistent quality to make it worthwhile to customers. I'm not sure how to make this one fly today, but it's probably a concept waiting for just the right creative and entrepreneurial spin.
Tuesday, June 27, 2006
How To Schmooze
There's some great bits of useful information cropping up on the 'Net for indie gamers this week... and it's only Tuesday!
This one is from Joseph Lieberman - the videogame marketing guy, not the anti-videogame senator.
Tips on How To Schmooze at Conventions
Don't roll your eyes! Stop that! One of the things I have grudginly learned to appreciate as an indie game developer over the last couple of years is just how useful these marketing skills really are. Even if you aren't actively marketing your game or yourself right at the moment - this is how you develop contacts!
I don't drink, so I don't know how well the tips concerning to alcohol really apply to me, or how much that restricts me from schmoozing opportunities. I think I can vouch secondhand for the obvious, "Know your limit" tip. I heard a story from a journalist who shall remain nameless here who said he got a little too drunk one night and confused Richard Garriott for Peter Molyneux. Repeatedly. In spite of numerous attempts at correction by said gaming luminary. He said the next morning, when he was actually interviewing Garriott, Garriott was gracious enough to pretend he'd forgotten the whole thing. But the journalist was pretty embarassed about it, even years later.
Monday, June 26, 2006
Ways To Be A Better Game Designer
I'm not a great game designer (though I aspire to be). I thought I was a great game designer once. Then I found out that game design is hard. It only seems easy until you sit down and do it, and realize that it's not about grand ideas, but about all the tiny little frustrating details and the trade-offs that come with them.
So I'm always looking for tips on being a better game designer. Raph Koster just posted an article with forty of 'em. Not all of 'em are created equal, but they are all useful bits of advice:
My favorite ones:
Giant Design Docs Are Useless
Man. If I had a dollar for every GDC presentation I listened to in the 90's where some designer went on and on about his wonderful, complete, awesome design document and how it was gonna make a killer game... and then followed up with either no game at all or a complete and utter flop...
Well, I'd have enough money to buy lunch. But still...
Design docs are important for doing a team job. But the most important thing about them is that they are concise, well-organized, and tell the story of the game's concept as simply and powerfully as possible.
Playtest Early and Often
From what few games I've had exposure to early in development, I think I can say that you could almost predict what games will be a hit from this principle alone. Sure, there are some games that come together at the last minute (Jet Moto is one example that comes to mind), but it's hard to beat a game that is playable and testable and FUN early in the development cycle.
And if it's not very fun, the earlier you can discover this, the better your chances of fixing it before the game ships or you go careening hopelessly over schedule.
I like this one. If you can't summarize the gameplay very simply in a few verbs and phrases, you are probably creating a mess instead of a game. Another useful little trick is to use those key verbs and phrases throughout development when you are dealing with feature creep - does the proposed feature or change accentuate these key elements, or does it draw attention away from them and onto something else entirely? If the latter, it should probably be cut.
Limitations Are Good
This was driven home to me a couple of years back while watching the director commentary for Star Trek II: The Wrath of Khan. The director was talking about how they pulled off a particular scene / set. The original proposal was far too expensive. Forced to work within a much tighter budget, they actually came up with a trick that worked far better than the original, more expensive solution. The director expressed the belief that this was usually the case.
Budding indie game developers, take note!
Labels: Game Design
Sunday, June 25, 2006
Rapid Level Prototyping
I was growing frustrated with the pace of development for Apocalypse Cow. I found I was spending too much time on a single level, trying to get it to an alpha or beta level ... even with stand-in assets. Then I found myself doing some "chrome plating" on the level. While this resulted in a few levels being pretty show-able, I'm still stuck knowing whether or not some of the later designs are even feasible, and what my total asset count is going to be.
So I decided to do some "rapid level prototyping," with a goal of actually having EVERY level roughed-in within about two weeks. It's probably too aggressive of a goal, but it's worth a shot. One of the things I'm trying to do with the game is to add some new challenge or gameplay element with every single level, so that keeps things... busy. There's a lot to do, but the sooner I get everything prototyped, the sooner I can know if some of these fuzzier ideas are actually going to work. There are some technological risks for later levels that this process forces me to deal with now instead of at the end of the project. Most importantly, at the end of the process, I should have the entire game integrated together and working, allowing me to look at and work with the game as a whole. Admittedly, a fairly UGLY looking whole.
We'll see how well this works. Once this phase is done, I should be able to generate a much more concrete "to do" list. I may also see a lot of ways to optimize elements and see what can be cut or combined. And I can make sure the story elements work, the gameflow logic is solid, saving / loading games work, and so forth. At least that's the theory.
Friday, June 23, 2006
No Design Survives Contact With The Players
There's a saying about combat that "No plan survives contact with the enemy." In game development, the same thing often happens with your game design coming into contact with the realities of development, and then the end users.
I have seen this happen several times, but my favorite story actually comes from a "dice and paper" RPG. It wasn't Dungeons & Dragons - it was another system called Fantasy Hero.
The Fantasy Hero system was based on the Champions rule system, which was designed for simulating comic-book super heroes. So it was extremely flexible, mostly-kinda-sorta balanced, and could handle all kinds of cosmic-level capabilities. I had an idea for YEARS about a cult of mages that had a "Doomsday Spell" which was devastatingly powerful, but also reasonably cheap in character-cost points because it was uncontrollable and only triggered on the moment of their death.
The idea was that this band of "doomsday mages" had a scarred magic symbol written on their palms that designated them as possessors of this Doomsday spell. Killing them would trigger this effect, which was a collossal explosion that covered over a kilometer radius.
These mages would make no secret of this symbol, raising their palm to those they'd meet so that everyone would know NOT to mess with these guys, as killing them would almost certainly guarantee the death of whomever killed them. They would be feared - and, grudgingly, protected, by anybody they came into contact with. They were the ultimate emissaries of evil. And perfect fodder for recurring villains - the enemies who would smile smugly KNOWING that the heroes wouldn't dare attack them.
I waited for a long time to bring these guys to bear against the players. I came up with the concept YEARS before I got to use them. And oh, boy, was I prepared for their dramatic appearance in a campaign. The forces of evil were invading the nation of good, and had occupied a fair portion of the eastern territories. They had a gigantic encampment around one major city they had just seized, and were getting ready to move again.
The attacking army sent one of these doomsday mages (whom they were in alliance with) to negotiate a surrender with the defenders - who were in turn joined by the player characters. I'd put a lot of time and effort into this doomsday mage. I expected him to be a recurring villain, a thorn in the player's side for some time, as I was sure they'd hate not being able to kill this guy.
He appeared. I played him up cocky and oily and just rubbed it in. Nobody could touch him - he knew it, and the players knew it. The players hated him INSTANTLY.
And so they jumped him on the edge of town. And beat the crap out of him. But they did not KILL him. They knocked him unconscious, and kept him alive with healing spells. Just barely.
So now they had an unconscious Doomsday Mage that will self-destruct if he dies. What would you do with him?
Well, one of my inventive players had a summoned mount that could fly. It could carry both him (the character was a him, the player was a her) and this unconscious mage. So they flew up to an altitude of about 5,000 feet, flew off to the invading orcish army encampment, and let the unconscious mage drop.
Even assuming a terminal velocity of 20d6 damage, the mage didn't have many BODY points left to live. He hit the ground and died instantly. The explosion was kind of a Hiroshima / Nagasaki type thing. The flying PC and his mount were too far above the explosion to take any damage, but the orc army was DEVASTATED, as my entire campaign was about to be. I sat in stunned silence as the players looked at each other, grinned from ear-to-ear, and asked, "Where can we find more of these Doomsday Mages?!?!"
After years of expectation, my great plans for the Doomsday Mages were ruined. Overnight, they become nothing but a mere footnote in the history of my campaign world. The Doomsday Mages found themselves hunted to be uses as involuntary weapons of war. Those without means of flying them to their death could kill them with slow-acting poisons. The Doomsday Mages scattered to the winds, seeking magical means to remove the awful doomsday spell and the scar on the palms of their hands.
The orcish advance was halted by the devastating blow to their front lines, allowing the defending kingdom to finally mount a solid counterattack (with the players' help, of course). Dropping the mage-bomb was the pivotal point in the war and in the history of the world.
And the players ---- man! When they realized that I'd never INTENDED to let them use the Doomsday Mage to bomb the attacking army into the stone age, they were simply beside themselves with glee for their own cleverness. And that game session became one of their favorite adventures of all time.
The take-away I learned from this was to always consider a new, untested feature that you want to add to your game / design from the point of view of a player looking to game the system. This is particularly important in a multiplayer game, as any trick that gives a minor advantage will rapidly propogate to become the only way of playing. And of course, playtest playtest playtest (not appropriate for dice & pencil RPGs, but critical for designing computer games).
The other thing I learned - and this is really only more appropriate to RPGs - is that the players LOVE to feel like they "out-clevered" the designer. So let 'em bask in their victory for a while. THAT will be the thing that they remember for years.
Thursday, June 22, 2006
Those getting the newsletter (check the top of the sidebar to the right) have already seen this.
A picture is worth a thousand words, they say, so this is already too long. Peace!
Labels: Apocalypse Cow
Server Move, Some Broken Links
We're getting ready to move to a new ISP... and some of the broken links you guys may have been experiencing at Rampant Games are a symptom of the troubles that we've been having with the existing service.
Anyway - I know that right now the Hackenslash demo and the Outpost Kaloki demo links are not working - I'm going to try and fix these ASAP. The Void War demo links should be fixed now. ANYWAY - please let me know if there are any other broken links and I can see what I can do. Some files were hosted on a secondary server that went down HARD last weekend, and since then we've made some DNS changes.
Contact me at: feedback [at] rampantgames.com if you have any more busted links aside from those mentioned...
Wednesday, June 21, 2006
Aveyond Tops the Charts
Well, not entirely, but while I was distracted by another RPG called Oblivion, Aveyond has been turning into a real indie hit. And it should - it's a great game! Though if you have been following this blog for a while, you already knew that, and already downloaded the demo for ten free hours of play. Well, okay, that last part is optional, but it's worth your time. :)
A lot of old-school gamers really like the "classic" style of the game. What's even more interesting to me, anyway, is that it has really been well received by "casual" audiences... the ones that have been pigeonholed as only liking match-three type games. Turns out this audience may have a been broader taste than some folks believed. Of course, I like to chalk it up to evidence of a theory I suggested a few months ago. I still believe that - casual is an adjective, not a genre. There's a lot more that can be done to appeal to the so-called "casual" gamers than just throwing yet more match-three games at 'em.
I already suggested once that Aveyond was something of a "casual" RPG - at least more casually oriented. And that's proving itself out. Why?
Amanda F., the game's designer, suggested the following on the indiegamer boards:
"Like a lot of casual games, it's very easy to learn and very easy for the
player to start and stop. It has a nice little journal feature that the player
can use to get back into the game if they've been away for sometime. I have a
lot of players who open up the game just so they can wander around and enjoy the
"In my opinion, there is a certain style of game that is popular on casual
game portals. Take a look at the best sellers. You'll notice a lot of them look
friendly and cute. You'll also notice that the cute games are usually on top of
each catagory be it puzzle, action, arcade, etc. Perhaps the market is more
interested in the style, not the type?"
Cute? Maybe. Non-threatening? Definitely. And maybe that's a big key right there.
Look at the covers of most mainstream, 'hardcore' games, and they tend to show off the challenge of the game. I mean, the Void War 'box art' (not that we have a box) is a perfect case in point - two ships locked in mortal combat. They kind of taunt and challenge you to play. Contrast that to the marketing message of most casual games, which seem to try to "invite" you into entering this cute, fun, and relatively safe world.
I dunno - maybe I'm grasping at straws here. But it's late and I'm tired.
But Aveyond really is a lot of fun. Even for someone who's been all jaded with playing Oblivion (which probably cost a hundred thousand times more to make than Aveyond, but I guarantee isn't a hundred thousand times more fun!)
Tuesday, June 20, 2006
The latest anti-videogame bill (co-written by the wannabe King of Torts himself, Wacky Jacky Thompson) in Louisiana has just been blocked by a U.S. District judge. Apparently applying fuzzy, subjective definitions to violence in videogames and then throwing it in a bin labed 'porn' just isn't going to cut Constitutional mustard. The politicians keep sending up these horrible laws, and so far the industry has managed to keep knocking them down. But we shouldn't have to.
I'm fairly convinced, after seeing some of the deception that took place with a similar bill that almost passed here in Utah, that the politicians really don't give a crap about the real issues, but are simply garnering "family values" points that seem to be free of political consequences. After all, only children play videogames, and children don't vote, right?
But you've heard me rant about this before. Once or Twice (*GRIN*). Ranting on a blog is all fun and everything, but this year we took things a little bit further and contributed in a hopefully-not-too-insignificant way to givin' the ol' First Amendment a hand.
Crashing the Party Party
I found out that David Hogue, who sponsored the Utah bill that lumped violent videogames into the "Materials Harmful to Minors" (read: pornography) law, was running for the state Senate the same day they were having the Republican Caucus meetings here in Utah. Well, I'm not a Republican. But I figured I'd do what I could to help get him removed from any position of authority so he could threaten more harm.
So I crashed the Republican Party party. It was just around the corner, at my neighbor's house. So my wife and I, having NO clue what to expect (I vaguely remembered hearing about how those worked in a political science class in college and a civics class in High School), showed up. There was free food and lots of fliers and handouts. Oh, and a request for donations. Knowing that the donations could go to support Orrin Hatch's bid for re-election, I didn't donate.
Every time they said, "fellow Republicans," I felt a twinge of guilt. I'm not from a rival party trying to spy on anyone or anything (like that would have done any good!) I'm just independent. I had heard that you didn't NEED to be a registered Republican to attend these meetings, but as the meeting continued I began to worry if you could go to Federal prison for Impersonating a Republican.
Fortunately, the rules were reiterated so I could breathe a sigh of relief. You did NOT need to be a registered Republican in order to participate in this caucus meeting, but if you were elected as an officer or a delegate, you had to either be a member or sign up for the Republican party at the end of the meeting. I deferred. However, I did get to cast my vote for delegates and officers, and I was asked to help count the ballots after the votes. BOY did that feel weird. Fortunately, we had no pregnant chads or hanging chads or anything like that. The worst we had to deal with was some really sloppy handwriting, but that was my own vote, so we were eventually able to make it out.
And - most excitingly - I was able to speak up on what I thought was the most troubling issue: The rash of anti-videogame laws that fail to solve the problem, threaten to cripple a growing U.S. industry, and the very questionable actions that had been taken to try and force them to pass. The rest of the people in the room looked at me a little puzzled, as they were all there to argue about policies about public schools and stuff, and here I was bringing up videogames right out-of-the-freaking blue. But they politely asked me some appropriate questions, and didn't treat me like anyone's idiot nephew. And if videogames weren't on anyone's radar before, at least they were aware that there was at least ONE complaint out there.
I left the meeting feeling very, I don't know... civic? And I figured we'd done our little tiny insignificant bit to help preserve a new creative and artistic medium. And there were a couple of delegates that we'd elected that learned that this was an issue that their neighbors cared about.
And We Get To Be Even More Political
The GREAT news was that whether or not my emotional speech to our delegates from our little corner of the district had any bearing or not, Hogue failed in his state senate bid. Not a big surprise, going up against an incumbent.
Because we put our name and phone number on a piece of paper at that meeting, we're getting calls by a bunch of campaign groups who are basically doing "market research." They often ask us what we consider the biggest issues for this election. I guess they figure we're politically active now, and suddenly we've become important. Now if only we'd contribute money to them, I'm betting we'd be a lot more important.
We tell 'em. Preserving the first amendment and freedom of expression for videogames is usually not on their list. But hopefully, after my wife and I have given them an earful, it might be put ON a couple of lists.
A Visit From A Candidate
Saturday, we were visited in person by Carl Wimmer, who is running for Hogue's soon-to-be-vacated seat. His opponent, Dennis Sampson, is an old friend of David Hogue's, and Hogue is acting as Sampson's campaign manager. My wife got a chance to speak with Mr. Wimmer at length on our porch. Not so subtley, she brought up the question of his stance on videogames and all this legislation attempting to regulate it.
Wimmer, a longtime law-enforcement officer, said that he was opposed to violent videogames, but he believes the government has no right to try and regulate it. Which is how we feel. I mean, sheesh - nobody in their right mind wants to see gruesomely violent videogames being sold to children! That is not what this is about. It's about the "chilling effect" of government regulation on a powerful new medium of expression.
Between Wimmer's response, and the fact that he's running against David "Videogames are porn!" Hogue's chosen replacement, we decided to let him put his sign on our lawn. Of course, we're in a cul-de-sac so I don't know if very many people will actually SEE this sign unless they have gotten very lost or have driven all the way to our house just to see a sign next to our mailbox. But hey, it's there. Maybe that's why all our Democrat-leaning friends never visit us anymore...
But I am hoping that in a very tiny way, the anti-videogame stance is hurting some politicians in this election.
And maybe next time I'll crash the Democrats' caucus meeting. My wife can hit the Republican one (I think she's actually registered). We can compare notes, and see which one served better food.
Monday, June 19, 2006
Mainstream Games Get Even Narrower
I don't think this article will be freely available on the NYTimes website for more than a few days, but here it goes:
* Analysts are estimating a 30 to 50 percent increase in the cost of making "top-tier" games for the new consoles.
* Analysts are really concerned about the games industry - not that it's going to die or anything, but that the days of explosive growth seem to be over.
* Bobby Kotick, CEO of Activision, has some even more interesting comments. One was that the industry is going to focus more narrowly on games with higher hit potential. Read: Fewer games, mostly in proven genres.
* Mr. Kotick is further quoted as follows: "The idea of full downloadable games is so far in the future that it's almost incomprehensible as an opportunity," Mr. Kotick said. But he added that there were more immediately plausible revenue opportunities from selling downloads of supplemental game levels or "characters, new weapons, new missions, or auctioning off places" in a virtual world.
Yeah. Nevermind that Half Life 2 sold (from what people can tell) about as many copies via STEAM as they did in Retail. Nevermind that Epic is planning an even better delivery system for PREY that will allow people to play while the game is still downloading. Nevermind the biggest story of the XBox 360 is the LiveArcade stuff. Nevermind that the indies are going full-bore on the fully downloadable game thing. True, you aren't gonna find many indie games with 3 gig download size, unlike top-tier AAA games.
So there are four possibilities here:
1. Mr. Kotick's myopia about downloadable games is respresentative of the entire mainstream games industry, and they are all clinging desperately to the status quo...
2. Mr. Kotick's myopia is particular to just himself and his vision of Activision's future
3. Mr. Kotick's comments were smokescreen to reassure investors and distribution partners, and to conceal Activision's plans for taking advantage of downloadable games.
4. Mr. Kotick really does know something we don't know.
If it's #1, then the games industry really is going to be in trouble as they churn out fewer, even more derivative products, sticking even closer to the tried and true.
No matter how you slice it, the efforts of the mainstream industry to further narrow its scope means the door will left even more wide open for the indies.
Sunday, June 18, 2006
June Status Update
I finished Oblivion today. I don't know if it's actually "finished" when I've not completed ALL the quests I intended to follow, and when I've only explored something like 10% of the dungeons I've encountered in the game --- but after way too much time devoted to the game and my character very nearly maxed out on his level, and of course the main storyline completed - there's just not a whole lot more worth doing. But unlike most story-based RPGs, ES: Oblivion still allows you to keep playing after it's been "won." Which is cool. I may go back and play a little, but the drive is definitely gone. But it's satisfying.
Also - we've been making some DNS changes in preparation to move RampantGames.com to a new server and a new ISP. Some of you may have noticed outages over the last few weeks... out current hosting solution has not been very responsive, so we're moving. So there may be a little bit more downtime in the next week or so, but I certainly hope to find us more stable than ever following this move.
*Knock on wood*
Friday, June 16, 2006
How Do I Get Past the Harpies?
Especially back in the 1980s (but still true today), if you happened to know a thing or two about computers, people assumed you were an expert on the subject. And you'd get called on to fix other people's computers. At the age of 14, I knew how to program in BASIC and a little bit of 6502 machine code; I knew what a floppy disk was (they were mainly 5 1/4" back then); and a little bit about booting up different kinds of machines. That made me a "whiz kid" and earned me some measure of respect and awe from adults. Which was of course, very cool.
One Saturday a woman from our church needed help with her computer, and had asked my parents if I could come over and take a look at it. She lived a distance away, so my dad dropped me off to take a look at it, promising to be back in a few hours.
This lady was very gracious, but had no clue what to do with this machine on her kitchen table. This was a "portable computer." Back in 1984, a "portable computer" was jokingly referred to as a "luggable." They were about 50 pounds or so, had a built-in 4" screen, and were about the size of a small suitcase.
I spent about 20 minutes fiddling around with the system, asking the lady for her boot disks and anything else that came with her system. I figured out the problem, but I wasn't able to fix it (I think it was a bad disk, and she didn't have a backup). I gave her my best advice, and I was done. And... I still had a few hours to wait before my dad would pick me up. She gave me some lemonade, and said that she thought there was a couple of games on her assortment of floppies.
The one game I found held my interest for a few minutes (it was some game about a garden maze full of monsters - all ASCII characters), but then I found a disk with a version of BASIC. I booted it up, and began programming.
By the time my Dad showed up to pick me up, I'd written a short little text-adventure game. I only had time to do a really simple text parser, and it had something like 20 areas and a dozen items scattered through them. I left the computer running, and forgot about it. The lady thanked me again for my help (what little I'd done), and I went home and forgot about it.
Shortly after dinner, we got a phone call from this lady. It was for me. I was wondering if there was something else wrong with her computer. I answered the call.
"How do I get past the harpies?!?" she begged me.
It took me a few seconds to realize what she was talking about. She'd discovered my little adventure game --- and had gotten most of the way through it. She was stuck at the harpies, which kept killing her.
"Oh, you get the wax from the candles and put them in your ears. Just 'Use wax.' That way you won't be effected by their song," I responded.
"Thank you!" she said. And she explained that she'd been playing it all evening, and had been trying to get past the harpies for the last two hours, and it had been driving her nuts. She thanked me for the solution, and hung up - presumably to finish the game. Which had taken her almost as long to play as it had taken me to write.
As for me, I felt GREAT. This was the first time someone else had played one of my games - and she'd apparently been hooked on it the entire evening. She LIKED it. And she was not a geeky computer-game addict like me... just some woman who used her computer for her business. But my little invention was of worth to her.
There have been a lot of games since then, and a lot of players. And the feeling hasn't changed much.
It still feels great.
Thursday, June 15, 2006
Lessons Learned Playing Computer RPGS
So here are some lessons I've learned playing Computer Role-Playing Games (a bit of an Oblivion slant here, as I've been playing it lately). It's amazing how much you can learn about Real Life from these games...
#1 - People will use really elaborate locks to protect their pickaxes and yarn
#2 - Strangers met in cities are usually safe. Strangers met out on the road between cities are almost always trying to kill you.
#3 - It doesn't matter if they are hungry or not - wild animals are ALWAYS agressive and attack on sight.
#4 - Wild animals also sometimes have pockets in which they carry loose change.
#5 - People really don't mind repeating themselves endlessly.
#6 - Burials are only for people who died of natural causes. If someone dies due to violence, their body will be left out in the street forever and people will just learn to ignore it.
#7 - The world may be coming to an end, the invading monsters marching in the street, and the town burning around their ears, but merchants will always have time to haggle with you over prices and will always make sure they make a profit.
#8 - But the merchants are right - you've also almost always got time to sleep, have dinner, and run errands in the midst of an immediate apocalypse.
#9 - Weapons and armor made of soft, precious metals are somehow much stronger than their more boring steel counterparts.
#10 - Perfect strangers will seek you out to ask you to run errands for them.
#11 - Monsters may all look alike, but if one of them has his own unique name, WATCH OUT!
#12 - You may be the best locksmith / lock picker in the universe, capable of facing down villains that can wipe out entire ARMIES - but there will always be some doors that are invulnerable to nuclear blasts and completely impossible to unlock without the correct key.
#13 - Nobody has a problem with you searching through (or even smashing) barrels and crates if they aren't inside someone's house (and sometimes even if they are).
#14 - Barrels are great places to store gold coins and suits of armor.
#15 - An enemy can fire an unlimited number of arrows at you in spite of having only five arrows in their quiver. It's like a pointy, hostile loaves-and-fishes miracle.
#16 - The cashier of any store is willing to buy your pocket-lint from you for half retail price.
Got any more fun lessons you've learned? Lets hear 'em!
Void War 1.20 Demo REDUX
And yet another Version!
Well, not, not really. But it turns out the main links to the Void War demo were still pointing to (*cough*) the old version. So if you installed version 1.01... uh, that wasn't it. SURPRISE! Sorry to waste your bandwidth. Well, more than I usually do with this blog.
The links SHOULD be fixed as of a little after 10:15 AM this morning, Pacific Time, and the installer should tell you that you are installing version 1.20. When you run the demo, in the main menu screen, it should say you are playing version 1.20.
This should be a lesson to me about posting up a new version of a game late at night under the influence of cold medicine. But since I tend to forget these lessons when it's late at night and I'm under the influence of cold medicine, I don't know of how much value it will be to me.
Anyway... the links on the main Rampant Games page and the Void War page *should* be correct now.
Wednesday, June 14, 2006
Wow! A Void War Update!
UPDATE: Some links (including some principle ones) were actually to the OLD AND BUSTED version 1.01. They are fixed now, and should all be pointing to the NEW HOTNESS. Should.)
Yes, it's long overdue - but Void War is now up to version 1.20.
Grab the free demo here. If you've already played the demo and the time has expired, fear not! This one will reset your timer, so you'll have another 60 minutes of free single-player gaming (and unlimited multiplayer, with 5-minute automatic cutoff).
If you have already purchased Void War: You'll need to re-download Void War from the link provided in your confirmation email to upgrade to the new version. If for some reason that doesn't work, contact me ( feedback [@] rampantgames.com ) and we'll get you hooked up.
Some of the changes to this version:
* Tighter ship control. This should make ships like the Cyclone much easier to fly
* Slightly reduced effectiveness of lasers. This should give you a little more time to dive for cover or for a power up when you start getting pounded
* The view preference is maintained throughout the session: So if you prefer third-person view, you won't have to keep switching to that view every time you advance a level or respawn.
* The energy preferences are also maintained throughout the session, so you don't have to reset your energy priorities every time a new match begins
* You can now skip to the next line of a cutscene by clicking a mouse button or the "fire missile" control from the keyboard. As always, the "escape" key cancells the entire cutscene ... the mouse button just speeds it up.
* Brightened up the ambient levels a little more so you can SEE the asteroids you are about to run into.
* Using the new Vorbis / Ogg libraries for better music playback
* The "Update" button on the launcher now takes you directly to the Rampant Games Downloads page.
* Lots of miscellanious bug fixes in joystick control, audio playback, gameflow, and AI.
Due to the changes in the AI, ship physics, and weapon dynamics version 1.20 will be multiplayer incompatible with previous versions - your friends will have to update to 1.20 as well.
Labels: Game Announcements
Tuesday, June 13, 2006
Living the Dream!
As I recall the story, Clark Peterson heard about the "Open Gaming License" of the latest version of Dungeons & Dragons in 2000. As an old-school gaming geek (now turned lawyer), he thought it would be really cool to start a company creating role-playing game modules like TSR (the original makers of Dungeons & Dragons) did in the "good old days." He managed to contact his old college gaming buddy, Bill Webb, and as partners they formed Necromancer Games. Their goals were modest: They'd create game modules and expansions as a hobby, and hoped to cover their expenses and maybe have enough profit for a case of beer to split between them.
They did significantly better than that. And so far, they've managed to weather the storm of the industry downturn, in spite of the fact that many of their competitors (the majority, by most counts) have called it quits. And besides making a bit of cash on the side by doing what they love, Clark and Bill and the numerous authors who have published through Necromancer Games have had the chance to do something really cool, learn a lot, meet some childhood geek-heroes, work with licenses of beloved classic properties, and otherwise have a great time doing something they love.
It was a childhood dream. As adults, they realized the opportunity was there to make it a reality. There really was nothing stopping them.
A friend of mine, Jana, always wanted to be a writer. She did a stint as an editor for a college science fiction magazine, but after school she found herself doing Quality Assurance and tech writing. Not exactly what she'd envisioned. She had some early attempts to get published met with the traditional rejection slips, and for a while it looked like the dream was gone forever.
Then, a few months ago, facing the usual job volatility of high-tech industry, she decided to take it as an opportunity to work on writing as a 'side' career. In fact, she told me she came to a bit of a crisis of self, and reached the realization that it was time to either make something of her dream, or to put it away forever.
Rather than an all-or-nothing approach, she started seeking out opportunities to do what she loved doing and make a few bucks at it. And she she succeeded.
The bucks were certainly few. But besides the money, she got practice, experience, contacts, and a reputation. Now she's getting people contacting HER to ask her to write for them. She's finding herself surrounded by better and better opporunities (and better and better pay). Moonlighting in this side-career certainly has its challenges and is a lot of hard work, but she's doing what she loves. And profiting from it.
These aren't rags-to-riches stories. Neither of these stories end with the individuals becoming rich and famous and living happily ever after. In fact, none of these stories actually END. They are still ongoing, because the people involved still love what they are doing and are seeing success - either monetarily or in some other level of satisfaction. And there are tons of more stories like this. This is pretty much the common story of most indie videogame developers!
It's SCARY taking the plunge and committing the effort (and, usually, money) to living the dream and doing "what you always wanted to do." It involves a metric butt-load of work, and often some outlay of money, with often very little to show for it at first. There's the tremendous risk to your delicate ego to do something new that you might suck at. It's hard making a commitment to something that your brain tells you is just a dream, and therefore couldn't ever be real. You are supposed to be grown-up now.
But there's nothing stopping you. In many cases, it's very possible to start small and minimize your risk - as Bill, Clark, and Jana did. That may mean slow rewards at the beginning, but that could be considered all part of "paying your dues." But it doesn't have to stay there. What I've found is that success tends to breed success. Just as doing nothing tends to result in more of nothing getting done.
The Necromancer Games story was actually one of the inspirations for me starting Rampant Games. And we just had a pizza party last week to celebrate actual profitability (and squander what meager profitability we had). And I have been amazed at the number of opportunities that have resulted from my efforts with Rampant Games and Void War. Nothing earth-shattering, but very cool nonetheless. Really, my current full-time job is a direct result of my indie game efforts.
Yeah, this is a scary thing to do. It's a TON of hard work. But is it worth it?
I can only speak for myself and say: TOTALLY!!!!!! Though I expect Jana, Clark, and Bill would say the same thing.
I mean looking back over the last few years and what I've been doing, even my minor accomplishments and successes are things I can look back and be proud of, and say, "Cool, look what I did!" It sure beats the heck out of thinking back on all the television I might have watched.
I'd rather keep trying to live the dream.
Labels: Indie Evangelism
Monday, June 12, 2006
DDO Flies Solo - Kinda
So there's a small hoopla about Dungeons & Dragons Online (DDO) becoming more "solo-friendly." There's a new difficulty level getting added to quests in the harbor area (the "lowbie" quest area) for "solo" difficulty.
I'm sure a lot of this is to combat the (correct) perception that DDO is "solo unfriendly." The group dynamic is what makes many MMORPGs fun. But nobody likes to go to a world feeling he's going to be forced together with complete strangers upon whom his success is dependent. The chance to meet new people is rarely a motivator for me to start up an MMO. If there's no existing friends online (whom you may have met being forced to group with complete strangers at some point), folks often just log in to hang out and solo.
Sorta like playing a single-player game like Oblivion. Or Cute Knight. Or Aveyond. (Plug plug).
So why bother playing a "Massively Multiplayer" online game if you are just going after what is effectively a single-player experience? I had a tough time getting my brain around this in my early EverQuest days, but the simple fact that other people are there sharing the same imaginary world with you makes it far more real (and enjoyable). Plus, most soloists I know want the OPTION to play with other people when the mood strikes them. And they enjoy the social opportunities a Massively Multiplayer world offers in the form of chatting, trading, and so forth.
My friends and I have been playing DDO since the "head start" days. Our guild is one of the "founding guilds" on our server (Khyber). We've even got our name and original membership on the founding stone in the harbor. Go us. But we play DDO very differently from most people. We play it a lot like we play Neverwinter Nights. We get together once a week at a pre-arranged time once a week, hit a few quests, and then call it a night. Sometimes we have a stranger join the group if we have less than six people. DDO is GREAT for playing this way. The quest areas are very close together so there's no half-hour traveling that has to be done in order for us to play together (our bane in our EverQuest days). We pop in, and within five minutes of everyone arriving, we are kicking hobgoblin butt.
While the way that we play the game sounds like the 'optimal' way to play DDO, does it really foster longevity in a subscription-based game? We've already had people drop out of active play from our early days the first couple of weeks. I don't know if they've cancelled their subscriptions yet or are still on the fence. But we're down to the point where we only have 5-7 people show up a night. Having 7 is frustrating because DDO only supports 6 players in a group, and tends to be a de-motivator as we split up into two parties.
The way we play, we're really not part of the larger server community (if there is one... judging by the forums I believe there is one, but I rarely see it in-game). So if more of our gang drop out, there's no motivation for anyone else to stay.
I really do like the fact that DDO plays "differently" from the other MMOs out there (many of which might as well be called "WoWWs" or "World of Warcraft Wannabes," though many began life as EverQuest wannabes). But there's some Darwinistic principles at work with subscription-based MMOs that can't be ignored. People come for the content, but stay for the community. Right now it seems (from my very uninformed perspective) that DDO is having a little bit of trouble with both.
I'm still rooting for it.
Sunday, June 11, 2006
Ways to Fake More Believable AI
And now moving 180 degrees from the original post of complex simulation of an ecosystem and characters in a world... here's a bunch of ideas on how to fake it. Some of these were taken from a CGDC lecture from many years ago about using Deception in Game Design. Sorry, I haven't found proceedings for that lecture or anything else other than my decade-old notes, so any resemblance to what the forgotten lecturer spoke on is purely coincidental.
#1 - Swap Cause and Effect
Our brains are wired to recognize causality. It's critical to our survival. We experience pain when touching a hot stove, and our brains hastily lay in the neural pathways that equate the stove to dangerous pain. In fact, if no causality exists, we'll often make up our own in a vain effort to order the universe and make it more predictable than it is. That is the foundation of superstition.
So one powerful trick is to swap cause and effect. This is well-used (and often sloppily implemented) in computer role-playing games. For example, an NPC might apparently perceive danger, and warn the player. From the player's perspective (the only one that matters), the NPC was being smart (and believable) by recognizing that there was danger approaching. But really, the causality was backwards - the warning effectively triggered the danger to appear.
#2 - Limit Interaction
Interactive Games have everything that movies, books, recorded audio, and comics have all rolled into one package. So if games have all the power of these other artistic media, why are we still struggling with cardboard characters?
It's because it is interactive. Once you let the player poke around your carefully crafted world, the illusion comes apart. TV sets only resembles a real world when carefully lit and filmed at very specific angles, edited to make it contiguous. The characters don't have to be subjected to random interruptions from the audience and unscripted things happening on the set. But that's what games are all about.
One way to work around this is to limit interactions. You see this in the almost stereotypical "conversation trees" in RPGs and adventure games - the player has a very limited palette of things he can say to the AI characters. The player may not even have the option of attacking a "friendly" character, thereby preventing some game-destroying events from taking place.
Face it, the game is going to have limitations one way or the other. You may as well put it on the UI side where players can ignore it.
#3 - Interweave Scripted and Random Behaviors
One of the clearest signs that a character is computer controlled is purely deterministic behavior. Throwing a little bit of unpredictability into their behaviors will keep the player on his toes.
When we did Twisted Metal, the little bit of randomness that I through into the AI attacks convinced some players that the AI cars were actually attacking each other. They weren't, really (though at one point they were), but it created a more compelling illusion for the players. They loved the feeling that they were in a true free-for-all.
#4 - Force Decisions
If you are going to use this, use it sparingly, because there's a good chance players WILL figure it out. With this technique, you pretend to offer multiple paths, but they both converge on the same path. Players WILL figure this out, though, and it will annoy them.
#5 False Causality
This is a little trickier than #1 - but basically you hint that some event occuring now is somehow linked to some past event or decision... where really none exist.
For an example - take the "Arch Enemy" scenario from Daggerfall. Now imagine if this random event hinted about something like, "You killed my brother in the dungeon X," pulling X from a random list of dungeons the player has visited. The player may be wracking his brain trying to remember what he killed in that dungeon and how it could have led to this turn of events. It's a nasty little trick, but it could work.
#6 - Interweave a Non-Interactive Storyline With the Interactive One
This is usually implemented by the old "doling out the backstory" trick - as the player goes through the game, he encounters bits of a secondary story (usually one occuring in the past) that he has no influence over. But through this, certain characters come alive - which helps make up for their robotic reactions when the player finally encounters them in-game (if he ever does: In the System Shock games, the characters are long dead when the player encounters pieces of their stories).
Labels: Game Design
Saturday, June 10, 2006
Elements That Make More Believable AI
I attended a GDC session a few (read: MANY, as it was called CGDC back then) talking about using Deception in Game Design. I still have a bunch of notes from that session, though the context is now hopelessly muddled with my own experiences and ideas. One of the parts that stood out was a list of things to do to make AI characters more believable in a game.
Since I've been talking about that a bit (it's been a little bit of a holy grail for me, since High School), and it was the topic of Raph Koster's blog I referenced yesterday, I thought I'd bring up some of the points from that lecture and a few of my own thoughts on identifying elements that make more believable AI characters in games.
Software Sucks at Simulating Humans
There are many, many problems in a game universe that are "very hard" to solve with computer software. Simulating people in a general situation is one of them. We still haven't made a program that can pass the generalized Turing Test (and I really don't forsee us doing so in my lifetime), so creating truly believable AND fully interactive characters in-game is still an impossibility.
In fact, it seems the more realistic you make them, the more their flaws stand and make them less believable. There's a difference between realistic and believable. Slinging a fireball is not realistic. But if you do it right in a fantasy game, it's entirely believable. The point is not to make games (or characters) more realistic, but more believable.
#1 - Give The AI Perception
Apparently this is the most important. This comes down to letting the AI recognize what's going on around it. I think this goes a little bit beyond just perceiving, but actually making inferences as to what is happening. This is as simple as the AI noticing that the player is trying to steal from them. Or as complex as the AI trying to infer intention out of the player's actions, or to try and figure out WHY certain things are happening.
#2 - Give the AI Emotion
The next most powerful way of making believable AI is to give them the appearance of emotion. Again - this can be as simple as getting them mad at you if you try and steal from them. Or it can be infinitely more complex. But our brains respond so well to perception of emotion that we will attribute emotion when none is there to inanimate objects.
#3 - Give the AI Memory
This is sort of a subset of perception - but giving the player a memory of past interactions with the player is a powerful tool for making them seem more 'believable.' Specifics are better than generalities here. If the AI won't trust you (emotion) because it remembers (memory) that you tried to steal a pot from them (perception), you've got something close to a believable character in the game.
Another way to extend this even further is to have the AI communicate with each other about events - particularly those involving the player. Now, it's pretty common these days in RPGs to have non-player characters (NPC's, AI-Controlled characters) parrot back major plot events that the player triggered or performed. This is cool and all, but it feels artificial (especially when people in far-off cities seem to know all about it the moment it happens). But having the AI characters talk about little incidental gossipy stuff - perhaps even something that the player only witnessed - is even cooler.
#4 - Give the AI Some Kind of Personality Quirk
This wasn't part of the lecture, but this is something I'm interjecting. The human mind loves to categorize things, and it takes very little for a person to be pigeonholed in the minds of others. Just think back on your High School experiences for endless examples. One little sentence was all it could take for someone to get classified as a geek, or a snob, or a ditz. If you give your AI characters just one small but noticeable quirk, it is often enough to make them stand out and for the player to attribute all kinds of emotion and subtext to conversations where none really existed.
As a "ferinstance," I'm gonna draw upon Oblivion again, since I've been playing it and it's fresh in my mind. There's a dark-elf alchemist in Skingrad who, as part of a passing conversation, asks if you know the penalty for necrophilia in this country. If you ask, "Is it a first offense," she says, "Let's say.... no." Well, that made that character come alive... she's a scary-weird lady, but in spite of that, I find myself looking forward to doing business with her, because she's unique and interesting. That's all it took.
The Player's Perception Is Everything
As mentioned in the last post, the player's perception is everything. Doing a good job of these four items is a tall order, even going to great lengths implementing Raph Koster's full ecological and AI models. And I'd still like to try something like that. But there are also some ways of faking it that will usually get you a lot more mileage for a lot less effort. Which was actually the entire POINT of the GDC lecture - how to make the game feel more realistic by faking it more.
Labels: Game Design
Friday, June 09, 2006
More Interesting AI
Raph Koster has posted a GOLD MINE of information on the ecological / economic systems of Ultima Online (see part 1, part 2, and part 3), and a discussion on the "dumbing down" of NPCS in MMORPGs.
Raph's comments go on how these sophisticated plans for Ultima Online and Star Wars Galaxies were eventually deep-sixed in favor of maintainability and simplicity (not to mention catering to players who value predictability). Definitely great goals, I admit. But it's sad that there have been so many missed opportunities - sacrificing the potential for greatness for the merely adequate.
I've been on both sides of that fence. I remember arguing against the complex, hard-to-maintain physics system in Jet Moto. But that was partly because the physics for the player's bike was so expensive that it left me with no cycles left for doing AI, Physics, and Collision Detection for the 19 OTHER bikes in the game. But that's another story...
The one thing these deep, detailed, UGLY simulations have is what Noah Falstein refers to as Emergent Complexity --- which means Emergent Gameplay. You can end up with a lot of great features and playability that occur "for free" as a result of the interactions between these competing systems beneath the game. But you also end up with a lot of unintended features (bugs) the same way, which are really scary-hard to track down and fix. It's especially scary to console developers, or MMO developers who live in terror that something unforseen will throw the entire game balance out of whack.
Perception IS Reality In Games
There's a point Raph brought up in the Ecology articles that is absolutely critical, though. And that is that it's the player's perception that is key. If the player doesn't see it, it didn't happen. Most of the time. It doesn't matter that the dragon appeared near town because it was hungry and was responding to a complex chain of events, or because some script told it to spawn there. From the player's perspective, it's the same thing. Unless he's somehow privy to the causality of the dragon showing up.
For example: I'm playing Oblivion. When I meet a stranger for the first time in that game, I have noticed that they don't all start with middle-of-the-road opinions of me. Some start disliking me, and some start liking me. Sometimes the reason why is obvious - they may be a member of a guild I belong to, for example. But much of the time, I don't know how their initial attitude begins.
Now, this could be the result of some complex set of relationships. Or it could be a random dice roll. Or some setting they scripted into the game initially (maybe this is a person who's not supposed to like ANYONE). The thing is, I DON'T KNOW and I have no in-game way to find out. There are no conversation options to find out how they feel about other characters in the game, too see if I honked off a close friend of theirs in another town. So if these different starting-opinions actually are a result of some deep, detailed behavioral model, Bethesda wasted their time developing it. I can't tell the difference.
However, if (as a game developer) you give the player some visibility into that model, and some ability (and incentive) to mess with those parameters, you can keep many players entertained for hours and hours, and stun them with your advanced, interesting AI. Just look at how many people enjoyed playing The Sims just to mess with their sims' heads and get them into really twisted relationships.
That's not saying that you should lay bare the entire guts of your simulation. But exposing some of that causality is important. At the very least, give some strong hints (remembering that for the most part, players do not get 'subtle'.)
Raph, in his articles, notes the problems with this. How do you expose these sorts of things to the players? And how do you give the AI the perception and understanding to see what kind of changes are happening in their world that would change their reactions? And then how do you turn that into entertaining gameplay?
Or as Raph puts explains it, how do you get the farmer to turn the fact that rabbits really are eating his crops into a rabbit-hunting mission for the player?
Okay. I've got an alternative point-of-view on this based on an old CGDC talk that I'll have to share later.
Labels: Game Design
Thursday, June 08, 2006
Thanks For the Pizza!
Wow. What a difference a couple of days can make.
Blogger's been kind of on the fritz, and our webhost decided to migrate machines without, you know, TELLING us. I guess they figured we wouldn't notice when http://www.rampantgames.com went down and didn't come back. So things have been... quiet... for a couple of days. However, the problems should now be fixed and everything back-to-normal.
TGB Final Release Delayed
Speaking of fixed, the big news on the indie game development front is that in light of some of the issues and bugs folks were having with Torque 2D Game Builder with the last release candidate, GarageGames decided to delay the release of the final version AND extend the Early Adopter pricing a few days. While I know this was a painful decision for GarageGames and the overworked, underpaid TGB dev team over there, the response amongst the community has been very positive, and GG team members have stated that they felt strongly that this was THE RIGHT THING TO DO.
I think this speaks volumes about GarageGames' commitment to the quality of this product. And in the meantime, they have released RC2 for those TGB owners to sink their teeth into. So it's really nothing but good for their customers.
Void War Pizza Party
Back when I was developing Void War (wait, that ever ENDED? How come nobody told me?), we had no idea what making or selling indie games would be like. I told everyone that if it at least made enough to pay for itself and to fund a pizza party for everyone involved, we'd call it a success. We had fun doing it, and we had pizza. What's not to like?
Well, it did. It took a while, but it did, and so Tuesday night we invited the dev team to a pizza party. Well, at least those who live in the local area. While I briefly considered sending a slice via FED-EX to the remote guys, the level of toxicity on the receiving end might be enough to make it considered a terrorist attack, so I nixed that idea.
Yes, it was a terrible way to re-invest that money. But I made a promise, and wanted to keep it. It was a good time, and a good way to tell everyone thank you for the work they put into the game.
And an even bigger Thank You to you folks who purchased Void War and made it possible. (And I'm gonna single out Chris specifically and embarass him, because he told us to have a slice on him when he bought the game! You Rock!) I am very proud of what we accomplished with Void War. As I've said before - there's an incredible elation and validation I experience when people play this game and like it enough to shell out their hard-earned cash for it. It's a whole Sally-Field-Winning-the-Oscar kinda feeling.
You guys rock. Thanks for the pizza!
And with that, I am back to work on the next game...
Wednesday, June 07, 2006
Building the Perfect Villain
I've had some discussions this week in an email list about villains, and what makes a "good" villain in a story (be it a movie, videogame, dice-and-paper RPG, or whatnot). I think this was brought about by Wizard magazine's top 100 villains list, and it's apparent lack of either Mr. Morden or Alfred Bestor from Babylon 5 in the list!
I've had a couple of the villains from my dice-and-paper roleplaying game campaigns that have been really successful, but it's hard to bottle it. A lot of it depends on your players not slicing and dicing the villain into oblivion before he's done monologing - and giving him a chance to survive to be a recurring bad guy. But for whatever purpose you wanna make one - here's some suggestions for making a villain that your audience or players will love to hate:
#1 - He should appear more than once.
If the good guys blow the villain up the moment they meet him, he obviously won't make a lasting impression. It's extremely helpful for evil to have an actual name and face when the good guys go gunning for him in the final act / level. Earlier appearances could be before the protagonists realized that he really was the villain. When you find out that the kindly old lady who served you tea is really the criminal mastermind that ordered your parents' murder, it's way more effective.
Examples: Darth Vader; Rene Belloq in Raiders of the Lost Ark; most comic-book villains (they keep appearing again and again)
#2 - He should have a Presence throughout the story.
Even when the villain doesn't make a personal appearance, the protagonists should still perceive and FEEL his influence. Notes or recordings from the villain, or minions doing his bidding. And people should TALK about him. Not just what he's doing - the villain himself, personally. This is one more way of making the villain something greater than just "the final boss" when
Examples: Sauron in Lord of the Rings; the Cigarette-Smoking Man in X-Files; Pennywise the Clown in Stephen King's IT.
#3 - He should be or feel HUMAN
Not that the villain necessarily has to BE a human - he could be an android from Altair XIX as far as I care. But he should have some spark of humanity - a trace of weakness and / or personality in him that people can identify with.
Examples: Al Bestor in Babylon 5; Doc Ock in Spiderman 2 (the movie).
#4 - He should have a believable motivation
Bad guys don't just do evil because it's not good. They should have some purpose - ideally, a purpose that the audience / players can identify with. Maybe he just takes it too far. Get to the source, the human NEED, for the villain. WHY does he want to take over the world?
Examples: Magneto in the X-Men movies; Marshal Gerard in The Fugitive.
#5 - He should have some kind of pre-existing link to the protagonist
The best villains aren't enemies of the hero(es) by chance - the most drama comes from the feeling that this head-on collision has been destined for a long time. This works really well if the relationship was formerly one of friendship, but some betrayal split them apart.
Examples: Lex Luthor in the TV show "Smallville;" Gollum in Lord of the Rings (he's the former owner of the ring).
Tuesday, June 06, 2006
Game Moment #7 - Forbidden Forest
As I was creating the index to the "Game Moments" articles, I discovered, much to my chagrin, that There Was No Seven. So I'm now rectifying the matter - here is the legendary lost Game Moments Number Seven. It's a classic game, now in Technicolor! -- Jay
My best friend from Junior High School through pretty much the end of public education was a fellow geek named Kevin McCarthy. Though we went to the same school (Eugene Burrows Junior High, in Maryland), we lived pretty far apart. He lived out in the boonies of Accokeek, MD - a place with large homes, large properties, and large potholes in the roads. We spent nearly every weekend together - which generally meant we ended up alternating at who's house we spent the weekend, as we lived too far apart to make trips back and forth an insignificant event.
We'd spend our time watching really horrible fantasy movies (they were all horrible sub-"B" movies back then), playing Dungeons & Dragons, spending our money at the arcade, and hang out with other friends in the area. And we'd play videogames on our home systems. Kevin and his twin brother Corey had an Atari.
Eventually, I got a Commodore 64. Right before one of Kevin's visit I managed to get my hands on a couple of new games. One was Summer Games, by Epyx. The other was a little quirky hard-to-find title that everyone seemed to be talking about: A gem called "Forbidden Forest".
Entering the Forest
As we typically did, Kevin and I stayed up late playing multiplayer or hotseat games. We gave Summer Games a good workout, though as we got tired and punchy we derived the most amusement out of making the high-divers do belly flops. Then, just before calling it a night (or so we thought), we booted up Forbidden Forest.
We were greeted by some eerie, cool music and a cinematic opening that wasn't too that wasn't too common in games at the time. It showed a forested scene with something flying in the background. As the flying creature came closer, it filled a large chunk of the screen (it's in 3D!!!!!) and it was clearly a DRAGON. So things were getting interesting.
The graphics were blocky and not exactly even state-of-the-art for the time period. But it was one of the worlds first 3D "third-person shooters" for computers (if not THE FIRST). You controlled this lone archer (we assumed he was an elf) in some forest, atop a hilltop. You could run left or right - we always assumed that it was in a circle, because you'd eventually come to the same spot. The forest had LANDMARKS - like an old shack that I always wanted to walk to, but it was forever just out of reach due to the linearity of your avatar's movement. There were certain spots with better visibility that I favored for dragon-hunting.
But unlike other "side scrollers," your character could fire into the screen, or off at an angle, down the hill and deep into he forest. You had to stand still in order to fire your bow, which made you vulnerable for a critical second or so. Some monsters would spawn nearby in the forest, charging you at an angle from the trees. Others would appear further out, deeper in the forest and down the hill. You'd get these giant tree-jumping frog things that would leap up off on the horizon as tiny, untouchable things.... but you knew that in a couple of seconds they'd be landing on your head. And the dragon! He'd appear a tiny little thing in the distance - but if you didn't kill him as he approached, you'd be running for your life as he'd come at you from the side breathing fireballs. The only way to avoid certain death was to change direction suddenly as he was chasing you, running beneath and behind him as he flew past.
The cool thing about the 3D experience of this game was the SCALE of some of these monsters - something that has been lost in most modern 3D games (except those wonderful MMORPGs, where collossal dragons still live). These monsters appeared off in the distance... and even dozens of yards away from you they appeared much larger on-screen than your little elven archer. When they did get close, you could easily see just how epic these things were. The giant snake's HEAD was as big as your archer. Your little dude, all alone with his bow and limited supply of arrows, was facing down a forest full of Godzilla-sized monstrosities.
The monsters came in waves. In one wave you had to kill swarms of spiders that would emerge in ones and twos. In another, you'd have to face down a single (but nasty) dragon. In another, hordes of giant jumping tree-frog-thingies would be leaping from somewhere in the distance to rain down on you. In another - one of my favorites - a gigantic specter out in the distance was summoning skeletons to attack you. You could only clear out that level by shooting the specter right inside his hood into his unseen face, after which he'd let out a creepy electronic wail and discorporate.
And after every level, your archer would do a funky dance to victory music. Sorta like they do in the Final Fantasy games, but looking more like an epileptic seizure.
It made for an incredibly compelling and immersive experience. At least circa 1983 or so. It was so immersive that Kevin and I didn't notice that the late-night gaming sessions had gone much much later than expected.
Dark Passage Into Night
One other cool immersive element of Forbidden Forest was that time would pass during the game. Day would fade into twilight, twilight into night, the stars would come out, and the moon would slowly cross the sky. The trees would lose their color, becoming more grey-and-blue in the moonlight. And inevitably, the final, climactic encounter would happen during the darkest night, when an mysterious storm would come through, lighting up the sky with pixellated lightning bolts.
The final boss was the demon lord Demogorgon. He'd lurk out on the distance - a shape towering over the trees. He'd get a little bit closer when you stood still. In the darkness, you could almost never see him - you could only catch glimpses of his sillhouette as he'd blot out the stars behind him. Occasionally he'd be illuminated by a flash of lightning - but only for a brief moment. Every time you stopped running (to take a shot, for example), he'd stay in place only a few brief moments, and then he'd teleport away. But each time, he'd creep a little bit closer. You could run all night long... but eventually, you'd have to stop. And that's when he'd get you. His gigantic head would descend, filling half the screen, and supposedly devour you. And that was the end.
We never did manage to kill Demogorgon that night, though we tried. Repeatedly. Endless numbers of dragons and skeletons and spiders were dispatched on our way to battle the ultimate evil, but every time we got there the demon lord would defeat us. There was a trick to it, I later discovered. The up and down joystick movement controlled the arc of the arrow, and you had to hit him just right. All of the other monsters could be killed without such fine control, but Demogorgon required more.
We tried everything everything else that night. At one point we tried running for a long time, watching as the sky turned yet darker and the stars dissapeared in what was perhaps storm clouds, and then re-emerged. We hoped that if we battled Demogorgon until morning that the early morning sunlight would make him easier to see and vulnerable.
And Then The Dawn Came
The dawn never came to Forbidden Forest that night. Once Demogorgon appeared, the land was bathed in eternal night. After enough time, the stars dissapeared, perhaps covered by thick stormclouds (the lightning had to come from somewhere, right?)
But after many, many times being devoured by Demogorgon, the sun came in through the window of the family room, dispelling the magic of the all-night battle against the forces of evil. With the sunlight, the fatigue from playing this game (and others) all night long hit us like the proverbial ton of bricks.
We were exhausted. It was time to crash, for a few hours anyway. The Ultimate Evil would be waiting for us on another night.
Sunday, June 04, 2006
Torque 2D Game Builder Quick Review
Taking the Plunge Into the Second Dimension!
UPDATE (6-8-06): Due to number of issues that cropped up in RC1 of Torque 2D Game Builder, GarageGames announced Wednesday that they would be pushing back the final release (and the price increase) to address bugs - many of which I brought up in this "First-Time User Experience" review. As of right now, RC2 is available, which should be much more stable. I haven't tried it yet.
I realize that this was a dissapointing event for GarageGames and the TGB devepment team that has been working around-the-clock on this release, but I have heard from these same, overworked developers that they felt strongly that it was the right thing to do. Massive props to GG! I think this speaks highly of their commitment to making TGB a success.
The "Torque Game Builder" (formally known as Torque 2D) is losing it's "Early Adapter" status and is going up in price in a couple of days (June 7). Well, kinda. It's still going to be $100 for a license for indies for the "binary" version without source code. But the price is going to go up to $250 for the indie license with the full source code.
I'd been considering getting TGB for a few months, mainly for rapid prototyping of ideas. When they announced that it was now capable of rendering 3D DTS models, I was sold, but I still hesitated to purchase it because I didn't really need it *right now*. The impending price increase spurred me into action. If you are like me, you have two more days to get it at the reduced price point, after which the price goes up SIGNIFICANTLY if you want to have the source code version. (And I'm gonna say right now - YOU DO).
The Pricing Dilemma
As far as the price is concerned - I think GarageGames has kinda painted itself into a corner. Their initial objective for the Torque Game Engine (back when it was under a different name) was to make an industrial-strength 3D, networked game engine available to ANYONE who wanted it. The $100 price point meant that even a 13-year old kid with dreams of becoming a l33t game designer could mow lawns for a month and afford the engine. This was a great, idealistic goal, and I certainly applaud them for it.
But the problem is... the game engine is available to ANYONE who wants it.
An experience game developer who has worked on 3D or networking engine development knows what a pain in the keister it is to build and maintain something of this scale, and intuitively understands that the bargain-basement price of Torque comes with some concessions. Concessions like less-than-stellar documentation, no one-on-one personal tech support, and so forth. Now, I have not personally worked with a major third-party 3D engine before, but the stories I have heard is that the level of customer support you get for a $500,000+Royalties engine isn't a whole lot better than that.
But then you've got that thirteen-year-old who's been mowing lawns for a MONTH to purchase this game engine. He doesn't have the same perspective - $100 is a lot of money, and he's got plans for making the next Halo. Once he gets past the novelty of loading in his own models into an empty 3D world, he wants to know, "What do I do next?" He needs mentoring and guidance for this monstrosity he's purchased, and nobody's giving it to him. He constantly demands customer service and training to use this expensive piece of software. When he doesn't get it, he gets very frustrated. And when he does get it, he's soaking up resources that could be spent on getting the next revision done.
I believe that what GarageGames is doing with this tiered pricing structure for their Game Builder product is to try and deliver something "safe" to this audience. If you are willing to pay an extra $150 for source code, then you understand the value of it and aren't afraid to dig in and get your hands dirty. The $100 product will take care of the "entry-level" people who just want to tinker.
That's my conjecture, at least. I don't pretend to understand what the minds at GarageGames are actually thinking at this time. But that logic makes sense to me.
What Does It Get You?
But then comes the real question: Is it worth the $100 / $250 price tag for a small indie developer on a tight budget, especially when there are competitive 2D game development options out there like PopCap's free framework (well, free, unless you are selling a game using the built-in audio options, in which case you owe SOMEONE a license fee), SDL (free, open-source), and PTK?
I've only had a couple of days to play with the engine, so I do not have a definitive answer. But here's what I've come up with so far:
The Torque Game Builder is, at its heart, a scripting language for creating 2D games. But it also comes with a lot of tools to make things a little less painful for game developers. Going through the included "Basic Tutorial," you can throw together a playable 2D shooter in a matter of HOURS through the built-in tools. However, what TGB does NOT provide is a "click and play" level of functionality that completely isolates you from the need to code. If you are an artist with no desire to touch the programming side of things, the Torque Game Builder's tools won't magically build your game for you.
However, what the tools DO provide is a very streamlined, fast interface to putting together levels, UI's, and so forth. Getting pictures up on the screen and rudimentary behaviors implemented is extremely quick - or it least it should be. Once some bugs are ironed out and you know what you are doing. Then begins the real work of creating quality content and code.
Getting My Hands Dirty
From my own experience, I started out trying to put together a very basic top-down shooter - the type I enjoyed in the arcades as a kid. I found I had archived some free "SHMUP" (Shoot-Em-Up) 2D space ship art by Nauris Krauze and Craig Fortune. I also had a bunch of old art resources from Void War that I figured I could re-apply to this quick-and-dirty project. I wanted to bring in a 3D model to see how hard it would be to integrate some 3D elements into a 2D game.
Installation didn't go as nicely as I'd have liked. Choosing something other than the default directory resulted in a failed installation. Actually, everything still WORKS, but the desktop shortcuts and the uninstaller never made it. While not a significant issue by any stretch, it does hurt my confidence a bit. But I'm evaluating a release candidate, NOT a final version, and I know from painful experience how these things happen.
My project was based heavily on the "Basic Tutorial," but with some pretty substantial differences. My very first attempt was stymied within an hour. As soon as I had to start creating new script files, I opened up Codeweaver (TorqueDev) and started putting things together. Inexplicably, the next time I tried to load my project into the editor, TGB froze on load and would simply not return. I had to shut it down with ALT-F4 and see the "program is not responding" message. I don't know what I did that caused it, but nothing I could do could fix it. So I ended up having to create a new project.
Starting over from scratch was a pain, but I was able to replicate the previous hour's work in about ten minutes. So that may demonstrate how much more productivity the toolset can provide once you have gotten accustomed to it. I had the player ship, a starfield background in another layer, and an enemy ship waiting off-screen. The player ship was controllable with arrow keys (a quick look-up into another part of the reference documentation revealed that the strings used to detect cursor-control arrow keypresses were, mysteriously, "up," "down," "left," and "right." Go figure!)
One frustrating problem I discovered is that the main T2D tool doesn't recognize changes that have been made to code outside of the editor. I had to get into the habit of leaving the editor shut down, only bringing it up when I really had to. This is unfortunate, as the editor looks like it's trying to become it's own "mini-IDE," left open constantly.
A Taste of 3D
I was still using a 2D sprite for the player ship control at this point, so now I decided to go exotic. Hunting down the old Milkshape model for the Osprey in Void War, I converted it to DTS format. The documentation that comes with TGB says VERY LITTLE about bringing in 3D objects, but a hunt on the "Torque Developer Network" revealed a basic script-based way to make it work. I was going outside the tools, but it was still a pretty trivial scripting job. Ten minutes after finding out this critical information, I was able to replace a 2D sprite with a 3D object, and get it scaled and rotated into position.
Moving the 3D ship left and right was fun, but I wanted to have it bank as it moved left and right. A little more digging revealed the "setShapeAngularVelocity" command, and I thought I was home free. There was a small trick - I needed to be able to switch to banking at a different angle at a moment's notice, before it had completed it's full bank. All it would really take is doing a comparison of the fighter ship's current bank with it's desired bank, and calculate the amount of time it would take to turn the remaining amount, and which direction the new bank should take place.
This is where I discovered that the function that reads the 3D Shape's rotation in does NOT take into consideration accumulated changes from angular velocity. So reading in the rotations just returned the original starting rotation. I posted a message on the bulletin boards to see if anyone had an answer to my query. Nobody did.
Undaunted, I decided to fire up the SOURCE CODE and see what I could find. Sure enough, the ROTATION values were an euler vector being returned by the engine are really just storage - the actual rotation matrix is being calculated by a quaternion class which is being directly modified by angular velocity. But the changes weren't being reflected back in the the euler rotation vector. My initial mathematical hack to eulerize the resulting matrix and stuff those values back into the euler vector didn't work, so I came up with an even less elegant hack. But it worked. A couple of hours later, I was able to read the cumulative changes from Angular Velocity.
Go me! But this required a recompile of the source code - something that would not have been available to someone who had the Binary license.
After that, everything else pretty much followed the tutorial without a big hitch. Getting the enemy ships to fly past the player along random, mostly-straight paths was easy. Getting collision woking the player's laser shot was a little tricky, simply because I'd left in a statement disallowing callbacks. Once I found and fixed that, things came together quickly.
Working with particle systems using the built-in particle engine editor was a little frustrating, but I was operating it cold, without having read the fine manual (or PDF document) beforehand. It is NOT an intuitive tool.
The game is not yet done, but it's I was fairly impressed with what could be thrown together by a beginner to the tools in a matter of about six hours.
Pros and Cons
So after an admittednly limited evaluation period, here are some of my thoughts on the Pros and Cons of the Torque Game Builder:
* Inclusion of 3D model support - so you can have an eye-pleasing mixture of 2D and 3D elements in your game
* A nice suite of tools to assist in rapid development and prototyping
* Underlying engine is mature
* Built-in Multiplayer / internet game support
* Reasonably complete documentation and tutorials included with the installation
* Strong community support
* High Performance
* Very pretty particle engine
* Even the RC1 release still feels buggy - IMO, it's not ready for a full release yet (though it's close).
* Inadequate documentation and functionality on the 3D Shape class
* Engine requires 3D hardware, limiting potential market (but not by much, these days)
* Particle Editor was non-intuitive and kept resetting the scale of the graphs on me.
If you get the Torque 2D Game Builder right now for $100 (or $80 if you are a TGE owner), and you plan on creating and selling 2D games in the future, it is my feeling that the TGB is another 'steal'. It's dirt-cheap, it offers a much gentler learning curve than it's older brother, the Torque Game Engine. And I see the inclusion of the new development tools as a speeding up the development process and helping newbies and seasoned vets alike get over those awkward early prototyping stages and into the hardcore dev stages.
I personally do not feel the TGB tools are quite yet "ready for prime-time." I experienced too many bugs in my initial experience to feel comfortable with the tools "as-is." There are also some quirks, like having to restart the main TGB tool anytime you modify the scripts. It's certainly possible that they may have these worked out in the next few days, but I am a little concerned that RC1 feels a little too unstable still with such a short time-frame to release of an official version 1.0. That being said, even earlier versions of TGB have been used for commercial products already --- so this is not a show-stopper.
The "killer feature" for me was the integration of 3D models into the engine, but it seems like this feature is being downplayed right now. The missing functionality and lack of included documentation or direct tool support certainly makes it look like a second-class citizen. Reading the correct rotations for the model was a pain and required a recompile, but simply adding the model to the game was a piece of cake even without tool support.
As a "power user," I have a difficult time recommending the "Binary Only" distribution. Sure, it's only $100... but will it provide all the power someone needs to build a full 2D game? I think so, but it's really hard to say at this point without diving much deeper into the engine. It is definitely a lot more accessible than the Torque Game Engine for a first-time game developer, and most competitive products that offer this layer of abstraction are getting kind of long in the tooth (such as DarkBasic). EVENTUALLY, if GarageGames continues to support this product (and there's no signs that they are going to stop), I think this will eventually be a a reasonable offering.
And the biggie - the $250 indie license for the full source code. Is it worth the extra $150 over the price of the binary? If they manage to clean up the list of outstanding bugs that remain from the last beta and release candidate, then I'd definitely give this the nod of approval. I'm very impressed with the speed at which I was able to go from being a near-total n00b* to getting something resembling a game up on the screen.
The $250 price tag is a bit steep if you are not serious about making a go at it with developing commercial products. If you are only going to be making freeware games or tinkering with projects to satisfy your own curiosity, you may be better off going with the Binary release, or experimenting with one of the free engines out there. But taken as an investment, I can't see how this wouldn't be money well-spent, and would pay for itself from the very first project with reduced development time.
* I do have a bit of experience with the TorqueScript language with TGE. While there are some different classes and utility functions to learn in TGB, the fundamentals of the language carry over very nicely, which eased my transition.
Thursday, June 01, 2006
Oblivion - the Flower Picking Simulator
So here I am - in the controversial game of Oblivion. It is so vile that the ESRB forced a re-rating of the game as to make it for Mature players only. And what is it about?
Well, in my game, it's about hopping and skipping through meadows picking flowers.
If you haven't played the game - I kid you not. The game covers vast, realistic outdoor areas, with plants scattered across miles of terrain. These plants can be harvested for their seeds, roots, leaves, and whatnot. These harvested plant parts can be sold at local alchemical shops, or you can use them yourself to create alchemical concoctions of your own.
My character class, determined early in the game from my tendency to hide when bad guys show up and strike from behind, is an ASSASSIN. That's right, a bloodthirsty, amoral killer assassin. One of his key skills, which needs to be increased through in-game practice, is alchemy. For making all those vile poisons to coat his arrows and knives with, of course. To get enough materials together for constant alchemy practice, I take the 'scenic route' from place to place so I can take time to ... pick flowers.
Another of the assassin's key abilities is Acrobatics, which is increased over time by hitting the jump key. So long as endurance doesn't run out, I find myself hopping around as I go from place to place to increase that ability.
Which means that as the vile, evil, bloodthirsty assassin, I am spending MUCH of my time hopping and skipping through meadows picking flowers. The very game mechanics and play balance of Oblivion ENCOURAGE THIS. For all assassins. If you play an assassin and want to make progress, the game pushes you to do exactly this sort of thing. Hop and skip through meadows picking flowers. For a large part of the game. I'm about 30th level now, and I'm STILL hopping and skipping through meadows picking flowers in-between quests.
Ayep. This, parents, this is the game you should be warned NOT to purchase for your sixteen-year-old son, because it would put dangerous thoughts into his head.
I don't really blame the ESRB. I mean, past the first Oblivion Gate you see all kinds of nasty gross things and corpses of people who have been tortured to death. That's borderline rated-M material right there. Like Diablo, you are journeying into Hell (or "Oblivion"), and so it's got to look kind of ... hellish. So even poor flower-collecting assassins have to deal with some dark, nightmarish imagery. No problem.
My game of Oblivion: The Flower-Picking Simulator might be VERY different from someone else's game of Oblivion: The Genocide. These big, open-ended games - especially roleplaying games, and even MORE especially moddable games - are more akin to a paint set and a canvas than a movie or book. A lot of the experience is what the user puts into it and wants to get out of it. That's the beauty of interactivity.
But I think this points out the ultimate futility of games ratings systems for being anything other than a VERY rough guideline for parents. But force of law in the recent epidemic of FUD-fueled legislation? Silly and stupid.
After all, how WOULD the ESRB rate, say, the Star Trek holodeck?