Creating a game is a bit different from designing applications such as NetPaint and NetText. The largest adjustment you will have to overcome is implementing a graphics engine of sorts to handle all the drawing and animation that goes on in a typical game. Up to this point, you probably have been relying on Swing heavily, and making using of the update()/repaint() mechanism built in. The process Swing uses to draw is known as Passive Rendering, and while using Swing will still be more than fine for your basic User Interface in game, things will not go very smooth if you try to push Swing much further.

The process we will be using in the creation of Lemmings is known as Active Rendering. Here, instead of just "suggesting" to a component to draw, we are going to grab the buffer and draw directly on it. While there are numerous approaches to accomplishing this task, the easiest and more than likely the fastest is with the aid of a class known as BufferStrategy. Every frame, when your graphics engine is called upon, you will request a the Graphics2D buffer from the BufferStrategy, drawn on the Graphics2D object like you are accustomed, and then tell the BufferStrategy to go on and flip the buffer when you are done with all your drawing. This might sound daunting/confusing, but actually is quite more straight forward than swing, and works far more reliably.

Also, you want to avoid the overuse of Threading in a game, and unless you are integrating sound and networking, the rest of your game should probably run on one thread. All objects should be updated according to the time passed between each frame, rather than numerous timers or threads for each individual game object.

To see a general example of the set up of a BufferStrategy and the proper use of threading in relation to multiple objects, check out http://www.hydrous.net/~gt/2335/GraphicsExample.zip. Remember that you will probably want to use a Canvas instead of a Frame as in the example, as you can still use a Swing UI with an actively rendered Canvas embedded.

A few things you might want to remember/know when creating a game are as follows. Most of these come from experience, and some are fundamentals of Java and OOP.

Once you read the complete lab, you might be stumped on how to possibly implement maps easily in the game. As you may notice, Lemmings maps will be dealing with quite a bit of direct pixel manipulation. From the explosions to walkable areas, each pixel on the game screen might be touched individually at some point in time

One approach to the map would be with the aid of a couple of images, more specifically BufferedImages. A level can be created in any paint program, saved to a .png or .gif, and then used as the backdrop. A second image can also be created that will "mask" the level image. While the mask will never be displayed to the user, it will contain all the information on which portions of the map are walkable, which are not passable, and which pixels have been blown away etc.

The mask should be the same size of the level image, and can be thought of as going on top of the level image. The mask will be a "key" of sorts, as each pixel on the mask will correspond to the same pixel on the image. Instead of being used for display, the mask will have color values that indicate the status of each pixel on the map. For example, a Red Color (255, 0, 0) might represent an unwalkable area, while Blue (0, 0, 255) could represent a boundary. Whenever a Lemming moves in the game, you can check the mask to see if the move is valid, or if actions should be take to move to a valid pixel.

Since we have both the level and mask in images, accessing each specific pixel is quite easy and can be done with the help of the images Raster. A Raster contains all the pixel colors and the ability to set and check the color of any given pixel on the image. For example, lets say an explosion occurs at a point and has a radius of 5. You would then check the mask's Raster to see which pixels fall in that radius and have Color values that match pixels that can be blown up. After switching the relevant pixels on the mask, you then can change the level image to reflect the explosion in the mask. The methods you will primarily be concerned with for achieving this task will be the BufferedImage's getRaster() and the setPixel()/getPixel() methods of the Raster.

It is suggested that your program utilize three control threads for it's basic functions (hint: each of these should have a UML state diagram):

While we said that each Thread is a loop, in practice it MAY be best implemented in a method without a loop and just set a timer to call that method again later.

The main objective of the game is to get all of your Lemmings safely through the current level. You do this by giving special abilities to your Lemmings which allows them to navigate safely to the end (unless of course you have to blow up some of your Lemmings for the greater good of the group). Every level has the following properties related to it:

In this section, you will learn of the multiple abilities that a Lemming can have during the progression of the game. To give a Lemming a particular ability, you will have to do the following:

