A relevant article for game developers

[johndh]

I stumbled across this today, and felt it needed to be shared.

http://makegames.tumblr.com/post/113662 ... ing-a-game

As I work towards completing my own game, I’ve been thinking a lot about finishing projects in general. I’ve noticed that there are a lot of really talented developers out there that have trouble finishing games. Truthfully, I’ve left a long trail of unfinished games in my wake… I think everyone has. Not every project is going to pan out, for whatever reason. But if you find yourself consistently backing out of game projects that have a lot of potential, it could be worth taking a step back and examining why this happens.

[Ken_Oh]

In a way, it kind of flies in the face of Wesnoth's game development, but one has to remember that David finished his game when he released it to the public. That doesn't mean he had a 1.0 version out, but it was completely playable.

[Gambit]

I found point 11 interesting. A pit I didn't realize I had fallen in (many, many, many times) until that post explained it to me.
However, every time I do rewrite from scratch, I end up with cleaner, easier to work with code that makes developing real new features faster. So I'm not so sure I'm going to change my habits even now that I know I have them.

[Midnight_Carnival]

Liked the cartoons most.

One thing they didn't tell you though: Do not, under any circumstances start with the titlescreen or splash screen! It gives your project really bad voodoo! every game made by people I know which started with this got no further. Although I agree with thier advice about making sure you have a good engine or whatever before you make the game pretty, the point I have just made is not about that, it's about not jynxing youself!

[johndh]

I found point 11 interesting. A pit I didn't realize I had fallen in (many, many, many times) until that post explained it to me.

That was certainly the most relevant point for me as well. I'm not working on an entire game, but rather just a tech tree for a game, and I've been "done" with the buildings multiple times now. Whenever I finish one part of the project, I realize how much better I've gotten, and the older models, textures, and animations just don't live up to my newer standards, so I get stuck in a cycle of make, improve, disapprove, remake, lather, rinse, repeat. If I didn't spend so much time redoing my old work, I'd have had a playable release a long time ago (say, a year or so). I'm almost done now, but how many times have I been "almost done" so far? I've lost count.

However, every time I do rewrite from scratch, I end up with cleaner, easier to work with code that makes developing real new features faster. So I'm not so sure I'm going to change my habits even now that I know I have them.

I guess the question is whether it keeps you from finishing or not. A finished project is worth something even if it's less than stellar, while a million top-notch almost-finished projects are all worthless. Even if you learn a lot about programming and whatnot, even that is empty if it never leads to a finished product. Plus, you can always redo the messy parts for another release. That's where the "save it for the next game" part comes in, or in this case "save it for 2.0".

In a way, it kind of flies in the face of Wesnoth's game development, but one has to remember that David finished his game when he released it to the public. That doesn't mean he had a 1.0 version out, but it was completely playable.

What do you mean? I'm not the foremost expert on BfW pre-history.

One thing they didn't tell you though: Do not, under any circumstances start with the titlescreen or splash screen! It gives your project really bad voodoo! every game made by people I know which started with this got no further. Although I agree with thier advice about making sure you have a good engine or whatever before you make the game pretty, the point I have just made is not about that, it's about not jynxing youself!

How would you, anyway? You'd be making a title screen when you don't even have a feel for the game's play style, art style, or general vibe at all. You could wind up with a lighter and softer title screen for a darker and edgier game, or steampunk for far-future sci-fi. It would be like that one album by Atreyu, except they presumably did it on purpose.

[markm]

Using existing engines can certainly save a lot of work.

I picked up an Athena-widget based GNU licensed Civ game long ago to save building some such thing from scratch. But a few versions later someone started Freeciv, which seemed a better approach partly because it separated the server from the client. So the old Athena based one was dropped, no one seems to have bothered picking that up again, and work continues using Freeciv.

Things seem to get interesting though when you use different engines for different scales, when each of those engines / scales actually works just fine on its own. Part of what I am aiming for is the interaction between the scales. But quite a few players who are fond of one scale or another are actually quite unfond of the idea of people operating on other scales interacting with "their" game.

Originally I had a Fantasy Roleplaying game. I found that my players at that time were decidedly unfond of running baronies and kingdoms and such, they just wanted to dungeon-crawl and were not the least bit interested in who would create such dungeons, what for and why, let alone how the builders would pay for them. Thus the interest in Civ type games. Just how many dungeons can a planet afford? Can new ones be built fast enough to keep up with the rate at which adventurers clean them out? If we do decide to raise adventurers on our planet, how will that help our planet overall?

Using existing engines means encountering the people who like what their engine already does just fine and are not at all interested in allowing people running under some other engine to interact with their economy or balance of power or whatever...

...Despite so many common claims that an everything-game would be awesome. For there is indeed a tendency for people to tunnel-vision in on a particular aspect of the game and see value in eliminating all other aspects so people playing those other aspects don't "interfere". That "interference", that interests me so much, is not seen as a good thing at all by some people...

-MarkM-

[Ken_Oh]

