Yes, but the emphasis should be on the word "glorious". :cool:

Wait.. there's a Fable 2?

Yessir. There's even a GoTY edition.

Nowai. You lie. Fable 2 is a lie. just like the cake is a lie. And you sir.. are a lie. (Note that I really have heard of Fable 2, but I was so disappointed in it that I pretend it never existed, much like the cake.)

I dunno man, if you're having fun, maybe it's not a problem.

-Crat
http://lpmuds.net

I don't think this is a fair statement. With subordinate clauses, you can pack a lot of information into a single sentence. I would pigeonhole Black and White thusly, "Train your own god-beast and nurture or torture a bunch of hapless sentient creatures." Am I missing something? :tongue:

I very much disagree with this. Vision, concept, design… these have nothing to do with team management, deadlines, or corporate structure. Not at the initial stages, anyway. A commercial game may be forced to drop ideas at later stages due to time constraints, but those have zero impact on vision and – if you are donig things right – zero impact on game concept, either. It pretty much just affects the level of polish and the number of changes you can make.

Even then, commercial games are increasingly developed in a more hobby-like fashion. Game development companies are wisening up to the fact that meeting deadlines at all costs just results in shitty games. Game teams are also generally made up entirely of people very enthusiastic about the game they're working on, which is why a lot of game companies have employees that work 80 hour weeks with no overtime pay (and why those remaining deadline-focused companies can so easily get away with forcing 80 hour weeks on employees).

Games are not like other software in a lot of ways. Every game worth playing is a labor of love. There are certainly additional motivations present in the commercial space, but I do not believe that money or corporate success is the primary motivator for most professional game developers. It's just a side benefit that they get to make money by working on what they love. You can see and feel that when you talk to any professional game developer.

The fact is, every thing I've said is exactly what hobby MUDs do. The good ones, anyway. Everything. Many of them don't realize that they're doing it, and many of them do a lot more wandering around in circles before getting where they're going. These techniques and rules aren't fundamentally different in any way to how MUDs have always been developed. They're just spelled out and now something you can be acutely aware of, which in turn will make your hobby project better, let you work faster, and hopefully have a better team dynamic.



Are they saying anything contradictory to what I have?




Definitely. There are a few reasons why I think that happens so often with MUDs, but it's not really relevant to this topic (or this topic's current tangent, either). The short of it comes around to lack of solid leadership – which may just mean that the guy leading the project isn't at all qualified to be a project leader. That's a very special skill that most people don't have, and it's not an easy skill to learn at all.



That's the problem, KaVir. You can't. Sometimes you've got two people who just are not going to agree, end of story.

If you can hash out a solution everyone is happy with, obviously you want to do that. If you simply CAN'T come to such a solution, stop wasting time pretending that you ever will. It's pointless.



The paid part has little to do with it. You seem to be assuming that commercial developers are motivated more by money than by the game. And you also seem to be assuming that a commercial project must be run in the 1970's corporate hierarchy structure.

The software industry as a whole (game and non-game) is moving away from that. Very very slowly, yes, but they are. The good techniques that work for managing a team of volunteers work equally well for a team of paid devs. Seriously. You may not believe me, and I wouldn't blame you – I thought the environments were entirely different myself until i started seeing some of the truly great commercial and hobby teams here. The newer team management techiques like the Core Protocls – which were designed explicitly for software developers – really do just work for any team of (almost) any size, with or without money driving them.



Then your developers are not as good as they could be at that job, pure and simple. They might be working their ass off, but they're diverting energy into something other than "make the best damn medical software we possibly can," and the software suffers because of it. They don't need to be willing to work on medical software for free – hell, I wouldn't work on a major game for free, either, I need to eat dammit – but if they care more about corporate status than the quality and impact of their software on the world, then they're only second rate developers at best (for this project, that is). You CANNOT put 100% effort into something you don't really care about. Maybe your company's rewards and management style is just stuck in the 1980's (the vast majority are, unfortunately), or maybe your corporate leaders are focused on pure profit the easiest way possible instead of profit through excellence and reputation (the vast majority are, unfortunately), or maybe HR just hired the wrong developers because they don't understand the importance of passion in any endeavor (the vast majority don't, unfortunately). I'm sorry you're stuck in that position.



And you're wrong. I'm not sure how to explain it better. Sorry. :(

Just remember, vision != concept. The vision is a few words long. The concept is not. You are probably just stuck in the thought process that the vision is the concept, and it's not. At all. Or perhaps you're confusing what we call "vision" with those big long rambling statements of personal motivation and intent. Different kind of vision entirely; English just sucks at differentiating the two.



Again, vision != plot synopsis. You are confusing the two. Your favorite movies can all be given a very fantastic vision that fits the definition, and that vision fails in any way to represent the entirety of the plot, the characters, or the many fine details of the movie.

However, the plot, the characters, and the many fine details of the movie all support the vision.

It's a one way relationship, but it's a very important relationship. The movies that lack a vision are not the "complex and interesting" movies, they're the movies that seem to just be a random grab-bag of disjoint plot, action, and lack any underlying meaning.

Those interesting movies are the ones that had a clear vision, not the other way around. I cannot drive that home enough. EVERYTHING has a vision, a mission statement, a motto, whatever you want to call it, and it is the foundation upon which everything else is built. Without it, you have nothing to build. Without clearly defining it, you risk building something that just doesn't work.

To bring it back to MUDs, compare the average MUD out there that is a stock area MUD with a few random new features tossed in with something like KaVir's God Wars 2. The former lacked a clear vision. It might have had a very interesting set of game concepts – maybe those new features really are pretty cool – but the MUD as a whole is mediocre, bland, and uninteresting anyways, because the overall game experience is average at best. Meanwhile, God Wars 2 is unique, focused, and has a purpose besides just "be a fun MUD lolz." Maybe KaVir hasn't even spelled the vision or even the concept out to himself, but it's clearly there none the less.



You seem to think that game companies sit around, think of how to best commercialize some basic concept, put out an ad for developers that says "hey we haz idea to make lots of $$$ come sign up plzkthx" and that's how all games are formed. That's actually quite wrong.

The vast majority of games are conceived of first by a small group of developers (or even a single person). He puts his ideas on paper. This is an idea he's passionate about. He recruits a few other developers that are also passionate about his idea. They put together a basic concept. They then try to sell it to publishers to get the funding to work on the project full-time and get it into top tier shape. Those games are the ones that come out that people just freaking love. Those are the Left 4 Deads, the Baldurs Gates, the Resident Evils, the Metroids, the Zeldas, the Dead Spaces, etc.

The ones that are corporate driven are the ones like Superman the Video Game or Halo: ODST. And they suck.

There certainly is a segment of the game industry that's all about money, but it's a lot smaller than you seem to think. Mostly just focused on cell phones and the like, or on cloning the truly popular games. Those aren't the triple-A titles, they're the crappy little knock-offs.

Hollywood is another story. The executives at the movie companies have gotten really dumb lately. It's not because they are "using vision" to make their movies. It's because they STOPPED using vision to make their movies, and instead are jumping straight to the concept stage and tossing in every "cool movie" bullet point they can in the hopes that enough "cool features" in the plot/action will sell. Or they stopped using anything except a vision, perhaps, with their vision being something dumb like "make more monies lolz."

Compare most action movies that seem to lack a coherent vision. Hitman, for example. Tits, blood… about all it had. They seemed to skip the vision part and went right into "what do we want this movie to have? tits and blood sell, lets go with those!" and that was it. Now look at 300. All it had was tits and blood, and yet it was a damn entertaining movie. It had a vision. That vision was not "tits and blood," but instead it was something like "over-the-top restylized greek tragedy." They obviously had to add a lot more details to the overall concept, and even more details to the script, costume design, coreographic, etc. The vision DOES NOT DEFINE any of those details in any direct way at all! But that vision is still clearly visible in every part of the movie, start to finish. It simultaneously defines the movie while utterly failing to describe what the movie is in any way.

THAT is vision.

DO NOT confuse it with concept, or plot, or any kind of detail. That's not what it is. It's the foundation on which you build those pieces, it's the goal you keep in mind when evaluating what to build, what to write, what to draw… but it doesn't somehow magically tell you what to build, what to write, what to draw. It tells you what not to do. It tells you what direction to go in. And that's it. But clearly you need that – you have to have a direction, you have to have some criteria on which to weed out the majority of the thousands of ideas you're going to have, because you can't actually implement anywhere close to all of them, and if you somehow could, the end result would be a massive collection of unrelated puzzle pieces that form no kind of recognizable or meaningful whole.

I think the paragraph plot summary is the most useful design statement.
I'm sorry but I really think the conceptual vision of a half dozen words is far to short.

That's the point! :)

Look at your examples. It's proof of why the vision is important. Wombats? Seriously? Ridiculous. Let's say we went with some big long "vision" like you want. "Wombats in space shooting exploding radishes at each other and then lighting the vehicles on fire!" That's a horrifically stupid vision. The worst part, when you realize that players think wombat in space is stupid, you're fucked. You're pretty much stuck going back to the drawing board and redoing EVERYTHING. I mean, what do you keep? Is wombats on earth better than wombat in space? Was it the radishes that were over the top? Maybe the vehicles didn't fit the theme properly.

Go back to fire and explosions. Look at the actual example I gave you (I give these things for a reason, people). Igneous's final game concept is absolutely and totally different than their initial concept. It was originally supposed to be an Indiana Jones style valcano platformer adventure brawler thing. The concept was pretty big. The vision was "fire and explosions."

They got into the game and realized that a lot of their initial ideas just weren't fun. The running and jumping and platforming was fun, but the fighting was bland and generic and boring. So they cut it. Then they realized that they just didn't have the artistic resources to make a human character look good; they were just four programmers doing a student/hobby project, not a big team with artists and such. So they dropped the adventurer guy idea and just went with the marble, which even a programmer can model.

What they did NOT do was cut the fire and explosions and the volcano and try to make Indiana Jones in the Amazon Rain Forest battling Spider Monkeys and Tarantulas.

A big part of that was that since they wanted to have fire and explosions, the first thing they did in their engine was figure out the particle engine and physics to make really cool lava, fire, and explosions. So when they actually got to the point of implementing the game play elements (and found out many of them didn't work), they already had the fire and lava stuff implemented. Why throw out all that work? That lava looked damn cool for one month of work by four guys who've only been programming for two years with zero professional experience. I mean really cool. And so they ran with that, NOT with the adventure platforming brawling bits, because it was a simple vision that they were all gung-ho about.

And it gave them the freedom to make a better game. If they had stuck with the boring concept bits and tried to hold themselves to low-quality character art, the game would have been crap.

The final game is obviously more than fire and explosions. It's got other elements to it. It's not a particular big and expansive game, but then it has had very little work put into it compared to most games, including most MUDs – just four guys in their spare time who were learning how to program (and not just how to program a game) while doing it.

But look at what you did. You took that vision and game up with a ton of other game concept features for it. That vision could have been anything. AND THAT'S THE POINT. It gives you the freedom to EASILY toss aside the crap that doesn't work and realign the game concept to what you can actually do or what is actually fun while keeping you on track, directing your development, and avoid the all-too-common problem where you just throw away the whole project because you have no possible way to salvage it.

Take another example. Let's say that you want to make a cartoony NES Mario-like 2D platformer, but you want to add some really novel brawling mechanics to the fighting. So not just jumping on enemies' heads, but using some cool bullet-time-based action brawler combat mechanics that rely on using dynamic world elements as weaponry. Totally cool idea. But what's the vision? The vision is really stupidly simple: "platformer with fun combat." That's it. The game concept is much bigger.

So you get to working on your game, and lo and behold, the art style you had in mind (cartoony) doesn't fit at all with the combat system you've been developing. It just doesn't mesh right. Well, the vision didn't limit you to cartoony graphics. So you redraft them, update your concept, and keep rolling. Now you get further along and find out that you just can't make the dynamic level stuff work right. You realize that the math involved in deformable terrain is way over your head, none of the other volunteers/paid-developers/whoever on your time is up to the task. It's just not possible. But hey, you don't require deformable terrain in your vision, so you can toss it, redraft the concept, and keep going. So now you've got this combat system, but you realize that the brawling just isn't fun. It just feels like a lame Mortal Kombat. The terrain might've made it cool, but that was 100% infeasible for your team with no way around it. You just can't make this brawling fun, it just doesn't work with the platformer. But hey, the vision didn't require you to use brawling, just that you have some kind of fun combat system. So you axe the brawling, go back to the drawing boad, and come up with a new combat system based on jumping on some kinds of enemies and tossing them at other kinds of enemies or hitting them against certain kinds of terrain to create new effects. That works, it fits your vision, and on you go. Now you realize that the realistic graphics don't work, so you go back and revitalize the old cartoony graphics, which work a lot better with the jumping/throwing combat mechanics. Lo and behold, you have Super Mario World, considered by many to be one of the greatest video games ever made.

Let's take another example, though. Say your game is all about fire and explosions again. Your first development phase is engine proof. Make sure you have the skills to develop the engine. Turns out you can't actually make good looking fire. You just don't have the skill. Nobody on your team does. Well, you know you can stop right there. The whole game is just infeasible for your team. Go back to the drawing board and do something else.

You are a person who is really focus on plot and depth, I take it. That's fine. I tend to be too (my favorite games are Roguelikes, Bioware RPGs, and the big adventure games with plot). And guess what? You still have a vision for a game. It's a simple, short, several-word vision. "Intellectually deep game with emotionally stimulating plot." Tada. You have a vision, weighing it at only 7 words. Depending on your definition of "intellectually deep" you might even be able to just drop the second half and end up with only 3 words in your vision.

And that vision is important. When someone comes and suggests that you add platforming elements to your game, you stop and ask, "does platforming enhance the plot? is it a deep, intellectual gameplay mechanic or just more button mashing and timing gameplay? it's just timing. it's not deep at all. that does not fit our vision. no, we'll skip the platforming." Then someone comes along and says, "how about we make the bad guy the main character's mother/father/brother/sister/cat.?" You think, "that's so cliche. That's not stimulating at all. It's been done in like every fantasy movie and game plot ever. The player is probably going to be expecting it, even. No, not good. Come up with something else."

Clearly there's a vision there. When you finally come up with your game concept, it'll probably be a few paragraphs of details. The actual game design document (the third piece of the design puzzle) might be 200 pages of plot notes, game mechanic ideas, and so on.

That game design document is utterly important. There's no question. But every single thing you put into it in some way reinforces your vision. The bits that don't are the bits that you either end up cutting out of the game, or if you don't, end up bringing the game down and making it less than it could have been.

You totally agree with the importance of the vision… you just don't realize you're doing it. ;)

Then I guess we'll have to agree to disagree. Black & White, Spore, Fable…these are just three examples of games that had to drop features and curb their vision and concept because of deadlines. And in my opinion the end products suffered horribly as a result.


Debatable. But even if that were the case, it doesn't change the fact that they aren't hobby games, and they have pressures (and resources) that hobby games don't have.


Every software industry thinks it's special ;) I'm guessing you've got friends in the games industry?


Correct, but it's not the end of the story - as I said, the more compromises you make, the more you drift away from what you enjoy, and the harder it is to keep motivated. If you end up with an overall design that none of the team are particularly enthusiastic about, it's pretty safe to assume that the game will never see the light of day.


It has everything to do with it. Commercial developers won't stop working and go home just because they're a bit bored.


You seem to have a very…idealised view of how software development should work, and how software industries are supposd to be neatly separated into little boxes. But I'm afraid it really doesn't work that way in the real world.

There is a lot of crossover between software industries, and while specialised knowledge can give you an edge in one or another, it's not at all uncommon for people to move between them. As someone who has worked in the aerospace, telecoms and medical industries over the last 13 years, I'm more interested in projects than industry. I also worked in the games department of a telecoms company for a few months, that was a pretty fun project (at least until they shelved it), but there was nothing magical about the software just because it was about 'games'.


No, I think exactly what I said. Are you suggesting that making money isn't the main objective of a commercial game?



I could perhaps see it working in a few specialised cases (such as the batman thing which relies on existing knowledge), but overall I agree - for most games you'd really need a paragraph to provide anything useful.

Well, perhaps, but they also are unlikely to put in 80+ hour work weeks if they're bored (and don't have a superb work ethic to make up for it).


I'm not sure you really realize what you're disagreeing with here. Elanthis said that passion makes for better developers. He didn't say that people without passion are terrible, will never ship a product, don't exist, etc. I think you might be disagreeing something other than what Elanthis said…

Anyhow, this whole vision thing is really quite simple in the end of the day. If you think that you use the vision to implement the game, plot, etc., you will obviously fail – as several of you have pointed out! – because that's not what the vision is for. Frankly I think the whole thing has become a far bigger argument than it ever needed to, perhaps based on some initial overly literal interpretations of 'vision'. That, and Elanthis has an occasional tendency to use hyperbole which can obscure the main point he wants to make, or dare I say, his vision. :tongue:

I agree with you entirely on all those points.

Not all game companies "do it right." A lot of these techniques and formulas are pretty new, and while they've been shown as highly effective, it just takes time for companies to pick up on it.

Look at how many companies still use 1970's style corporate structure in their software departments while ignoring all of the proven research in proper software project management, proper team management, motivational techniques, and so on that have been developed in the 80's, 90's, and 00's. My boss still tries to entice developers with stock options even though it's been shown that 95% of employees don't give two shits about stock options, especially in companies where there's no public stock and no liklihood of going public anytime in the forseeable future. My boss must've missed the memo. Mismanagement doesn't disappear just because there are better ways of doing it, unfortunately. The dinosaurs will go extinct, but it takes a lot of time. :)

Some of the bigger companies are kind of schizophrenic, too. Like Microsoft. That's the same company that both screwed over games like Fable or Mass Effect while simultaneously pioneering some of the very management and game design techniques I'm talking about. A company that size is just going to have those kinds of problems.

If I implied that all game companies work in the ideal way, I did not mean to. My apologies. The _good_ game companies (or good divisions of companies) that produce good games use techniques like these. :)

People are learning, though, slowly. Take the example of Mass Effect. It suffered badly because Microsoft forced Bioware to release it on time for Christmas, and it didn't get finished properly. The gamers complained, because while the core bits of Mass Effect were fantastic, the lack of polish and effort in finishing the side quests and a few other bits were very evident and dragged the game down from a 10/10 to a 6/10 at best. Which, from a purely corporate standpoint, means less profit, but it also pissed off a lot of the developers. They wanted to make the best damn game they could. Microsoft learned its lesson, and for Mass Effect 2 is allowing Bioware to take all the time it wants to finish the game – it's been pushed back once already, and will probably be pushed back again based on reports. And Microsoft is going to let it happen, because they want Mass Effect 2 to be a 10/10 just as much as Bioware's developers want it.

A lot of companies don't learn, and it sucks. I wouldn't ever work for one of those companies, and I wouldn't recommend anyone else who cares about games to work for them, either. One nice thing about the game industry compared to the rest of the software industry (and this is similar to the game hobby field) is that developers are in far shorter supply than game ideas, so it's not hard at all to find something to work on if you don't like the project you're on already.



Sure. Haven't said otherwise. That doesn't invalidate the ideas I've presented for game design nor many of the team management skills.

Yes, they're different. Yes, there are some changes in approach here and there. You don't have to worry about deadlines in a hobby project, but you don't have to worry about boredom killing motivation in the corporate world either. You have to keep development moving along in either case.