The default behavior (Walker) of all Lemmings is to pace back and forth. While in this state, a Lemming will walk as far as possible in the current direction it is facing, then it will turn around and repeat. Since Lemmings are not particularly smart creatures, they will walk off edges and will only be stopped by vertical obstacles. If a Lemming walks off an edge, one of several things may happen:

In addition to the default walking behavior, Lemmings have the following abilities:

A complete list of all original Lemmings 2 abilities can be found at http://www.utahdesign.com/lemmings/games.html.

While playing the game, you have the option to do any of the following:

Your game interface must contain the following items:

In addition to these game specific components, you need to have the following components:

You will need to construct a level set that requires you to use each type of the Lemming. Your levels should be larger than one screen size such that you can show your scrolling ability. There are several components to each level, which are:

All of your levels MUST be winnable, but complex enough to give some sort of challenge.

You will need to come up with some sort of way of representing a level on disk, such that you can load them whenever necessary. We recommend you use the rasterization method mentioned earlier.

While your team is able to explore many design options, the following program organization must be followed:

Your program must have three distinct units within it:

In practice it will look something like this:

           +---------+ User Interactions  +----------+  2-Player   +------------+
           |   GUI   |<------------------>|  Kernel  |<----------->| Networking |
           +---------+  Game Reactions    +----------+   Updates   +------------+
        

Your program must make non-trivial use of packages to properly organize your source files. One suggested method is:

          edu.gatech.cs2335.lemmings.gui    - The GUI front-end
          edu.gatech.cs2335.lemmings.net    - The networking components
          edu.gatech.cs2335.lemmings.kernel - The game-play kernel
          edu.gatech.cs2335.lemmings.junit  - JUnit tests.
        

Your team will need to develop numerous UML diagrams to explain how your program will be organized and how it will work. The minimum set of diagrams your TA will need to see are:

Remember, these are the absolute minimum of the diagrams your TA expects to see, to get more than a "C" you will need to detail almost every aspect of your system.

You do not need to account for using JUnit to test your program in your UML designs.

Your must create JUnit tests for all methods in the game-play "kernel" of your program, except the few methods that interact with the GUI or networking components.

To make life easier, you may test an accessor in conjunction with testing a modifier with one set of tests. For example:

          public class Foo {
              /* stuff */

              public synchronized void setBar ( int bar ) {
                  this.bar = bar;
              }

              public synchronized int getBar () {
                  return this.bar;
              }
          }

          public class TestFoo {
              /* stuff */

              /** Tests both getBar() and setBar(int). */
              public void testGetBar () {
                  Foo tester = new Foo ();

                  tester.setBar ( 12345 );

                  Assert.assertEquals ( tester.getBar(), 12345 );

                 /* many more test cases */
              }
          }
        

You will be graded on the thoroughness of your testing... in almost all cases, fewer then three or four test cases for a method is totally unacceptable.

Please see Lab3 and the CS2335 Lecture Slides for more details on proper use of JUnit.

