It looks like you're new here. If you want to get involved, click one of these buttons!
This guy here is one of the writers on the BW MMO project, he calls it "the project that shall not be named" or "Project Revolver" as a code name. (or it could be ME2, not really sure).
Quote: ‹ Select ›
What would you cut?
While still working on Mass Effect, I'm included in some of the Revolver meetings. Revolver is at that interesting point where things start getting cut. This is good. The project had a whole lot of things up in the air, a ton of features that were each individually doable but way beyond the scope of the project when taken together (unless we had more funding than any other project and weren't planning to ship until 2012). And it's far better to cut gameplay features now than to get halfway through development and realize that there's no way that a given feature is gonna be possible, and you have to change the story and a whole bunch of other dependent features to make up for the big cut you have to make (not to mention all the wasted man-hours).
All the cutting has me thinking, so I wanted to put a question out there for everyone. (Note: This is purely hypothetical. This is not something Revolver is doing.) So tell me what you think:
You're working on an RPG project. Due to resource constraints (time, money, manpower), you have to cut either multiplayer or romances from your game. The two aren't directly in competition -- romances impact the writers and the designers, and are one of the most design-intensive parts of the game (with a ton of scripting and complex conditionals to make sure that romances don't break the plot, or get broken by the plot, and a lot of designer cutscenes and romance-specific animations like hugs and kisses), while multiplayer impacts the designers a little (in terms of making sure that the story doesn't break when there are two people playing it) and the programmers a ton (in terms of making sure that conversations, combat, exploration, and, well, everything else works with two or more people playing). But the project only has the time and personnel pull to get one of these features (and they're semi-opposed, since very few games with co-op multiplayer include romances; few people like watching their gaming buddy convince the elven bard to open her heart).
The choice ultimately comes down to you -- either you're in a very high position, or you're the tiebreaking vote.
Which feature do you cut?
No wrong answers. I'd love to hear what you think.
Addendum: To be clear, this is not something BioWare is currently considering for any of its games, and it's rarely a choice that would come down this way. Multiplayer is about ten times more resource-intensive than romances on almost every level.
This surprises me hugely, but I'd cut romances before multiplayer. I love the romances in RPGs, and I really want to write one myself... but ultimately, people who love the romances in RPGs are a minority. A good romance can leave players talking about it years after the game ships, but a good multiplayer system can leave players still playing the game years after the game ships.
This mean that it starts out as a single player campaign then opens up to multi player?
Quote: ‹ Select ›
Stuff I can't talk about, talked about
More prototyping this week. It's at the point where a lot of it is specific enough to the setting that I can't really talk about it, even quasi-metaphorically:
Me: So we're trying to figure out how flight messes up plots -- which plots can be broken by you being able to fly into an area that you'd ordinarily have to walk through (and thus run into encounters that advance the plot)...
Astute Reader: Personal-level flying, eh? Sounds like you're making a game with lots of magic -- like maybe you playing an angel or a dragon!
Me: Uh... no?
Astute Reader: Oh, not fantasy, then? You're confirming that?
Me: I'm just saying that there are, y'know, other ways that you could fly, I guess...
Astute Reader: Like in a pulp setting with jetpacks? So you're doing Flash Gordon, then? We knew it! Or is it Harry Potter? It's Harry Potter, isn't it?
One thing that is neat, though (and talkable) is the notion of letting our plots get "broken" while still giving the player alternate ways to get to the same content. As games have gotten larger, it has become more difficult and more complex to make individual levels -- which means that they take more time and more money, and you generally don't get to have as many of them. That also means that designers are a lot more skittish about letting players avoid content. In Baldur's Gate 2, siding with the vampires or the Shadow Thieves gave you entirely different dungeon hacks at the end, and after you finish the big fight at the asylum, you have a choice that results in you either ending up in the Sahuagin City (after which you go to the Underdark) or just going straight to the Underdark. Players who make a certain choice end up skipping an entire dungeon. In Jade Empire, there were encounters that you could skip, definitely, but there was no way you were gonna skip an entire dungeon -- the dungeons were just too expensive and too few in number.
(NWN2 was pretty good about this with the quests that let you side either with the city watch or the thieves -- you ended up doing mostly the same quests, but with different enemies in place. The players get to make a choice, and the designers didn't have to design entirely different levels, half of which nobody was going to see on a single playthrough.)
Right now, we're focusing on making dungeons (where here, "dungeon" means "an enclosed area with a bunch of combat in it") that give the players multiple reasons to go inside -- so the player doesn't have to make the choice between getting content or missing content for roleplaying reasons (or worse, being forced to get the content and having the only choice be whether you're polite or rude about it). We're also trying possibilities for getting quests for the same content from entirely different people, so that if you tick off the elves who were going to send you into the haunted ziggurat, you can still get a similar quest from the local dwarves -- you might be hunting for a slightly different quest object, but you're still wandering through the haunted ziggurat and killing pretty much everything you meet.
We'll see how it turns out. A lot of these things we're prototyping are pretty minor in and of themselves, but when you throw in three or four of them, suddenly that dungeon is looking quite a bit different...
You can use voice commands in the game? wow, this may make it possible to play via console
Quote: ‹ Select ›
What I can't talk about.
It's a frustrating time on the blog these days, not because work is going badly, but because work is going well, and I really can't talk about it in any kind of useful detail.
We're doing... things... with plot hand-ins. The short and legal version is that we're looking at ways to speed up the roleplaying process, or at least the parts of the roleplaying process that need speeding up. As I've said before, I don't think that going through eight nodes about finding a magical acorn for somebody is valuable roleplaying. The guy or gal who needs a magic acorn might be written well, but at this point, it's not necessary to tell somebody to pick up the plot item he finds lying around in the nearby dungeon, and if those words can be better used elsewhere -- like in a romance, or a complex plot that actually needs some explanation, then the words should be cut. Same deal for plot hand-ins. Giving the acorn to somebody and then saying "You're welcome" or "Arrrr, pay me more" isn't roleplaying these days.
So, at some point far in the future, when this game is announced, I'll be able to go into more detail. Until then, I get to be vague.
Quote: ‹ Select ›
Of Pixies and Puzzles
Today, I worked on a conversation puzzle for Revolver (aka the project that must not be named).
Conversation puzzles are tricky animals. Back in the good old days, they were awesome, because conversation was the only thing aside from combat and "where people walk" that you could track really well. If you wanted a puzzle, you pretty much had "pulling chains / pushing buttons", "walking over squares in the right order to spell the names of ancient dead gods", "dropping objects onto squares to make the right shape", and conversation puzzles, in which the puzzle was anything from a debate to a trial to decoding a made-up language to, well, whatever else the writers could come up with as puzzles without having to bring in a tech designer.
Now, of course, the player's voice is used in conversation, which pretty much spells the end of conversation puzzles in most of their forms. (This isn't true for every BioWare project, but it was true for Mass Effect, and it is going to be the case for Revolver, which lives down the tech-stream from Mass Effect, so there we go.) Some people might suggest that you simply not record VO for the puzzle-type situations (like if the conversation file represents reading a note on the door, for example), which sounds good to non-programmers like me, until we get summarily kicked in the shins by cinematic designers who very politely talk about built-in automated camera tools and staging utilities and pause-for-recording-time algorithms and, well, a whole lot of stuff that makes normal conversation work without somebody's head exploding, and which is just big enough and tricky enough to make "just turn off the VO for this part" the kind of thing that makes it a bad idea to casually try to use it for puzzles.
So we don't really have conversation puzzles anymore. Away they fly, off into the land of things that used to be. I imagine they'll find a gentle nostalgia thermal to drift along, possibly falling into formation with animation sprites and turn-based combat as they sail off toward the horizon.
This doesn't mean that we don't have conversations that are tricky, of course. We have them in Mass Effect, although that ended up being a learning experience (in which we learned that spending 2300 words of dialog on one clever tricky conversation that used a whole bunch of conditionals and blank-node pyrotechnics to replicate a neat little negotiation is maybe not something you want to do all the time unless you didn't have a whole lot else to do that weekend). And we're going to have them in Revolver as well.
But, like everything else in the project that must not be named, they're getting a face-lift.
A lot of our basic assumed systems for conditionally displaying dialog are based on NWN-logic, things that made sense to writers who were using that toolset. The toolset we're using now is different in a few important ways -- namely that we have blank nodes (which is a fancy way of saying that if you have a node filled with no text, the system skips it, but STILL CHECKS ANY CONDITIONS OR ACTIONS ON THAT NODE), which we didn't have in Neverwinter, and that we now have category-based player options. The former means that writers can essentially program in the dialog toolset, putting one conditional query on each blank node in a list instead of just making the world's biggest conditional statement and slapping it up on there.
The second affects the way that we set up player choices. See, in the old system, you had potentially unlimited player options, and you just said, "Hey, show this one if X is true, and show this one if Y is true, and show this one if Z is true, and always show this last one."
With the new system, we have categories for where each player option goes -- the good, normal, and evil options, the option that is usually just a goodbye, and so on. And when the system starts looking for player options to go into those slots, it just takes the first option listed as that type of dialog choice that tests as TRUE.
I imagine many people, people too polite to just stop reading, are cocking their heads thoughtfully and trying to figure out why this means anything at all. Well, it sort of does. Let's say, for example, that you have a conversation puzzle, and you want to determine whether the player has done X, Y, and/or Z.
In the old system, if you wanted to test that all in one dialog node, you'd need to make:
1. Blah (appears if X AND Y AND Z)
2. Blah (appears if X AND Y BUT NOT Z)
3. Blah (appears if X AND Z BUT NOT Y)
4. Blah (appears if Y AND Z BUT NOT X)
5. Blah (appears if X BUT NOT Y AND NOT Z)
6. Blah (appears if Y BUT NOT X AND NOT Z)
7. Blah (appears if Z BUT NOT X AND NOT Y)
8. Blah (appears if NOT X AND NOT Y AND NOT Z)
9. "Screw this dialog puzzle. Prepare to die!" (Always appears)
And wow, let's hope that X, Y, and Z are very easy conditionals to test, because of any of those are nested complex thingies in themselves, well... yeah. It gets really obvious really fast why most conversational puzzles in the old system used turns:
Pixie: (Some riddle that tests for X)
Pixie: (Some riddle that tests for Y)
Pixie: (Some riddle that tests for Z)
Player: Uh... is it some kind of insect?
Pixie: Oh, it looks like you haven't learned all of the answers yet. Come back soon!
Doing it that way is just a ton easier than writing 8 custom conditionals to test for every damn permutation.
But now, in the new system, the first thing to return TRUE when tested is what the player is going to see in any given spot. So if there's a spot called "Default", the basic ordinary answer, and we have that X-Y-Z puzzle, we can do:
1. BLAH (IF X AND Y AND Z)
2. BLAH (IF X AND Y)
3. BLAH (IF X AND Z)
4. BLAH (IF Y AND Z)
5. BLAH (IF X)
6. BLAH (IF Y)
7. BLAH (IF Z)
8. "Sorry. I have no idea."
That's the same number of nodes, but right there, it's already a bit easier to code, because you're not having to make a bunch of not-tests. If you put it into a turn-based fashion, it gets even easier.
Pixie: What have you learned from the spirits of the forest?
1. "Not to lie." (IF X)
-> Pixie: That's great. (Increment number of test-bits passed by 1) What else have you learned?
1. "Not to cheat." (IF Y) (links to the normal Y response)
2. "Not to eat the green berries." (IF Z) (links to the normal Z response)
3. "That's it." (links to the final testing bit)
2. "Not to cheat." (IF Y)
-> Pixie: That's great. (Increment number of test-bits passed by 1) What else have you learned?
1. "Not to eat the green berries." (IF Z) (links to the normal Z response)
2. "That's it." (links to the final testing bit)
3. "Not to eat the green berries." (IF Z)
-> Pixie: That's great. I'm glad you've learned something. (Increment number of test-bits by 1) (link to final testing bit)
4, "Nothing. Sorry."
-> (Final testing bit: count number of test-bits.)
(If 3) Pixie: Wow! You rock! Have some XP and a new sword! (Quest ends)
(If 0) Pixie: Okay, you had nothing. At least put in a token effort, Sparky. (Quest still ongoing)
(All other cases) Pixie: Well, you did something. Here. Have a little XP. (Quest ends)
A ton less duplication of writing effort, and far fewer custom conditionals. Best of all, the conversation only lasts a long time if the player is doing well by getting the correct answers. A player who hasn't done very much and isn't gonna ace this puzzle doesn't have to go all the way through the damn puzzle just to learn that he didn't get a very good score at the end of it -- the pain is quick. This ends up rewarding the story-exploration players (the people who explore every possible dialog choice and investigation hub they can find) with what they want: more dialog. (And XP, but who doesn't want more XP?)
I'm looking back up at all that, and it's entirely possible that nobody except me is ever going to care about this post. Ah, that's what the LJ-cuts are for.
That said, it was still really cool to realize that I'd shaved some words off a conversation puzzle, shortened it for people who weren't doing well, and kept the logic simple. For a non-programmer like me, it felt pretty good.