Can I use feature creep to my advantage? [closed]

Question

Can I use feature creep to my advantage?

Every time I prototype a game, features are inadvertently added. This happens either through coincidence, or it happens to be easy to add based on existing content.

If I know the genre of the game, can I just start making the basic mechanics and add features as they become apparent?

For example, if I want to make a 2d platformer over the course of 6 months, can I just start making the running, jumping, shooting, etc. and add the core mechanics as I inadvertently find them? Or is this too risky of a time investment without a predetermined plan?

My logic behind this is that the design will be more bang for the buck. The design choices will more easily be built around what is easy to make (time-wise).

In summary, is there anything wrong with building a game before I design it?

Answer 1

That is an interesting question. Mainly because answering it raises the shades-of-grey versus black-vs-white dilemma.

is there anything wrong with building a game before I design it?

If you think of that question as a yes or no type, the answer can only be: yes, there is. If the answer can be more nuanced, then it changes. Reason: you should never build a game before some designing. But you sure can save parts of the design for later.

It means, I don't think you should see the issue at hand as a do or don't. Rather, it is something that you should think of in terms of degrees. Feature creeping maybe the very second root of all evil in what regards game development (the first, as Donald Knuth has thougth us, is that "premature optimization is the root of all evil"). However, in my experience, not thinking of any of the main features, i.e. not having at least a basic design of where you want to go with your basic mechanics, is not a good idea either.

The first main reason is that it is helpful resource-wise (including time as a resource) to have some planning to guide you trough - because reaching dead-ends all the time due to excessive try-and-error can be just as waste of resources as having to include unforeseen features.

The second main reason, game-design-wise, is coherence. Good game-design has conceptual coherence, or consistency if you want. It means, the overall game-play, the history, the implementation, even the graphics, should fit each other as smoothly as possible. It is very unlikely that a game-design will achieve something like that if main features are just found out on the go. If not for anything else, because on the go has a lot of randomness into it: the things you will step on may have very different impacts depending on when at the development process you did find them.

I don't mean saying that you shouldn't do what you said at all. I am just claiming that you have to find some balance.

For example, if I want to make a 2d platformer over the course of 6 months, can I just start making the running, jumping, shooting, etc. and add the core mechanics as I inadvertently find them? Or is this too risky of a time investment without a predetermined plan?

I would start by introducing a slight modification in your sentence. By making the running, jumping, shooting and etc you are already implementing core mechanics. What you would add on-the-go in your example are the specific game-play features.

It is not because you know the game will be a 2D platform, that running, jumping or shooting can't vary depending on the game design. Can your player run on the walls? Can your player float in the air when jumping? Even, can your player shoot while running? Does your player shoots only in a linear direction or via a parabola? These decisions can be very much game-feature dependent.

But I see your point: these mechanics often have some parts that vary very little. So, if you do some game-design and decide on basic features as much as to be somewhat sure how running, jumping, shooting, etc will work, that's a start. Then you can go for these mechanics and keep building on them.

Of course you can still later find a new feature that requires you to alter these mechanics - no matter how basic they were. But the key here is probability. The probability that this will happen too often will be smaller if you at least did some thinking on the consequences of running, shooting, jumping and etc for the basic ideas you had for the game.

---

Lastly, if you want to go that route, I would suggest the following. Think of it as a iterative process. You do some initial, broad-level design-thinking. You implement what seems basic and more "universal" within your game, for it to succeed. Then you do some more design-thinking, re-evaluate what you implemented and go for some more implementation.

Answer 2

When doing complex projects like games, you often can't make all the features you want, because you're running out of time/money or because they didn't turn out to be as good as you expected. This is known as feature creep. But there's a flip side to this; you will also find features that you didn't think you needed, but as the project takes shape their need becomes apparent.

This is why people build prototypes - so they can learn what works and what doesn't, so they can cut features that don't work, but also so they can find new features that would be awesome. If you're not doing either of those things you're not learning, you're doing it wrong.

This is basically the sentiment expressed in a talk called Advanced Prototyping, by Chris Hecker and Chaim Gingold, which includes many examples from their work on Spore, where they were often surprised by what worked and what didn't, going as far as redesigning whole systems based on prototype feedback.

Another example is the design process for Left 4 Dead; at first the game only had basic zombies, but from playtesting with experienced players, the designers found that the players stuck together effectively and the game was too easy, so they added special zombies to break the team apart and keep the game exciting.

