The Complexity Barrier

Discussion in 'Game Development (Technical)' started by Dan MacDonald, Sep 15, 2006.

  1. Dan MacDonald

    Moderator Original Member Indie Author

    Joined:
    Jul 26, 2004
    Messages:
    1,424
    Likes Received:
    0
    I posted this on my blog over on GG and it got some good feedback so I thought it would repost it here for those who might be interested.

    http://www.garagegames.com/blogs/15718/11205

    Here's a quote from the entry...

     
  2. bantamcitygames

    Administrator Original Member Indie Author Greenlit

    Joined:
    Jul 27, 2004
    Messages:
    1,737
    Likes Received:
    79
    Good article Dan. This is the whole reason I am no longer using my own engine code. Everytime I wanted to do something "different" in my game, I spent hours and hours adding it into my engine first... only to decide it wasn't a change that I wanted to keep anyway for gameplay reasons.
     
  3. Nexic

    Indie Author

    Joined:
    Nov 5, 2004
    Messages:
    2,437
    Likes Received:
    0
    Good article. The complexity barrier is one of the reasons I'm considering a move to flash :-\
     
  4. ggambett

    Moderator Original Member Indie Author

    Joined:
    Jul 26, 2004
    Messages:
    1,982
    Likes Received:
    6
    This is true, but the increase is small or manageable if you have a solid technical design to begin with. Your article seems to apply more to the hobbyist developer where little is planned beforehand and a clear path from start to end isn't visible from the beginning.
     
  5. Musenik

    Original Member

    Joined:
    Dec 5, 2004
    Messages:
    796
    Likes Received:
    0
    I agree with Gabriel. The code for my product has been growing for the last 12 months, and it feels incredibly managable. I have to hold myself back from adding new features, because I'm trying to stick to a deadline. I've been using the same GUI for the last seven years. It's incredibly tight and flexible. Now that it's in Python I feel semi-ominpotent.

    For example, I just replaced an entire mini-game in three days (coded and tested), while dealing with a bit of a cold. (for ten miles, in driving snow, uphill both-ways...) The work included touching the script compiler, one line, and a couple lines in two other modules. I added one new button type, and then wrote an entire module.

    Having said that, I also agree with your three tenants. They are very much in line with what Amanda has said about game designers and high-level tools. Although, I do feel a solid understanding of computer science is incredibly useful to design computer games.
     
  6. Dan MacDonald

    Moderator Original Member Indie Author

    Joined:
    Jul 26, 2004
    Messages:
    1,424
    Likes Received:
    0
    I think this is true from one perspective, but false from another. It is true, good technology and planning push out the complexity barrier and enable you to manage a lot more features and complexity then you could before. It's simmilar to the change the industry experienced moving to object oriented programming. All of a sudden the size of project a team of developers could deliver increased dramatically. Good planning and good tech help hide complexity and keep integration costs at a minimum.

    Also, certain games do not even have the capacity to hit the complexity barrier. You could create a game like bejeweled and hard code everything, poor encapsulation, constants in the code and still do just fine and ship the game.

    A project with a similar scope and complexity as bejeweled can largely be planned out before hand. One can start with the initial concept, do functional decomposition and break down the entire design and implementation and write a complete spec if they wanted. When you have this level of familiarity with a problem you can write really robust technology around it.

    However there is a whole class of games, especially if you are trying to do something different where you really can't know the end from the beginning. There's a lot of experimentation to identify the core set of features and functionality that will become the final game. It's harder to plan ahead for everything and as a result you can run into unintended complexity.

    A lot of lessons are learned in hindsight as well. An experienced developer will know that it's not simple enough to just have a good CAnimation class, and CSprite class in their engine, they know they will also need to have a way to build animations and add them to entities if they ever want to have any hope of adding different types of enemies or characters to their game. A person can only get so far hard coding animations in initialization methods, before it becomes too much of a hassle to add content.

    You are correct in your observation however, that this post is not really for experienced developers who have already found ways to deal with this problem. But to help educate developers who have hit this point without knowing or understanding why. There is also a strong insinuation that if you do not already have a lot of technology you've written, content creation, editors etc. Then you should really try and leverage something that's out there in order to focus on the task of making games and increasing your chances for success.
     
  7. Applewood

    Moderator Original Member Indie Author

    Joined:
    Jul 29, 2004
    Messages:
    3,859
    Likes Received:
    2
    I sort of agree with both of you.

    Dan's post makes sense to me on a logical level, but in practice I've never seen this to happen and then agree with Grabriel.

    Properly written code in a nice encapsulated style should shield the entire app from core changes. If it's working right, you should only need change the stuff a new widget affects. If it isn't working right, get bttdb before your code falls apart.

    I do think the complexity barrier, as you call it, is a real phenomenon. But, I don't think it's a hard limit (per person) on what level of feature-richness a game should be able to achieve. I think it's more a case of it being a trap to be avoided. It *can* be avoided indefinitely imo, but perhaps only if you know it's always lurking in the wings and ready to trip you.
     
  8. Dan MacDonald

    Moderator Original Member Indie Author

    Joined:
    Jul 26, 2004
    Messages:
    1,424
    Likes Received:
    0
    You are correct; it's not a hard limit. What makes it a limit is actually the affect of decreasing productivity that comes as a result of increasing complexity. If the more you work, the less you accomplish it's very easy to get downtrodden, depressed, and unmotivated and it is these factors that eventually kill the project not the actual complexity.

    The complexity barrier can be overcome if you understand it and can rationalize why adding making a small change may take 45 min, instead of the 30 seconds it would have taken at the beginning of the project. A clear understanding of the problem equips you to overcome it as opposed to fall victim to it.
     
  9. Anthony Flack

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    2,176
    Likes Received:
    0
    I certainly have run into a lot of escalating-complexity problems that could have been avoided if I'd been more experienced when I put my basic structure together. In the end, instead of worrying over-much about making sure that everything interacted properly with every other thing, I decided to just wait and see what features would actually be used together in the finished game, and fix any irregularities as necesary. So I'm not going to bother making sure that robots behave properly on conveyor belts, until I know that they will actually appear in a level together.
     
  10. Davaris

    Original Member

    Joined:
    Sep 29, 2004
    Messages:
    767
    Likes Received:
    0
    I've never really noticed the taking more time to add things problem as the project gets bigger. I guess I have C++ to thank for that.

    The thing that causes me the most trouble is if I change one thing in my engine, it breaks something somewhere else that I don't find out about until much later. It only seems to occur in the code for my game's rules. Oh well... :)
     
  11. Musenik

    Original Member

    Joined:
    Dec 5, 2004
    Messages:
    796
    Likes Received:
    0
    Good engineering has little to do with choice of programming language. Good programmers can write clean, well engineered assembly language, if they put in the effort.

    C - grade languages, like C++ help save that kind of effort. B - grade languages like Python save even more effort. I'm hoping someday to find an A - grade language. It's possible they will be specific to a task, like RPG maker, but I digress.

    If your engine is breaking outside of the module that is changed, then you have too many inter-module/object dependencies and/or side effects.
     
  12. Davaris

    Original Member

    Joined:
    Sep 29, 2004
    Messages:
    767
    Likes Received:
    0
    Yes the rules section of my code is very messy. My only excuse is they are RPG rules. :)
     
  13. Musenik

    Original Member

    Joined:
    Dec 5, 2004
    Messages:
    796
    Likes Received:
    0
    If it's worth your consideration, make your rule set scriptable. That's a nice way to encapsulate incongruous functionality which will require a lot of tweaking.
     
  14. Davaris

    Original Member

    Joined:
    Sep 29, 2004
    Messages:
    767
    Likes Received:
    0
    It isn't worth the trouble. My game has always been a poor seller. And I can safely say that my next game won't be an RPG. I'm over them. :)
     
  15. stiill

    Original Member

    Joined:
    Feb 13, 2006
    Messages:
    108
    Likes Received:
    0
    Great post-- stirring up a lot of interesting discussion!

    Another way of looking at the problem is people trying to turn prototype engines into production engines. At some point in development, you really shouldn't be adding features that require changes to very much code. If you're still working with that engine you cranked out in a few days early on in the project, though, that's unavoidable.

    If you're writing a new game with a lot of custom-coded systems, there is a very high chance that you'll need to rewrite some or all of the core. The more complex your game is, the more the adage "plan to throw one away" becomes applicable. It is possible to avoid that with meticulous architecture planning and up-front design, but in some cases it's just easier to crank out that prototype-- a running copy of your game is a pretty great spec.
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer