Frayed Knights Dev Diary: Stupid Is As Stupid Fights
The heart of any RPG is the combat system.

Right now, Frayed Knights is feeling kinda heartless. And who taught that skeleton to hold an axe like that, anyway? Yeesh!

This week I spent some time working on combat. Putting together menus, re-thinking the interface, and then re-thinking it again once I prototyped it and saw where it was going.

Analysis Paralysis
One challenge I've faced is sort of a low-grade "analysis paralysis" with respect to individual systems. I found myself sitting down at the computer and not really being too sure how to approach the problem. Where do I begin? Do I use Torque's built-in UI stuff for the interface, or try to take greater advantage of the TGB-added sprites for menus? If I can't nicely pick out which enemy I'm attacking by clicking on them (overlapping collision areas makes it tricky), how do I handle it?

The trick I should have learned by now (but it still slowed me a bit) is - after preliminary analysis and consideration is done - to just pick one way and do it. Modularize it as best as you can so it CAN be changed later without too much impact if you decide you took the wrong path. But like the quote says (many attribute it to General George S. Patton, but I heard he borrowed it from a civil war general):

"A good plan, violently executed today, is far and away better than a perfect plan next week."

Stupid Torque Tricks
Torque has UI controls called "GUI Bitmap Buttons" that are supposed to be pure bitmaps. You are supposed to have one for each state of the button (normal, disabled, hovered-over, and pressed). Now, in the event no such bitmap exists, the fallback behavior of the button is simply to display text.

I needed text you could click on in menus, and so the fallback behavior seemed to be about perfect for me. There was a problem, however. For some reason, GuiBitmapButtonCtrl doesn't respect its given profile, and keeps reverting back to GuiDefaultProfile.

That screws up my pretty little font and stuff, which irritates me. Now, a good and responsible programmer, with the source code to the engine, would hunt down this bug, kill it, and check in the changes back into HEAD and contribute to the community and stuff. Me? I just cheesed out and whipped up a work-around. When the menu first comes up, I call setProfile() to force it to my nicer display font & stuff. Now, this still doesn't solve the problem, as there is another bug I've run into a few times where the string doesn't respect case... I guess the engine is trying to re-use strings and isn't paying attention to differences in case. So instead of "Attack" (capital A) I get "attack". The same problem cropped up in last week's post where the NPC was labeled "ELF LADY" (all caps) - which isn't the string I passed in (only the E and the L are supposed to be capitalized). There is probably something boneheaded that I'm doing here, so if anybody knows how to fix this issue, please let me know.

Behind the Curtain
Though a lot of what I've been doing has been creating only semi-functional interfaces and stubs, I did spend some time this week getting the framework of combat handled. Combat works in a phased system, rather than pure turn-based. Every action takes a certain amount of time to complete. An "average" action takes 10 phases. Now, rather than having you delay that many phases to complete the action, I play with time a little bit and reverse the order of things: The action and its effects take place immediately, and the delay occurs afterwards as you recover or recoil from the action.

So, for example, if you rest (take a breather) to recover endurance, you will immediately gain back the endurance, but you will have to then wait 10 phases to take your next action. The time it takes for the 'recoil' may be dependent upon your character... one character may take 10 phases to swing a sword, but another may be able to do it in 8. So after 80 phases, the faster character will have had 10 attacks, and the slower character will have only had 8.

Combat just proceeds in this way, phase-by-phase. I have the basic pipeline in and more-or-less functional, but there's really nothing HAPPENING at this point. Combat ends after 40 phases (or when you hit the "C" button, which is also how you initiate combat right now). No attacks or damage take place (yet). But I have some of the core logic in tracking everyone involved in the fight and handling combat order in place.

Which means I think it will work, but I still have no idea whether or not it will be fun.

Monster Spawning
While I GUESS I could have had combat occur completely abstractly for testing purposes, without any monster visuals, I am a sucker for the shiny. I wanted to see monsters appear when I forced combat (for testing purposes) by pressing the "C" key. So I used the DrewFX Skeleton Pack along with the Tridinaut Medieval Weapons Pack, and created a little funtion to spawn an attacking monster for the combat code to use. As you can see from the screenshots, the two different packs aren't 100% compatible out-of-the-box. The skeleton can hold the weapons by its thumb - which could show great talent, but I'm not too thrilled with the idea. So I'm going to have to go in and fix them myself.

Unfortunately, very few content developers seem to support Blender formats in their content packs. Which confuses me. I mean, Blender is FREE guys... how much effort would it take? Well, okay, I know the answer to that one. Blender's import utilities are not exactly stellar, and do I expect any of these premium modeling packages to support export to a top open-source competitor? So I'm going to have to go through the painful process of importing them into Blender myself, and then fixing their mountpoints / origins and hope they export without losing crucial data.

Later.

The other thing this process brought up was just how I'm going to be handling creature spawning and the "abstract" method of handling positioning. How and where do the players encounter the monsters? I am trying to avoid dealing with complex pathfinding and collision issues with this game - we're talking quick-and-dirty here. What this is coming down to is a secondary set of data structures defining abstract pathing.

Constructor Madness
I also played around a little more with Torque Constructor (version 1.01) this weekend. Since it has been nearly 2 months since I last played with it, I had to re-learn everything. I had it crash on me once, and lock up on me once more. Still not quite ready for prime time. However, I note that version 1.02 is now up, so hopefully that'll be fixed up.

My assessment hasn't changed a whole lot from the last time I messed around with it. But this time I was actually trying to create something vaguely useful for the game. There's still a bit of a learning curve to figure out, but I am very, very fond of the ability to slice up brushes so easily. Maybe because that's how I'm used to working with Blender.

What's Up This Week
There's still some more functionality I want to get in place with combat.

Aside from that, this week will be spent working on the Traps & Locks minigame dialogs. Yes, after all my ranting about making more rogue-friendly RPGs, I figured I'd BETTER have an interesting rogue-oriented elements in the game.

If I have time, I'm going to throw in the save / load menus (non-functional). At that point, I'll have a crappy prototype of full game functionality.