Of course, this doesn't mean you should build your game without any prior design at all. You should make sure that the core of your game is fun before proceeding, because that's often the hardest part of making a game.

Answer 3

I would say yes, go for it. But plan some common features / classes ahead of time to have some cohesion between each new component.

Unity is known for its component approach to game development, and would allow this form of development easily. If you aren't using Unity, you could replicate a semi-component approach. I'm unfamiliar with other game engines.

Unity game objects all have a transform component. This states the position, rotation, and scale of the object. So make a generic 'transform' class to hold these values, plus a reference to the actual game object maybe.

Take a 'Jump' component, for example. Have all the logic work with a game object's transform class to do the manipulating of position. (Or your engine will have a similar built in class already.) You could attach this 'Jump' class to any object, and the class will animate the transform position when an action is triggered (Jump.PerformJump() or whatever). The Jump class doesn't have to know anything about its owner (or, at least, minimal info).

Now you can have fun creating a ton of components, then attaching them to game objects, combining them on one object, etc. For example: Run, Jump, Crouch, MovingTile, FireWeapon (specify the 'bullet' sprite, and behavior to make a generic component), etc.

Make each component as generic as possible to allow for multiple uses / variations. For FireWeapon, you can specify the bullet sprite, speed, damage, etc. You could try to make those attributes normalized, so that speed and damage is specified between 0 and 1. Then scale those to the game's max values. This way you only worry about relative differences between the weapons. Plus this adapts to global settings such as difficulty where a higher difficulty has a higher max damage, etc.

Before you know it, you have an arsenal of components to plug in, and you can now quickly develop for any game type.

Answer 4

Brief: most of the time you cannot have a single design step followed of a single coding step. You will have to alternate them. As a general rule, try to respect what is already designed (not what is already coded).

About not having an initial design (just a sketch or a mental image): if you do not have a design you do not have a design. You must do something to come with one. But as long as you start to build one, try to respect it, do not come with a new one every time.

---

Do experimentation and get random features may or may not be harmful. It may even be beneficial or unavoidable. For example: you know that you want to support jumping (many 3D/2D RPG do not allow to jump). How do you know it? Because you imagined a game map requiring jumping to sort an obstacle? So the jump implementation is good enough as long as it lets the player sort that obstacle or does it have to comply with certain characteristics like maximum reachable altitude, can be it boosted by items or game objects in map, physics must include acceleration or bounce (when Mario jump into an enemy He gains impulse to elevate again and that is very important for the game play)?

If you already can answer those questions then your design documents (imaginary or real) are very complete. If you cannot answer those, then your design is incomplete. In this case, you will have to go again to work in the design or do experimentation to fill the gaps. The opportunities may be very open or very restrictive. If some of your game levels will have obstacles, and you just need the jumping for them then there are a lot of freedom to decide the maximum reachable altitude or the speed, maybe you decide to pretend there are a physics engine begin it all just to improve the visuals of the jump animation but you do not need it for anything else. (In many 2D RPG games you cannot jump when you want, but as long as there is a single tile hole in a map, trying to step into it automatically triggers a jump to the floor tile next to the hole tile)

I understand that It is OK to go to code without a complete design as long as you respect what is already decided. Also It may be unavoidable in some situations as game universes may be built from a variety of different thinking processes. For example a card game: I know I want the cards to have Attack and Defense, a certain numbers of card in the table at a given time and that the player during his/her turn can choose with which card attack which other card. It may look to some as an already complete design, but then it comes the balancing of the game, only possible through many simulations. After many simulations I decide that a card with Attack 10 is overpowered, I can simply delete it from the game but I like it too much so I will do something different, I will create a new rule that says that if a player attack with such a card it cannot attack with other card during that turn. Now I have a new rule that enriches the game mechanics, but apply it to a single card looks weird (like a dirty hack), I realize It looks weird and then I decide to create a new set of cards that have high numbers but the new limiting rule applies to them. Now I have a more complex game mechanic, built above the simpler original one, in my opinion, I turned it to my advantage to make a better game.

Now, one thing about that last example, in the proposed example of the card game, new cards may result in new assets (cost increase, time increase). But I think is a good example of let the opportunities you only see when coding influence your design decisions in a good way.

I don't think most of the games we play were fully designed before coding, I'm sure they had to make difficult decisions to comply with timelines and so.

When somebody else is paying for it all: explain, negotiate.