Nathaniel Chapman

I'd even argue that in a lot of cases traditional tabletop math isn't fun in tabletop games. For example, the emphasis in pre 4.0 d&d on success or failure being the major scaling aspect of your character at low levels (fancy way of saying you miss a LOT) on single actions that make up your entire turn really hurts gameplay even in tabletop sessions. It certainly doesn't help PC games, either. Fallout handled this really well by letting you opt in to higher difficulty challenges (called shots) so you could scale as you gained levels without making you miss all the time in order to provide a sense of progression.

Personally for me the math isn't as important as the results of the math, if that makes sense. It isn't critical that you know how the armor scaling formula works in WoW as long as you know that it works, more armor is better, and that relationship is clear as you upgrade your gear. Also, this is true because sometimes math that looks pretty inelegant can work out elegantly in practice. For instance, you may have a relatively complex formula generating the values that you end up with but as long as those values result in good gameplay, you're golden. I think it's a mistake to intentionally obscure the math, however I don't think it's a requirement to display the math itself. On the other hand games should absolutely display the results of the math, i.e. how much damage an attack will do or your chance to score a critical hit.

I don't know, I think it can go either way. Simplicity in rulesets in my eyes can make a game trivial, or it can make it elegant; interesting gameplay isn't really dependent on how complex the rules are, it's dependent on how complex the player's choices are.

Aaaactually, I think a lot of the fluff things can be integrated into the ruleset in a smart way. However, that is really part of the 2nd or 3rd layer of development on a rules system. I'd describe my approach as this: 1) Develop the core mechanics that will drive the game. For something like D&D or Fallout1/2, this would mean developing a simple version of the tactical combat game. For a more action oriented RPG, it would mean developing the action gameplay. 2) Determine the variables that make sense to expose to RPG progression. In a western CRPG, character development is a key part of the gameplay, and a lot of the job of an RPG system is to express that character development in the rulesset. So basically, you pick out from the core gameplay which variables you'll use to express tougher and weaker creatures/challenges/etc., and to allow the player to improve relative to those challenges. 3) Develop the framework in which those variables will be improved. This is the step that Josh and I are saying is mistakenly taken as the first step in a lot of systems. This is the point where you determine things like attributes, classes, etc. A lot of the choices here are more about how you want the game to feel, what kind of player experience you want to create for each class, etc. These are higher level goals that rest on the lower level gameplay you've constructed earlier. This is also where you'd tie together the classes in a way that integrates well with your story/world. The real advantage to this system is that you really understand the foundation and can use that to elicit the kind of gameplay you want when setting up the more touch-y feel-y aspects like classes, stats, level progression, etc.

I wouldn't worry about this negatively affecting Obsidian.

I think the way Left 4 Dead handles that stuff is really cool. They have some things that essentially detect whether the player is getting stuck performing necessary actions and then tells them what to do if so. For instance, if you start a game and don't move for a while, it says "Press WASD to move" or if you stare at an item and don't use it it will say "Press E to Use".

It sounds like you don't like the notion of it being integrated with the rest of the game - or, just that you don't like tutorials. For instance, if instead of F3's tutorial, it had an optional tutorial that was a seperate level (think of the tutorial in Deus Ex) then it doesn't seem like you'd be as concerned with it? Maybe I'm reading what you're saying wrong.

Ugh, lost a long, detailed post on this. I'll be more brief but still try to make the point. Along the lines of what Josh is saying, I don't believe there are any real rules as far as RPG design goes. It's very hard (and maybe foolish) to isolate an individual mechanic away from the game and try to evaluate it qualitatively. Instead, you have to identify what kinds of things you want the player to experience, and then craft an RPG system that achieves those goals. It's very difficult, as Josh mentioned, to try to determine the intent of many PnP/Computer RPG systems because I do not think they are designed this way. Instead, they are designed piecemeal, with each mechanic attempting to simulate a particular event or refine/react to a particular system that existed in a previous game. This is why a lot of PnP RPGs, if you play with all the rules, grind to a halt in practice - the rules, while possibly individually perfectly fine and balanced - don't in practice result in a compelling play experience. Of course, each individual designer has preferences for some mechanics over others. As an example, (not to speak for Josh and he can correct me if I'm wrong) Josh has a general preference from Damage Threshold systems and I generally prefer percentile damage reduction systems. Meaning that, if we were designing in a vacuum, we'd each be more likely to pick the system we prefer. But you're never designing in a vacuum in practice. We both have our reasons for preferring each, but I think what makes a good system designer is being able to set your preferences/distaste for specific mechanics aside and evaluate instead which mechanics best result in the kind of gameplay you are trying to create. It's a lot like engineering or technology programming in a way. If you ask a good tech programmer or engineer what the best car/game engine design is, they'd respond "depends what the car/game is supposed to do".

