| |
Site Navigation
Main
News
Forums
Games
Games Database
Top 100
Release List
Support Files
Features
Reviews
Previews
Interviews
Editorials
Diaries
Misc
Download
Gallery
Music
Screenshots
Videos
Miscellaneous
Staff Members
Privacy Statement
|
|
Here are some topics from the official Icewind Dale II forum.About the subraces levels
It will make exactly one level of difference, actually. A moon elf fighter with 250,000 XP can be 9th level with his or her standard bonuses. A dark elf fighter with 125,000 XP is 8th level and gets an additional +2 to intelligence, faerie fire 3/day, magic resistance, day blindness, and vulnerability to fire spells.
BTW, the reason the penalty ends at 10th level is to keep dark elves and other races one level behind everyone else, instead of many levels behind everyone else. If they kept their penalties, the moon elf fighter above would be 20th level with 3,000,000 XP and the dark elf would be 14th level with 1,500,000 XP. That's a little severe.
The reason why the stas of sub-races are different from the manual
We're not bowing at an altar, here. Not all racial bonuses and penalties can be implemented according to the FRCS totem pole. In fact, the deep gnome's Non-Detection power (and Non-Detection in general) downright screws up the whole game when combined with Invisibility. Drow cannot levitate or cause globes of darkness to appear. Ghostwise halflings cannot telepathically communicate with other halflings (and even if they could, how often would that come into play?). In the course of adding and subtracting the various powers that sub-races can and cannot have, we find ourselves balancing according to what is left of their abilities.
A reply on some comments on rushing out games and not listening to board members
Let me take a few moments to explain some things, from my perspective.
This project started development in the summer of 2001. At that time, we were looking at a 4-6 month dev cycle, which is completely and totally insane. Steve Bokkes and I wrote the original story and area documents. These areas were split up between the designers, with me getting only two.
I focused the majority of my attention towards helping the designers have a collective understanding of the story, characters, and general design goals in the game. Once that had been established, I focused on what I arguably am best at: rules design and implementation. Given the original length of our dev cycle, I compiled a three phase list of rules changes that I believe could be implemented. The first phase included the implementation of kits (a given), the implementation of sub-races (based off of the same general idea of kits) and the implementation of 3E ability scores, saves, and attack bonuses. The second phase included the implementation of true 3E feats and skills. The third phase included the dissolution and restructuring of the creature file format, interface, and general engine code to accommodate true 3E multiclassing. The phases were based off of what the dev cycle might actually become (in case someone thought, "A game in 4-6 months?! WHAT?!").
A number of other tidbits were included on those lists: spell disruption checks, the addition of the use magic device skill, bonus spells for all casters based off of high ability scores, ability score stacking rules, armor subtypes, the player scripts that never made it into HoW, and a bunch of other little junk. We attempted to discuss most of these ideas with fans given the obvious obstacle that our game could not legally be announced. While we do listen to our fans, we do not listen for volume. We attempt to listen to arguments. If we are persuaded by arguments, we attempt to implement sensible changes. Sometimes, unfortunately, those changes just can't be made in the time available for us. I designed an entire list of feats and the methods by which they could be used, given our interface. Unfortunately, my design doesn't magically implement itself. It requires the efforts of many attentive programmers -- who are busy making the game as bug free as they can. Implementing new features or making large changes to old features is time NOT spent fixing bugs. In fact, it ALWAYS creates new bugs.
To give an example of what a new feature requires, I'll use base attack bonus. BAB is the replacement for 2nd Ed.'s class/level-derived THAC0 system. It's seemingly a simple change.
* Step 1: Give the producer and programmers a BAB system design that will work in your engine that closely, if not exactly, imitates 3E's BAB system.
* Step 2: Convert all 2DA files that list THAC0 bonuses to 3E BAB bonuses.
* Step 3: Programmer makes sure that BAB is derived from 2DAs in the same manner as THAC0 was derived from 2DAs.
* Step 4: Programmer removes 2nd Ed. attack progressions for warriors based on class, level, and specialization.
* Step 5: Programmer implements a system in which all classes gain additional secondary, tertiary, etc. attacks from an increased BAB that ignores secondary bonuses from weapons, spells, etc.
* Step 6: Programmer implements a special system in which monks gain additional hand-to-hand attacks at an advanced rate, despite a slower BAB progression.
* Step 7: Programmer implements a system for handling off-hand attacks and base multiple attacks from creatures with claw/claw/bite or similar attack actions.
* Step 8: Programmer makes a batch conversion files that derives new BAB values for creatures to replace their THAC0.
* Step 9: Programmer modifies the creature editor so that THAC0 reads "Base Attack Bonus"
* Step 10: Programmer makes a batch conversion of creature files to remove half attacks, which do not exist in 3E.
* Step 11: All functions in the game that grant THAC0/attack bonuses are converted into BAB bonuses.
* Step 12: A designer goes through every item in the game that grants a bonus to hit, removes the word "THAC0:" and replaces it with "Attack Bonus".
* Step 13: Spells and effects that double a character's number of attacks are converted to granting +1 attack at the character's highest BAB. Programmer insures that extra attack does not drop the AB for the "real" primary attack, secondary attack, etc.
* Step 14: All code is implemented and all data files are updated. QA is informed of the changes.
* Step 15: Bugfixing.
BAB was one of the more difficult changes we made for IWD2. We're not trying to exaggerate when we say that some things are easy to do and others are not. We do listen to you, we really do. Often, unfortunately, we can't do what you're asking us to do. Sometimes, we have to listen over the din of many conflicting opinions and simply make a decision that seems sound to us from our perspective.
I spent a lot of time on the message boards prior to the announcement of the title. I spent even more time on the boards after that. Unfortunately, that means I'm not getting work done. I'm not answering Dave's questions, I'm not helping Darren, and I'm making absolutely no progress whatsoever on my new project. I believe it is essential for us to answer as many questions as we reasonably can. I try to be thorough with my reasons for design decisions, and I try to argue a point as long as I believe parties are gaining something from the exchange. However, even I get burned out. I picked a point at which I believed I had answered the vast majority of questions thrown my way and I started focusing my attention on work. I hope that searches through the archives and the presence of other BIS employees on the board can answer the majority of your questions. |
|
|
Icewind Dale II, Forum Update
