gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

OffTopic > Life Cycle Models and Project Buy In

#169191 - sgeos - Tue Jun 23, 2009 3:19 am

gauauu wrote:
but I'll stop derailing the thread

Split from Extra programmer wanted in the Help Wanted forum.

I think that this is an important discussion, because a lot of people show up looking for help, and the standard response is something along the lines of "what exactly do you want help doing?", with the implied question of "is your project going anywhere?" Proper documentation answers the first question and indicates a positive direction for the project in question.

gauauu wrote:
sgeos wrote:
gauauu wrote:
<Devil's Advocate> *snip*

It sounds like you are advocating the code and fix life cycle model. I think that this is the wrong model for anything that requires more than about 50 man hours to complete.

Well, really I was thinking of something closer to the "Evolutionary Prototyping" listed above it,

Evolutionary Prototyping Summary wrote:
The manager must be vigilant to ensure it does not become an excuse to do code-and-fix development.

Evolutionary prototyping can easily degenerate into code and fix, or act as a euphemism, and from the standpoint of any potential team member it shares the same difficulties generating project buy in.

Clearly you can always use money to generate buy in. But not everyone is in a position to do this, so barring cash, the first thing to do is present a convincing case that you are not using code and fix- lack of a bullet proof spec is intentional and in the best interests of the project in queston. You must communicate that you are indeed using a proper evolutionary prototyping life cycle model, and that your project is organized and going to stick around long enough not to be a waste of time.

I think that barring a proper spec, your webpage, visionary concept materials and more than anything prototype need to be that much stronger. Also, I think that indicating the requirements of your current iteration is needed to answer question "what exactly do you want help doing?"

As far as commerical projects go, has anyone successfully approached a publisher with a staged delivery proposal that spans multiple titles? I could certainly see using design to tools for tack on sequels if you don't have anything more important to work on, if your publisher goes for that kind of thing.

#169193 - gauauu - Tue Jun 23, 2009 3:51 am

A few thoughts:

First, yeah, I agree that the "Evolutionary Prototyping" idea makes it hard to sell your idea. Especially considering the number of people who show up here that we know won't complete anything. What I don't want to do is make it sound like good design is not needed.

Quote:
I think that barring a proper spec, your webpage, visionary concept materials and more than anything prototype need to be that much stronger. Also, I think that indicating the requirements of your current iteration is needed to answer question "what exactly do you want help doing?"


I think this is key. The guy asking for help with his FFIV game has a cool prototype engine in progress. If he can release a small quest demo, that could attract additional team members. Those team members might suggest new things that would get worked into the engine, that were never foreseen in the original design doc. In cases like these, the iterative approach can really work.

Similarly, in Anguna, my original ugly prototype attracted a graphical artist, who suggested a number of graphical changes that required a huge overhaul of my engine. The prototype was enough (without a full design doc) to attract his help, and if I had a full spec, it would have been completely wrong, as I wouldn't have taken his skill or expertise into account.

I can't foresee how this approach would work for a commercial game, though -- a large team and many financial interests and pressures would really complicate things. And generally, you already have some sort of knowledgeable team as the design doc and spec is being created. In hobby work, this is often not the case.

#169199 - sgeos - Tue Jun 23, 2009 8:18 am

gauauu wrote:
I think this is key. The guy asking for help with his FFIV game has a cool prototype engine in progress. If he can release a small quest demo, that could attract additional team members.

I think he is one of the few people on the right track. It is interesting that the only thing that sets him apart is that he has not given up. =)

gauauu wrote:
Similarly, in Anguna, my original ugly prototype attracted a graphical artist *snip* and if I had a full spec, it would have been completely wrong

So it sounds like documentation or a demo?

gauauu wrote:
I can't foresee how this approach would work for a commercial game, though

Differently. Commercial projects are driven by money. The proper matching of life cycle model to project determines the effectiveness of resource expenditure.

gauauu wrote:
And generally, you already have some sort of knowledgeable team as the design doc and spec is being created.

I know of one publisher that seems to use evolutionary prototyping by default, but it strikes me as incredibly wasteful. There is so much rework, I don't know why they just don't make two games instead of one. =P On the otherhand, I know of another publisher that seems to use a modified waterfall by default... and they don't allow schedule slips even if that means killing the team to meet deadlines. This is too far the other direction. This is why I threw staged delivery over multiple releases and design to tools on the table.

