How Success Killed Duke Nukem Forever

[[SAS]Solid Snake]

You can afford to do that with mods since everyone is doing it in their free time and you have no pressure to get it out of the door, but you're one of the biggest devs around you can't afford to **** about as people's livelihood depends on that game. I would be extremely pissed at Broussard if I worked for 3DR.

It isn't so much about the money, but the frustration of having worked on something for so long with nothing to show for it. This was the primary reason why there was a mass exodus at the 'middle' of the development cycle.

The other problem seems to be the way mod development has changed into. It seems to me, that a large proportion of mod developers are all talking about 'making it big'. Thus they become pathological liars who flaunt that they have a <Whatever> Studio/Ltd/Corp, non binding/illegal NDAs/contracts and so forth. The problem there is, is that they actually take it seriously (or take themselves too seriously). So what happens, is that a member joins, does some work and after a year and a half of nothing ... the member quits. They now can't show the work to anyone, use it in their portfolio because the team leaders would accuse them of breaching their non binding/illegal NDA/contracts. [If push came to shove, I bet the member could do it anyways since the mod team is unlikely to be able to take the case to court due to financial reasons or legal reasons (If the member was under 18 or under the age of legal responsibilities)]. {Believe me, I've been threatened six times from one "game company" before and each and every time I got my lawyer to call them slapping them six ways to Sunday}

I don't believe 3D Realms wanted to kill off Duke Nukem or do any harm financially to their employees. It's just that, the never ending goal of wanting to make the next best thing is an impossible goal. It was just unfortunate that the people that made key decisions did not feel it was impossible, and thus everyone suffered for that.

 

[Zur]

It isn't so much about the money, but the frustration of having worked on something for so long with nothing to show for it. This was the primary reason why there was a mass exodus at the 'middle' of the development cycle.

Use Agile and do gradual releases over the Internet

 

[[SAS]Solid Snake]

Use Agile and do gradual releases over the Internet.

Using a new paradigm isn't going to help a team if they don't know what they're doing. You can only be agile, when you know what you're doing. But being agile isn't so much about developing faster, but rather being more accommodating to changes. Or at least, it is to me. I suppose you could say that by being more flexible when changes occur, you can make a faster turn around.

Any ways, gradual releases over the internet succumb to the whole "this sucks" problem. Let me explain:

• "Why can't I open this door?" ; "Oh, it isn't implemented yet" ; "This sucks."
• "Why can't I shoot this weapon yet?" ; "Oh, we haven't actually coded that yet" ; "This sucks."
• "Why is that enemy a cube?" ; "We haven't had time to add in new graphics for him yet" ; "This sucks."
• "Why have you stolen graphics from insert game" ; "We wanted to prototype this game early, so we have taken a few liberties for now" ; "This sucks."

So you want to prepare your game / mod for release ... but then the strive for perfection kicks in.

 

[Sir_Brizz]

Open source your mod.

 

[elmuerte]

Use Agile and do gradual releases over the Internet

Agile doesn't imply gradual releases. And as far as I know most games have been developed more or less agile.
Or at least, I don't know of a single game which was first completely drafted on paper, then implemented, reviewed, design documents updated, then game updated, etc.

There are too many people with dollar signs in their eyes.

 

[JaFO]

Open source your mod.

yeah right ... let's have no project-managament at all and see if anyone can ever finish it.

Like Solid Snake said : throwing new techniques/paradigms at a project won't automagically solve problems for you, especially if those problems are a lack of project-management, vision and a complete failure to understand what software-design really is about ...

Been there, done that, got the t-shirt.

 

[-Jes-]

You aren't a part of us. So YOU are not included in "we". We are game-devs and the article is interesting to read. Average gamers might not care as they don't get something for their mindless consuming-habits-

What an ego.

Yes, the article is interesting and is a good read, but quite frankly, all it does is stating the obvious.

Anyone who's taken the slightest of interest in the game over the past 10 years knows what's been going on behind 3DR's doors.

However, it's all said and done, and I for one saw this coming from YEARS away.

 

[Zur]

Agile doesn't imply gradual releases. And as far as I know most games have been developed more or less agile.
Or at least, I don't know of a single game which was first completely drafted on paper, then implemented, reviewed, design documents updated, then game updated, etc.