In a way, it kind of flies in the face of Wesnoth's game development, but one has to remember that David finished his game when he released it to the public. That doesn't mean he had a 1.0 version out, but it was completely playable.

What do you mean? I'm not the foremost expert on BfW pre-history.

I was just noting that Wesnoth may never be "finished" as a game, however David built the game in a short amount of time (a couple weeks? a weekend?) and released it. Consequently, it looked like this, but actually releasing something (as far as the article is concerned, "finishing the game") allowed him to gain attention of artists and coders. The rest is history.

[Midnight_Carnival]

How would you, anyway? You'd be making a title screen when you don't even have a feel for the game's play style, art style, or general vibe at all. You could wind up with a lighter and softer title screen for a darker and edgier game, or steampunk for far-future sci-fi. It would be like that one album by Atreyu, except they presumably did it on purpose.

I wouldn't. But I've known people who would, it is almost like they get a great idea for a title(/screen) and hope that a good game will emerge if they give it a pretty enough face.
seriously.

[vcap]

Shadowmaster wrote quite a bit on the topic of wesnoth pre-history: http://shadowm.rewound.net/blog/archive ... n-0.1.html and http://shadowm.rewound.net/blog/archive ... -Dave.html

[jb]

I enjoyed this article. In many ways, it works the same when creating scenarios for Wesnoth.

I've made quite a few UMC wesnoth scenarios over the years. Sometimes with others, sometimes alone. Some projects get finished, some don't. Some of them are absolute crap, and some are quite fun.

I think the key to growing is to keep doing it. Accept your failures and enjoy your successes, but keep at it. Don't be afraid to fail, because in six weeks nobody will even remember, and you've already moved on to your next project.

In any creative process, finishing is indeed a skill. It's a bit about letting go. You have to let it go of your baby to see if it can stand on it's own.

[Jetrel]

Wow, Derek Yu is a surprisingly thoughtful and intelligent guy. I knew he'd done spelunky, but I didn't realize he was that intelligent/etc.

How would you, anyway? You'd be making a title screen when you don't even have a feel for the game's play style, art style, or general vibe at all. You could wind up with a lighter and softer title screen for a darker and edgier game, or steampunk for far-future sci-fi. It would be like that one album by Atreyu, except they presumably did it on purpose.

I wouldn't. But I've known people who would, it is almost like they get a great idea for a title(/screen) and hope that a good game will emerge if they give it a pretty enough face.
seriously.

(allacrost)

Note that this misprioritization was over on the code side; I didn't do a pixel of that titlescreen stuff.

[ancestral]

Wow, Derek Yu is a surprisingly thoughtful and intelligent guy. I knew he'd done spelunky, but I didn't realize he was that intelligent/etc.

Ahhh, one of the Aquaria boys.

[MCP]

First of all, fantastic article.

I found point 11 interesting. A pit I didn't realize I had fallen in (many, many, many times) until that post explained it to me.
However, every time I do rewrite from scratch, I end up with cleaner, easier to work with code that makes developing real new features faster. So I'm not so sure I'm going to change my habits even now that I know I have them.

Hi,

To introduce, I am a very meticulous and nit picky person when it comes to doing things correctly. Perhaps too much attention to detail, so I've had to learn some ways to compromise.

What I usually end up at is:
1. Version 0.1: Hacked together. Missing many features. Playable with probably 'minimal' functionality.
2. Version 0.2+ and onward: Maybe I want to add new features and I didn't realize all the requirements (all too easily). Refactor the code a little bit. Hack together the next part as best as possible.
3. Repeat.
Sometimes I get lucky and think of something so when I implement it, it's a much more malleable solution. Experience helps a lot.

The thing is, even if I choose the best algorithms and I write it 'correctly' according to my assumptions, there always something I didn't think of, for instance logic border cases, concurrency timing issues, question mark (Four letter words?! customers? quantum physics?), so I'm going to have to accept something part way there that is functional.

1. Correct: Get it safe 99.99+% of the time.
2. Time: Get is done quickly (or maybe it takes infinite time to implement), both in the number of hours spent implementing it and computation efficiency.
3. Money: Time costs money. Correctness costs money. There is a finite amount of money, eventually they're going to pull the plug, even on Duke Nukem Forever.
Pick two of those. You always have to pick 'Time' if you want to finish, so that leaves money constraints or correctness requirements. Usually I'd end up sacrificing correctness and some computational efficiency to get it done in the finite amount of money/time available. This is why complicated games such as the Fallout series contains so many bugs.

[batoonike]

Awsome article, thanks for sharing! Sent link to a bunch of people

[MCP]

I found these neat posts and linked video:
Cultivate Teams, not Ideas
With a link to: Ed Catmull, Pixar: Keep Your Crises Small

"If you give a good idea to a mediocre group, they'll screw it up. If you give a mediocre idea to a good group, they'll fix it," he said.
To avoid such problems, Pixar's development department now spends much of its time building healthy creative teams.

Code Simplicity>> Success Comes From Execution, not Innovation