Feature Development, Scope & Destruction

Syntax

Programmer
what is this?

So I see a lot of projects fail or go miserably wrong because not enough attention was paid during the planning stages to really nail down a plan of action surrounding the features and functionality of the project. This is a guide to help remedy those problems, and can really be applied anytime during the project however the sooner the better in most cases. This is not strictly a programming/development guide either, you can apply the concepts elsewhere but for the purpose of not being super vague I'm orienting this guide to feature development. Also forgive me if you are not familiar with Pokemon, I use a lot of Pokemon related examples to illustrate the concepts I cover. 

minimum viable product

So it's really tempting when starting a project to sit and brainstorm and daydream for hours about all of the fantastic features your project will have and all the people who love it. I do it too, and while there's nothing wrong with that when you get down to seriously planning a project you intend to see through it's just impossible to start there. Write your ideas down, make a list of all the features of your dream and then toss that document aside for later. Pick one feature. Now when I say one, I don't mean the login/logout or anything that would more or less be considered the framework of your project. What you need to do is identify your minimum viable product. That means you need to figure out how to make your project the smallest it can be, and still be at it's core a fun game. It doesn't sound intuitive but it is important. So you should identify the base feature of your game. What is the ultimate goal? Why are people logging on to play? Is that feature fun or rewarding, without any other embellishments?

Not everyone would but I consider Pokemon to essentially be a virtual-pet game, it's just on a different platform. If you think about all the features Pokemon offers in their games it can be mind boggling, but at it's core the main feature and main draw for the game is surprisingly simple and even in their slogan. gotta catch 'em all. Pokemon is a game based on collecting, all the other features are more or less secondary to this main feature. You want to complete your Pokedex, or at least catch your favorites and that's what they rely on to be the main thing that's fun in the game. That's what I mean when I say identify your main feature. It does not need to be unique, and it does not need to be revolutionary, it just needs to be a solid draw. Whether that feature is community based, collectable based, creation based(breeding or building sites), etc. it just needs to be identified what that feature is. If you think you can make a successful game or project revolving around that main feature then fantastic, hit the ground running and save the dreams for later down the road. Most people will not want to stop there however, and that's okay. 

Once you have that solid main feature you are going to want to select one or two other features that compliment that main feature very well. That does not mean battling and breeding should be those two features. If you're doing a collection based site maybe create multiple ways to collect pets(different types of pokeballs?) or make certain pets only collectable through certain methods(only obtainable if you trade with another player). If your site is heavily community based and your main feature is the forum, a live chat would be a good compliment. These other features should maintain the same goal as your main feature, and should seek to improve that main feature in some way. Be careful whenever you add a new feature that you are making that feature as small as it could be to start with. 

As you go through this process create a new list of your MVP feature list, and at the end compare it your original dream feature list. If even 50% of those dream features are on your MVP list then you are probably still being too ambitious. I can't stress enough how important it is to really cut out as much as you can and start small. Creating a game or website is a very large and daunting process and it is so much better to get something successfully out there in a few months than it is to spend 3 years on a gargantuan project and still not have a launch date. It's also a lot easier to learn from the mistakes you make the first time around when the project is smaller, and it's more rewarding because you're more likely to cross the finish line. 

understanding scope

In the project brainstorming phase of projects I see a lot of people being extremely vague about features that they want but haven't really thought through. However it's crucial when you're brainstorming features to be very specific about what that feature is and is not. Think of a feature scope as a list of rules to make the feature work or not work as intended. Imagine explaining how to collect Pokemon to someone who knows nothing about the game, but being specific enough that they could recreate the game. A vague statement will produce a vague or incorrect result. 

Bad Statement: "You throw a pokeball at the pokemon to catch it."

Bad Result: A game where every time the pokeball is thrown, the pokemon is caught.

Better Statement: "You throw a pokeball at the pokemon to catch it. The higher the level of the pokemon, the lower the chance to catch it."

Better Result: A game where the level of the pokemon determines whether or not throwing a pokeball results in a successful catch. 

The idea is to then become more and more specific, so if you were to explain this to someone they would understand that if they knock the pokemon out then they can't catch it, or different pokeball types work better or worse for different pokemon, or that status effects also effect the success rate of a pokeball. Define all the rules of your feature, and then try to imagine someone attempting to cheat. Pokeballs don't work when you throw them at a pokemon owned by another trainer. If you can define all the rules of your features, that will go a long way to help whoever will have to program the functionality, but also keep communication clear about how something is expected to work and whether or not a change fits within the current scope or not.

If you are changing or adding to the scope during project development, that's something called scope creep. It is not good, not fun, and usually leads to both angry project managers and angry developers. Once development starts, you shouldn't mess with the scope except where development needs clarification. Additionally, if you have changes you want to make then run it by the developer first to make sure they are comfortable with changing the scope or to find out what kind of impact that change will have on cost and deadlines.

Finally, make sure the feature scope with all the rules fleshed out still fits the goal of the feature. If the rules of pokeball throwing made it extremely difficult to catch any pokemon, maybe there's a rule that shouldn't be there because it shouldn't become difficult to play the game. Stating the goal of the features(be more specific than 'be fun') can also help a developer or even yourself 6 months from when you wrote the scope have a clear understanding of where you intend to go with it and what you were thinking when you developed the scope. 

feature value

Did you know features have value? There are ways to calculate hard and monetary values for features, but that could be a guide all by itself so I'm not going to get into that. But when you are generating feature ideas to add to a project or to an already launched game you should always be considering the value that features bring to the site. If it's a small feature but it's going to take a lot of programming work and your users could more or less live without then it may not be worth it to bring that feature in. A mantra of mine with browser based games is that your features for the most part need to be harder to consume than create. That means if it takes you 10 hours to create a quest line that will occupy users for 10 minutes, that would be a bad consume to create ratio. You want to flip that ratio as much as you can so that your users remain entertained by your content and features, giving you time to develop new ones without people getting bored or frustrated. Many people turn to random generation to get the ratio in their favor and if you're clever enough that can be a fantastic way to generate fresh content but there are other ways as well. If you can make small changes to a feature to make it last longer without becoming frustrating for the users, you'll find yourself with a lot more room to develop and come up with ideas. For example if the questline you created required users wait until nighttime to do a certain task, or require that they do some investigation to figure out the answer to a lore riddle then you can expand that questline time from 10 minutes to potentially 12 hours without overburdening your users with meaningless and boring tasks. 

If a feature you create can do any of the following, it's bringing in value.

  • Monetization
  • Bring in new users
  • Keep users occupied for longer than it took to create
  • Generates excitement or community organization
If a feature does any of the following, you're actually losing value.

  • Drives away current users
  • Conflicts with the general mission
  • Causes other features to become useless or undesirable
On rare occasions it's okay to create a feature that hits a point on that second list as long as it's being made up for in a clear way on the first list. Also, do not feel bad about removing or heavily modifying a feature you realize is having a negative impact on your site or does not fit your goals.

 conclusion

If you can make your project small, focussed and have a fantastic understanding of your features you'll be a lot better off when you hit the development level and more likely to avoid some common pitfalls. Especially if you're working on your first browser game site I highly recommend making it as small as possible so you'll see more progress, be less likely to give up and you'll learn a lot along the way to make your next project even better. 

If anyone has any recommendations, comments or feedback please share. I'd love to expand and update where necessary so it's truly helpful to people. 

View full guide

 
Back
Top