True, but the last PC exclusive full game Bioware released was... 8 years ago now? I don't have exact data on their sales, but I'd guess based on other games that their games since have done much better on consoles.

That's a bit of a fail pet theory. PC hasn't declined as a gaming platform, it's actually increased, both in terms of annual profit and market share (spurred on by fresh new markets like Poland and Brazil). I haven't seen any evidence for this. In fact, all the reports I've seen say that PC sales have steadily been in decline for several years, however there is a significant question as to the accuracy of those reports because they do not include digital distribution. Regardless, I actually agree that the PC market as a whole doesn't have much to do with gaming. I think Apple is doing well in the computer business because 1) their OS and hardware - particularly their notebooks - have been phenomenal in the last few years and 2) they have a massive halo effect from the iPod and iPhone.

I thought that claim sounded fishy, so I looked it up: Apple's market cap: 168.46B MS' market cap: 236.13B Market cap is probably the best way to determine "size", wealth, or value of a corporation. So Apple's a big company, no doubt, but MS is significantly bigger. And, if MS needed the cash, they could relatively easily raise it by issuing stock. So I don't think it's really valid to say that Apple is richer - Apple has a lot of cash on hand. It's not like, however, if they then proceeded to buy back a bunch of stock and thus raised their stock price that they would be poorer. I honestly just don't think that Apple really sees the computer as the place that people want to play games. Honestly, seeing sales figures of PC games over the past few years, I don't think that's a bad assumption.

Ohya Excel too, though that's usually reserved for system designers and producers. Actually, I learned my Excel skills as a producer and they do come in handy for system design... I actually just finished a pretty nutty DPS spreadsheet for SEKRAT PROJEKT that would make WoW theorycrafters proud.

Again, I don't really think Apple sees the Mac as a gaming platform at all, from what I've seen at least. I *do* think they see the iPhone/iPod Touch that way, though. It's funny, because iTunes would actually be a great digital distribution/achievement/matchmaking service ala Steam if they ever did go that way.

