8 réponses à ce sujet

[Sunjammer]

I've been trying to put together a flow diagram for module development which takes account of the various dependencies to try and determine what order things need to be done.

Some things are obvious: you need to create levels before you there is any point in creating areas and need to create the conversations before attempting to create a cutscene with dialogue. Others are perhaps less obvious, for example, during the beta we found that it was a good idea work out all the plot flags before trying to write the conversation.

Anyway this is what I came up with before my brain melted and dribbled out my ears ...



I'm beginning to think that putting it all on one diagram doesn't really work and perhaps the solution is to create process flows for specific tasks. For example if we need cutscene for our project what steps and designers will be required to create it, etc. I didn't manage to place every resource type (scripts for example could be attached to anything with and asterisk) and I changed my mind about three times as to what the arrows mean (so I'd ignore them).

Does anyone have any better suggestions and/or better software for presenting the module development workflow?

Modifié par Sunjammer, 13 décembre 2009 - 09:58 .

[Sunjammer]

Incidentally the image is a lot bigger so if you save it or view it on its own then you'll be able to read it.

[FalloutBoy]

Probably MS Project is what has been used on most of the projects I have worked on. Its not perfect, but I'm not familiar enough with other options to recommend anything else. At work right now we are using a web-based tool called JIRA which you can google if you like.

[Sunjammer]

I've not much experience with either but I suspect they may be overkill for flow/process diagram.  I tried SmartDraw earlier but it gets very upset if you have cyclic dependencies or you try to split things too much.  That said the software is only a secondary concern: our main focus should be working out the best approach to creating a module.  At a high level it is:

Writing > Custom Content > Art Resources > Design Resources > Module

Obviously designer can't really do anything until you've written the critical path and side quests (at least at a high level) as this will dictate everything else.  You need some form of the CC (even if it is only rough placeholders) before you can start on the art resources and you need the art resources before you can really do anything in the actual module.

However where I think the trouble starts is when you drill down into the Design Resources (the orange boxes in my diagram).

[JJM152]

Maybe you should start off with a Venn diagram first, just to get it straight in your head where all the areas of responsibility overlap before you attempt to attach any progression to them? I think Google chart API will let you do this... someone can probably correct me.



Also, your workflow diagram isn't very workflowy. It doesn't really show me the steps that are needed to acomplish anything (which is what workflows are supposed to do). Maybe you should start off with a big overall workflow that just deals with top level concepts and then build down from there. For example:



Step 1: Plotting your Module

Step 2: Interacting with the Toolset to lay out the actors and environments.

Step 3: Wiring up Scripting

Step 4: Exporting Module



That may seem pedantic, but that's what workflows are - an ordered list of processes based on conditionals. Processes of course can have sub processes that loop, etc (the basis of most popular PM principles like PRINCE2).



Anyway, this would certainly be a challenging endeavor, but I think if you actually want to complete it you might want to do it as a series of individual workflows starting from the top, most basic elements, and then drilling down and looking for overlap.

[FalloutBoy]

I disagree that design requires that the writing is done first. Is there going to be one or more forest levels? Swamp levels? Island? Big city? Small village? They can start making areas long before the details are fully fleshed out. They just need some rough outline of some areas to work on. If that means revisiting some areas later for touch-up work, so be it. It's better than people sitting around for weeks doing nothing. And they may just make something cool enough to fit the plot around it.

Your CC creators can work in parallel with everything. In fact that could be one of the last things to go in if you use placeholders.

You can also work on side quest content if the major plot isn't done. There's no such thing as a module with too much content.

I think OpenOffice comes with a MS Project equivilent. I would look into it if I were you. Break major things up into modular tasks and start entering them. I think you'll find that there is a lot of potential for overlaping jobs. One thing I always say when I start thinking "I can't do this until someone finishes that first." I ask myself what is the first thing I would do if "that" were done right now. Most of the time whatever it is doesn't actually require "that" to be done after all.

[TimelordDC]

I don't think a single flow diagram will work for the majority of the projects. The module development process is similar to a multi-developer project => not only in terms of the actual team members but also in terms of handling the different areas of a module. And a module is not like a formal project where everything in the project plan is required (ok, at least in the project design phase). Lots of things are optional in the module as a whole (VO, custom animations) and not every aspect will be present in every area.



The diagram would work if it is about a single playable area, though, once you color-code the optional aspects in area design.



Taking a sample, simplistic module consisting of 2 areas as a template, you could also come up with a list of things that interact with areas to achieve the final module. Eg: Plots can be across areas whereas cutscenes would be within an area block.

[JJM152]

FalloutBoy wrote...

I disagree that design requires that the writing is done first. Is there going to be one or more forest levels? Swamp levels? Island? Big city? Small village? They can start making areas long before the details are fully fleshed out. They just need some rough outline of some areas to work on. If that means revisiting some areas later for touch-up work, so be it. It's better than people sitting around for weeks doing nothing. And they may just make something cool enough to fit the plot around it.

Technically, asides from having to start open the program, you can begin on whatever part of the overall building process that you want to.

Workflows aren't necessarily a check list of things that you must do in a specific order. Instead they are often used as guidelines to help people put structure around what could otherwise be a complicated task.

Fixating on the endless permutations of the order that you could possibly do something in is a dead end. It's better to come up with "a way" (even if it's not the only way, or even the best way) and then streamline it and structure it enough so that it can easily be taught.

[FalloutBoy]

I don't know if it seemed like it, but I wasn't disagreeing with you JJ. You are right. You can lay down an ordered checklist for the critical path, but there is lots of other work that can be done in parallel. Almost all of it except the specific things in the critical path.



Like you know there will be a town in your module at some point and this town will have people in it. Someone can start making people. Is there going to be an awesome boss fight? Use a nug model as a placeholder if you have to and have a scripter start making AI for it.



The b2b export process makes it really easy to prototype things in test modules and export/import them into the final module when they are ready.