Naturally, the life cycle model needs to be in tune with the project. I could see using a cross between spiral and design to schedule as a happy medium between mass waste and immutable schedules. You could even have this span multiple releases and just extend the spiral for sequels, as it applies to the engine code, creating new content as you go. Then you could terminate with design to tools when you simply want to milk the mature franchise on a low development budget, by making nothing but new content. At that point, you reallocate your programmers to new projects.

All of this is not to say that I can't see using prototyping or waterfalls, but the key point is that you know why you are using that model and when it is effective, and under what circumstances you need to change course. If Big Title 1 used prototyping, that is probably the wrong choice for the sequel. I suppose I could see the right firm allocate directors that specialize in different life cycle models across different titles in the same series according to the management requirements of the various individual projects as they come up. Ie, different people for different maturity levels of the franchises.

#169625 - Karatorian - Mon Jul 27, 2009 11:35 am

I've always considered myself a hacker and the hacker mindset is generally to write code, not documents. Of course, having no design can be a problem, but I've never favored the Big Design Upfront method.

Here's an interesting case in point. If Linus Torvalds had designed upfront, rather than hacking, it's unlikely Linux would exist. Hyperbole, you say? Perhaps, but there's an interesting story to the the histrory of Linux to back this statement up.

Linux didn't start out as an OS project. It started out a terminal emulator. However, Linus had just gotten a brand new (at the time) 386 and wanted to learn about the new options, like protected mode and such, so he added some rather advanced features. He was also coding on the bare metal. Whenever you code a complex project on the bare metal, you end up writing about half an OS while you're at it.

At some poin Linus realized this and figured, hey, I might as well write the other half. And so, Linux was born. Of course, it's not like Linus didn't have a design doc, after all, once he'd decided to clone Unix, a lot of design stuff was already set in stone. But, on the other tentacle, if you read about the history of Unix itself, it was hacked up too, not designed in advance. In fact, Unix was started as basically the antithesis of Multics, which was an overengineered, designed by committee, top-heavy, unworkable design.

"Agile" may be the new buzzword for it, but all it really means is doing it the hacker way. Which works for me (and a lot of others too). So I guess I'd be more interested in a working demo than a spec.

Generally, I think the most important thing for a project is that the codebase builds and runs. Ideally, the game should be playable as soon as possible and be kept that way. That's the life cycle model I favor. I guess you'd call it "Evolutionary Prototyping", but I'd just call it "Hacking".

#169665 - sgeos - Tue Jul 28, 2009 4:14 pm

Karatorian wrote:
I've always considered myself a hacker and the hacker mindset is generally to write code, not documents.

This is fine for small teams, but when you have half a dozen people, they need to communicate somehow and documentation is often the way to go. In general, the more people you have the more documention you need.

Karatorian wrote:
Of course, having no design can be a problem, but I've never favored the Big Design Upfront method.

It is cheaper (in time or money, depending on what you are spending) to fix a problem before it is a problem (ie, coded). Sure, you might not be able to identify the problem unless something is there. There is also a school of thought that believes you'll throw away a prototype no matter how you do things.

Quote:
Generally, I think the most important thing for a project is that the codebase builds and runs.

This an end goal, so it is utterly important by definition.

Quote:
Ideally, the game should be playable as soon as possible and be kept that way.

It depends on what you are making. If your project needs a lot of end user feedback to complete, then getting something up and running ASAP is the correct solution. If the goal is to complete the project as quickly as possible and you don't need much user feedback, spending time on research and planning will pay off so long as it is not overdone.

Quote:
That's the life cycle model I favor. I guess you'd call it "Evolutionary Prototyping", but I'd just call it "Hacking".

The line between "code and fix" and "evolutionary prototyping" is discipline.

#169670 - Miked0801 - Tue Jul 28, 2009 7:35 pm

Hacking gets stuff done and it gets it done very quickly.

At a price.

If you are at the end stages of a project working on a throw away module that you are sure you won't see again, then I have only a little problem with hacking. If, on the other hand, you are working 'at the metal' on stuff that a whole engine is going to be based on, hacking is the very last thing you want to do. Your lowest level code has to be your most robust and best documented code. If not, you cannot properly debug anything else in your game. How do you know if that graphic glitch you just saw was the result of an edge case in your decompression routine / renderer or the high level code displaying numFrames()+1 in the menu manager? If the low level isn't solid, you just don't know where to look.