I believe it was Chris Crawford who pioneered the ideas of "verbs" in game design. The idea is this, the more verbs in your game design, the more things the player can do. Unfortunately many, many game designs are just "Dodge X and collect Y." This is especially true of Flash games.
If you hold to the "standard" definition of a game (A system of rules that a player interacts with, creating strategies and making meaningful choices, attempting to reach a defined goal.), this is not a game. There are no strategies to be developed, no choices to make and nothing for the player to discover.
I realize that game development is a great deal of work. Completing a "Dodge X and Collect Y" game can be quite an accomplishment. Developers who do this are going far past most people who say they want to make games. However, this is game development as an exercise; it is not game design. If your goal is game development, you are doing the right thing. If your goal is to be a game designer, you need to go farther.
Here are a couple questions to ask yourself about your designs:
- When a player encounters a game element (enemy, platform, etc.), what are the choices my player can make? - If there is always 1 choice, you have a problem.
- Do my weapons/enemies/levels support my player actions? - As a game designer, you are tricking players into thinking they have figured something out. In truth, you should be designing perfect scenarios where things work out perfectly for the player. They just need to find them. For example, does the enemy formation align in just the right way sometimes for a beam shot to take them all out in one shot? Does this hill provide perfect cover if I use this weapon?
- What is my magic moment? - This is a moment when everything aligns just right and the player can do something amazing. The right action, at the right time, in the right place, against the right enemy creates a fulfilling win for the player.
All of these things (and much more) should be clear before you code, before 1 piece of game art is created, before the GDD is even started.
"Dodge, jump, collect, attack" is a good starting point for many game designs. However if you find your designs consist of only these verbs, dig deeper. Try adding some other verbs to the design: dig, absorb, eat, reflect, phase, dash, inflate, bait, etc. There are loads of these things. There are also endless executions or combinations of verbs to experiment with in your designs.
Managing a game project is a daunting task. Contrary to what you may have heard, it's not simply saying the word "SCRUMM" 4oo times a day. The mechanations of managing a large game project are herculean and would quite frankly grind me to chum in its gears. However, I have a method for managing my own small game projects.
Any game is a substantial task and it's difficult to know where to start. There are so many aspects of game creation that choice paralysis can keep you from ever starting. A simple to-do list, that allows you to prioritize tasks, can help immensely. I use RememberTheMilk.com. It's free and I like how it lets me quickly change the priorities of items, use tags and export to iCalendar. You can also access it from you iPhone for a small yearly fee.
Here is my organization method.
Make a Short-term Goal
So you are sitting at your computer and you don't know where to begin. Make yourself a very short-term goal. For example, "Keyboard controls for the avatar with placeholder art." My current avatar has a few movement behaviors: run, crouch, sneak and jump.
List and Prioritize All Tasks
I enter my goal as a priority 1 task with stars (** Keyboard Controls **) so it stays top of mind.
Now I list all my tasks. I try to tag them with "art, programming, design or sound." This current goal is nearly all programming with a little placeholder art. I break down the programming tasks by action: walk, run, crouch, etc.
Now I use Remember the Milk's 4 priority categories to organize my tasks. Keep in mind your dependencies. Don't have a priority 1 goal that has lower priority dependency. I never have more than 1 top priority task other than my goal.
The priority 2 tasks are the few things in the running to be done next. There should not be more than 3-5 of these.
Priority 3 tasks are often a mixed lot. I use this group to lump in a myriad of tasks in case I get bored or frustrated with what I am currently doing. So if I am getting stuck on my current programming task maybe I will jump over to an art or sound task.
Priority 4 tasks are everything else. Sometimes I enter other goals in here that will later become top priority. I also enter loads of random tasks that don't have anything to do with my current goal.
Complete and Update
Now just stay on top of your list. "Complete" your top item when it's done. Move another task up to top. Once your goals is met, make another short term goal, and repeat the process.
Building on my previous post about bow great Collision Detection Kit is, here is something that is not so great.
Using HitTestPoint outside of a scrollRect will return false even when it should be true. This is bad news for games using hitTestPoint and scrollRect for camera movement.
Jobe Maker has a good explanation.