The vast majority of it is the same, and the same mistakes that kill commercial projects kill hobby projects.

There are plenty of hobby projects that have deadlines too, now that I think about it. Quite a few large Open Source projects are still primarily developed by volunteers but stick to deadlines and milestones. I'm not aware of any hobby games that do that, but maybe there are? It would be an interesting experiment to try – see how well a team of volunteer game developers work with a set of clearly defined (and very resaonable) deadlines for milestones. Deadlines that are unreasonable just cause pressure and stress, but maybe very roomy ones will help keep people focused? Dunno.



I'm a student at DigiPen. 90 staff members all from the games industry, hundreds of students who are aspiring game individuals, and I'm literally within walking distance of Microsoft, Nintendo, Human Head, Valve, Gas Powered Games, and a number of other game companies.

I'm also professionally (currently) not at all related to the game industry. I also have friends in the business/finance sectors, friends in the embedded microcontroller business, friends in the desktop business, and I myself am in the eCommerce business.

There are bits of how the technical stuff is designed that differs for all of them. Maybe that's what you mean by everyone thinking they're different. The game industry does have some differences at the project levels compared to any other software industry I know of.

I mean, if nothing else, we make games. Art. Literally, art. The greatest artform mankind has ever conceived. Movies, novels, paintings, music, sculptors, acting, singing, costuming, architecture, mythology… you name a form of creative human endeavor and it is used in games. You name a branch of science, and chances are it has its use in games (from biology to physics to engineering to geology to astrology to psychology). Plus we as programmers do all the crazy computational algorithms and software architecture stuff non-game programmers do… but we have to do it in 60 frames per second, often push it out to platforms where patching is literally impossible, and target multiple types of limited hardware with each project.

That very fact changes the entire mindset behind game development compared to, say, eCommerce development. You can be passionate about the technology in eCommerce software. You can be passionate about the quality of the software. You can be passionate about how good eCommerce software helps businesses become successful, helps consumers find the products they need and want. You're never going to be able to get excited about how your software has touched lives, though. Your software never has an emotional impact. Your software doesn't form the foundation of anyone's childhood. Your software does not define an entire sub-culture. ;)

Medical software I think would be more interesting than eCommerce. At least then you can be happy knowing your software does more than make people money. I'm not sure what you work on specifically, but I'm assuming that it in same way is improving treatment for patients and hence improving lives in very meaningful way.