Your program must pass PMD, Checkstyle and Javadoc without producing any errors or warnings (the checks to use have are the same as were specified in Lab3.

Your program must be packed into an executable JAR archive. The archive should contain everything needed for running your program and should be executable from the command prompt as follows (assume your archive is named "Lem.jar"):

          % java -jar Lem.jar
        

Lab2 provides details on how to do this.

Your team must create an ant build file to be used for building and testing your program. Your build file must have the following targets:

          jar        - Creates an executable JAR of your program (this should be the default)
          run        - Runs the program
          junit      - Runs the JUnit tests for the program
          build      - Compiles your program
          pmd        - Runs PMD on all of your source files
          checkstyle - Runs checkstyle on all of your source files
          javadoc    - Runs javadoc on all of your source files
        

Your program should not write any spurious output to the console (i.e. you will need to turn off your debugging messages in your submissions).

All "normal" exceptions must be caught and handled in an appropriate manner. An example of an appropriate manner would be having a pop-up window come up explaining (in "normal-people" English -- not "Java-speak") that there was an error. Exceptions that are outside of your control (e.g. running out of memory through no fault of your program) are not considered your responsibility.

Your whole program's GUI should be able to be seen (and fully playable) in a 800x600 window (with the level just scrolling left/right).

All Lemmings must be animated (this includes animation for those walking left, walking right, falling, digging, etc. for all the things a lemming can be doing).

We are requiring a minimum of three frames of animation per action.

You may find it easiest to pre-render the animation of the Lemmings.

Additionally, all Lemmings set to explode must have a count-down timer over their heads that counts down to the time when they will explode.

We know this is not a class on graphics and do not require extensive animation for the basic requirements in this lab. Simple animated stick-figures that have their arms/legs move is acceptable.

        19 March 2004 - Phase 1 Due In Lab (UML Designs)
         2 April 2004 - Phase 2 Due on WebCT Before 08:00 (Partial Code + JUnit Tests)
        16 April 2004 - Phase 3 Due on WebCT Before 08:00 (Complete Code)
        23 April 2004 - Phase 4 Due on WebCT Before 08:00 / In-Lab Demo
      

For Phase 1 you must submit a copy of all UML designs to your TA in lab. Please see Section 5.3. for more explanation of what diagrams are required.

Additionally your team must submit a completed P1_README.txt file. You should print out the file and staple it to the top of your UML diagrams. A good way of printing the file from within unix is with enscript, using the following command (substitute foo with the name of the printer you wish to print to):

          % enscript -2rG -P foo P1_README.txt
        

For this phase your team must write most of the game-play kernel and enough of the GUI to start the game with a single level and show the Lemmings entering the level, falling, walking around, and changing direction when they hit a wall.

For this phase you must complete the following portions of your program:

Your team must submit the following to WebCT in an archive (tar/gzip/jar/zip):

Everything should be working by now, except for the extra credit items. A few bugs remaining at this stage is ok (you can fix them over the next week), but they should not impact the overall functionality of the program. Sufficient levels should be included that show all of the tasks your lemmings can perform.

Your team must submit the following to WebCT in an archive (tar/gzip/jar/zip):

Phase 4: For this phase you will need to submit your finished project (extra credit options included) to WebCT as an archive (tar/gzip/jar/zip) with the following items:

In-Lab Demo: This is "your time to shine." Your team will have 12 Minutes to show your TA the functionality of your program. It is essential to be prepared when your demo time begins because your TA will move onto the next team as soon as your 12 minutes is up.

Details on what to have prepared for your demo will be posted to the class newsgroup during the week prior to the demo.

A list of instructions to Lemmings can be found at: http://www.kallex.de/lemmings/misc/instructions.txt

You may find it helpful to play Lemmings to get a "feel" for how the game works before writing a clone for it. The following are a few of the known clones of the classic Lemmings (which is no longer available for purchase):

Use of these programs is AT YOUR OWN RISK and subject to their respective licensing agreements. CS2335 provides NO SUPPORT for their use.

Like the members of your team, not every CS2335 TA is an expert in everything, here is a quick list of who is an expert in what. (Note that you can still ask any TA, but these are the ones who will be best able to answer any specialized questions.)

          TA      | Expert In
          --------+-----------------------------
          Ted     | Java Graphics
                  | Ant
          --------+-----------------------------
          Adrian  | Extra Credit Options
                  | Sockets/Networking
                  | Threads/Synchronization
          --------+-----------------------------
          Joe     | Lab Requirements
                  | Threads/Synchronization
                  | Using java.lang.reflect
          --------+-----------------------------
          Andrew  | Ant
                  | JUnit
          --------+-----------------------------
          Ryan    | Java Graphics eXpert
                  | Animation
          --------+-----------------------------
          Hemal   | PMD/Checkstyle/Javadoc
                  | JUnit
                  | Eclipse/SWT
          --------+-----------------------------
        

The CS2335 TA's will be providing help-sessions to help you with this project. The time and location of the help sessions will be posted to the newsgroup after Spring Break.