RPGWatch Forums

RPGWatch Forums (http://www.rpgwatch.com/forums/index.php)
-   News Comments (http://www.rpgwatch.com/forums/forumdisplay.php?f=10)
-   -   NWN2: Mask of the Betrayer - Design Interview @ Iron Tower (http://www.rpgwatch.com/forums/showthread.php?t=5262)

Dhruin August 25th, 2008 21:50

NWN2: Mask of the Betrayer - Design Interview @ Iron Tower
 
Vince D. Weller has a great interview with NWN2: Mask of the Betrayer creative lead George Ziet, discussing the design aspect of MotB:
Quote:

I guess you and Kevin Saunders really pushed the game into a different direction from NWN2. What was behind this decision? What are your thoughts, as a designer, on NWN2?

NWN2’s biggest sin was probably ambition. The team tried to do too much in too little time, and everything suffered a bit. It’s an awfully common story in the games industry, as anyone who plays a lot of games probably knows.

So when Kevin Saunders and I started preproduction on MotB (before NWN2 had even shipped), we ended up being pretty conservative… and that was for the best. Credit goes to Kevin for this - he recognized early that we had a short development cycle, and we had to focus on what we knew we could achieve, and nothing more, lest our game feel unfinished in the end.

For me, as creative lead, my unabashed focus was story. That turned out well from a production standpoint, since we could implement story with existing tools and tech. I really wanted to tell a personal story - more on that below - in a different part of the Forgotten Realms. So we devoted our efforts toward telling that story as thoroughly as we could, and we kept the core gameplay largely the same. There were some things we knew we wouldn’t have time to implement properly, like the NWN2 stronghold and a “full suite” of companions, so we dropped those features. (In fact, Kaelyn the Dove - my personal favorite companion - very nearly got cut. Timely assistance from Chris Avellone was all that saved her.)

That strict sense of focus taught me a lot. As developers, we should identify early what we can achieve in the time we have, and we should focus on those features. It’s better to build a game that delivers a smaller number of features at a higher level of polish than to build a game that tries to do more than development time allows, as NWN2 did.
More information.

pnutz August 25th, 2008 21:50

Ziets

And what a great interview, though I had to skim past some parts as I haven't played MotB yet, heh.

HiddenX August 25th, 2008 23:08

I am a software developer and system analyst - I work like this:

1) ask your customers for the most important, most essential, vital key features and functions that they want for the new software system.

2) let the customer prioritise the functions and features.

3) cut the last 20% - I love that ;)

4) add some indispensable features (from the developers point of view)

5) make a time plan / notate the most important use-cases / make test-cases

6) begin to develop

7) make prototypes, implement the most important things first, show them to the customer, test key functions (with the customer!)

8) adjust the priorities, functions, features, test-cases (with the customer!)

iterate 6) - 8) until you are ready - if the customer is available on a daily basis, you can iterate on a daily basis.

With this agile method of software development you get nearly bug free software in a short time and fully satisfied customers. Design errors, programming errors are recognized very early and can be fixed early, that saves a lot of money.


Agile Manifesto:
Quote:

* Customer satisfaction by rapid, continuous delivery of useful software
* Working software is delivered frequently (weeks rather than months)
* Working software is the principal measure of progress
* Even late changes in requirements are welcomed
* Close, daily cooperation between business people and developers
* Face-to-face conversation is the best form of communication (Co-location)
* Projects are built around motivated individuals, who should be trusted
* Continuous attention to technical excellence and good design
* Simplicity
* Self-organizing teams
* Regular adaptation to changing circumstances

Alrik Fassbauer August 26th, 2008 00:36

Yes, I had read about this technique.

It looks promising to me.

Prime Junta August 26th, 2008 11:19

It works, but it's not easy to apply. In particular, it's hard to find customers that agree to use it — those annoying gits usually insist on nailing down the feature set *before* signing the contract.

It also takes a team with rock-solid skills in the underlying techniques, a very good technology infrastructure, a team made up of largely "self-steering" individuals, and strong team discipline with regards to stuff like coding standards, use of shared tools like source repositories, issue trackers, documentation tools (we use a Wiki), and so on. They need to be able to continuously refactor, to keep their code clean even as it constantly changes, to be able to quickly switch code between each other (i.e., write and comment code to a fairly strict standard that emphasizes readability), to maintain the integrity of the system in a source control system, to test everything all the time, and to automate everything that can reasonably be automated. None of that is easy, and very, very little of it is taught at schools. The actual programming part — figuring out how to express an idea as an algorithm, and then expressing it — is the easy bit.

We've been doing things this way for the past five, six years or so, and are gradually getting better at it. We've even been lucky enough to have a few fairly big product development projects with the kind of customer involvement HiddenX describes. They worked out great. But no, it isn't easy at all.

And it still means that you have to nail down your "choke points" — critical features — as early on in the process as feasible. It's just a better, more reliable way of identifying and nailing down these features. :)

Maylander August 26th, 2008 11:41

Work at a very large bank myself (as a developer), and while we're using some principals of agile development, we can't use all - the wheels turn slowly here (so many people have to get involved for every little change), so going back and forth between the client would take too long.

However, we have been trained in, and use various ideas from, development methods such as scrum, rup, msf etc. Our development method at the moment is not a specific method, it's one we've adapted to fit our needs.

Anyhow, it was an interesting interview. It is certainly noticable that MotB got more polish than previous Obsidian product, as it is the best D&D product in a long time (in my opinion).


All times are GMT +2. The time now is 01:40.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
Copyright by RPGWatch