Naturally. Part of that just has to go with picking the right team. If you've got one guy who loves Halo-esque FPSes and another guy who loves deep, complicated MUD gameplay, you've got no business putting both of them on the same team to design (or even develop) the same game. It just ain't gonna work out. Don' do eet.

Generally, you want to get things like the vision, concept, and a good deal of the GDD down before you ever pull in a team of developers. It's not always possible, but if you can, great. Try to attract developers that are already in on your vision and concept rather than trying to get a bunch of bored developers together and then agree on what to do. That's good advice in the corporate and it's damn important advice in the hobby world. :)

I've been down the road of getting a handful of developers together and saying, "make a game." You argue for 6 months on what game to make, argue another 6 months on the specifics, and eventually all just drift away from the project because you can't get anything done. It's pointless and a massive waste of time, and nothing good comes of it. I've also been in the position of being paid to do the same thing, and saw the same result, except instead of "drifting away" it was "burn through corporate funding and go out of business." Same problem, same result, doesn't matter if it's commercial or a hobby.

Put out real game proposals. Just like we tell the countless people on the MUD forums who post "I have a game idea who wants to work on my MUD for me?" … WHAT idea? What specifics? Why do I want to work on this project? Does the project interest me? Do I believe in your ability to lead the project?

We do the same thing in the corporate game world. If Microsoft puts out an ad for developers on Halo 4, I'm not even going to apply. I don't give two shits about Halo. I'll go take the job offer at Valve or Bioware or Bethesda. People work for companies that make the kinds of games they care about, and if there is no such company, they go form their own company _with like-minded developers_. Pretty much how all the major game companies started, actually. ;)

It's a little worse off in the commercial space due to the use of NDAs, so you often don't know what job you're really applying for. In practice, a lot of the developers hired are friends of other developers and get recommended, and it works out anyway, but it's a bit hard to tell that looking in from the outside. And you can still walk away from the project after signing the NDA, but you have to be careful that the NDA doesn't include any excessive non-compete clauses.

(I was once asked to sign an NDA for a project that would have essentially ended my career if I had signed it. Not only would the non-compete clause have restricted me from getting another job in any remotely related field if I turned down the project, I'd have been bound by the NDA and it non-compete clauses even if I jumped on board and stayed with it until the project was complete. I'd be without work for two years in any field related to eCommerce or social networking on the Web, essentially, which are the only two real marketable fields on the Web, and the Web is what I currently do for a living. BE CAREFUL KIDDOS! READ YOUR CONTRACTS AND MAKE SURE YOU UNDERSTAND THEM FULLY BEFORE SIGNING!!!)



There's actually a lot of research that suggests that they damn well should, and it's not at all uncommon for managers with more modern management styles to allow something similar to that. Not letting the devs go home, of course, but being very, very, very open to project reassignment (temporary or longterm) if the programmer isn't up to par on the current task.

You can force someone to do a job, but the job is going to be done slowly, and the quality will suck. You could just fire any developer that isn't 100% motivated 100% of the time, but then you'd fire everyone before too long.

The McCarthy Core Protocols even have rules about that very thing. If someone isn't up to working for the day, don't make them. All they will possibly achieve is bringing the rest of the team down a notch. Let them have a day off if working at all is a problem for whatever reason, and just let them work on a different task or different project if what they have is being an issue for them.

There are big limits on this kind of thing, naturally. If you've got a guy who never wants to work on anything you give him, that's a problem. Talk it out, see if there's something you can do to fix the issues he's having, and if not, let him go.

It's really no different than taking a sick day. People get sick. You can't expect them to come into work when they're puking their guts out every 30 minutes. You even give them _paid_ sick days. But, if you've got a guy who's sick 2 days out of every single month, you fire him.

There was a presentation at PAX about the infamous deadline crunch in the game industry. The thing was that a research team over 5 years found that the companies that forced developers to meet deadlines consistently had underperforming products compared to the companies that were open to letting the developers work at a comfortable pace and take reasonablee personal time or project reassignments.

There was a neat graph I wish I had a copy of. It basically showed that as developers are given expectations (e.g., deadlines and milestones) their productivity rose (which makes me want to try them in the hobby project even more now) but that its a curve… too much pressure and too high of demands out of a stressed workforce resulted in productivity to drop.

The simple example being that the guy who stayed in the office all night trying to fix some bug to meet a milestone was actually less likely to fix it even a week past the milestone than the guy who told his boss it'd be a day late, went home, got a full night's rest, and came in and worked at full mental capacity the next day. The guy who tried like all hell to meet the milestone would often end up not only missing the milestone anyway, but missing it by a larger margin.

Any college student can probably back that up pretty easily. ;)

Again, all in moderation. A company that just lets any employee do whatever he wants is not going to work. At all. Neither will a hobby MUD project that lets developers commit whatever they want whenever they want to a central repository with no plan, for that matter.



It usually doesn't. Doesn't mean it can't.

It's unfortunate to be stuck thinking that suboptimal ways of doing things are the only way to do them, just because that's how they've always been done. Especially when we can point to real-life companies actually doing things in better ways that are actually working out very well.

I blame the managers and HR departments, not the developers. Most of them just have no clue how to run a good software department. You can't really blame them that much either, though… how would they have ever learned it? The techniques change pretty often to boot. A lot of the software companies around now are using software development techniques developed in the 90s which, while clearly better than the techniques in the 70s are 80s, fail to make use of the advancements made in recent years. I hope you're not stuck in an environment where the programmers are expected to wear suits and work in isolated cubicles. They figured out that actually degrades performance 10 years ago, and yet it's still so damn common. Sad :(



