Slashdot Mirror
Why Game Developers Should Finish What They Start
Michael writes "Too often, hobbyists and open source programmers take on game projects that they can't hope to finish. Freshmeat is rife with games from developers who have bitten off more than they can chew. So I drafted an article which takes a look at the major roadblocks to successfully completing open source and hobbyist game projects."
There are times when I'm working on my personal project (a game, not surprisingly) that I just stop after getting one feature debugged, and I end up doing anything but work on it for weeks on end.
The way that I get myself back on track is by concentrating only on the code that must get done and then I worry about making it more robust later on. I sometimes find myself worrying about the content. This is A Bad Thing(tm) to do while programming a game engine. It's a lot better just to focus on the code and the functionality first.
Obviously, there are times when I physically am unable to program for various reasons (real life and all that). But, no one said that being an open source game developer was easy.
I'd love to post my game URL here, but I'd rather not have my ISP think there's a DDoS attacking me. It's called Ether though, it's a web-based MMORPG. (there's a very uninformative page for it on SF.net [projectname: ethermmorpg])
As an amateur game developer, I can tell you I've got more half-written games around than I can count :)
:)
The reason why people give up is quite simple.. it's fairly easy to get a 80% complete game, and see what it's like. The last 20% however takes 50x longer to do, is really quite boring, and by that point I've had a new idea for a "greatest project ever!", and have decided to go and write that instead
One problem with games that other programs don't have so much is that most games (with the except of fairly free-form RPGs like nethack) is that most people will only play them once or twice, so if you write a game and release a 70% complete version, then 4 months later release a 80% complete version, very few people will re-download and re-play the new version, which is one reason people find it so hard to motivate themselves to finish them, and not just go and write something else.
Now pardon me while I try to get and think of another great idea for a new game and start to write that one!
Combination - fun iPhone puzzling
I have found that when I work on personal projects, a couple games amongst them, I get bored with them once the hard parts (those that I haven't had much experience with ie new to me) are done and bug free (as best I can tell ;) ). I then get distaracted by something else that catches my eye and proceed to half finish it, then.....
The article is about HOW to finish a game, not WHY.
I agree with Pitfall one, three is a bit suspect.
Opensource isn't just a one man band. The best games would have >1 developer to lend a hand.
Don't encourage rash, hacky programming tendancies to push quantity of quality.
Of course, fleshing out mist of your game can be a good way of making you want to complete it.
My advice: Get other people to help with graphics. Go to a site like www.deviantart.com and post a message saying pixel help / 3d help needed for xyz game, AFTER you have an engine that can showcase their work.
Looking good isn't a crime!
There are some rgeat freeware games around, and top down shooters using mouse look are excellent, and they usually have some funky particle FX.
As game development is simplified through libraries, we may see more amateur games, and more skill, pressuring commercial games sales.
CounterStrike for instance, if this used an open source, free beer 3d engine, then the 'best game' would have been open source and free beer.
OK quake 1 is open source now for ages, I am not sure what this means for counterstrike source code?
Valve obv. have license for thier commercial exploits of the game.
Modification of games is also prevelant, making open source games modifiable, even using md2 model files etc, would greatly increase thier adoption.
Top ten open source, free games?
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
And that's always been the case... of course, being more of a tinkerer of code than a real programmer, there wasn't much chance of it ever happening professionally. I've had so many ideas, and quite original, I'd think. Some go back to the early 90s, and they don't seem dated yet.
Well, the last few weeks in particular, I've been working on my first game for real. Allegro, gcc on linux. I'm doing the mundane stuff first, menuscreens, trying to get libmpeg to do cutscenes, not that I'll ever actually have any rendered.
Maybe it was the years of starting to doodle around with code, and never accomplishing anything, but I did realize that I needed placeholder images/video. Done, grabbed random mpegs, doodled out so laughable stuff in gimp. My game will use very little in the art dept, being SVGish in many aspects. At the moment, only the opening menu screens would seem to need any.
The point is, why does this guy think this is a revelation? I can't imagine that there is anyone out there that isn't using Allegro or SDL, or has io needs so simple that a keyboard routine is all they need. His first requirement, therefor, hasn't been an issue in at least 5 years.
His second issue, art/graphics. I can see this as contentious. Even so, those who really want to program, to author the game, they give up on it soon. (In some respects, at least... if I were doing a 3d game, I'm decent enough at 3d modeling). So people either finish this part, or they don't. Does he expect them to design games that don't need any, or would he just rather not see any unfinished games?
It sounds more discouraging than encouraging.
Offtopic: What in the hell do I do with my game, assuming I do finish it?
Check out the 'Indie Game Development Survival Guide' as it greatly expands on the article. A great book covering all aspects on how to complete a game (for fun or profit) as part of a hobbyist game-development team!
4 2
http://www.amazon.co.uk/exec/obidos/ASIN/15845021
"... they focus on strength areas like plot and storyline"
I have been writing a neverwinter nights modules for what seems like forever and I consider the authors tips, at least in the context of a "community mod", to be pure BS. Writing something good is hard, even on a platform like NWN where the game engine is already written for you and you can focus on the "plot and storyline". Doing it well is hard and takes a lot of work. Anyone who has ever written a large dialog tree for even a single conversation would know this. Think about what a players response to each line might be and write all the reasonable branches. By the time you have reached the grandchild node, it is immense. Oh and if any of these have a plot impact, or you include race or class based differences, it gets even more immense. Even a conversation between two NPCs to advance the plot can have you debugging for hours. A cut scene is a serious hair puller.
Blowing things up is the easy part. Fights are fast and simple to put together. Putting together an immersive environment with properly placed background noise and placeables - as opposed to empty and lifeless areas is difficult. Good, self consistent stories and smooth play are difficult. That is why 95% of the modules on neverwinter vault suck and that is also why my "soundstage" modules still have a toolset to gameplay time ratio of something like 100:1. And that is soundstage where I can keep track of the plot in a notebook becasue I will be DMing them later.
Oh and I periodically stop developing because I have a life; plain and simple. Wife, kids, job, friends, other hobbies. Sometimes I get sick of building and even play for a little while.
So here are my own tips on finishing the project:
1) If you have a spouse or significant other, they are simply a drag on your time and preventing you from delivering. Divorce is in order here. If you are not married, it is less of a hassle to extract yourself from this situation.
2) Kids? Give them up for adoption.
3) Friends. If they are not willing to help out on the project (remember the >1 developer rule), then they are not really your friends. Never speak to them about anything else for the duration of the project.
4) Other hobbies. And desires to do anything else with your free time is indicative of lack of focus. Sell your hot rod/mountain bike/golf clubs/books/whatever.
5) Getting bored with your project and need a break? This is the single biggest factor in not delivering. Oh, you say that you will take a break for a few days, watch that DVD, play, see friends, etc and then come back to work on your game again, but will you? Oh you might in a month or six, but your idea will be stale. REMEMBER - YOU ARE NOT DOING THIS TO HAVE FUN!!! Is the project starting to feel like you are still at work? You are. Now get back to that keyboard.
In defense of good software design, there is something to be said for system components that are not inter-dependent. Good design means there is some hope of debugging the system. Achieving this should not take a "bleary-eyed programmer" all night to do it. If this is the case, your software design phase failed.
Oh, wait, there is no mention of software design in this article...
I keep forgetting that game development is not about producing good software, but about efficiently pipelining your artistic assets. This misconception transcends this little article. For example, Game Developer Magazine is a worthwhile publication, but should really be called Game Artist Magazine.
I don't write games though, I've written software for assisting me as a structural engineer. However, my main motivation for writing it is generally to educate myself on some of the underlying theories and techniques. I figure that, computers are rock-stupid. Therefore, if you can explain it to a computer, you must have a pretty good understanding of it yourself. I've got more than a few half-written projects that I stopped as soon as I grasped the underlying concepts I was seeking to understand.
While I've never released any of these projects, I suspect that this may be a similar situation with some of the game designers. I.e., the game is mearly a means to an end. If the true goal of the game is accomplished before the game is finished, there is less motivation to finish the game.
A goal is a dream with a deadline
This really isn't a problem with game developers. It's not even unique to open source. Even with commercial development, a lot of projects are started but never completed. Some never make it off of the developers' systems because business requirements change. Some projects make it into production 'incomplete', with the intention of going back and adding features, but it never happens.
It's not necessarily a bad thing. Some projects begin to test a theory that never pans out. Those projects feed into the next iteration that makes it a little further. And some projects are so ill concieved that they never deserve to see the light of day anyway.
You can look at it as R&D, or as the electronic version of Darwinism.
It is amazing what you can accomplish if you do not care who gets the credit. -- Harry Truman
After a quick glance at the article, I noticed that there was information missing (a feeling I had before I opened the page.)
The reasons within the article are technological reasons about why games fail - pertaining to how the code is designed. It doesn't explain more pratical reasons, such as insufficient experience with programming or mathematics (e.g. you don't yet know how to divide a shape in two efficiently.)
This sort of stuff needs to be written over a period of time - you can't just write a single small article and say that it's done. That's also why there are books on the subject rather than one section in a periodical.
Happy Penguin's Game of the Month is an effort to fix this sort of problem.
Every month (or two, or three..) they choose a game to work on, and generally the end result is a greatly improved game. Currently they're working on TuxKart, if you view the screenshots of some of the improved models, they're amazing.
Anyone who has an incomplete game that they're no longer working on would do well to at least suggest it to the GOTM people, since they have artists and other people willing to do the type of work that coders hate.
After seeing how poorly the "fit and finish" of Champions of Norrath is as well as a few other games I have played, it is apparent that the professional game companies could do with some advice on how to finish a game too.
Test Test Test! That is imperative. Don't use the same testers on the final version. You need to see different actions than the expected ones to ensure the bugs have been found. I play plenty of Beta modules for NWN and you can see who tests their modules and who releases the latest modified code. I can honestly say there are better developers in the NWN community than some of the professional developers.
Specific issues for Champions: There should not be "holes" in the graphic walls a character can fall into and be outside of the defined world. There should not be a 10-30 second delay to a response to an action like your pack being full. Simple and common things like accessing your inventory must be fast. Do not force large automaps when you add more than 2 players.
Other games: If the player moves the camera to a specific position, leave it there. If you have 2 tough areas back to back allow the user to save in between. If you have NPC characters, either move them out of the path of the PC or allow the PC to walk through them. If an activity is not required for general game play, but can help with bonus play, do not force the user to learn it.
You can lose something that is loose, so tighten the loose item so you don't lose it.
If a project is to have a chance of becoming finished, it needs at least one person involved who is rabidly determined that it will get done, no matter what, no matter how long it takes. This person needs to have the will to take back responsibility/control from anyone who's not getting some part of it done, and the ability to either do all those parts of the project themself, or to find someone else who will do them. If you have a person with pit-bull like persistence and determination on a project, it is decently likely to get done. If you don't, it's hard to finish unless you're doing something pretty easy.
Furcadia - A free online game with user created content, DragonSpeak scripting, & more.
Another piece of advice: If you are writing the game just for fun, anyone who offers to contribute to it in anyway is not under any obligation, and may never get round to it. So try and rely on yourself as much as possible.
About two days ago, I shipped Demon after a year of development. It's a mod for Neverwinter Nights, the sequel to Shadowlords and Dreamcatcher. Both are in the Hall of Fame on the Vault and the Dreamcatcher series was Module of the Year. Yadda, yadda, yadda.
The closest I've come to understanding why I keep making these things is a comment made by a writer. They didn't write because they wanted to write, they write because they had it.
I make games because there are these stories inside me that keep wanting to pop out. Characters that demand being brought to life. Making the games can occasionally be fun, but the bugtesting and release is usually grueling and unpleasant.
So, I think I'll keep my day job of code wrangling and tip my hat out of respect to professional game developers. It's a tough job, putting something you've invested so much of yourself out there for the world to poke at.
From 92 to 96 I was working on and off on a 3D driving game. At the time, I was driving a truck and the frustration with the barrage of idiots I constantly had to avoid got me thinking, "Wouldn't it be great if I could just run them off the f*cking road" or worse... (yeah, real healthy, I know)
:(
So my idea was to make this driving game where you had to race across country, but that was just the plot for plot sake. (It was about as much plot as Doom had in the readme.txt)
The race didn't matter. It was just an excuse for the different locales. The actual purpose of the game was to race, rob, carjack and maim everybody and anybody you felt like with your vehicles. I thought most drivers could identify with this on some level and the idea at the time was "out there" and sure to make some controversy.
I was working around anywhere between 1000 ~ 2000 hours a year on this. (Depends which years) Every time it got close, a new game would come out and raise the bar. Like an idiot, I'd start all over because I wanted it to be as good as anything out there. Well, seeing the target for this 3D game was originally a 386DX, later 486DX DOS/32, mostly everything had to be done in assembler. (Actually, in hindsight, I probably could have gotten away with a little less optimization) it took forever for it to go anywhere. Just when I'd get the renderer in order and start adding the other elements of the game, a new game would drop and it didn't look so slick anymore.
Anyway, I took a break for almost a year. I decided to finally just finish it and get it done. Thought it would be easier in some ways now that base targets were lot more powerful. Well shortly into it, as I'm coding, I see on the television a story about Carmegeddon and GTA.
F*CK! I gave up right there, my thunder sapped. The first GTA was alright, but what I was envisioning was a lot closer to what the GTA series has become. It's weird looking back at notebooks with drawings of golf carts and cars dodging planes on the runway. (Though some of it would be dated, like the LA segment during the riots)
I've had a PS2 now for over a year and outside of trying a rental or two, there is only one game I own and play. Vice City. Though it's missing a few elements, (Where's the steam roller?), it's pretty much, for me, the ideal game. (Might change my mind after I play Doom3 though)
I try and take it with a grain of salt when I see how fantastic it panned out for them. Though it's hard not to think, if I hard only gotten that second 90% done, if I had just got it out and didn't keep revisioning it.
Oh well
-William Shatner can be neither created nor destroyed.