There are too many people with dollar signs in their eyes.

Indeed it doesn't. But if you do things properly, you have something that's more or less usable after each iteration. If this is the way game devs are working then the obvious problem is with the bar being placed too high. Hence the suggestion to do gradual releases over the net instead of trying to get a super-duper polished off product on the shelves.

 

[Sir_Brizz]

yeah right ... let's have no project-managament at all and see if anyone can ever finish it.

Like Solid Snake said : throwing new techniques/paradigms at a project won't automagically solve problems for you, especially if those problems are a lack of project-management, vision and a complete failure to understand what software-design really is about ...

Been there, done that, got the t-shirt.

How do you figure that open source products have no project management at all? That makes no sense and is pretty demeaning to open source development teams, frankly. For someone who hates "the man" so much, I have a hard time believing that you don't appreciate/use open source software on a daily basis.

The open source model would work just fine with what has been discussed. People generally don't mind if open source software is incomplete in the first few iterations, and you could simply present gameplay ideas through it, not your entire game.

Overall, though, I think as long as you don't call your releases "Beta", make it reasonably clear that you are not putting out a functional or polished game, make it clear when people ask/comment that your mod is absolutely not even close to completion, etc., dong incremental releases of your mod is fine. Mod teams don't generally have the benefit of large testing teams and large design teams making sure that the game is staying cohesive, fun, and easy to jump in to. Having those processes during development is part of what makes games feel polished and mods not.

 

[BoneofFear]

Overall, though, I think as long as you don't call your releases "Beta", make it reasonably clear that you are not putting out a functional or polished game, make it clear when people ask/comment that your mod is absolutely not even close to completion, etc., dong incremental releases of your mod is fine. Mod teams don't generally have the benefit of large testing teams and large design teams making sure that the game is staying cohesive, fun, and easy to jump in to. Having those processes during development is part of what makes games feel polished and mods not.

True but there's always going to be those 15 idiots from teh interwebz that'll say it sucks anyways cause it "doesn't feel complete." yet not (or in most cases never) bother to explain what they think should be improved or fixed.

 

[[SAS]Solid Snake]

Indeed it doesn't. But if you do things properly, you have something that's more or less usable after each iteration. If this is the way game devs are working then the obvious problem is with the bar being placed too high. Hence the suggestion to do gradual releases over the net instead of trying to get a super-duper polished off product on the shelves.

The problem is that the game would lose what made it special in the first place. By putting gradual releases on the internet, you diminsh any secret sauce you have. Even then, at what stage do you stop doing this at? When the game is 10% done? 20% done? 30% done? If you stop at any stage, then you risk having some parts of the game considered unfinished or unpolished. But if you release over 99% of your game over the net then you might as well make a game for free. The other problem with doing this is that people will get tired of your game. If development time is 2 years, then people would have played your game for 2 years already, and people don't suddenly start shelling out money because a game they've played for 2 years has become a product.

The main problem I feel with 3D Realms is that there was never a clear design for the game to begin with. This happens a lot with mod teams as well. For example, we see trends in the game development community, where everybody decides to make a realistic first person shooter. A mod team that was originally developing a third person realistic shooter, might suddenly think that a first person viewport could work better. Then a trend for vehicles catches on, so the mod team thinks adding vehicles could work better. Then a trend for co operative play starts, so the mod team decides to build new co operative maps... see where I am going with this? Because George could never be happy with selecting a few key game mechanics or a few key over arching mechanics and wanted to include everything, they winded up not having anything. One of the things I've learnt in my year of indie development is that:

If you target everybody, you target nobody​

Open source your mod.

It depends on what the actual problem is. Generally open sourced projects are those that are willing to accept that they don't have enough time to do everything themselves, or are willing to accept that they don't have all the skills necessary to complete the project. Open sourced development can have a lot of benefits, but there can be a lot of downsides too. For example, The GIMP is a perfectly capable image editing program but it never feels as polished as Photoshop. Everytime I've used The GIMP it has always been a mess because every developer decides his / her way designing an interface is the best. Open Office is an open sourced project I'm quite impressed with however. In the end, if the problem is project management (as it was quite clearly with 3D Realms) then shifting to open source development is unlikely to resolve that issue.

 