At some level, yes. It is not the prime motivator for the developers and designers of the -good- games that come out though. And the neat thing is, the -good- games make a ton of money anyway. If you're primary motivator is money, though, your game will be crap. There are more than enough examples of that happening. Or cases where the desire to make money, like Microsoft forcing developers to release games earlier under the belief that meeting some arbitrary deadline will increase the profit/expense ratio, fails.

(fyi, the average game programmer makes about $85k in his first 5 years in the industry and about $110k after 6 years, according to the February 2009 edition of GDM. given the level of technical expertise these guys are required to have, most of them could be working in more "professional" fields and making close to twice those figures. hell, I'm paying out the ass to go back to school, taking a huge pay cut while in school, and turning down what could easily have become a $180k salary in order to go work on games. I have another friend who quit his job as a top-tier developer in database technology to work on iPhone games because it was more fun. money clearly isn't game developers' primary motivation.)

This is actually a great example of why games are different from all other software. A very, very important one, possibly the most important:

If you release Version 1.0 of MedicalSoftPro, and it isn't the best product amongst the competition, it's not a _huge_ deal. You just release Version 2.0 a year later, fix the issues, and sales go up.

With a game, if the initial release sucks, there's no fixing it. You can patch it, release add-ons, but it doesn't matter. Once released, the game is done. It is what it is. If you fuck up the development and release the game, the entire project is pretty much bust. You don't even bother with non-critical patches and add-ons because nobody is going to care about them anyway. Only the good games even have a market for add-ons, and only good games have a clear shot at sequels.

You can't put profit before quality in the game industry, because it doesn't work. The two are tightly conjoined, not distinct entities. You can't cut corners and you can't half-ass the project in the hopes of having higher margins, because if the game doesn't rock, you'll not be able to recoup your expenses at all. If your developers don't do the best job possible, the project suffers, and sales suffer, and you can't just throw more time and money and resources at it to salvage it once the damage is done.

More commercial game projects get canceled than get released (sound oddly familiar, MUD developers?) because of mismanagement and mistakes during development, and once those are made, there's just no going back. You can't just put out the half-assed version 1.0 and hope you can turn it around by version 2.0. Most of those crappy games you see around are put out by companies that no longer exist, because once they prove they can't deliver, nobody wants to produce their next game.

(On a side note, that is clearly one of the bigger differences between commercial and hobby game projects. A hobby game project is just as susceptible to failure, and from most of the same reasons, but failure won't screw over the hobby project developers in any significant way. I do not however believe that that means that hobby developers should just accept failure as a likely outcome and ignore all the tools and methods available to avoid failure. If you don't care if you fail, find something else to do with your free time that you actually do care about. And just like how a corporate game company wants to avoid hiring unmotivated developers, you as a hobby team leader want to avoid "hiring" unmotivated volunteers that are going to bring your project down with them.)



Hence the game concept, which is that very paragraph. :)

Please understand – the vision is the most important, but "most important" does not mean "only important" thing. The brain is the most important part of a human body, but I think you'll find that a body is pretty useless without most of the other organs. And when you look at the whole, the last thing you probably think is, "wow, that's a nice brain!" You're probably more interested in all the things that brain is doing – its specific thoughts, personality, experiences, etc. But all of those would be drastically different given a someone else's brain. (Cue some idiot taking the metaphor out of context into an irrelevant nature-vs-nurture debate in 3… 2… 1…)

You can't sum up any human being with just a few words… and yet we do it all the time. And that is exactly how character designs are done. You start with a few simple words. Not a paragraph, not even a sentence. Just a few words. That's really the actual "pro" technique authors have been using for a very long time. Same idea. THEN you expand with details. However, in any movie, book, game, or any other story, a good author is really careful about over-detailing any character. Real humans are very complicated creatures, but even the most complex character you've ever seen in any story is stripped down, simplified, and reflects just two or three words (if not just one). They have backstory, they have desires and goals, that have development over the course of the story, they are odds with themselves at times… but they're still very clearly archetyped, because otherwise the character ends up being uninteresting and his place in the story becomes very muddled.

That character design process is the same as a full game, movie, or any larger work. Even very complex and intricate books are derived from a very simple concept, and that concept is derived from a very simple vision. You don't start writing a book by outlining the plot, you start by figuring out what kind of book you want to write. You come up with an overall concept for the plot and main characters, but that concept reflects the type of book you're making; if you're writing a thriller, you design a very different plot and sets of characters than if you're designing a romance novel. The details of that plot and the characters reflect the concept of the story, to the point where extraneous details, extraneous personality, and anything that doesn't contribute directly to the narrative or the underlying message of the narrative is cut.

Everything is designed this way. Whether you want to accept the truth of it or not I guess is your call.

Realize that these formulized rules weren't just pulled out of someone's ass. Nobody sat down and said, "how can we make game development better? I know, let's make up a bunch of steps, see if they work, and then write them down!" Didn't happen that way. People got together and realized that _everything_ is done a particular way, just usually people don't realize it. They studied how groups work, studied good designs and bad designs, studied the genesis of those designs, and wrote down what they saw. The pulled out the common successful elements and the common unsuccessful elements, formalized the definitions there-of, and there we have the rules I presented (albeit I did it in a pretty haphazard and poorly expressed format… sorry).

