12 réponses à ce sujet

[Happycrow]

For those of you who are older than dirt, yes, it's that Sunset World.  Or a take on it, anyway.

 

So, former PW devver here with an odd and incomplete skillset, I've got:

1.  Solid, if probably unremarkable, area-design skills, a bit remedial on some trigger types.

2.  Lots of custom-content I've developed for the purpose.

3.  A solid story with twists, turns, and multiple potential endings that all look VERY different

 

4.  No experience ever in actually making a module

5.  Zero experience scripting at all outside of writing dialogues and doing journal entries ages ago.

 

Has anybody ever posted a "here's what we recommend hitting first, and here's a good workflow" article on nwn2 module design?  I'm ramping up to start this project going, but am finding that while I know the things that I know, I don't know what it is that I don't know, and that worries me.  I'm assuming the best workflow starts with "get the areas made and solid first," since that's what everything else builds on, but post that?  journals and such first, or npcs, or, or, or....?

 

Feedback would be lovely.

 

Thanks,

 

Happycrow

 

 

[kevL]

if & when i'm module building (got sidetracked trying to fix the game..)

I use the Jackson Pollack / random machine gun method. (1) open toolset, (2) do something.

This method means I'm either doing something enjoyable, or deemed wothwhile.


Only later will i go back and fill in blankspots, this is a sandbox approach -- so having a(n ambiguous) plotline in mind develops itself and helps maintain a sense of Aristotelian unity.

[rjshae]

Do you prefer top down or bottom up design? If the former, you might start off thinking about what type of world map or overland map you want to use. Once you have that, then the various exterior areas can be built and populated, followed by the interiors. Bottom up approach would just be to start with a small area and then keep adding to it. You'll get faster results with bottom up, but it can end up more helter-skelter and inconsistent.

[Vekin101]

Good luck with the project Mr Happycrow!

 

No real imput from me as I am even more stunted than you in the toolset but maybe you should think about a "prologue" type module first to sharpen your skills and have goal you can achive before slipping into the timesink of a module.

[Happycrow]

Hiya, Veek!  Prologue won't work specifically for this, but I could do a little testbed thing, yeah.  

 

Design-wise I'm definitely top-down with this stuff.  I'm tempted to use neither a world map NOR an OLM for this, since the terrain you run back and forth across is a fundamental part of the story rather than just "flyover country."  If I can figure out how to make an OLM have plenty of elevation and terrain changes and be otherwise quite dynamic it might be an option; I"ll have to work on it.

[Happycrow]

KevL: the problem with Aristotelian Unity is that it tends to violate Aristotelian Physics.  At least, if you prefer that a single action be done in a single time.

[kevL]

post-post-modern Aristotelian unity then -- i agree Aristotle's a bit out of date ( the quantum violation of Bell's Theorem blows my mind, it really really does )

[PJ156]

If this is a story based module I can tell you how I do things.

 

I plan out the story to start get the overall story arc in my head then work out what areas i might need and what major cutscenes and scripts/cc I might need to move it forward.

 

I then prepare a flowchart which tracks the principle elements of the story and the way in which it will develop. this will identify when multiple threads will combine and appropriate places for side quests. All the big conversations and plot developments will be on this and some notes to flesh out how the story will begin. Not too detailed at this stage as this will likely change as I start to mod. at this stage you can identify 90% of your areas and how they might look. You can then work on the current and gather music, cc and other resources ahead of the later areas and convo's/scripts.

 

This method allows you to control scope creep.

 

In my latest work I then have prepared a spreadsheet. i use that to track tags and integers write my text (to make use of the spellchecker) and keep track of cc for credit purposes.

 

I then start with the first area and work my way through the plot.

 

I do not advise doing all the areas first as you will burn out and quality will drop. Do a little bit of something different each time to keep this interesting.

 

I advise that you test as you go. get each section near perfect at each stage. It means that when you come to test the whole thing it is all in place but the polishing. If you have to test to fail each time it's going to get very dull if you have left a lot of fail points ... and you will leave lots of fail points.

 

That's how I do it.

 

PJ

[Jezla]

Here's my $.02:

 

If you're telling a story, then plan your story first.  That is, know how it begins, how it progresses, and how it ends, as well as who the antagonist is and his motivation.  This will allow you to define your limits as far as what you need to build and do (I like PJ's term: avoid scope creep).  Once the main plot is established, it might be advantageous to decide what side-quests you want to include.

 

At this point I make a list of the locations I need for the story and side-quests.  This will be the basis for area planning.

 

Next, it's time to surf the Vault!  After I have an idea of the locations I want, I search for prefabs that might meet my criteria.  It's much easier sometimes to work with a prefab than it is to build every area from scratch.  I found several good ones to make use of for Legends of the Dalelands, and it's cut down build time considerably.

 

While I'm looking for prefabs, I'll also look through the various CC available and decide what I want and need.  Here's my rule of thumb for CC:  Use only what you need to tell the story or make the game more enjoyable for the player, not just anything you see that looks cool.  Think about creative ways to use the existing resources before you add haks.  This helps cut down toolset clutter, as well as reducing the risk you'll spend gobs of time figuring out that two CC packs aren't compatible.

 

Next I'll make an area planning document.  For LotD I did something like this:

 

Mod Name (mod_tag)

Area (area_tag) (Interior/Exterior) (Prefab Y/N)

Environment (lighting, weather, mood, type of terrain)

Events (Key story moments or encounters that happen in the area)

NPCs (key NPCs that will be placed in the area)

 

This document then becomes my guide through the build process.  When building I tend to build by quest.  I'll write the quest entries in the journal to plan all the steps in the quest, then I'll work on the areas for that quest.  It helps to stave off burnout by moving from major quest building to 'filler.'  Generally i save the generic NPCs and such for last, once I've made sure the quests are built and tested.

 

Hope this helps!

[Happycrow]

Great feedback, folks.  This is more than enough for me to start planning out my dependencies.  Thanks.  Will be a bit, but I'll start posting up progress here and there as it goes.

[kamal_]

Self pimpage:

http://forum.bioware...up-and-running/

[Happycrow]

Thanks, Kamal - that sort of thing is DEFINITELY helpful.