Reiterate: Prioritized Bug/Enhancement List, Then Start Again

Games are never done ... there is always something else that could be added and something that is not working properly. This activity will identify those things so that they can be addressed in future versions of YourGame.

Turn In: Word processing document with a prioritized bug/enhancement list for YourGame. This can be a section in an existing document or a separate document.

Many software development projects use a tracking software to identify things that need changed to either fix a program with the program or add something new to the software. These tracking software programs are called "issue tracking", "bug tracking", or "defect tracking" software. Most of those packages have the capability to showing comments from those that found the problem, those that fix the problem, and then those that test the fix to make sure it was done correctly. Each issue is given a unique id number and a status. The statuses could be something like New (a newly recorded issue), Assigned (problem is assigned to someone to work on), In progress (problem is being worked on), Corrected (the problem has been fixed), Test Passed (the problem was corrected), Test Failed (the problem was not corrected), and Closed (problem corrected and software sent out).

While we are not going to use a tracking software program for keeping track of problems with YourGame, we are going to keep a simplified list of things that need corrected and things that need added to YourGame.

In your word processing document create a section called "Bugs" and another section called "Enhancements". Each item in both of these sections should have a unique number. You may use just numeric values 1, 2, 3, etc. where numbers are only used once in either of the sections (i.e. if 5 is in the Bugs section, it may not be in the Enhancements section). Alternatively, you can prefix each of the numbers with the section that it is in (i.e. B15 for the 15th Bug and E15 for the 15th Enhancement).

In the section called "Bugs", make a list of what is wrong with program. These items may come from any testing or testing documents that you have completed. These items may come from people you have asked to try your game out and tell you what they think of it and also let you know what it not working.

In the section call "Enhancements", make a list of the things that would be nice if your game did. These are items that would make your game better, more fun to play, additional levels or challenges, or any other suggestions for improvement. Ask other people to play your game and provide feedback on what they would suggest to make your game better then include those items in your Enhancement section.


With your list of things that need corrected and things that would improve your game, the next task is to create a priority list. There are only 24 hours in each day and of those 24 hours, you have fewer to devote to making a better game. Therefore, it is important to decide what items need addressed first and what items are not that important. This priority list helps to make the best use of the time of those people working on the game. You will mix the bugs with the enhancements. Items that make the game not usable should be highest priority, if the game does not work then people will not play it. Items that are very minor and might not even be noticed can be lower in the list. Items that would make the game better in a way that more people would play the game just for that item should be a higher priority while those enhancements that would add very little value to the game should be lower on the list.

As you get more feedback about your game and as you continue to work on your game and it gets tested more, the priority items may change. That is ok. The intent of the priority list is to help you best focus the time spent working on the game.

The Cycle of Creating Games and Software

There are a number of ways or methodologies to create games and computer software. At a very basic level they all involve similar steps ... research or collect background information about your project, design or re-design how things with your project will work, build software, test the software, prioritize what will be done next, then start the process over again. When a group is working on a game, the members of the group may be working on these different parts of the process at the different or the same times.

This cycle continues as long as changes are needed to the game and you are assigned (yourself or your employer) to work on the project.

Copyright © 2021 Eric Schumm. Permission granted to freely use this in your classroom.