I have a related story about martial arts. Martial arts have been a part of the global human existence for longer than recorded history, starting with the first clubbing of any animal with a rock. Over millenia, the art was refined and refined, improved with new weapons, new techniques… eventually forming what some people considered the pinnacle of martial arts found in the East. A few short hundred years ago, a German man by the name of Johannes Lichtenauer, a swordsman and life-long student of martial arts, decided to travel the world and learn what he could from distant masters of the martial arts. When he finally returned from his journeys, he began to study in depth what he had learned. What he had noticed was that every form of armed and unarmed martial art had a great deal of common elements. He saw many techniques that simply did not work against other techniques, and a handful of techniques that seemed to universally work. He threw out all those techniques that he knew had weakness, that only worked in very specific circumstances against specific styles with specific weapons, and concentrated on those universally sound techniques. What he developed was a system of martial arts – a system, not a style – that at the time was essentially undefeatable. He did this not by picking and choosing the best of the techniques, but by breaking them down and figuring out WHY they worked. He determined that there were only a scant handful of stances that were universally effective. He determined that there were only a scant handful of attacks that didn't leave the attacker wide open in the process. He noticed that defensive approaches to combat were doomed to failure, because if your attacker makes a tiny mistake then you have no opportunity to press it while if you make a mistake then your attacker can press it. He noticed that every attack can simultaneously be a defense, allowing a martial artist to simultaneously attempt to kill his opponent while protecting himself from his opponent with every move. He noticed that timing was key, and HOW timing was key, in that martial arts works much likes notes in a musical composure, with full notes, half notes, quarter notes, and disrupting the beat of your opponent's attacks and pre-empting his tempo was the only way to retain control of your opponent.

Licehtenauer's system of combat turned into the core of all western martial arts, down to modern day Olympic fencing (although the nature of sport combat versus combat for survival has, sadly, caused a good deal of the proper martial arts to be lost and bad techniques to gain popularity). Lichtenauer didn't just invent a new way to fight. He broke down all the styles he found, pulled out the base elements, and formulated those base elements into what was (and in many modern practicioners' opinions still is) the greatest form of martial arts mankind has known.

I've studied Lichtenauer's system, and I've studied other styles including Japanese styles. It's easy to see the truth in the above story if you have. Kenjutsu (Japanese swordsmanship) is made up of many styles. These styles all are very similar to each other, and very similar in many ways to Lichtenauer's system, naturally. The styles, however, are made up of many, many, many techniques, each designed for a specific use in a specific circumstance. There are stances, there are base attacks that form the foundation of the style, but in the end the masters that created these styles just worked through trial and error to find ways to defeat particular attacks or defeat particular defenses. They worked at being excellent swordsman, and they truly were excellent swordsman, but they failed to truly grasp what it was that they were doing or why what they did worked. It took thousands of years and the birth of one inquisitive, sharp German boy to bring martial arts into a true science.

Lichtenauer's systems have been revised and extended over the centuries, for sure. His system works poorly in some ways in sport combat, for example, depending on the specific rules, because his was the art of killing and surviving, not of tagging each other with sticks. There are alternative styles for when a skilled opponent is facing many unskilled opponents, where Lichtenauer assumed every opponent was equally skilled (which is a safe bet; underestimating an opponent will get you killed, otherwise; but it can fail to help in situations where you really are just massively outnumbered by many lesser opponents). Lichtenauer's system is unpopular in the East to this day because the East continues to use traditional Eastern weaponry that has a great deal of weaknesses compared to Western weaponry (the katana is NOT the ultimate weapon that Hollywood portrays it as; quite the opposite, really – a Western longsword would shatter a katana after enough impacts, and the katana will never in a million years cut through the longsword). However, the core of modern martial arts is derived from Lichtenauer's system.

The same thing is just as true with any other art-slash-science, including the techniques used to manage teams, the techniques used to write literature, the techniques used to compose music, and so on.

A second story! There was an article I read just a few days ago about the science behind music, for example. It's still hard for many of us to really think of music as a science. It's almost the oldest form of pure-art humankind supposedly has, right after paintings. And yet, there is a science behind it. There's a reason certain notes are pleasing, there's a reason certain combinations of notes are pleasing, there's a reason certain notes and combinations of notes evoke different moods and emotions. Once you understand the science of it, you truly can break those rules down into algorithms and formulas, and from that point you can procedurally generate unique compositions that sound every bit as "artful" and masterful as the compositions of Beethoven or Mozart or Led Zeppelin. And piss of a lot of artsy music purists in the process. I think the word "abomination" was mentioned in the article, not because the scientific techniques produced crappy music, but because it worked so well and the closed-minded musicians felt that it was inhuman and unethical to pursue further. :)

There is a science behind writing. There is a science behind painting. There is a science behind game design. Those fields are not defined by some people making up arbitrary rules. They're discovered as truths after enough analysis, same as physics or any other "pure science."

The rules I presented are the first steps in the development of the science of games, and are derived in large part from the existing study of the science in the development of other kinds of stories and other kinds of entertainment (including the millenia-old art of the puzzle).

The idea of the vision is formulized not because someone thought it sounded like a good idea. It was formulized because it already exists, and always has existed, even though people didn't really realize it before. There probably is some refinement to the idea possible. I'd bet on it, actually. But suggesting that the vision is bogus and that the game concept (which is what some of you keep seeming to confuse the idea of the vision with) is all you need is simply ignoring the facts. You can get by with ignoring the facts if you want; people have been doing that since the beginning of human existence before the facts were even discovered. But acknowledging them helps. Understanding them helps. It helps avoid mistakes, it helps avoid wasting time, and it helps to improve the quality of your endeavors.

In other words, learn from others' failures and learn from others' successes. :)

