Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Release often, sure. But early?

By Denor in Culture
Wed Sep 20, 2000 at 04:59:14 PM EST
Tags: Software (all tags)
Software

I'm working on a linux game, both to hone my skills and to impress future employers. It'll be handled in true open source fasion -- OSF-compliant license, a CVS tree, a maintainer (me) accepting patches, the whole deal.

But if you go searching through Sourceforge, you're not likely to find it highly publicized anywhere. You might find the page itself, but very little is on it save a shortened version of this writeup to explain the lack of more compelling content. I'm following the open source mantra pretty much exclusively - except the "release early" part.


So why? It's a question I'd been asking myself for a while. I started the game to scratch my own itch - free in-depth gaming for linux - and had pretty much decided on the open source method. My preferred operating system is, after all, Linux. Shareware seemed more likely to be popular in the windows world, and I had done enough Windows programming to have it turn me off for a while. So Free software it was.

But why no code release? I needed to think about this for a while before coming to a conclusion, but I finally managed to formulate some reasons I feel are compelling enough to do things the way I'm doing them:

  • The Design: I know how I want my game to end up. Every bit of it is either in my head or (more likely) on paper. It details every bit of how the game should work. I've never seen a professional game company's design documents, and this is likely not up to such standards, but it's the equivalent for my game. I'm past design now, and into coding, but am very early in the process. If another person were to join the process at this point, they most likely would submit code that doesn't conform to the design - or even if it does, it could be missing subtleties that I had in my head. The lack of design documentation in electronic format compounds this problem as well.
  • The Team: I've been reading usenet ever since I found out what the 'tin' command was. I used to be an enthusiast of a group creating role-playing games using a specialized engine. I used to read posts on all sorts of game developer message boards. One thing all these had in common were the team announcements. One person would post, saying they had a killer idea for a game, and ask others to follow. Sometimes an already-formed group would post, announcing their game in the making. In many cases, however, nothing was heard from these people. The group would break up, and nothing would be made. After seeing this happen countless times, I've become a bit superstitious about it. I'd rather work on the code knowing that, if it fails, I am the only person who is disappointed. Not an entire team of people, nor the public.
  • The Finished Product: Being an avid Linux games fan, I follow the postings on linuxgames.com and The Linux Game Tome for interesting developments. I mostly focus on the amateur games released by individuals or small teams, as that's the demographic which I will one day be a part of. Most of the games I see released there are in early form - 0.1 or so. They get improved, certainly, but they're not finished by a long shot, nor will they be for some time. This is always vaguely disappointing to me -- I like a finished product. In keeping with this, I'd like to release a finished product, or at the very least, a playable product.

I do plan to open up completely once 1.0 is out. The design issue is taken care of - as the entire program would be complete, the design will be readily apparent. The team is also not a problem - if I have a team, and it later breaks up or fails to get together in the first place, there's still a game, and source code to boot. And since 1.0 will be fully playable, there will be a finished product.

I've managed to convince myself with these items, but I do have some reservations. A part of me still demands "You play nice with the other developers, hear? Share that code!" And I've found myself thinking of reasons to do it, as well:

  • The Design: As much as I like my design and think I have it all figured out, I'm not inexperienced enough to believe that there aren't any flaws. Chances are good that anyone perusing the design documents could point out things which are obvious, but I'm not seeing because I'm too close to the code.
  • The Bugs: When this hits initial 1.0 release, I forsee quite a bit of bug-fix released afterward. I've never attempted to widely distribute a program before - perhaps my game makes assumptions that it shouldn't, and will break on others' machines for reasons fundamental to the way the game was made. Other folks could certainly help catch this before it was too late.
  • Can I let go? This is the most important question, at least for me. I've followed usenet, mailing lists, and even occasional kernel-traffic discussions, and I always swore that I'd never be like those developers who couldn't tolerate one bad word about their creations. I'd be better - I'd listen to criticism, try to make the game more than it was originally. I'd take a fork in stride, not demanding that all who would partake of my game's code follow my will as to how they should modify it. Now, I'm not so certain. I seem to already be a bit posessive as it is - if I can't handle giving away the code now, when will I be able to give it away? "When it's done" is a tempting answer, but I could just keep adding features and never releasing it if that were the case. Taking on someone else could help solve this early on.

