jcompton

Oh, absolutely. And it's also an interesting choice to think about for the imperfect world we live in: - Would you rather have an interactive romance that is interactive but not especially romantic, or romantic but not especially interactive? A lot of complaints come from the opposite direction as well. In a measurable number of them, it is possible to just sort of float by choosing the noncommittal responses, and still get to the end of the romance. That leads to another design question I'm surprised didn't come up in the original post: - How difficult should the romance be? Accidental clickage of cheese graters aside, should it just be outright impossible to randomly guess your way through the romance? Should it actually be Hard to get the NPC to love you forever (or love you so much they have to leave you/kill you/betray you/whatever, if you want to play it dark)? Conversely, should it be Hard to get the NPC to break the romance? I feel that a romance that is part of a larger RPG challenge should not be itself a minigame. If you're ever putting the player in a situation with four choices, three of which are romance-breaking but none of which are patently offensive or dismissive, you're probably making it too hard. If there are totally unspoken challenges (You have to volunteer to buy Jim the Jester a new hat at one of the first two haberdashers you encounter, even though Jim's never mentioned wanting a new hat, or else he terminates the romance), that's also too hard. Don't make it "original Pirates" simple ("shall I Make Pleasant Conversation, or just Propose Marriage?") but don't require the player to collect the rose, the perfume, the candles, the massage oil, the book of poetry, and train up CHA or Bluff before the romance can be completed. That's not to say that you shouldn't expect the player to be observant about the NPC's personality. ("Why did Chaquilla get so angry and stomp off when I asked her if she was going to write a letter home? ...oh, right, she's told me before that her brother slaughtered her entire family and left her just barely clinging to life!" That's valid, if extreme.)

No, it's not--but writing romantic development in linear prose is somewhat different from writing it in a branching-interactive setting, particularly one in which the player character may be a homicidal maniac, or a kleptomaniac, or a sociopath, etc. etc. Unlike in a flat one-on-one romance story, the PC is not a fixed concept, it's something that the player makes up as he/she goes along, as the game exploration and dialogue options allow. Even people who are genuinely enthusiastic about this style of CRPG romance inevitably have a moment where they stare at a reply screen and conclude, "Well, that sucks. My character wouldn't say anything remotely like any of these to Suzie the Sorceress to comfort her about the loss of her favorite penny loafers." Even if you get a great critical-path romance outline from someone who is very very skilled at flat narrative*, you still need to bend and shape that into something you can guide a large percentage of your player base through without them feeling that they have no influence over the course of the romance, or are being forced into a tiny box of reply options in order to play nice with the romance NPC. (And, of course, if the interactive person is ham-fisted about their job, it may end up still feeling too linear, or being almost impossible to navigate because the new options tend to sabotage the critical path... etc. etc.) Actually, I was a little surprised to see that the original post doesn't really address any of the interactive challenges, which are more than just a mechanical concern. They color the type of character and the types of situations you can successfully communicate in the game romance. What personality types do you choose to exploit on the PC side, and which will the NPC either reject outright (and how will they know?) or cut off the romance with if they show up too often? After all, somebody has to decide things like "When can we assume that the PC probably really does like the NPC and will avoid being deliberately cruel?" NPC: "Oh, <charname/>, you really are one giant barrel of role-playing love. Now that we are at a dramatic inflection point approximately 60 percent through our romance, I think it important that we have a serious talk." PC1: "Sure, honey. What's on your mind?" PC2: "Get away from me before I sand your face off with a cheese grater." If you don't offer cheese graters in the early going, players will complain that they feel they were forced into the romance, that their "Grugnak the Destroyer" PC concept was not properly honored by the designers, blah blah. Continue to offer cheese graters too late and, on some subtle level, it can color the player's feelings toward the NPC and about the relationship. (In the real world, we may occasionally bite back a really great cutting remark we thought of firing at a loved one, but if every time we see them we strongly consider making them cry, it's not a Quality Relationship.) These types of things don't come up in a flat narrative--sure, a romance novelist may "let you inside the head" of a character to see the different options they consider in certain situations, but the scope is nothing like this. * - There's a bigger "Why games should/shouldn't be written by Hollywood screenwriters" debate here as well...

In part that's because the model has inverted over the past 10 years or so. In the past, "games you build other games with" typically fell into one of three categories: - An end-of-life way to squeeze more out of a successful game engine at the end of its life. Stuart Smith's Adventure Construction Set, Bill Budge's Pinball Construction Set, Garry Kitchen's Gamemaker, Bard's Tale Construction Kit, "gold box" Unlimited Adventures, etc. The public product reflected a proven game engine which probably wasn't going to be used for any new titles, and a mixture of internal developer tools, cleaned up somewhat for the general public. - A failed attempt to build a commercially viable engine, repackaged as an editor. - A game shipped with some tools as a "here ya go, kid" afterthought. (I'm sure there are a few exceptions, but you get the point.) NWN(2) were expressly different, and of course the widespread public Internet has increased pressure to allow more content creation because it's drastically easier to share your content with more than just a few friends. (You see the occasional person asking "Hey, does anybody have that ACS/BTCK game I uploaded to Q-Link/CompuServe years and years ago? I've lost my original disks!" here and there, but for the most part, those mods and modded products just didn't have legs.) So it's changed the order and the timing of when developers may start caring what the public thinks of the tools, but I still say little has changed from an engine development standpoint. It's true that you don't get the advantage of "ripening" the engine over a few public products before releasing the tools like you did with ACS/BTCK/etc., but I think most eager modders are happy to take that trade.

My strong intuition is that most of the time, "we'll need to cripple the engine, and therefore the content creation tools, so that the average retail customer content creation enthusiast can use the tools" is not the case. Sticking with the item creation example, it seems a slam-dunk that a "friendly front-end" lets anybody who can hold a mouse make a Sword of Wounding that, say, does double-damage on hit, lets an intermediate content creator slap a script on it which also plays a special sound effect and a color pulse (or something) through a simple short block of code, and lets an advanced content creator cause the sword to also solve all Sudoku puzzles within 100 meters of the wielder using a complex script involving a call to _fold. A sensible, consumer-oriented toolset would make it easy to do the first, doable to do the second, and probably offer no advice whatsoever about doing the third. My point is, I would be shocked if any engine designers deliberately omitted features because they didn't know how to expose them in a friendly toolset. It's far more likely that an engine wouldn't have, say, a _fold function because the designers didn't think anybody at all would use it, not because they were obsessing over ways to explain complex math within a friendly toolbox window.

That being the case (you are not someone angling to find work by mastering a toolset and then going to the developer of that toolset flogging yourself as an employment candidate), the solution seems obvious--find a game/game maker which you enjoy creating content for, which has a collection of tools you are comfortable using, and do your thing. There is hardly a game or gaming genre on this planet you won't be able to find some number of players for, if you want your work to be seen. Don't worry yourself about games whose development environments are outside the scope of your abilities, as that will distract you from implementing your ideas in an environment that is within the scope of your abilities. If I'm reading you right, it sounds like you're saying you grasp how to create content in NWN. So... create your content in NWN. There is no rule that forces you to implement your ideas in the newest game environment on the shelf. Do you genuinely believe that a Sword of Wounding defined with hand-rolled assembly language makes a better Sword of Wounding than one made with XML datatypes or a pretty GUI? All else being equal, usable tools give content creators more time to create. If your complaint is that ease-of-use creates a glut of content of questionable quality, that's what reviewers, peer recommendations, etc. are for.

It came down to a matter of convenience. The conversation went something like this. JC: "So. Shall we have 2D, 3D, or a hybrid? (blah blah blah listing various pros and cons.)" WW: "It's very simple. You can have a 2D engine. You can't have a 3D engine." JC: "Okay, then!" We did look into licensing existing 3D and 2D/3D RPG engines but they were out of our price range. Not with any real authority. But you did say "speculate," so... presumably character/creature work would be somewhat faster in a 3D world because the artists wouldn't have to spend a lot of time rendering a zillion frames of each individual layer. I suspect area creation time is only slightly longer (due to the need for special solidity, occlusion, light, etc. maps, but those are actually fairly easy for the artists to construct) and may actually be faster since the area only has to "look good" from one angle. I'll be satisfied with the schedule when we're done. As for artist availability (within our budget, of course), I was a little surprised to find that it was relatively easy to find area artists who could also meet our requirements for special mapping, animation overlays, and so forth but rather difficult to find sprite artists. In retrospect this makes a lot of sense, as soup-to-nuts sprite work isn't much in demand, therefore younger/newer artists aren't being trained to handle it, and the older artists who mastered it 15 years ago are all management or otherwise highly paid nowadays and don't have time to indulge our need for recolorable elves, flaming swords, and tendril staves.

That's basically true, although there are exceptions which require/strongly recommend paying attention to install order due to: - Being a "big fix/tweakpack." Generally things which comb over many or most of the files in the game making wholesale changes like to go first so that they can make their changes before other mods get their grubby little hands on them. There are exceptions, however, but most developers are good about documenting this sort of thing. - Content dependencies (Mod B has content which requires the presence of Mod A in order to work, like two mod NPCs talking to one another, or one mod quest adding content to another mod quest.) - Inefficient use of WeiDU (you're overwriting files you should just be patching in place because you were lazy, didn't know what you were doing, etc.) - Frequent updates of a mod, so you'd like it towards the end of the stack so that when you have to reinstall it, fewer mods have to be "peeled off the stack" first. Pre-WeiDU, the only things you could safely install atop an existing installation were fairly limited--items, I believe creatures, etc. Any changes to existing scripts or files were destructive. Adults were morose, children wept, the skies were gray. Etc. But, no, ToEE modders have their own suite of tools and installation methods, they do not use anything like WeiDU to my understanding. Honestly, I'm a little surprised nobody (other than us, in WeiNGINE) seems to have adapted things like WeiDU dialog construction/compiling for use in other projects, mod or otherwise. (It's GPL, so.) I know the NWN(2) dialog editor gets some good reviews, but any graphical editor would be hard-pressed to code up a complex multi-actor dialogue more quickly than a Wei*-style conditional chain allows. (And even for simple single-actor/PC reply dialogs, it doesn't take more than a few states for .d syntax to start beating a GUI.) I suspect that the fact that one can count on two hands the number of people who are both interested in games and know OCaml is a limiting factor to adapting WeiDU's dialog compiler and patching system to other engine/data file formats. Actually, I think it's just one hand.

There are about 20 contractors involved in the story design, coding, and audiovisuals. If it was just down to Wes and me to make a game, it would probably look like Rogue.

It's intriguing to see IWG2 brought up in relation to this project, since Wes's experience with IWG2 was in fact a key consideration. If you'll permit me the historical digression... With IWG2, Wes was trying to shoehorn a story he liked into an engine (ruleset) he liked. Of course, he was doing this with (at best) a hand tied behind his back because he couldn't alter the engine directly, only through file modifications. After X amount of work on it, it was clear that there were some irritatingly fundamental differences between the two engine flavors which couldn't be easily papered over. What not everybody realizes is that before he started the project, he gave serious consideration to bypassing the shoehorn and simply writing a new engine which could give him a similar result. In essence, he chose the wrong option, but by time he realized it, the moment was gone and he wanted to work on other things. So, yes, when we first discussed this 18 months ago, we went over what had happened with IWG2, whether he had made the "right call", and whether he still believed he was up to writing a novel CRPG engine. In some ways, of course, the task is easier now than it would have been in IWG2-land--that was a project meant to play a specific game, which would have meant supporting all of its filetypes and quirks and whatnot. Our engine is built differently. It also afforded him the opportunity to implement a ruleset he liked even more than the 3E (ish) offered by IWD2. Now, whether he would agree that he made the right move in terms of his free time by saying, "Yes, Jason, I can write a new, novel CRPG engine for you" is another question, but the fact is that he did say he could and he has, in fact, done so.