Not all toolsets are written in .NET... it's a good rapid application development platform but it's not the second coming. I don't think, if we had to write our toolset in C++, we'd be crying. (Well, actually, GDI+ is kinda butts IMO so maybe we would, ha). Actually, if you're talking about NWN, it was written in Borland C++ Builder. We re-wrote the toolset in NWN2 in .NET for that among other reasons. Apple hasn't been serious about games *ever*. Like, since before MS Dos existed. The iPhone/iPod Touch is the first time that they've really ever been serious about gaming. And honestly it's really all market concerns that drive these things. There's not a graphics programmer worth his weight who can't write in OpenGL, DirectX or another API. If Apple suddenly had 70% market share, you can sure as hell bet we'd be making Mac games. And that's assuming that you take the Consoles out of the equation... Windows PC is the only development platform that you can develop both Xbox360 and PS3 games on, and if you're supporting those platforms the additional work to support Windows is pretty small. The fact is, in many cases it'd be more expensive to develop and QA SKUs for Linux or OSX than you'd see in returns. It sucks, especially for those of us that prefer those platforms for general computing. Again, the toolset doesn't have anything to do with it. I know our tools department could crank out great tools in Cocoa or whatever. It's all about the market. At least we're at a point where you can dual boot the OS of your choice (regardless of whether it's Linux or OSX) and Windows.

I've been playing this a fair bit recently, I've been pretty darn impressed so far.

We use middleware. I'm not sure whether or not there are legal issues with saying what specific middleware we use before it's actually announced or whatever, so I'll refrain from saying any particular packages. Nothing mysterious or shocking, just covering my butt as they say.

I'm not going to reply to each post here individually, but I just think you guys are generalizing too much about what kinds of games these are and what's important in them. RE5 didn't make that control decision because they didn't realize the right analog stick was there. They weren't scared of changing the controls, or anything. It's pretty clear why they made that decision and it's because it reinforces their gameplay. If you don't like the gameplay, that's fair enough, but I think it requires some consideration beyond simply complaining that it's anachronistic. Particularly coming from a forum that, I imagine, loves top down, turn based tactical RPGs. The fact is, when you throw primarily melee opponents at a player with ranged weapons, the instinct is for the player to just run backwards and fire because that is often a dominant strategy when fighting melee opponents. That gameplay often feels degenerate and one way to solve it is to not let the player run and gun, or to slow them to a walk, or to make firing on the run very inaccurate. They're all valid solutions. I also question whether many players find the RE control scheme is awkward, considering RE4's sitting at 96% on Metacritic and sold about 4 million copies. Granted that's not an argument for or against the control scheme, but it certainly is the best objective measurement I know of with regards to arguing the potential success or failure of a design decision with respect to the game it is intended for.

The Unreal engine has been in development for over 10 years. There's just no way that Onyx would be as big - and as I stated before, Onyx being smaller has plusses and minuses. But for what we do, Onyx is often better suited for the reasons I stated above.

I think it's pretty silly to claim that it's inherently evil/indefensible to not allow run and gun. Playing devils advocate, in the right kind of environment couldn't the Resident Evil system be more tactically interesting as the decision of whether or not to move is weightier? Particularly when fighting lots of melee enemies, where the natural tendency of a player might be to just run backwards and fire? Full disclosure, I have spent a lot of time thinking about how to deal with shooting mechanics in a scary game filled with primarily melee opponents

Was there a Blackjack minigame in ME? I totally don't remember that.

MS WERD + occasional flowcharts usually. Sometimes with a little photoshop/illustrator work over screenshots or drawings.

Skool'd. Thanks for the info and insights. So, since you're feeling talkative, what makes Onyx better suited for (some of) OE's RPGs than UE3? Quick disclaimer: I didn't work directly on AP, I've been on other projects so I can only share second-hand info with regards to UE3 specifics. And in no way is this intended to demean UE3. But, I can give some general insights. First, there's a benefit that has ultimately nothing to do with UE3 or Onyx specifically - having an in-house engine means that you have the low level architects of the tech just down the hallway. Second, Onyx is much simpler than UE3. While this means that we don't have as many features as UE3, the features we do have are specifically tailored to our processes and our people. Finally, the more "user-friendly" and well developed your tools are, generally, the less flexible they are. Meaning that, in general, with bigger, more complex engines it's very easy to develop the kinds of games they were designed to make and much harder to do things that they weren't intended for. This may seem counterintuitive, but it's a logical progression of the process of honing a tool/engine/etc. You make decisions to specialize certain things and you need to start making assumptions on the part of the user. This stuff can drill down to the very low level technically - a renderer and engine designed to display hundreds of onscreen units in a Strategy style game probably won't be structured anything like a fighting game engine, for instance. You also narrow things down because the more decisions you leave to the user, the more complex and time consuming it is for them to develop the specific thing you want to help them make. That's the whole selling point of an off the shelf engine - they've made a lot of those decisions for you. But, of course, that means that they're less well suited to doing things that they weren't intended for, and often forcing them to adapt to something they weren't built for is much harder than just rolling your own. That decision is ultimately handled on a project by project basis - for some games it makes a ton of sense to use UE3, on others it makes sense to use an internal engine like Onyx - but, for instance, if we suddenly wanted to make an iPhone game my guess is we'd probably just start from scratch rather than trying to shoehorn Onyx into running on a phone. Think of it as a spectrum of game-making tools. On the far end of "flexible but difficult to get something up and running" is starting up Visual Studio/Xcode/etc. and working from scratch. Next is using a smaller internal engine like Onyx. Next is a lighter weight third party engine, maybe like Quake or Source. Then comes a big, heavy, feature rich engine like Unreal. This is generally as far as professional game developers go in the "easy to use, inflexible" direction because we're really annoyingly picky and can't deal with restrictions But, there's still stuff further in that direction. For instance, it's easier still, but less flexible, to make a mod for Source or Unreal. And then, even easier but less flexible than that is something like the NWN2 toolset. This isn't to say that any point on this spectrum is inherently good or bad. UE3 is a great tool for projects that benefit from its strengths and aren't hurt by the inherent relative inflexibility of a more mature, "off-the-shelf" engine when compared to an engine developed specifically for the purpose. Trying to make a turn based strategy game, or MMO, or traditional CRPG in Unreal is probably not as easy as doing it with a lower-level engine because you're going to be fighting what Unreal is built to do. Or take NWN2's toolset - it's an awesome tool if you want to make NWN2 style campaigns. It's not quite as good if you want to do something more off the wall - something like Adam Miller's card game modules is I'm sure very difficult. If you want to do something turn-based, you're going to have to constantly fight the fact that the entire interface, AI, creature behavior etc. is intended for a real time game. And of course it's completely impossible to make an FPS with it. Of course, with VS and a blank slate you can do whatever you want within technical limits - but you'll be spending as much or more time just getting a character to render and animate, UI to draw, etc. etc. as you will making gameplay. Whether that tradeoff is worth it or not depends on your budget, what you're trying to make, etc.

I think you are barking up the wrong tree here. The selection of the possible audience and thus the supported platform(s) is rarely up to the developer, but rather a decision that is made by the publisher(s). i.e. whether or not to include certain consoles. Game production will in the end always come down to simple business decisions and in that regard you list some of the major points for DirectX: easier, better and faster to do. If you look back to NWN1, at that stage the differences between DirectX and OpenGL were much less relevant and linux looked quite promising as a future gamer platform when the development started. However in the aftermath it seems, that linux clients didn't make for a significant enough share of the market (even by now) to justify the necessary efforts that would go along with supporting it as a platform. Of course that sounds a bit like a deadlock: How will linux ever become a significant platform for the gaming industry, if nobody supports it? But I don't think that this can be addressed or solved by the game developers. For that you should better try to convince the IP holders and publishers, who actually decide about those directions. Just my 2ct. Honestly I think linux (or more accurately linux distro X, probably Ubuntu) will become a significant platform when the software community around it matures to the point that people want to adopt it. If I want a high quality, UNIX based, moderately open-source driven, relatively secure OS with a phenomenal and very pretty GUI, I can buy a Mac and get OS X. I can even run X11 apps, or non-gaming Windows apps in VMWare Fusion and then dual boot into Windows when I want to play a game that isn't made by Blizzard or id. If I just want to play games and run most software under the sun, I have Windows and a desktop computer. Windows 7 is even pretty darn good, all things considered. And then you've got Linux, which for many users, is like taking Windows' quality of UI design and melding it with a developer share even smaller than OS X. I love the idea of using Linux, and really there's nothing (or very little) wrong with Ubuntu itself. But in Linux I don't get games, I don't get VMWare, I don't get iTunes, or Adium, or Digsby, or Safari, or Google Chrome, or Office, or the Adobe suites... it's just not practical, sadly. And, until people want to adopt it for those other reasons, few people in development or publishing are going to risk adopting it for games.

FYI most srs bzns PS3 developers do not in fact use the OpenGL ES implementation on the PS3. libgcm is the "closer to the metal" API that is generally more commonly used. Unfortunately, what I hear a lot from graphics guys is that OpenGL is kind of an abandoned baby these days. Few people on the hardware side, excluding Apple, have been doing much with it commercially, and Apple seems to have just discovered gaming with the iPhone. It's a bummer because OpenGL is pretty much all you've got on OSX, and there are a surprising number of Apple fans in the game industry... heck, on a given day at Obsidian it's likely you'll see at least one Macbook Pro in an office. I'm actually writing this on my Macbook Pro! Anyways, yeah, as you mention porting a game engine is more complex than "just" rewriting the renderer. Particularly as middleware becomes more and more prevalent, if middleware vendor X doesn't support a given platform, chances are you aren't going to port your game to it. Apple and MS both choosing to focus on their own proprietary languages/APIs doesn't help much either, particularly when you're talking about porting, say, a toolset.