Game Development Reference
In-Depth Information
the time you're done thinking through your game on paper, you should have
many questions that need to be answered and a list of items to research.
The next phase is prioritizing the questions and tasks that this early design phase
has uncovered. Not every game will have features that require researching, but if
there are any research tasks that the game relies on then they need to be done
first; this might be as simple as a quick Google search or it may require asking
people who are better informed or reading topics and articles on the subject.
Small toy programs are a great place to try out different research ideas, which if
successful can be cleaned up and incorporated into the final project.
Once you think you have finished all the research, ask yourself ''What is the very
least I can do to get a basic working game?'' Then do that and if possible try to do
it in one sitting. Once you have a first iteration of your game, it's much easier to
come back to it and slowly refine it. A half finished game is harder to pick up if
you've had a few days break from development.
Game programming requires time; usually a period of four or so hours is
required for a minimum session, especially if you want to get into that state of
flow when you stop noticing the passage of time and become entirely focused on
the task at hand. To-do lists are a good way to direct your development efforts.
A good tip is to write the to-do item and then just below it, write the smallest step
you need to do to start this to-do item, for example.
1. Set up the development environment and get a basic window and game
loop up
- Open Visual Studio, create a new project and call it ''Project Minstrel''
2. Build Simple Song Classifier skeleton class
- Add SongClassifier.cs file and add System.Speech library
The little sentence after the to-do point is something you can do right now; it's
almost easier to take that first step than not, and once you've taken the first step,
you're obliged to finished the full to-do point. Don't collect a backlog of un-
finished to-do items each time you begin developing your project, then throw
away the last to-do list and start again. Anything that's super-important you can
copy across.
Don't be afraid to stop working on a project if it doesn't seem to be going any-
where. Every project, even those that don't get completed, imparts some kind of
 
Search WWH ::




Custom Search