(Vaguely) related thinking aloud... well, not aloud, I mean... bah, you get the idea...
* Making a Rogue-Friendly RPG part I: Rogues Get No Respect
* Frayed Knights Dev Diary: Getting Around In the World
* Frayed Knights Dev Diary: Background and High Concept
* Frayed Knights Website

Yo! Conference Happening In the Forum

Labels: Frayed Knights, Game Design, Roleplaying Games

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

 
Why Bother With Single-Player RPGs?
Over at ComputerAndVideoGames.com, Obsidian Entertainment CEO Feargus Urquhart talks about the danger to single-player RPGs posed by MMORPGs.

And I agree with him completely. I'll paraphrase his contention in my own terms: MMORPGs already have the "Wander aimlessly around a lifeless non-interactive world playing whack-a-mole with monster-shaped targets" genre pretty well sewn up, and made entertaining by the sheer power of multiplayer. So why would anybody want to do that in a single-player RPG when they can do it online with friends and get some kind of bragging rights in a whack-a-mole competition?

So he's pushing for more interactive single-player worlds. Worlds that respond to the player as a hero, instead of treating him as Generic Player # 29,371 that must not affect the status quo for the sake of the other thousands (or millions if you are talking WoW). Let the player kick over some anthills! Permanently change things! Mess around with the campaign world! Whatever.

To be honest, most recent western RPGs are pretty good in this respect (though they could always do better). I haven't played any of the Diablo-clones, and they like Diablo 2 might be pretty static. The "jRPGs" seem to be the worst in this respect, as much as I love 'em.


(Vaguely) related ravings:
* Are Graphics Really Killing Gameplay?
* The Rules of Roleplaying Games
* Making a Rogue-Friendly RPG (part I)
* RPG Design: Why Can't I Get Past the Stupid Door?

Read or Post Comments on the Forums

Labels: Game Design, Roleplaying Games

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

 
Why Bother With Single-Player RPGs?

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

 
Hey! You Got Your QA In My Programming!
Scruffy-Looking Cat Herder has an article entitled, "Skill Set Development" that discusses not only the need for separate QA and Development departments within a company with an IT division, but also the different skill sets.

For the most part, I'm in agreement. QA is a very different mindset from development, and it IS very hard to test your own code anything close to exhaustively. Whether or not it is useful for you to submit your software to a separate QA department (either internal or outsourced) really depends upon the cost of failure. If you are pushing out a small, internal application where failure might mean a loss of a few minutes and an irritated Customer Service rep, then you could certainly argue that it's not worth the effort. If failure means your company finds itself short a hundred thousand dollars in taxes at the end of the year, a pass or two by a dedicated QA team is probably warranted. If failure means your entire customer database can be compromised and personal information hijacked by a malicious external party, then the cost of failure could very well be your entire business.

He also goes on to claim that "developers are better off cultivating a perspective of getting their software out the door and testers are better off cultivating a perspective of preventing software from getting out the door until they cannot break it."

There's where I'll take some exception. My stint as a QA guy was actually as a weird hybrid position. I was an "Automated Testing Engineer" or something like that at Symantec. Basically, I wrote software to test software. The experience was incredibly valuable to me, as not only did I discover Python there, but I also learned to get into the QA mindset a little bit. That really helped open my eyes a bit more about "defensive coding" and learning to predict where failures are likely to occur in my own code. I think programmers who have a little QA angel (or devil) sitting on their shoulder warning them to protect their code against likely vectors of failure are going to write better code.

And based on some comments I got from some QA people testing my code at a later job, I think it worked. Though that could be chalked up just to the fact that I was a more grizzled veteran than some of the other coders.

As far as testing time is concerned, one solution is concurrently testing alongside development. This is a huge pain in the butt for developers, and I wouldn't want to get dogmatic about it, but having testing begin at the earliest possible state can not only save time, but can also help the developers get a better grasp of code quality and problem areas.


(Vaguely) related public display of ignorance:
* My Favorite Job Interviews
* No Excuse for IT Ignorance
* Programming Tip: Comment First
* My Worst Bug Ever

Read or Post Comments on the Forums! (All the cool kids are doing it...)

Labels: programming

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

 
How To Earn $8000 / Month By Making a Free Flash Game.
Wow. It is possible to earn six figures in annual income on a single game programmed in approximately one month. The trick is - you have to make a really popular Flash game. Which is about like catching lightning in a bottle. But GigaOM has an interview with Paul Preese, author of Desktop Tower Defense, which shows just what is possible by a solo programmer.

I was pointed in the direction of this game by community members here after I evangelized Flash Element Tower Defense a few months ago. Like most Tower Defense games, it's wonderfully addictive and fun. And it's free. Yet this free game is clearing $8000 / month for the developer, with 20 million pageviews per month.

Why am I wasting my time writing games in Torque, I wonder?

Oh, wait, right... the trick is writing the RIGHT game. There are zillions of Flash games out there right now (some that are even pretty good) that aren't earning diddley. Like all successful games , it is just a combination of a great game, the appropriate marketing, and good luck. But in the interview, Paul outlines several things he did to increase his odds and help make the game the success it has become:

#1 - Take a Well-Known Genre and Make It Better
Ouch. Once again, pure innovation doesn't seem to cut it. Paul borrowed from the popular Warcraft III mod, and even from Flash Element TD, and built on that solid foundation. But he didn't just create a "me, too" product - he added some new ideas of his own. So yes - there's definitely some innovation in there. Sometimes it doesn't take much.

#2 - Promote Through Web Aggregation Sites
I'd say promote through any means possible. But it is interesting to see that as word-of-mouth (and word-of-social-bookmarking) grew, its slow start began to snowball.

#3 - Profit Through Ad Revenue
Once you get up to 20 million pageviews per month, I guess Adsense begins to make some real money. Though he's also getting some direct advertising deals as well. He's probably making much more than he'd have made if he tried to sell his game for $5 or $15 a pop.

#4 - Keep the Budget Low
Paul thinks he can create a game the scale of Desktop TD every month. It costs him $130 a month in server fees. If the game had cost a quarter-million to make, it might never have become profitable.

So there you go. This is not a formula for success by any stretch --- but indies should take note and learn from each success. Congratulations to Paul Preese for not only a successful game, but a truly fun and entertaining game. And a tip o' the sombrero to Coding Horror for the link!


(Vaguely) related envy...
* Design: Picking Apart Flash Element TD
* Quick Strategy Games
* RPG In a Week
* Should I Become An Indie Game Developer?
* The Ten Commandments of Indie Game Developers
* 20 Ways to Make Money Making Indie Games
* How to Avoid Making Money Making Indie Games

Read or Post Comments on the Forum. Or Not!

Labels: Biz, Free Games

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

 
Indie RPG News, May 28, 2007
Those Indie RPG developers are at it again...

Nethergate: Resurrection
First off, RPGVault has a 3-page interview with Jeff Vogel about the new Nethergate remake, Nethergate: Resurrection. One small tidbit from the interview describes Vogel's company:

Jonric: For those who aren't familiar with Spiderweb Software, where is it located and how large is the team?

Jeff Vogel: We're based in Seattle, and we started out in 1994. We have three full-time employees. We had a tarantula mascot, but she passed last year.

Depths of Peril
Soldak has added new villains to their villains page; added imps, orcs, and zombies to their monster page, and added a new short story entitled, "Fire Scrape."


The Broken Hourglass
The Planewalker Team has put together a somewhat technical description of their "on-the-fly creature customization" system, which allows them to create anything from random encounters to highly tweaked single encounters. Anybody planning on modding The Broken Hourglass should take note, but it is also a nice bit of insight into the types of things that are being taken into consideration with this game.


Frayed Knights
Hey, how'd this get in here? Well, we've got sort of a monthly-summary up on GarageGames. This week I'm tackling the heart (and most complicated part) of the game, combat. To be followed up by the traps & locks mini-game. the save / load game menus, and the character sheet sub-panes (like the level-up dialog, personal inventory page, etc). Once that's done, we'll have Cycle #2 completed (I think). Cycle #1 was mainly the design document.


And that's it for this week. If you have any more news on indie RPGs that are in late-development (or from veteran indie teams), please let me know. I'm getting press-release type stuff from the Planewalked and Soldak guys regularly, which makes this really easy (hint, hint, indie devs....)


(Vaguely) related indie RPG lunacy!
* Beyond the Gate: Jason Compton on the Making of The Broken Hourglass
* News Bits on Upcoming Indie RPGs
* Frayed Knights: Background and High Concept
* Indie RPG Roundtable

Discussion on the Forums

Labels: Frayed Knights, Indie Evangelism, Indie RPG News, Roleplaying Games

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

 
RPG Design: What Am I Going To Do With All This Money?
There's a question I wish I had to ask in real life more often. Like, ever. Alas, I'm talking about fantasy worlds. RPGs, particularly. Both computer and table-top.

Heroes and their Treasures
While it may not be the final dramatic objective, the overarching mechanical goal in RPGs is to improve your characters' power. There are two means of doing this. The first is by increasing their inherent abilities, or internal improvement. The second, and even more significant in some games (particularly fantasy MMO's), is external improvement through better tools. A +4 Butter Knife of Annihilation, Armor of Imperviousness to Nuclear Blasts, Boots of Buttkicking, a Big Blue Dress of squeezing out one extra spell before you run out of mana, whatever.

Exceptional tools for use by heroes is a staple of heroic fiction upon which these games were originally based. Glamdring, Excaliber, Sting, the Millenium Falcon, Silver the horse, the Batmobile, and more. I was reading up on "Jack" tales a couple years back - research for a possible RPG that has been backburnered for something a little less aggressive for now. Jack is best known for his exploits with the magic beanstalk, but there are tons of stories about him. And besides magic beans and a magic harp, he was constantly being gifted with powerful magic items, usually by either old crones or beautiful young maidens.

The thing is, those Jack tales were all stand-alone stories. If they all dealt with the same Jack, then Jack was a polygamist with multiple personalities and a massive stash of magical items that he forgot about before every adventure. In more modern stories (and RPGs), our heroes have a bit more persistence between adventures. This is fine. But what do we do with the treasure hoard?

In stories, our heroes just don't have to deal with such things. If an "upgrade" occurs, it's usually because the previous tool was lost / destroyed / used up, or he / she just sort of ignores who inherits their former possession. Who cares what happened to the Klingon Bird of Prey Captain Kirk and his crew used in Star Trek IV, anyway? These are stories, not games, and so the author is very deliberate about the dramatic purpose of these external extensions of the characters.

The other thing about these stories is that these items are always earned by the heroes. Maybe it's just an artifact of the modern, western fiction, but these tools are almost always legitimized by the hero having to earn them in some way. In some cases, it may be inherited, though even in those cases it is often re-earned. Or, in Luke Skywalker's case, his father's lightsaber was lost in a battle with his dead ol' dad, and he had to create his own for the final confrontation.

In many stories, the fellow who simply buys his way into the rank of heroes by purchasing a bunch of neat toys is simply a pretender. His fraud is exposed later - sometimes fatally - when he demonstrates he doesn't deserve the honor he bought into.

RPG Heroes and their Disposable Gear
Now we have the roleplaying game. As it is a game, simple use of "dramatic need" goes out the window. Loot is part of the positive feedback cycle of the games, which is rarely used for anything other than upgrading the characters with more powerful tools. This brings up some problems. What do they do with their loot?

Some players, for roleplaying benefit, use their gains to donate to the poor, pay their father's medical bill, or whatnot. Most, however, simply spend it on upgrading their character. Getting super-powered gear at the local Magical Mini-Mart, or in-game equivalent.

