Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    298
  • comments
    1135
  • views
    232440

Mini-Article One

Sign in to follow this  
HopeDagger

180 views

Feature Creep, Game 'Size', and ToDo Lists

I had always told myself that I was immune to the dreaded ailment known as 'feature creep'. I've been pretty confident that I've always adhered to the general overall picture of the game rather than went off on tangents to implement things that would make a game jut out at some strange angle. I'm biased because I'm the author of my own works, but so far I think I've evaded this stigma.

For quite some time it has been my belief that games should always try to maintain equal breadth AND depth in its 'features'. What does this mean? Imagine a game as a linear list of components. Any element from "ship selection system" to "hand grenades", whereas each component contains a linear list of subcomponents. You'd end up with something like this (taken from Membrane Massacre's Roadmap file):


  • Visual additions
  • Particle system revamp
  • Alpha and Additive blending routines
  • Convert all particle spawning instances to use blending (if needed)
  • New/better text font
  • Visual indicator of where your ship is when you start/respawn
  • Adding shading to pop particles
  • Explosion system (smoke + explosion 'tracers' (maybe not?))
  • Have explosions knock back player/enemies
  • Screen shake effect upon explosion
    [x] Explosion shrapnel that can get stuck in both the level and membranes
  • Improve missile trails
  • Add yellow 'semi-stalker' cells that rush at player and cut through walls with ease
  • Enemy modifications
    {*} Fix the 'get stuck on some walls' bug when eating fast
  • Throw other enemies aside with ease
  • Eat laser beams (become 'redder' and grow)
  • Devour missiles; 'opening mouth' in its direction and doing bubbles
  • Add blue 'freezer' cells that use freeze bomb and are shooters
  • Immunity to freeze particles
  • Freeze particles make it grow (to double its size!)
  • Create ice roots when eating through terrain
  • Use freeze bomb(s) if: a) near player, and b) counter has expired
    [x] Use freeze bomb if missile in vicinity
  • Use freeze bomb when destroyed



  • Long-winded, but you notice that although there is a tree-like structure evident. Also it's worth noting that the maximum depth of any 'ToDo node' is proportional to the breadth of the parent node. Imagine a game with a Roadmap like this:


    [ ] New enemy AI
    [ ] Goblin Fighter
    [ ] Allow mob to drink 'potions of fire'
    [ ] Allow mob to breath fire for a duration
    [ ] Increase mob's perception for duration
    [ ] Gain special 'fire god' powers
    [ ] Immunity to all fire damage
    [ ] Exception to 'hellfire' spell damage type
    [ ] Gain mob-friendly status on all fire-element mobs
    [ ] Allow mob-to-mob trade with fire-element mobs during status
    [ ] Implement new mob trading window for goblin fighters /w this status
    [ ] Greater Vortex Wurm
    [ ] Give burrowing status boosts when underground
    [ ] Let underground wurms have a chance of creating earthquakes
    [ ] Earthquake system for vortex wurms
    [ ] Have vortexes randomly spawn as wurm burrows across map
    [ ] Make special vortexes destroy all vorpal-element equipment on the player
    [ ] Give special damage bonus to Elf-kin mobs/players


    Here we see that each node has a very large depth compared to a practically tiny breadth. Its effect on the gameplay is almost literal. You'll end up with something that has very deep gameplay, but a tiny scope (or breadth). Given the environment of the game this is describing one might think of roguelikes, but these games tend to have massive enough breadth to cover said depth.

    This is essentially what feature creep is. You start implementing one feature, and then you forget about the rest of the project. Your mind wanders into this single-dimensional reality and you write this feature like its the new focus of the game. The result? Certain game features go incredibly deep and have great detail, but as a whole, the game suffers. You end up with a rather shallow shooter with an extremely detailed character creation system, or an RTS with a killer GUI/menu system and weak gameplay, or an RPG with an astounding combat system but no storyline. One (or several) elements of the game get developed to an amount disproportional to the rest of your game. Balance is very key.

    This is also a wonderful reason why you should keep a Roadmap/ToDo-list for your projects. Lists like the above don't usually get made because their purpose is to keep you aware of the breadth/depth of your game. Most perpetrators of the above don't keep roadmaps, and so its easy to forget about the rest of your game. It's exactly the reason why a tree-like structure is ideal: to keep yourself from taking any one element out of scope. You might want that dynamic menu system like Game X, but it will look more than a little silly if the rest of your game is programmer art.

    It's worth noting that this syndrome is typical of hobbyist and some indie developers more than all else. Commercial games constantly have people watching over 'the big picture' of the project to ensure that it doesn't grow without bound in random directions. Is it a coincidence that these projects have clear design documents and thought-out goals beforehand?

    Do keep a roadmap. Do form a clear and concise vision of what you want your game to be before you touch code-to-IDE. Do avoid feature creep by taking a look at your whole project before coding. And, of course, do remember the scope of your game; don't get carried away! [smile]



    While you're in the mood..

    ..Take a look at Eliwood's interesting look at the flavours of hobbyist game developers. Like anything, there's no such thing as only four shades of gray, but it's scary how easy it is to fit nearly every developer (or dev-wanna-be) into one of these headings with minimal trouble.
    Sign in to follow this  


    4 Comments


    Recommended Comments

    I've realized that all of my projects that 'floated' with no cause or reason to their development had an infirm design from the start. Inevitably, these projects end up with me scrubbing them since I have no cohesive vision for the end product.

    Now, I force myself to set a rigid design and only add extra features if I think it significantly improves the design. At the same time, I dump a lot of features from the rigid design that seem "one-off," such as (for example) space stations you can walk around in. Would that be cool? Yeah. Does it distract from the main thrust of the game? For sure. Does it waste my time to implement it? Yes.

    Share this comment


    Link to comment
    Quote:
    Original post by HopeDagger
    It's worth noting that this syndrome is typical of hobbyist and some indie developers more than all else. Commercial games constantly have people watching over 'the big picture' of the project to ensure that it doesn't grow without bound in random directions. Is it a coincidence that these projects have clear design documents and thought-out goals beforehand?

    From my glimpse behind the closed doors of a commerical developer I'd say they're just as prone to fall to feature creep as everyone else [smile].

    Good reminder though to myself as I chalk down the requirements for my game. Especially that link to Eliwood's blog. I'm certainly not getting enough done, and I don't particularly feel that smart due to aforementioned lack of getting enough done. I've spent a fair chunk of today discussing save game design theory on the design forum, which is stupid. Grr - I'll have to make a special effort to kick myself off the internet tomorrow to stop this slackness!

    Share this comment


    Link to comment
    My god.

    This is one of the most insightful posts I've read in a gamedev journal ever.

    Seriously, to anyone reading this, HopeDagger is SPOT ON with this. All of my failed projects? No clear goalset. All (one) of my successful ones? Very well-defined initial scope (with enough features in it that I could cut things OUT to make it manageable rather than having to add things).

    Only one single feature got added to the game (on-exit save), and it was a last-minute suggestion by someone on the forums that I had honestly not thought of. It was a quick (one hour) feature that added (I think) a substantial amount of playability to the game. If you're going to creep in a feature, that's the kind of feature to do it. Small work item, large impact.

    Never creep in the opposite type (large work item, small impact). That's where you truly start to fall down the rabbit hole.

    Share this comment


    Link to comment
    Huh, I think I need to make a to do list for Angels 22...

    Also: that's a cool article:

    I like to think I'm a 1, but sometimes I do slack off, I have to admit(why draw airplane sprites when you can draw spaceships exploding?)

    Sir Sapo is being increasingly a number 2, however(HEAR THAT SAPO? GET TO WORK)

    Share this comment


    Link to comment

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Advertisement
    ×

    Important Information

    By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

    We are the game development community.

    Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

    Sign me up!