Search the Community
Showing results for tags 'planning'.
Found 3 results
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.
This is a guide to help new game designers work out how to plan and execute a level design that works. Often I found that simply trying to hop into a new level and build it based off a loose idea in my mind leads me to almost immediate failure almost every single time. It is frustrating. So I have over time developed a clear process that helps me successfully work out how to do level design that works for me by breaking it down into steps. The Idea Obviously every level starts as an idea. This idea will be spontaneous or deliberate. Either is perfectly okay! This is where you dig out a notebook and keep these written down, or even better drawn down in rough form. Don't worry we will refine them later. These game level ideas should be organized into their own notebook or sketchbook so you can find them later. If you cannot come up with ideas, the best ideas are to look around your environment. If you live in a city, maybe that city corner you drive or walk by is a good environment for a game, or if you live somewhere more rural - that old barn in that field? The point is to make yourself more observant of what resources are around you to generate new ideas. Remember, ideas right now are rough concepts, not full blown levels. Setting, Location, and Theme The next step after you have an idea to come up with the setting, location, and theme to frame your idea in. This further takes the idea and gives it greater bounds, allowing it to grow in your mind into it's own environment. The three points here are: Physical location of your level. Is it a city? Rural town? Indoor or Outdoor? Past, Present, or Future? Actual location of your level, the more specific location of your environment within your physical location defined above. The theme of the environment, this is abstract and defines stuff such as time of day, weather, atmosphere, mood, and other elements that bring your location into focus and what makes it feel the way it does. Purpose Quite simply put, why are you set on doing this level? What drives you? Features What features does this level have for the player? Questions to ask will be: How does this level stand out visually or technically? What game elements are the focus of this game level that make this environment unique? What will the player experience in this environment? Make a list Research and Reference Studies Take some time looking around and studying architecture and environments that meet your above needs. Collect, study, and constantly refine your ideas based on research. Remember, now is the time to refine and improve your concept. What you are looking to collect are references of the following things: Anything that matches your location Anything that matches your environment Anything that matches your style design Props that match your style design Now is also the time to start to start sketching out unique design ideas and putting these on paper for later reference. These studies allow you to ask questions about props or designs now rather than later. The Story Now that you have your environment, what is it's story? How is the player entering the environment and what story leads them there? What story shaped the environment before the player got there? These are important questions to jot down in your notes. The Goals Goals come in three real forms: Objectives Obstacles Set Pieces What objectives will the user have to complete? What obstacles will be the players way? What events will happen (set pieces) along the way? Focal Points Focal points are used in any environment to orient your player. What focal points can you use to keep your player feeling directed and not lost while in your environment? Mapping (on Paper) Take some paper, and draw simply a top down view of your environment, make sure to note all objectives, obstacles, set pieces, as well as focal points. Also note any unique sections. This is your visual guide when building your level out. Mapping (a List) Now take your map you drew, and make a list of all the elements on it. This list is your working list of things to do. Now are you are armed with an organized blueprint of a level design! Now you can finally sit down and execute that wonderful level design! Let me know what you thought of this rather succinct guide on level design