Overview of Lab
The purpose of this lab is to allow you to become familiar with programming with the Silverlight framework, and to experience a day in the life of a maintenance programmer. You will take a somewhat poorly designed and implemented application, improve its design through refactoring and add some basic additional functionality.
This is a 4 person project. You may select your own project team members to work with. Unassigned people will be involuntarily grouped after the in-lab signup.
The basic application you have been given is a simple implementation of a basic third-person shooter type game. It uses Silverlight to play the first level of a partial implementation of the game inside a web browser. You find some good tutorials on Silverlight at: http://silverlight.net/Learn/
Your company hired Fred from UGA to develop the basic game. Unfortunately, Fred slept through most of the object-oriented design lectures and failed to really learn to program very well. As a result, he got a part of the project completed and then quit to open a gopher ranch. Your mission is first to refactor Fred's crummy code into well-structured C# and OO. Secondly, you will add some functionality to make the game a little more complete.
Your first step should be to enusre you have the Silverlight development kit installed. This kit is available free from Microsoft. It requires that you have Visual Studio 2008 with Service Pack 1 already installed. After installing the Silverlight kit for Visual Studio, you should have everything you need to develop the program. Next, load the provided code into Visual Studio and build the solution. When you start the game, a web browser should open, and you can play the game the way it is right now. As you can see, the application has the following features complete:
Displays a start button, allowing the user to start a new game. Exits the game when the user presses the Esc key. Moves the players airplane around the screen in response to the arrow keys. Fires bullets in response to the player pressing the space bar. Randomly generate enemy planes and move them down the screen Detect collisions between the bullets and the enemy planes and destroy the planes Keep score and persist the running score between instances of the game. Some of the important missing functionality:
Keeping track of player lives and ending when lives = 0 Detecting when the player collides with an enemy plane and destroying the player Unit tests programmed using NUnit Important Important
When writing NUnit tests, you do not normally need to test "getters and setters" or Properties UNLESS they do something more than get or set a value. You also do not have to write tests for any methods that display to the browser.
You need to apply some refactorings initially to obtain a better and more maintainable overall design. Then, you will enhance the program to add new fuctionality. Remember to first write NUnit tests, then rerun your NUnit tests (or the application itself for Gui classes) to ensure the application still works after each refactoring. Don't try to refactor and modify everything at once. Apply one refactoring at a time.
Look over the existing methods and try to determine which can be tested with NUnit. Write NUnit tests for these and ensure they pass. Look at the class Constants.cs. This class has a lot of the game constants centralized in one globally accessible class. It would be better if the constants were located in the classes that need them. Move these values into the appropriate place. Now look at the ResourcePool.cs class. This is a custom class for having a collection of objects that can be reused. If a class is not marked as in use, it can be provided for someone to use. This can make garbage collection more efficient. If I precreate some bullet and enemy classes, then during the game whenever I shoot, I can ask the resouce pool to just give me a bullet object that is not in use. This means that I do not incur the cost of creation and destruction of the objects--especially if the player is the "spray and pray" type. Right now the ResourcePool class expects GameObjects. If we think about it, we might want a more reusable class which could hold things that are not just GameObjects. Examine the GameObject class and apply the Extract Superclass refactoring to remove functionality related to object pooling. Name your superclass PooledObject. Make GameObject a subclass of PooledObject. Then change the ResourcePool class to use instances of PooledObject instead of GameObject. Now study the code for other refactoring opportunities. When satisfied, with the code organization and design, proceed on to adding new functionality. New Functionality
When the player's airplane collides with an enemy plane, destroy the player's plane and decrement their lives by one. Keep track of player lives. Print the remaining lives to the screen each time the player dies. The player should start with 5 lives. Extra Credit
For those people looking to go above and beyond the call of duty, we are allowing you to complete extra features of your chosing from the following list.
Powerups: Besides enemy planes, some kind of powerup appears. If the player collides with it, the player receives some kind of bonus.(5-10 pts per unique item) Increasing difficulty: As time progresses, more enemy planes appear and they move faster.(10 pts) Enemies Shoot: Enemy planes don't just move down screen, they also fire bullets that the player must dodge. (10 pts) Improve the UI display. It is pretty plain now. Add better score display, a help screen, etc. (10 pts) Turn-in Requirements
Warning Warning Your application must work from within Visual Studio using the Silverlight library. Be sure and turn-in all code, resources and solution files necessary to run your program.
You should turn in:
VS solution/project files. All source code/ resources necessary to run your project. A README file with the following information CS2335 - Lab 6 - Spring 2009
gt gt gt gt
Requirements prior to running the program:
.
.
.
Instructions to use your application:
.
.
.
Known Bugs:
.
.
.
O/S(s) Developed/Tested under:
.
.
.
Extra Credit Opportunities Attempted:
.
.
.
Refactorings Applied/Comments:
.
.
.
Code Analysis Tools Used:
.
.
.
Please submit an archive of all these files in the following formats: zip for Windows, or a link to your subversion repository.
30 Day Summary May 14 2013 — Jun 13 2013
|
12 Month Summary Jun 13 2012 — Jun 13 2013
|
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.