While this is neither heroic or particularly dramatic, it causes an extra issue: The toys the players get via purchasing and trade-ins may be much better than the great, awesome, dramatic loot the game designer (or gamemaster) had them earn through desperate and exciting adventures? What do you do when Frodo figures he's better off selling Sting, the Mithril Shirt, and what the heck... let's pawn the One Ring, too... for a +5 Shortbow of Belly Bursting and an Ever-Full Beer Tankard?

But if you don't give them that opportunity --- what kind of "money sink" do you put in the game that is of value to the players. 1st edition AD&D had rules requiring that the player characters spend a hefty amount of money in order to gain a level, but this wasn't so much a money sink as a source of endless player complaints.

And so wonderful and wonderous items of heroic fantasy, theoretically rich in dramatic benefits beyond mere game mechanics, get commoditized in the economy of a game to the near-meaninglessness of pellets dropping at the press of a feeder bar. It's bad enough in single-player CRPGs and Dice & Paper games, but its absolutely insane in Massively Mutiplayer Online RPGs.

What To Do About It?
Now, I could argue that's not a bad thing. Especially as a player. Because we're ultimately talking about a game, here, not a novel, and that changes everything. As a gamer in an RPG, I'm worried about my character's survival, man. All the cool dramatic fuzzy-wuzzies don't mean a thing to me if I'm destined to be a secondary character who dies in the middle of the book in a pool of his own blood, mourned for maybe a chapter or two and then forgotten. While I subconsciously yearn for drama and story, my immediate concern is far removed from that. I'm here to kick butt, take names, and win, dang it. And I'll use store-bought magic items, endless restoring of saved-games, finding loopholes in the game system, and anything else I can do to accomplish that objective. And THAT is the fun of the game, dang it!

Maybe not as fun as some alternatives, but there's a fine line between that kind of fun and pure frustration.

But assuming you'd like to get the best of both worlds, there are a couple of solutions I've seen, and one more I've tried (without much success).

The Store Sells Only Mundane Magic...
One option, especially in games with lots of randomized loot, is to make sure that the "earned" loot is always superior or less generic to what can be found for sale in the game world. The "store-bought" gear is only useful to replenish consumable (limited use) items, or to fill in gaps in the character's equipment list. The problem with this is that very soon the player's wealth vastly exceeds anything they could conceivably purchase, and so any 'rewards' that aren't immediate and direct upgrades become useless to the player.

Upgrades "R" Us
Another option is to allow the player to upgrade a single item, rather than replacing it. This does an admirable job of helping simulate the heroic fantasy that fathered the entire genre. The problem with this is that once the player finds their prized weapon, the game master / designer can no longer reward them with a better weapon. Gandalf throws all other swords into the "for sale" bin, so he can upgrade Glamdring to shoot lighting bolts out of its crossguard and stuff. And once again, upgrading is kind of a mechanical, drama-less activity.

Upgrade II: The Quest For Loot
One thing I've experimented with Dice & Paper games is maintaining a "quest component" in the creation of magic items. Maybe the new armor - in addition to requiring a hefty upgrade cost - also requires a rare cockatrice feather or dragon scale (or both...) This - in theory - allows me the opportunity to make the new item a memorable event and make it feel "earned," even though it remains an upgrade (and a money sink). Unfortunately, that's harder to implement in a CRPG. Not unless half the game was designed around generating semi-random quests based on the player's options.

What Do You Think?
Is it a problem when the gamemaster can't have treasure that is truly treasured by players? If so, what's the best way to deal with the problem, in "dice & paper" games or in CRPGs?


(Vaguely) related pondering of the trivial:
* RPG Design: Quest Abuse
* RPG Design: The Brute Force Problem
* RPG Design: Why Can't I Get Through The Stupid Door?

Read or Post Comments on the Forum

Labels: Game Design, Roleplaying Games

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

 
Games As Editorial Content
Yesterday, Persuasive Games announced (via the Water Cooler Games blog) that their games will begin being featured in the New York Times online edition as editorial content. Effectively filling a similar niche as political cartoons. Their first title, Food Import Folly (subscription required to play the game, but that link has a description and screenshots), concerns the extremely limited FDA inspection of food imports. The website notes that the number of food import shipments increased from 2 million to 9 million over the last decade, but the FDA resources and personnel has remained roughly constant.

You may recall my evangelizing of one of Persuasive Games' previous titles, "Airport Security." I think this is an important step for games --- a new area where game-makers can and should explore. It is another potential market, albeit a small one. I don't know if the online games will help the TimesSelect subscription rates, but I'm pleased to see them embracing more of the potential of being an online news service. But more importantly, this is another small step for computer games in demonstrating their power - and importance - as a medium of communication.

And for rapid development buffs - Food Import Folly was created in Flash in only one week.

Congratulations to Persuasive Games!


(Vaguely) Related Attempts At Being Political...
* Airport Security Parody Game
* Games As Art: Media's Double Standard
* Do Games Matter?

Read or Post Comments on the Forum

Labels: Indie Evangelism, Politics

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

 
Frayed Knights Dev Diary: Mocking (Up) Conversations
Greetings, true believers... to another chapter in the saga of making an indie RPG for the PC, Frayed Knights. This week is about more quick & dirty development of prototype #1 - trying to get semi-functional stubs of all the game elements thrown together in this "evolutionary prototype" and begin iterating on it.

Movement Revisited
This week I continued work on the control system, and came to realize that what I posted last week is just not going to work. In particular, the problem arises when one is turning towards an interactive object or character... like the image to the right (which was also posted in the forums earlier this week). In this state, with the elf on the edge of the screen (though we could really afford to slim her collision volume down a bit), we have a very tough time turning left. If the elf was very tall, it would be impossible to turn left.

Back to the drawing board. Maybe...

What it comes down to is that either completely separate mouse buttons will have to be used for movement versus clicking on interactive elements, or interactive buttons will have to be added to the screen to control movement (outside of optional key controls). Or both. Or neither, and I scrap the whole system for a new one. One of the central design elements I'm trying to maintain is that the game must be completely playable using ONLY the mouse. Keyboard controls should be strictly optional. And I want to do it without cluttering up the UI too much.