So there's room for doubt in this belief. I'm doing what I feel like I should be doing, and I think I have good reasons, but I'm not sure. That's why this article is here: Is releasing often enough? Or must I also release early, to gain the full benefits of the system I'm using?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o linuxgames .com
o The Linux Game Tome
o Also by Denor


Display: Sort:
Release often, sure. But early? | 24 comments (23 topical, 1 editorial, 0 hidden)
Design notation? (2.85 / 7) (#1)
by maketo on Wed Sep 20, 2000 at 03:56:15 PM EST

Just curious, what design notation are you using? UML? If you decide on something standardized, you can hope that people will be able to hook-up to your project fast... As for the question on whether your design is good enough, it will show soon enough in the implementation phase ;).

I personally like to do a good job and that implies patience. Do not be mislead by fame and fortune of others, patience is a virtue. Delay the release until you know you have released a solid product. It will speak of you in the future. Good luck.
agents, bugs, nanites....see the connection?
When is early too early? (3.33 / 6) (#2)
by GrayMouser on Wed Sep 20, 2000 at 04:01:10 PM EST

I'm also designing a game in my spare time, and have considered the issue of when to release it as a beta (the engine will be proprietary, client free but some of the same principles are at work).

I've come to the conclusion that I won't release anything till the code is coherent enough to be recognized as _my_ game: design, structure, etc... Before that, I'd just be showing some classes and features, but not a game.

If you're going to go open source, a compromise might be to wait till you've got a solid beta version. The framework should be all mapped out and documented, and most of the features laid in (even if only in empty methods to describe how they will work at a future time). This way, anyone who comes in and wants to add can see the direction you're heading and get a fairly good grasp of the reasoning behind the design.

Likewise for subsequent releases. Wait until you've got the next set of features fairly well mapped out before you release, then others can help fill in the gaps without tearing it in all different directions.

seperate engine from logic (3.28 / 7) (#3)
by madams on Wed Sep 20, 2000 at 04:02:45 PM EST

If you've seperated the game engine from the game logic, it may be possible to distribute just your game engine. This would let other interested people hack/use your engine without getting involved with your game design. Maybe they would just play around with your engine, or maybe they'd use it to make their own game. If you have a copyleft license then you would (almost) guarantee that you'd get back changes to your code, which you could then incorporate into your game.

--
Mark Adams
"But pay no attention to anonymous charges, for they are a bad precedent and are not worthy of our age." - Trajan's reply to Pliny the Younger, 112 A.D.

Re: seperate engine from logic from content (3.40 / 5) (#6)
by sugarman on Wed Sep 20, 2000 at 04:22:17 PM EST

I was thinking along the same lines as yourself., but more in the terms of actual game content. By content I'm meaning art, models, level design, items, etc. (I'm not sure if this is how you are defining 'game logic').

The 'release early' paradign is to allow for bugs to be caught quick enough to be fixed before a drastic rewrite is necessary, or before future additions are built upon the old, flawed code. By separating the content from the rest, you can still gain the benefits of open source, and still maintain control of you 'vision'.

As a bonus , you will likely get 2 unique products out of the project:

  • The engine, which can be opensource freeware
  • Your game, using the engine, which could be freeware, shareware, etc using whatever terms you see fit.

    So release what you have in beta, with perhaps a 'sample level', or the bare minimum to actually make it look like a world (placeholder art, and sound, whatever), and maanage that as an OSS project. When you are happy with it, call it 1.0, and release your content using the 'foo' engine.

    Good luck!
    --sugarman--
    [ Parent ]

  • Re: seperate engine from logic from content (2.25 / 4) (#8)
    by madams on Wed Sep 20, 2000 at 04:52:13 PM EST

    By content I'm meaning art, models, level design, items, etc. (I'm not sure if this is how you are defining 'game logic').

    By game logic I mean the art, models, interface, control structure, plot structure (i.e., everthing that makes it a game). The engine would include rendering, drawing, frameworks, etc (i.e. the generic and reusable parts of the game code).

    Or maybe I was talking about games that don't have any art, models, or levels. Just the engine and some logic to make it run. What kind of game would that be?

    --
    Mark Adams
    "But pay no attention to anonymous charges, for they are a bad precedent and are not worthy of our age." - Trajan's reply to Pliny the Younger, 112 A.D.
    [ Parent ]

    Re: seperate engine from logic from content (2.00 / 2) (#15)
    by fluffy grue on Wed Sep 20, 2000 at 06:04:19 PM EST

    See anything on the Atari 2600. :)
    --
    "Is not a quine" is not a quine.
    I have a master's degree in science!

    [ Hug Your Trikuare ]
    [ Parent ]

    Minor problems with your ideas. (3.71 / 7) (#4)
    by bmetzler on Wed Sep 20, 2000 at 04:16:27 PM EST

    You say "a maintainer (me) accepting patches,". But yet the whole point of the your tirade is that you aren't accepting code. :)

    You want to write a game. But yet you want to write a game in the spirit of Open Source. I don't have a problem writing a game all by myself because it's a little project of mine and then releasing afterwards. It's really no big deal because it's not that important.

    The reason it's important for commercial open-source projects to release early is because of something SGI learned. They apparently wrote this open source product and then dumped it into the community. Then all the developers were like, "Huh, what, what's this do?". SGI siad that should they do it again, they'd develop it with the code available the whole time. Because then, when it's done, interested programmers have seen the code from the ground up and learned what it does. It's a lot easy to understand the code when you've worked with it right from the beginning, rather then getting a 100k lines of code tossed at you. Programmers, especially me, will be more willing to join a project if the hurdle is small.

    I guess I'd write it alone, if that was what I'd do. No one *says* you have to show your code right away. Enjoy yourself, have fun. Then when you want, post the code.

    If you do make it available for others to join you right away I'd make sure real-time communication was available. Whether it is IRC, or AIM, or whatnot, make the developers all use it. I find it helps a lot to be productive as a team.

    -Brent
    www.bmetzler.org - it's not just a personal weblog, it's so much more.
    you make a good point (1.40 / 5) (#7)
    by ketan on Wed Sep 20, 2000 at 04:49:20 PM EST

    It's important to give people something real with which to start. If you don't, then nothing will happen; a project can't crystallize around nothing. Just like a bunch of recent k5 postings.

    I've wrestled with this, too. (3.25 / 4) (#9)
    by galen on Wed Sep 20, 2000 at 05:06:29 PM EST

    One of the most difficult things about writing a game is game design. It is almost impossible to get it right without having feedback from other game designers. I am in the process of building an opensource game too, but I completely redesigned the game several times before starting to code, then threw the code out and started over again.

    I am lucky to have another good game designer to bounce ideas around with, even though I reject 95% of his suggestions, and remodel the ones I do like into something almost unrecognizable.

    I am also under no illusions about what will happen when the game does get released. If anyone at all likes my game, I will probably receive suggestions that will ruin the flavor of the game, or grossly unbalance it. I'm convinced that to make a really good game, one experienced person should have absolute veto power about design decisions.

    As for practical suggestions, leave plenty of room for ways in which the game can be improved without destroying your creative vision. My game will make it easy for players to suggest new artifact types, maps, and AI strategies. Release the game when it is playable and it shows enough of your design so that new contributors can follow your lead. Suggest to them areas of the game which are weak, and need improvement. Require a design reveiw before patches are accepted.

    If you make the game truly open source, and enough players don't like the direction you are taking the game, it may fork, but that can sometimes be a good thing. Also, don't make the initial release version 1.0 if you expect any near-term bugfixes.
    Time flies like an arrow. Time arrows with a stopwatch.

    Best of both worlds (2.50 / 6) (#10)
    by squirrel on Wed Sep 20, 2000 at 05:10:32 PM EST

    I suggest you write up your documents and share those with the outside world. That way you can get comments on your concept and design without having to give out your code or accept code from other people.

    Here are the docs I'd like to see:

    1. Feasability. What will make this game special or cool?
    2. Requirements. How should it work? What features will it have?
    3. Design. How is the underlying code designed to make 1 and 2 happen?

    Can you tell I just graduated with a CS degree? ;)

    Good luck!

    Re: Best of both worlds (1.00 / 3) (#17)
    by feebdaed on Wed Sep 20, 2000 at 06:10:39 PM EST

    Last time I checked CS at NCSU still stood for Crop Science!

    Did you change majors again?

    [ Parent ]
    Learn from Mozilla (4.25 / 4) (#11)
    by Stargazer on Wed Sep 20, 2000 at 05:13:18 PM EST

    Personally, I would advocate releases as soon as they're even slightly beneficial.

    However, if you're not willing to do that, I would advise you to at least take a lesson from the Mozilla project, and give a release with substantial time before your final release. The single-biggest problem that the Mozilla project (and others) have faced is the steep learning curve for the code -- when you go from having nothing to having everything, it's tough to make a transition. (This is not the fault of the Mozilla developers, mind you, and I appreciate their efforts all the more for them having to deal with this.) Hence, fewer people use your project, you get less feedback, so on and so forth.

    It's hard to think of code as something you can't own. However, it really isn't, and hence, you need to try to keep in mind that whatever happens to it upon release is best for all parties involved. If others change the code to make differences that you don't want, you don't have to take them -- there's nothing to stop you from sticking to the old codebase. Likewise, there's no reason to force them to adapt your entire game engine just because you don't want a certain feature in mind. The community has a vested interest here -- the dearth of game code has hurt our ability to reach some users. Please keep that fact in mind when you consider what would be best.

    -- Brett



    Depends on what you're writing... (3.57 / 7) (#12)
    by robgrant on Wed Sep 20, 2000 at 05:23:52 PM EST

    You should consider the differences between writing a game and writing an application. With games, everyone generally wants something different from everyone else, or they want more than what is reasonable. Games should follow the vision of their designers, not the vision of their fans. Otherwise, they'll end up a mess of ideas.

    Applications, on the other hand, are more appropriate for the "release early, release often" philosophy. Developers who write programs for practical use, rather than entertainment, are able to concentrate on adding and improving features that they find useful, which may in turn be useful to other users. Personal preference is not a distraction as with games.
    "You can't get that stuff in Holland" --Mike Portnoy
    "Release Early" doesn't mean "relea (4.12 / 8) (#13)
    by bkosse on Wed Sep 20, 2000 at 05:33:12 PM EST

    When ESR said "Release early, release often" he didn't mean release something that doesn't work. At least, I hope he didn't mean that, and judging from his examples, I'm fairly confident he meant: release something that works early in the process, and keep public releases up to date with the core code. As in, CVS is cool, and using it is good, but make point releases often. The theory behind a point release is that it will likely compile and work while any given CVS checkout isn't even reasonably guaranteed that.

    That said, Game Design And Architecture by Andrew Rollings and Dave Morris is an excellent book. It describes why design is critical. Unfortunately, it's really geared towards a full team doing the work, and with one person doing research, design, and programming (not to mention graphics/sound/music), a lot of what they talk about is only partially applicable.
    -- Ben Kosse

    That is exactly what he meant. (3.66 / 6) (#16)
    by Carnage4Life on Wed Sep 20, 2000 at 06:10:31 PM EST

    When ESR said "Release early, release often" he didn't mean release something that doesn't work. At least, I hope he didn't mean that, and judging from his examples, I'm fairly confident he meant: release something that works early in the process,

    Here's an excerpt from the 9th section of the Cathedral and the Bazaar that clarifies ESR's opinions on "Release Early, and Release Often" with regards to the initial release:

      It's fairly clear that one cannot code from the ground up in bazaar style . One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode. Linus didn't try it. I didn't either. Your nascent developer community needs to have something runnable and testable to play with.

      When you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the foreseeable future.


    [ Parent ]
    Ah, that's where I heard that. (1.66 / 3) (#20)
    by bkosse on Wed Sep 20, 2000 at 08:49:21 PM EST

    I knew that what I said sounded really familiar. I guess ESR beat me to saying what he said.
    -- Ben Kosse
    [ Parent ]
    Just because people send you patches.... (3.16 / 6) (#14)
    by GrimJack on Wed Sep 20, 2000 at 05:36:23 PM EST

    You seem worried about someone coming along and forcing patches on you...

    I had a brief period where I played around with an opensource 3d game engine, and if there was one thing about it that I could change it would have been to have the person in charge of accepting patches being a little more free to return patches that weren't quite ready for prime time, the mantra of "Isn't opensource great because look at all the code we have" was often bantered around and eventually I gave up on the project because before it was even at a 1.0 release it was quite bloated. I'm not sure if they ever changed this behavior since as I really stopped keeping track of the project.

    I guess my point is that just because someone sends you a patch doesn't mean you have to include it. If you don't think it fits in return it to them with an explanation, if they disagree they can always fork off the code and try to prove you wrong.

    IMHO having someone who can decide what doesn't go in tends to separate sucessful projects from ones that go nowhere.

    I wonder how common this problem is? (4.50 / 4) (#18)
    by Deven on Wed Sep 20, 2000 at 06:11:53 PM EST

    I've been struggling with similar issues. I've got a conferencing system (fairly different from IRC, but similar idea) which I started writing in 1992. I've spent far more of the time since then not working on it than I've spent working on it. Nevertheless, it's about 10,000 lines of C++ code at this point, and it does some clever things.

    I originally wrote the system as a simplistic tool to chat in real time with several family members, avoiding long-distance costs. It evolved over time to a halfway capable imitation of an older conferencing system I used years earlier at RPI. It's not quite as sophisticated yet as the experienced users of RPI's conferencing systems expect, and the interface seems arcane to many who are unfamiliar with those systems. Accordingly, there are only a small handful of regular users.

    Currently, the source code is unreleased. I've often considered releasing it as free software (i.e. Open Source), but never quite felt ready to do it for a variety of reasons:

    • The project never felt close to "done", and I've been reluctant to release it while I have a mile-long TODO list.
    • I'd like to be able to use the code as an example of the kind of work I'm capable of, but there are some serious defects in the design and coding that I'd want to fix before it can be the caliber of example I want.
    • Between things I want to fix and things I want to add, there are some major architectural changes likely. Involving other developers makes this more difficult.
    • At the same time, releasing the source usually suggests accepting patches from others, which would dilute the code; right now it's 100% my own code; diluted code wouldn't serve as well as an example.
    • I never seem to find enough time to work on the project, and maintaining a full Open Source project with all the ancillary bits (website, CVS server, mailing list, etc.) takes time.
    • I'm concerned about trying to build and maintain a userbase. It's harder to find motivation to add features and fix bugs when few people will ever benefit from it. Releasing the code would enable someone else to "steal" users with my own code, especially if I don't find time to compete with any potential forked codebase.
    • I've wondered if there's any potential to make money from the code, that might not be possible if the source is freely available. I still wonder about this, but I'm not convinced it's worth pursuing. I'd rather find a way to make money on it as an Open Source project, if possible. Meanwhile, I do have a day job.
    • And, of course, I simply haven't gotten a Round Tuit (tm).
    After recent reflection, I've concluded that my best course of action would probably be to release the code as Open Source, but not under the GPL at this time. I don't want to encourage a code fork, and I want to be able to maintain a pristine version of the code for now; I don't know that I'm ready yet to incorporate outside code and start the dilution process. I could maintain a patch pool of outside patches and possibly my own code fork, my code vs. the patched version. The QPL seems like the most appropriate license at the moment; I'd consider switching to the GPL at a later time.

    Even so, I need to find some time to audit the code for things I really don't want to be seen, and to clean up some of the ugliest kludges, and to get the infrastructure setup, etc. I don't know when I'll find the time, but that's basically my current thinking.

    Anyone have any thoughts or suggestions for me?

    Deven

    Deven

    "Simple things should be simple, and complex things should be possible." - Alan Kay

    TODO lists (2.33 / 3) (#19)
    by Erf on Wed Sep 20, 2000 at 08:26:01 PM EST

    One (possible) result of opening the source is that, if any of the items on that TODO list happen to be someone else's itch, they'll get scratched off in a matter of days. In theory, anyway.

    -Erf.
    ...doin' the things a particle can...
    [ Parent ]

    Re: TODO lists (3.00 / 1) (#24)
    by Deven on Fri Sep 22, 2000 at 03:01:40 PM EST

    One (possible) result of opening the source is that, if any of the items on that TODO list happen to be someone else's itch, they'll get scratched off in a matter of days. In theory, anyway.

    True enough. But that still has some potential disadvantages. They will implement it their way, not mine. Their way isn't any less valid than mine, but it does present the prospect of a fragmentation of the "vision" of the project. And, of course, it dilutes the portion of the project which is my own code. While that's not necessarily a bad thing in the long term, I'm not sure the time is right, yet.

    That being said, I think it would be good for the source to be available sooner than later, to avoid the learning-curve problem Mozilla has dealt with. After all, even if I were to refuse to accept any patches at all, others could still be familiar with the code as it evolves. (I'm not saying I will refuse patches; I haven't decided how to handle them yet. If there's worthwhile patches I don't incorporate into the code, I'll try to make them available, and I might maintain two code branches myself...)

    Deven

    "Simple things should be simple, and complex things should be possible." - Alan Kay
    [ Parent ]

    This problem is very common... (3.20 / 5) (#21)
    by Luis González on Wed Sep 20, 2000 at 09:39:39 PM EST

    A long time ago, I were planning about developing a fighting game, just for proving that I could do that. It happened in 1994, the game was entirely programmed in Basic, and sucked, and I though that distributing it would be a great shame. This year, however, after buying my first own PC (a very cheap Pentium with B/W monitor), I decided to resurrect that game.

    Planning was not so hard, because I already had the idea. Coding it was not so hard either, because I'm good in C programming. But I still were worried about when to release. I decided to give away a 0.1 version, playable but with minimal features (i.e. plain fixed quick and dirty formats for data, a primitive player editor, no special techniques...), and then build upon that, adding new features and fixing the bugs people are reporting.

    The advantage of this approach is that you have a working first version that has the crucial and distinctive features that belongs to your idea of the game. Then it's easy to add news features and release often.

    The disadvantage is that building it can take a lot of time, but not so much as completing a 1.0 (finished) version. A finished version is meant to be finished, with all major bugs fixed, a goal that is very difficult to achieve without extensive testing and major feedback.

    I suggest you to first build the most important features of your game and release a playable version. Then you can add everything that is missing. And you can get a lot of feedback if users can play an early version and catch bugs in it.

    BTW, if you're interested, the game is Chuchunco City (Mirror in the U.S. is here)... :-)
    -----
    Luis
    LGM.cl

    A general reply (3.66 / 3) (#22)
    by Denor on Thu Sep 21, 2000 at 02:49:06 PM EST

    Thanks for all the input - and to think, the whole time I was writing it up, I was worried that nobody would be interested in the article. I'm glad I got to create a lot of discussion, and it's good to know that others are in the same boat I'm in.

    Most the comments here reinforced my gut feeling - hold onto the code until it's playable, then release to the world, accept patches from others if the patches compliment the game, etc. I have been worried about forking, but since there aren't any real issues that I think would create a fork (I'm open to a lot of features for my game) it shouldn't be a problem.

    The program's data driven - it's mostly an engine with some built-in behavior, and then a big datafile that tells it how the universe is structured. I did this to get people interested in the program itself: Creating plugins for the game is trivial, considering that I'll release a plugin tutorial, the format for creating them is human-readable, and the main datafiles and save game files are in the same format as the plugins. Once people are familiar with the way the datafile operates, they'll be familiar with the way my program operates by extention (since all the program does is perform actions on the objects specified in the datafile). It'd be an easy way to get people interested, and those who can't code C++ (like me :) can still contribute by making plugins or alternate universes for the game. I'm hoping that'll cut down on the steep learning curve involved in contributing to most projects.

    As for the design documents themselves, they likely won't go up on the web unless I make a distinct effort to do so - nothing except for the API docs (I love kdoc) is on the computer. Everything else is (mostly) on paper in a three-ring binder in my backpack, or in my head. Though I think it would be an excellent debugging excercise for me to go through everything and type it up... and I did just download dia... and my stuff's already in UML... Hmmmm.... **thinks about it**

    At any rate, when it's finished, I'll post an MLP for it, or maybe get someone to review it, so everyone here can laugh at my coding^W^W^W^Wsee how it all turned out :) I'll likely announce it to the public as version 0.9. Just bugfixes at first, and then a development version if there's interest in more features.

    Thanks for the input, all. This is one of the reasons I love K5 - anyone with a problem or different outlook can post a story, and everyone can decide whether they want to see it. Thank you for choosing mine.


    -Denor


    (4.33 / 3) (#23)
    by kraz on Thu Sep 21, 2000 at 05:11:38 PM EST

    The main problem I see with open-source games is the over-emphasis of the design doc. The design doc only captures a static vision of the game, while the code captures the dynamic essence. A design doc should be a guide not a dicator.

    However, design doc acts as an important reference point for particular projects. I think a design doc is more important in say an RPG than it is for a shoot'em up. But the design doc in either genre provides a reference vision for the developers. The trick is getting everyone to agree on the same vision. In a comericial setting this isn't a problem since there is both a game designer and art producer who will maintain the vision, but in an open-source project these roles don't have authority they would in a commerical setting, unless the team already recognizes the person's authority.

    I think if you are the principle developer or developers then it will be part of your tasks to maintain the integrity of your vision and make sure it doesn't get to polluted by others suggestions. For instance Rogue-like game follow this model. People make suggestions but not every suggestion is accepted by the dev team. For those people who really want to see their own vision they simply take the existing code base and modify it until it matches their own vision of what the game should be. For instance look at how many variants of Moria/Angband there are. Angband is a Tolkein based game yet now there are Angband games based on the Cuthulu Mythos, etc..

    Whether or not you have a design doc you will be re-writing your game engine and logic at least once or twice. Your initial design doc will only capture your initial vision of the game. While expereince will help you come up with a design doc that comes close to the finished game, there will still be stuff that you will not have considered.

    I've seen too many ``open-source'' games that start with these grand design docs and then disappear into oblivion. I think for most simple games it is best to have some kind of overall concept of your game. First start by seperating your game into chunks -- get a general idea of the how the game should flow. Then worry about filling in the details. As you go about filling in the details you will find yourself re-thinking the logic of the game. Now here comes the killer: features. You might find yourself adding features up the wazzoo, you must resist this temptation and know when to stop. Otherwise you will always be working on the design doc and not the real game.

    While I have not participated in a truely-open-source project I have contributed an open-source game to the community: See XInvaders 3d. The principle benefits I got from releasing my code was peer-review and testing. Code Peer-review helped me flesh out some bad design descisions, make the game more portable, and clean up my code. Testing helped me hunt down bugs which weren't occuring on my machine.

    The one problem I did have was with patches. It was difficult to turn down some peoples patches. Simply because I felt they would change the game too much. Others were not accepted because I felt they would violate some design goals I had when I originally started the project. That said. I think there should be a place for patches which aren't included in the game. That is keep the patches in a unofficial directory. For instance, certain patches which let you cheat, are similar to the GameShark on consoles--not officially sancationed but allowed. That way people could still contribute without polluting the code-base.

    However, patches are good too because they allowed me to fixed bugs very quickly that were reported to me (and fixed).

    Anyhow, this post is getting way to long and I must get back to the real world. bye bye and good luck...

    Release often, sure. But early? | 24 comments (23 topical, 1 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!