[Sir_Brizz]

It depends on what the actual problem is. Generally open sourced projects are those that are willing to accept that they don't have enough time to do everything themselves, or are willing to accept that they don't have all the skills necessary to complete the project. Open sourced development can have a lot of benefits, but there can be a lot of downsides too. For example, The GIMP is a perfectly capable image editing program but it never feels as polished as Photoshop. Everytime I've used The GIMP it has always been a mess because every developer decides his / her way designing an interface is the best. Open Office is an open sourced project I'm quite impressed with however. In the end, if the problem is project management (as it was quite clearly with 3D Realms) then shifting to open source development is unlikely to resolve that issue.

This makes no sense and, frankly, doesn't even matter in this context.

Open source projects start because people realize that open collaboration will, in the end, create products that have more features well fleshed out than any other means, since the "design" of the program is not limited to any one person.

Moreover, open source projects always have a design goal in mind. Have you used Firefox? Google Chrome? Both of these projects are open source and neither of them are suffering from bad UI design or project management as a result of that.

The GIMP has looked and worked the same for as long as I can remember (well over a decade). They've added features but I've never seen a major UI overhaul in that time. Really, the problem there is that you just can't get ANY software to compare to Photoshop. There is a reason why it is still so widely used, nobody has matched it's feature set and ease of use. Open Office, while good, suffers from the same problems with documents of different formats for example, any xlsx file takes FOREVER to open in OO). This isn't a problem with open source, this is a problem with trying to reverse engineer proprietary file formats.

In the end, though, you're right that making a project open source won't fix project management issues.

 

[elmuerte]

yeah right ... let's have no project-managament at all and see if anyone can ever finish it.

Is a product ever finished?
And where do you get the idea that there's a relation between no project-management and open source?
Here are only a few open source projects with (extensive) project-management:
PostgreSQL, Firefox, Thunderbird, OpenOffice.org, Linux kernel, Debian, Drupal, Eclipse, Emacs, FreeBSD, OpenBSD, Apache HTTPD, JBoss, Spring, GNOME, GCC, Python, Firebird, Lucene, Asterisk, OpenMoko, Blender, LLVM, Perl, Python, Samba

Indeed it doesn't. But if you do things properly, you have something that's more or less usable after each iteration. If this is the way game devs are working then the obvious problem is with the bar being placed too high. Hence the suggestion to do gradual releases over the net instead of trying to get a super-duper polished off product on the shelves.

Not perse. There is no rule that with agile development you have a constant working product. In fact, that is generally not the case. One thing that does signify agile development is that the product can change drastically in a "short" timespan. Doing gradual releases might not work well in that case, the gameplay could change a lot between releases. This will only annoy your players. Episodic/periodic content does work. But you can start with that when the core gameplay is fixed.

It depends on what the actual problem is. Generally open sourced projects are those that are willing to accept that they don't have enough time to do everything themselves, or are willing to accept that they don't have all the skills necessary to complete the project.

If you take all open source projects, that statement might hold true. But in the same line you can say that generally things (books/music/etc.) people/companies create are crap.
But that argument is moot.

Open sourced development can have a lot of benefits, but there can be a lot of downsides too. For example, The GIMP is a perfectly capable image editing program but it never feels as polished as Photoshop. Everytime I've used The GIMP it has always been a mess because every developer decides his / her way designing an interface is the best. Open Office is an open sourced project I'm quite impressed with however.

Photoshop never felt polished to me either. Anyway, open source development has nothing to do with crappy user interfaces. For example, neither Microsoft Office 2007 nor Apple iTunes are open source. And those are quite terrible on the user interface department.

 

[Zur]

Not perse. There is no rule that with agile development you have a constant working product. In fact, that is generally not the case. One thing that does signify agile development is that the product can change drastically in a "short" timespan. Doing gradual releases might not work well in that case, the gameplay could change a lot between releases. This will only annoy your players. Episodic/periodic content does work. But you can start with that when the core gameplay is fixed.

It must be particular to agile scrum then. I understand the problem with gameplay even if that would be acceptable during beta testing since even the big guys do it.