(I think I've said about everything I can on the topic, and then some. If anyone is still skeptical, I'll just have to accept that there's nothing I can do to convince you. I'll get over it. I hope some of you are getting value out of the discussion, at the very least. Good night! ^_^ )

Is the air sufficiently oxygenated up there on that pedestal you've constructed? :wink:


There is certainly a lot of value, but unfortunately I think that value is diluted slightly by the post length. (Hope you don't take this badly, it's not meant to cause offense; just meant as a remark in passing to improve the quality of posts with some very interesting content buried in them.)

If you are trying to keep your grasp on the Epic Post award, I think this could well do that for a long time. :lol:

But they're still going to put in a lot more work than a bored hobbyest mud developer. And no matter how exciting a project is, there will always be boring bits.


Not quite - if the competition is "better" (which of course is somewhat subjective), the customers will use their products instead. Patches and updates no longer matter, because the potential customers have already bought your competitors product (including expensive specialised hardware).

However it's certainly the case that meeting deadlines is very important. If you delay the release of a computer game, the customers grumble. But if you delay the release of a medical product, the customers who need a product now will buy from your competitor instead - and losing market share can have other knock-on effects, such as losing partnerships with companies that produce third party tools.

So you have to reach a balance between the two. This usually means dropping non-essential features from the initial release if the project falls behind schedule.


It's exactly the same for mobile phone development - if the product sucks, there's no fixing it. As with games you can patch later releases, and offer patches to existing customers, but by that point most of the damage will already have been done.

However compare that with hobby muds:

If the initial version sucks, it doesn't really matter, because there's no "release" as such - the product is under constant development and refinement, and customers tend to be a steady trickle (rather than all waiting around for the grand opening). You simply open the doors when you feel ready for players - and if you mess up badly enough, you could just close the doors, rename the product, and reopen again in a few months. No harm done.

You don't have any budget concerns. You want customers, but you don't need them to survive. You might give yourself deadlines, but there's no real pressure to meet them. There is no "finishing line", so you're better off developing at a comfortable pace rather than burning yourself out. Your staff aren't being paid, so you can't expect them to put in anything close to the same hours as a full-time job - but it's perfectly feasible to create the entire game on your own, so reliance on others isn't necessary.

Developing a hobby mud is very different to developing a commercial video game. Certain conceptual principles of video game design may be interesting and/or useful to a mud developer, but the differences are bigger than the similarities. MMORPG development would be more appropriate to us, but even that has many differences, and shouldn't be viewed as gospel.

I have been skimming/skipping your posts, because I have a very short attention span and they tend to run rather long, but I decided to read this one. I got as far as your second quote before I wimped out. I guess I'll probably end up reading the rest through the quotes of it that other people include in their responses. I'm probably a bit worse on the paying-attention category than other people, but you may wish to start including bullet lists or sections or something so that people can jump to the parts they really want to read and skip the rest.

I will go back and read the novel in a bit, but for now I just wanted to reply to some stuff that came before it. :)

Some of my absolute favorite games were Populous, Dungeon Keeper, and Black & White. The common theme there is that they were all headed by Peter Molyneux. They were all a lot of fun to play. However, in the later games, there seemed to be some element missing, and I think that element was mid-term goals.

Populous was simple. You're God. There's another God over there. You both have tools available to you, and the more followers you get, the more tools you can use (and more often). You win if you have the only living followers left. The game was set in levels, and levels got progressively harder with less resources.

Black & White was more ambitious. Your goal was to take a childlike creature and grow them into a godlike avatar. You had the choice of being nice and developing a friendly avatar who would defend your people, or being mean and developing a vengeful avatar who would kill the enemy by whatever means necessary.

The problem is, it tried to be BOTH a sandbox game, letting you do whatever you wanted, AND a story-driven game, forcing you to follow a script.

The story was decent. The set of things you could do was decent. However, if you weren't following the script, there were no mid-term goals available to you. Either you went back to the story, or you puttered around planting trees, pooping on villagers, whatever.

I think a successful game needs to have short-term goals (fetch me a spoon!), long-term goals (become powerful enough to save the kingdom), and mid-term goals (uncover the corruption in the city's land-grant office). It needs to be flexible enough to let you shift around doing short and mid-term goals freely, but still nudge you towards the long-term goal (or one of them, if you have alternate endings).

A true sandbox game can only work with lots of players (who write the story themselves via PvP conquest), or with the kind of really good goal-driven AI we don't yet have available to us without a LOT of work and CPU power.

I'd like to hear more about the AI comment. What makes you say that the CPU is a limiting factor? I'm tempted to believe that the computational resources are actually relatively cheap, and it's figuring out how to model the problem that is vastly more complicated.

You know, quix, you might have inadvertently hit it. Mid term goals might be just what's needed to stay the course in developing a MUD.

elanthis, your enthusiasm is unquestioned, but in comparing your opinions to KaVir's, yours lack "As someone who has worked in the aerospace, telecoms and medical industries over the last 13 years…". :wink:

The credentials game is an exceedingly dangerous one to play; I don't think anybody here wants to start getting into the business of evaluating people's opinions based on "credentials".

I know plenty of people who've worked in plenty of industries for far more than 13 years, and their opinions are terrible and uninformed, and I wouldn't go to them to seek advice in anything but how to be bitter and short-sighted. Fortunately, KaVir is not one of these people, but such statements really don't mean very much at all. Let me evaluate statements based on the statements' worth, not based on the number of certificates, years, or other "gold stars" obtained by the speaker. If what you're saying is true, it should hold up on its own merits, ne?