We All Need... Someone... We Can Click On...
To create interactive objects in 3D space, there are a couple of different approaches you can take (that I'm familiar with, at least). The first is to project the mouse cursor into some 3D location in the scene, and then run a collision ray through the scene to the 3D cursor and see what it collides with. If it's with an interactive object, then you signal the client in some way to let it know that there's something "clickable" beneath the cursor. The advantage of this method is that it allows occluding objects to block access to interactive objects very naturally - a closed door will block you from clicking on the character behind it. The downside is that the projection of the mouse cursor into 3D space isn't very exact - as it only has 2D coordinates. So you can end up with some strangeness unless the cursor is ALWAYS centered due to perspective, where the player thinks he should be able to click on something, but the game thinks otherwise.

Another way to try this, if you don't have too many interactive objects within range, is to collect them in a list and to "unproject" them and their collision boundaries into 2D space, gathering their real screen-space positions. This has the advantage of more exact results (as exact as the collision volume boundaries get, at least) for clicking on the objects, but you lose collision information for intervening, non-interactive objects.

A hybrid approach would be to perform the second check, and then project the cursor out at the distance of the candidate object, and then perform the 3D collision check to make sure it still connects as a "sanity check".

There is probably a better technique than the above, but those are the ones I'm familiar with.

I'm currently using method #2, with plans to integrate the hybrid "sanity check" approach later on. What this gives us now is a good foundation for our evolutionary prototype. Hopefully I've designed it so the behavior can be easily expanded upon (or completely overhauled) later with few problems.

Oh! It's a Text-Based RPG!
One of my projects this week was to get the basic interface for conversations working. I'm doing some weird stuff with conversations that might not work.

What typical RPGs (think Bioware's RPGs, here) do with a "conversation tree" system is actually similar to how I'm handling interactions with objects... sort of a text-based sub-game. Anybody who has created a Neverwinter Nights module and used a conversation to simulate actions not normally allowed in the game (like swimming across a river, or climbing a rope) knows exactly how and why to treat things this way. While it isn't as immersive as actually seeing the actions play out graphically on the screen, it allows a lot more freedom in designing interesting situations.

Talk To Me...
For actual conversations, I'm doing something a little different. I'm not going to go into much detail right now, because I want to be able to talk about it when I'm actually implementing the nuts and bolts of it about a month or so from now.

From a pure interface perspective, it isn't too far removed from a traditional conversation tree system. You have several choices. The NPC responds to your choices with some canned statement (though it may be modified on-the-fly, which will really limit my ability to localize this game). You get new choices. This continues until you or the NPC end the conversation. The big difference is how the choices are made available, and how the NPC responds. The difference is that these are not statically related... NPC response A doesn't automatically lead to player choices B,C, and D. It all depends upon what events have occured in the game, the NPC's relationship with the Frayed Knights, and the collected social skills and feats of the party members.

So instead of delivering a static script, an NPC may be of value to speak with at any time in the game. Spending time and effort to befriend an NPC isn't going to be effort wasted beyond the one quest the NPC is assigned to - they will continue to be of value throughout the game.

At least, that's how it all plays out in my head. So when I click on the responses generically labeled "Response1" and "Response2" in the conversation menu, I'm actually envisioning this really cool, complex dialog. My imagination is so much easier to program than a computer game... Actually getting it to work involves many factors including inheritance and knowledge tables and heirarchies and risk / reward factors and stuff.

Soon...


(Vaguely) related posts where I pretend I know what I'm talking about
* RPG Conversation System Redesign
* Non-Combat RPG: A Fool's Errand?
* Frayed Knights Dev Diary: Getting Around In the World
* The RPG Commandments
* Prototyping Means Sucking Less Sooner

Read or Post Comments on the Forum

Labels: Frayed Knights, Game Design, Roleplaying Games

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

 
More Guitar Hero 80's Edition News
According to GameSpot and 1Up, the new title of this summer's Guitar Hero game is Guitar Hero Encore: Rocks the 80's.

The updated track list known so far:

• "Lonely Is the Night" (Billy Squier)
  
• "Synchronicity II" (Police)
  
• "18 and Life" (Skid Row)
• "Bathroom Wall" (Faster Pussycat)
• "Nothing But a Good Time" (Poison)
• "Shakin'" (Eddie Money)
• "Play With Me" (Extreme)
  
• "Metal Health" (Quiet Riot)
  
• "Heat of the Moment" (Asia)
• "I Wanna Rock" (Twisted Sister)
• "Holy Diver" (Dio)
  
• "I Ran" (Flock of Seagulls)
• "Round and Round" (Ratt)
• "I Want Candy" (Bow Wow Wow)

The speculation from this title is that this might be part of a "Spin-Off" series called "Guitar Hero Encore." At one point RedOctane (or was it Harmonix) suggested all kinds of Guitar Hero spin-offs, including a Country & Western version for the U.S. (which I'd probably skip...), a pure "Heavy Metal" version, and an 80's version.

Man... I could imagine a "Guitar Hero Encore: Woodstock Edition" with music from the Vietnam War era that would be killer. Okay, sure, I wasn't born when some of those songs came out, but still.... Would be nice to get some more Hendrix, Jefferson Airplane, CCR action...

Very cool potential here. Can't wait for the game to be released. It looks like it might be a mid-July thing.

Read and Post Comments In the Forums...

Labels: Guitar Hero

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

 
Blogging Ultima
How about a blog where someone goes through the entire Ultima series, start-to-finish, and blogs his progress?

Ophidian Dragon (CageBlogger) is doing just that, over at Blogging Ultima.

Starting back in February, with Akalabeth: World of Doom, he's playing them in the order that they were released, including the spinoffs like Ultima Underworld, Savage Empire, and Martian Dreams. The articles are largely play-throughs, though he includes a bit of commentary and historical notes (and lots of screen shots... be warned, we're talking graphics from before Pac-Man's birth in a couple of cases...)

This should be enjoyable stuff for retro-gamers, RPG designers looking to see what's gone before, or just the idly curious. I have only read a few entries so far, but it's been a great trip down memory lane, even looking over the ones I never played.

A tip o' the +2 Helm goes to GBGames for letting me know about this gem.


(Vaguely) related trips down the Deadly Corridor of Memories
* Game Moments #9: Ultima Underworld
* Game Moments #6: Ultima VII
* Can CRPGs Age Gracefully?
* Bungling Burglars Break Into Lord British's Building...
* Behind-the-Scenes Look at the History of Ultima Underworld
* The Origin of Fun
* Who Are the Best Game Villains

Read or Post Comments In The Forums

Labels: retro, Roleplaying Games

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

 
What Is the Best Language To Use To Start Writing Games?
This question came from Roberto, who gave me permission to share it. He asked me what language he should use to start learning to program games. You had to start with a tough one, didn't you, Roberto?

The short answer is, "Write a game in whatever language will let you get the job done."

The longer answer just nitpicks at the short one.

How I Started
I started writing games in BASIC. Not some fancy version of BASIC, either, but really ugly, minimalist implementation that wasn't ANSII compliant. I learned, at least partly, by typing in code from magazines and books like Creative Computing's BASIC COMPUTER GAMES. While its not really practiced today (why type it in when you can download it or cut & paste?), that process was an invaluable learning tool for me. Not only did I learn the language this way, but I also got a feel for how other programmers used the language to approach and solve problems. How they used the data to represent the world and player actions.

I actually continued this practice when I went to college. I took a data structures course, and we had weekly assignments that included implementing these basic data types covered in the class (stacks, queues, etc.) For implementing a stack (in PASCAL), I actually wrote the Towers of Hanoi puzzle, with the ring sizes For a binary search three, I wrote the game of "Animal," where the computer had to guess what animal you were thinking of (and, when it failed to guess properly, it would ask you to fill in the blanks with the new animal, and a qustion that would distinguish it from the others.

Times and technology have changed a lot since then. My BASIC and PASCAL skills are languishing (I've used VisualBasic professionally, but its resemblance to the BASIC I used back in the early 80's is vague at best). But the core skills and way of thinking about solving problems that I learned back then are still being used every single day. So my choice of language back in the day was largely irrelevant. The most important thing was that I did it.

How does this apply to you? You'll need to determine your requirements based on the following criteria:

#1 - AUDIENCE NEEDS
What language / engine / system will be most accessible to your intended audience and platform? If you are only writing a game for yourself, it doesn't matter... but if you are writing games for others to enjoy, you will need to make it as easy and as convenient as possible for them.

Making your audience download additional virtual machine or framework in order to run your game can be a problem. This includes using the latest & greatest version of DirectX, OpenGL, the .NET framework, JVM, and so forth. You'll want to go with whatever users are likely to already have. Flash is a great option because even though it does require a (small) additional download, most users already have it installed on their machines.

Download size is also an issue, of course, though this is not directly related to your choice of language. Smaller is usually better, but it tends to break down into thresholds that are hotly debated amongst game developers. It used to be that anything over 7 megs was the kiss of death, but times have changed.

So - best case... make it something your users are unlikely to have to (manually) download and install at ALL (in theory), like a web-based game. Next best case: An entirely self-contained executable. Next best case: An executable (or web-based game) that requires a very common external dependency - like an older version of DirectX or OpenGL (which is unfortunately not as common as I wish it would be...)

#2 - YOUR NEEDS
What language are you most familiar with? What is your own easiest / cheapest solution?

If you know how to program in VisualBasic because of your day job, why not write a game in VisualBasic (unless you feel it's trumped by your answer to question #1 above)? If you have no money to even buy a compiler or engine, you'd better start with a free / open source option, like Java, Python, or Microsoft's freebie version of VS 2005.

Go with what you know. If you don't know anything yet, then you'll need to do more research and find out what strikes your fancy. Look at what games are being made using the various languages and see if they match what you have in mind for your own game. The list of 2D and 3D game development tools is constantly evolving (there's one on DevMaster here for 3D engines, if you are interested), which might also dictate your language of choice.

What language (or engine) has the best community support if you get stuck? There are many, many books (and websites, and forum posts, and magazine articles...) about game programming in C++. If you choose a more obscure language, it might be harder finding help or answers to questions.

Then there's also your own plans / desires. Are you really wanting to create a game engine, or a game? (My advice, starting out, is a GAME). Are you pushing for a career in web development and web-based games? If you are looking at hardcore game development, that world still runs in C++ (and probably will for the forseeable future). Java - as much as I want to cheer it on - has started losing what headway it once had. And while C# is an attractive option, what with Microsoft's XNA initiative and everything, it's got the whole "Microsoft Exclusive!" thing it is riding on.

#3 - THE GAME'S NEEDS
What are the needs of your game? If you are planning a SNES-style JRPG, then why not start with something that's already got part of the work done for you, like RPG Maker? (which uses RUBY to extend its functionality)? Are you planning a 3D game project for your first game (if so, may whatever gods you worship have mercy on your soul...)?

Look at what is available and what best matches the needs of the game.

And If You Still Don't Know...
So if you still have no idea where to begin, here are some ideas. I'd recommend starting with a 2D game, and using some kind of mid- or high-level engine or graphics library to get you started. Pick a language that works best for the three criteria I mentioned above, and just get cracking.

I'm partial to Python + PyGame, mainly because I am a Python convert. It's a pretty easy language to pick up and use, it's free, and its multiplatform. The biggest problem is that compiling to a native executable (and not requiring your audience to download and install Python) is sort of problematic, and I'm not sure what options are available outside of Windows.

Torque Game Builder is another option I'd heartily recommend. It's got its quirks and issues, but the tutorials that come with it are almost worth the price of admission on their own. And many games are being made right now in it.

I haven't messed with Blitz3D or BlitzMax, but both have been used to make commercial games in the past, and they have solid community support with people who swear by them.

Good ol' C++ and SDL is a great "workhorse" option. Not the easiest to learn, but so much of the world (outside of web development) still runs in C / C++, so learning the language won't do you any harm. There are also TONS of game engines and libraries (some free, some cheap, some not-so-cheap) that are C++ based besides SDL. SDL is nice because it's free and used in a lot of 2D games.

Some great, top-selling games have been made with GameMaker and RPGMaker (Cute Knight and Aveyond, to name my favorites), so don't ignore these options. I know some game development schools / courses have students start out with GameMaker, so it is useful both as a general learning tool and an engine to create commercial-quality products.

In the end, it still boils down to just picking a likely tool and then running with it and finishing a game. Even a simple Space Invaders clone that won't be played by anyone outside of your immediate circle of friends will be an invaluable learning experience. Like the ads say, "Just Do It."

(Vaguely) related stupidity:
* Programming Tip: Comment First
* My Worst Bug Ever!
* Torque 2D Game Builder Quick Review
* A Day in the Life of a Game Programmer

Read or Post Comments on the Forums

Labels: programming

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

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

Why Work Is Looking More Like a Video Game

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

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

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

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

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

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

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

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

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

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

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


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

Comments in the Forums

Labels: Biz, productivity

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

 
The Broken Hourglass: Weapon & Equipment Properties
There's an update today on equipment properties in the upcoming indie RPG "The Broken Hourglass," which you might find interesting:

Rules and Mechanics: Special Equipment Properties

One thing I was especially interested in seeing was that certain weapons have a "flexible" property, which makes them more difficult to deflect or parry. Now I am wondering if any of those Planewalker guys are actually as geeky as me, and misspent some of their youth as I did dressing up in armor and hitting each other with padded sticks in their local medievalist organizations. I did, and I frequently used a shield, and I hated fighting people who knew what they were doing with a flail. They'd change the trajectory of the ball-and-chain in mid-swing, so that you'd not catch it with the shield as you'd intended, and the ball would whip around and nail you in the shield-arm -- or worse, the shoulder or back. Which, in the rule system we used, meant insta-kill if you weren't armored... Hmmm, I hope TBH doesn't use THAT rule. That would suck. It'd be almost like going back and playing the original Bard's Tale again, with newbie characters that were slaughters after taking three steps out of the safety of the starting tavern into the city. But I digress...

There's an awful lot of attention to detail in the game mechanics in The Broken Hourglass - at least from what I can see - which will hopefully translate into stellar gameplay. More detail than you often see in mainstream RPGs these days... which I, for one, appreciate. At least we know that the choice of weapons will be an interesting one.


(Vaguely) related prancing about English K-Nig-Hts.
* Beyond the Gate: Jason Compton on the Making of The Broken Hourglass
* RPG Combat Design
* Indie RPG Roundtable

Comments in the Forums

Labels: Indie Evangelism, Roleplaying Games

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

 
Talk Like A Fighter Pilot!
I don't know why I have this fascination with the sub-cultures that evolve around specific games or genres, but that sort of thing really does intrigue me. I did a little post several months ago about the jargon that has evolved in City of Heroes (and MMOs in particular). I stumbled across a post a couple of days ago about the latest version of Falcon 4.0, and I was very amused that I actually understood almost all of it.

While City of Heroes jargon was partly derived from other MMOs and partly original, much of the jargon in Falcon 4.0 discussions is based on real-world terminology. Flight simmers are an interesting bunch - part of the fun for many of them is to preserve the illusion of reality, and to immerse themselves into the role. You'll find arguments over "realism" settings, not because of the challenge factor, but because one setting or another is closer to matching what pilots really go / went through. I wouldn't be surprised to find that most of these instructions are entirely applicable to real-world combat pilots.

This thread, started by Ghostrider117, is a discussion of how to best defeat the R-77 Medium-Range Missile (AKA AA-12 Adder).

1: ECM on to deny bandit an early lock
2: Get high and fast, 30,000 feet plus to extend AIM-120 Rmax 500+ Kts
3: If bandit is jamming (no radar brick) you have to burn through the jammer, use RWS with reduced barscans to 2 bars. If he's not jamming use TWS mode instead.
4: Achieve radar lock and fire just inside of Rmax
5: Crank right or left and put bandit at the edge of your radar gimbles
6: Reduce speed (Very important as this delays his launch Rmax)
7: Watch target aspect and your RWR spike and your WEZ circle
8: If bandit has turned away to defeat the AIM-120 long shot, turn back into him and push the fight. You know if he has turned away as the RWR will not show a spike, and your missile WEZ will shrink.
9: If bandit has fired you have two choices, but turn ECM off to deny HOJ

[a] (Aggressive) Keep him on the edge of radar gimbles untill your AIM-120 goes
pitbull, then slice back and run, full AB, put the RWR spike on your six. Go downhill full AB, but if the RWR continues to show the M symbol, prepare to climb and then
beam the R-77 as it runs out of energy.

[b] (Defensive) Slice back and run before pitbull, he might leave his ECM on and your slammer will go HOJ while you will outrun the R-77

I've had the AI do aggressive BVR tactics and defensive as well. Perhaps the most
challenging is the fight were the bandit turns away to defeat an AIM-120 long shot, and as you push the fight, and get a medium range AIM-120 shot, he turns into you and fires an R-77 at you. I found that a split S right at slammer pitbull with full AB dive can shake the R-77 as the Mig is often destroyed.

I tried playing the new version of Falcon 4.0 a couple of weeks ago. I was amazed at how much I'd forgotten. I was actually pretty good at the earlier version at one point. If you really want to take a crack at deciphering the the above instructions, here are a few hints:

Pitbull (A-Pole): The point at which your missile is no longer slaved to your plane's radar system, but instead uses its own radar system. Before your missile goes pitbull, if you make evasive maneuvers, your missile will "go ballistic" (unguided).

BVR: Beyond Visual Range. Where medium- and long-ranged missile combat takes place. If I were to make anything truly resembling "realistic" combat in a Void War sequel (and no, I won't), it'd be all BVR combat. You'd fire your missile, take evasive action... and then wait a few days to see if you hit and if you are going to be hit. (Of course, if you are hit, you won't know about if your opponent was ever hit due to the whole speed-of-light transport delay thing...)

ECM: Electronic Counter Measures. Jamming the enemy radar.

RWR: Radar Warning Receiver. A fun little device that shows you where and how strong you are being tracked by radar. It'll also show what kind of radar is tracking you (which you can also determine audibly, as the system will convert the radio signal to an audio waveform - just like a radio). A "spike" on the RWR is a visual indicator of something "painting" you. The trick with the RWR is that it can show strength, type, and direction, but it is incapable of determining the radar system's distance from you.

Split S: A maneuver where you dive, and then come out of your dive in a different direction than when you began the maneuver. The usefulness of this against missiles at closer range is that the missile will have exhausted its fuel, and is now gliding towards you. Aggressive maneuvering causes the missile to waste energy which it is incapable of getting back.


Okay - your turn. What favorite games do you have that have their own jargon? What sort of terms and expressions have emerged?


(Vaguely) related use of confusing terminology:
* City of Heroes Jargon
* Game Moments #2: Falcon 4.0
* Wanna Learn To be A Fighter Pilot?
* Game Moments #11: Falcon 4.0 (again)
* Guest Game Moments: Falcon 4.0
* How I Single-Handedly Lost the Pacific War


Comments On The Forums

Labels: Flight Sims, Mainstream Games

- posted by The Rampant Coyote @ 6:00 PM (Permalink) links to this post

 
Watson Fails Spot Check; Spared 1d3 Sanity Loss
Yeah. That really does look an awful lot like Cthulhu, doesn't it? Not the corpse --- or the shadow-eyed assistant to Sherlock Holmes in the foreground. That squid-faced winged statue in the back. Good ol' Dr. Watson is oblivious. Which suits me, Sherlock Holmes, just fine. When Cthulhu awakens, I'd rather have some clueless edible folks between me and the Great Old One while I head for the hills.

I can't say Sherlock Holmes: The Awakened is a stellar game, or one immediately worthy of anybody's gaming dollar. It's got its share of flaws and weirdness - some common to all adventure games, some unique to this series. It's got a lot of empty space you navigate around with nothing happening while you cast about for clues. But dang it, I'm having a lot of fun playing it - and that's ultimately what its all about, isn't it?


(Vaguely) related sleuthing:
* Sherlock Holmes: The Awakened First Impressions
* Sherlock Homes Investigates Cthulhu
* Coming Soon: More Graphic Adventure Game Goodness?

Comments in the Forums

Labels: Adventure Games

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

 
Indie RPG News, May 18th
Some tidbits of what's going on (from what I have heard - feel free to fill me in on more scuttlebutt) from around the world of indie computer RPGS:

Aveyond 2: Ean's Quest
The cover art for Aveyond 2 has been revealed on Amaranth's blog, and it's very very impressive --- as you can see to the right. Thus sayeth Amanda on the sequel: "Unlike Aveyond I, the story for Aveyond II is deeper and more serious. I've still jam-packed the game with weird humor, but you will see some notable differences in the next sequel."

You can check out more details of the game-in-progress on her blog. I can't wait! The full version of this portrait is available on the artist's site.

Depths of Peril
Soldak keeps sending me nifty stuff, so I'll keep posting them here. They've posted some art and descriptions of the monsters of Aleria - this installment includes the giant scorpion, the scorpid, and the death knight. They have also posted a new short story entitled "Draaien and the Ring." Check it out at your own... peril?

The Broken Hourglass
Chapter 3 of the short story, "Moonshine" has been posted over at Planewalker Games. This story helps reveal a little bit more of the setting and a glimpse of the seedier side of Mal Nassrin.

Also, Gaming Trend has posted a podcast interview with Jason Compton, who I interviewed here just a few weeks ago. Tune in for more information The Broken Hourglass, which certainly sounds like it may be a killer indie RPG!

Blades of Exile
Game programmers! Wanna get a look at some RPG code? Now's your chance. Jeff Vogel has open-sourced 1997's "Blades of Exile," including source code, graphics, sound, and support files. It's released under the Common Public License. For new RPG developers wanting to know where to start, this might be something useful just to use for research.


Go Indie!

COMMENTS

Labels: Indie Evangelism, Indie RPG News, Roleplaying Games

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

 
You Play Like a Girl
GBGames has an article up entitled, "You Play Like a Girl," based on his experiences playing the indie RPG Morning's Wrath. In Mornings Wrath, you play the princess. Instead of rescuing the handsome prince, you are actually betrayed by him in the first few minutes of the actual game.

Gianfranco comments that this is the first game that he's played in which he plays a female character. He enjoyed it, but it was a different experience for him, and it sounds like he considered it a little bit weird. He wonders aloud whether or not the overwhelming population of male player-characters in games might be a reason they are not more popular among women.

Me? I dunno. I often play female characters in games, even if given the choice. I enjoy seeing the little blonde girl beating the crap out of the hulking muscle-bound brutes in fighting games (and in the TV show Buffy the Vampire Slayer). I had no problem playing Laura Croft as she beat Indiana Jones at his own game. I had no problem playing Rhen in Aveyond, and I got used to playing the pink-haired Cute Knight.

But what if all or almost all videogame characters were female? Would I have become such a game nut in the first place? Or would I have considered gaming to be a "girl's activity" and ignored it? It's kind of interesting to see what happens when the shoe is on the other foot.

Georgina Bensley (author of Cute Knight) had some interesting comments about this a few months ago, if you recall from her interview here. She mentioned some subtle aspects that might make games less comfortable or attractive to female gamers: "Default high-score lists filled with male names. Selection between male-only character options. Claiming to have equal options for male and female characters, but actually having twice as much content available for male PCs as female ones. Always showing female characters within the story as weak and helpless. Things like that. I don't think anyone, male or female, should feel ashamed to play a game that's girl-*friendly*."

Interesting stuff to consider, as gamers and game designers.

Comments on the Forums

Labels: Game Design

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