Oh well, I don't pretend to know of any solution but, if a shareware company pulls something like this off, they have all my respect. In fact, it would be nice to see the internet as a nurturing ground and the publishers as simply a way for the most popular games to be distributed under material form.

 

[[SAS]Solid Snake]

Photoshop never felt polished to me either. Anyway, open source development has nothing to do with crappy user interfaces. For example, neither Microsoft Office 2007 nor Apple iTunes are open source. And those are quite terrible on the user interface department.

I think my point is, is that with open source projects, teams must be very vigilant in what code they accept into their official builds. Not all projects are unfortunately.

 

[BITE_ME]

So whats going to be on the tombstone?

 

[elmuerte]

It must be particular to agile scrum then. I understand the problem with gameplay even if that would be acceptable during beta testing since even the big guys do it.

It's also not the case with scrum. Of the the things with scrum is that it doesn't focus on the product as a whole, but mostly on small parts of the product.

I think my point is, is that with open source projects, teams must be very vigilant in what code they accept into their official builds. Not all projects are unfortunately.

Nah, I think it's more related to interest and personal need. Most open source products don't focus on selling the product. So there is usually no need for dressing up the application every now and then so that it looks new and improved. It's more difficult to sell a new major of a product when it still looks the same. In the open source world, when nobody is interested (or has a need to) change certain part of the application it simply won't happen.
There are a bunch of people working on improving The GIMP user interface for quite some years. Their plans have never been to make The GIMP look like Photoshop. Their work was towards creating better workflows. The workflow of The GIMP is quite good, but it takes a little while to know it. Anyway, they are planning a major overhaul of the user interface. but the problem with it is that is needs to completely replace the current interface, rather than perform incremental changes. That's why it is taking them so long.
Open source projects usually are not rushed towards deadlines. They release a stable product, when it's ready. And minor releases when it's deemed useful. You can't do that with commercial software that easily, because you want to earn money from the releases as much as possible.
Of course having open source software doesn't mean you can't sell it, or earn money. It's just more complicated than just selling the "finished" product.

Now going back to game design. You can't perform the release fast and release often principle that open source uses. Because that will only annoy the users. As I said before, major changes in the gameplay are a no go. So you first have to finish that part as far as needed for the current content. After that you can only extend the gameplay, and add new content. Which you could consider episodic.
A good example would be how The Ball and Prometheus have been released. The core gameplay has remained the same, it's mostly new content and additional gameplay elements.
This works for free games. But maybe not as well for commercial games.
People get stuck with only a partial game, and then have to wait for an undetermined time for the next part. so you can't charge them for the full package, just the current part. You also have to work out how you are going to release the next part: as isolated packages, or as addition to the previous part. The major issue would be to keep people's attention and get them to pay for the next part and not forget about it.
A while ago Horror writer Stephen King performed an experiment where he wrote part of a book, released it. Waited until enough people bought it, then write and release the next part. So that sales of the current part would pay for the development of the next part. (the books were released a ebook without DRM). It worked quite well, except that story development failed. King couldn't give it the right direction. For games this isn't the same issue, because most of the work goes into production of the content rather than working out the story (if it even has a story). But compared to books there is a much larger initial investment in time, because you need to work out the gameplay.
Telltale Games needed a lot of initial development to get their story engine off the ground. After that creating the episodes wasn't that much work, while they would still improve the story engine. Adventure games don't have much gameplay logic, so doing the incremental releases works quite well. The other good action of Telltale Games was that each episode was an isolated story. So there was no initial development to create an overarching story line.

uhm... I guess I started to ramble...

 

[KaiserWarrior]

Indeed it doesn't. But if you do things properly, you have something that's more or less usable after each iteration. If this is the way game devs are working then the obvious problem is with the bar being placed too high. Hence the suggestion to do gradual releases over the net instead of trying to get a super-duper polished off product on the shelves.

You would be surprised, I think, at how many middle managers think that "Agile Development" means "LOL We don't need a design doc, just code whatever".

These usually exist in environments where there are too many managers (or manager wannabes) and not enough actual design and program people.

 

[drakon]

I never thought I'd see the day where the words "success" and "Duke Nukem: Forever" were in the same sentence...

 

[elmuerte]

I never thought I'd see the day where the words "success" and "Duke Nukem: Forever" were in the same sentence...

You just did it again.