A relevant article for game developers
Moderator: Forum Moderators
A relevant article for game developers
I stumbled across this today, and felt it needed to be shared.
http://makegames.tumblr.com/post/113662 ... ing-a-game
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.
It's spelled "definitely", not "definately". "Defiantly" is a different word entirely.
- Ken_Oh
- Moderator Emeritus
- Posts: 2178
- Joined: February 6th, 2006, 4:03 am
- Location: Baltimore, Maryland, USA
Re: A relevant article for game developers
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.
Re: A relevant article for game developers
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.
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
- Posts: 836
- Joined: September 6th, 2008, 11:08 am
- Location: On the beach at sunset, gathering coral
Re: A relevant article for game developers
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!
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!
...apparenly we can't go with it or something.
Re: A relevant article for game developers
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.Gambit wrote: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.
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".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.
What do you mean? I'm not the foremost expert on BfW pre-history.Ken_Oh wrote: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.
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.Midnight_Carnival wrote: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!
It's spelled "definitely", not "definately". "Defiantly" is a different word entirely.
Re: A relevant article for game developers
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-
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
- Moderator Emeritus
- Posts: 2178
- Joined: February 6th, 2006, 4:03 am
- Location: Baltimore, Maryland, USA
Re: A relevant article for game developers
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.johndh wrote:What do you mean? I'm not the foremost expert on BfW pre-history.Ken_Oh wrote: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.
- Midnight_Carnival
- Posts: 836
- Joined: September 6th, 2008, 11:08 am
- Location: On the beach at sunset, gathering coral
Re: A relevant article for game developers
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.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.
seriously.
...apparenly we can't go with it or something.
Re: A relevant article for game developers
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
Re: A relevant article for game developers
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.
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.
Re: A relevant article for game developers
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.
Note that this misprioritization was over on the code side; I didn't do a pixel of that titlescreen stuff.
(allacrost)Midnight_Carnival wrote: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.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.
seriously.
Note that this misprioritization was over on the code side; I didn't do a pixel of that titlescreen stuff.
Play Frogatto & Friends - a finished, open-source adventure game!
Re: A relevant article for game developers
Ahhh, one of the Aquaria boys.Jetrel wrote: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.
Wesnoth Bestiary ( PREVIEW IT HERE )
Unit tree and stat browser
Canvas ( PREVIEW IT HERE )
Exp. map viewer
Unit tree and stat browser
Canvas ( PREVIEW IT HERE )
Exp. map viewer
Re: A relevant article for game developers
First of all, fantastic article.
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.
Hi,Gambit wrote: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.
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.
Re: A relevant article for game developers
Awsome article, thanks for sharing! Sent link to a bunch of people
Lamps and Megarace http://forums.wesnoth.org/viewtopic.php?f=13&t=30708
Re: A relevant article for game developers
I found these neat posts and linked video:
Cultivate Teams, not Ideas
With a link to: Ed Catmull, Pixar: Keep Your Crises Small
Cultivate Teams, not Ideas
With a link to: Ed Catmull, Pixar: Keep Your Crises Small
Code Simplicity>> Success Comes From Execution, not Innovation"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.