Gamedev atricle about a failed game-project

hi

i found this article by fortune. its already a year or 2 old and maybe you´ve already read. but if not: it is an article about a failed gameproject of an iran company. they report about their problems they had at programming, the engine, artwork, etc.
maybe it could help someone to avoid pitfalls and conceptual traps in the game-developing process

http://www.gamedev.net/reference/business/features/pmAOP/

great article.

It is extremely frustrating to read that they did such newbie mistakes that I didn't even consider to do.
But, even when you don't do mistakes, it is about the weak points of your decisions and skills that make the difference of fail or success.

1st sentence of the programming mistakes.

I also have problems avoiding this. Some think are making fun and you want to go on with them. Soon, you noticed that the task you did before isn't working correct and isn't completed and you have to recode your "Fun Task". Good Article.

Thats where the tools should come in.
A very fast tool to (half automatically) place fauna in the Leveleditor
takes a coule of Hours programmers work, but
saves the Level-designer weeks.



Thats like Multiplayer functions.
Its very very hard to implement it correctly in the end of the project.

saw this a long time ago on the irrlicht forum. definately intresting and addresses the very basic beginner oversights very well.

Very good article. Too bad about the guy's game

good thing that there are people here on the forums who bring these good articles on the table for those (like me) who have limited connectivity to the internet. Thanks

(Did someone else too see similraties on their projects mistakes and the ones in the article)

a lot.

Good articler and a must read for everyone who is green and wants to make a MMORPG or similar.

Personally, I don't think that they would have failed so much if they would'nt had that "budget pressure" behind their necks so early. Being free with no restrictions, limitations and deadlines can be so fruitful to a project. Obviously, they had much to learn throughout the project and RPG's may be not the wisest choice for the first, big, selfproduced project, but if they had more time to discover their own possibilities, I believe that they could have made it better.

This is a great read man! Thanks! So much to learn here.

"This might sound controversial, but I believe that our game rules should have been hard-coded from the start, instead of wasting time on trying out all kinds of hand-made semi-scripting tools. "

Controversial my ass. This is one of the most interesting points of the article for it points towards the difference between indie and industry... Industry can make a game AND and editor... indies have to choose one or the other to start off with.

And actually, this trancends entertainment games. For example, when designing edu software, I constantly get asked if I will be making an editor, to let the teacher create her own worlds. And I say "No." and hardwire the educational content to the game. It's easier to develop, maintain, and ultimitely get your message across in a hard wired game than an open editor IMO.

Great article, but GameDev.net is full of such material. If it's not already in your bookmarks or RSS feed, you are missing out on the single most useful info source for indie game devs IMO.

The more time is spend on an early prototype,
the less gamerules have to be "dynamic" to be defined
later.

Its important to define early on what has to be static
content and funtionality, and what should be dynamically
imported.
This defines what a potential editor must include.

Making a game fully dynamic sounds tempting to the developers
selfesteem, but can potentially blow up development time
without adding much value to the product.

Defining functionality very static can prohibit
fixing obvious flaws in the gameplay laster on.

Thats where the prototype must sort out these questions early on.

@Fastlane, Democles, those are some great points, though I'm just a writer I do voice my opinions to the developers I work with.

Check out the writer's site too. He has some fantastic articles on there. This guy has solutions to things I never thought of...