everything is in file
CSUS 1 of 13 CSUS COLLEGE OF ENGINEERING AND COMPUTER SCIENCE Department of Computer Science CSc 133 – Object-Oriented Computer Graphics Programming Fall 2021 Dr. Muyan Assignment #1: Class Associations & Interfaces Due Date: Monday, September 27th (11:59 PM) Introduction This semester we will study object-oriented graphics programming and design by developing a simple video game we’ll call OnTarget. In this game, you (the player) will be controlling an ant walking around a path while trying to avoid collisions with spiders and keeping your ant fed. The goal of this first assignment is to develop a good initial class hierarchy and control structure by designing the program in UML and then implementing it in Codename One (CN1). This version will use keyboard input commands to control and display the contents of a “game world” containing the set of objects in the game. In future assignments, many of the keyboard commands will be replaced by interactive GUI operations, and we will add graphics, animation, and sound. For now we will simply simulate the game in “text mode” with user input coming from the keyboard and “output” being lines of text on the console. Program Structure Because you will be working on the same project all semester, it is extremely important to organize it correctly from the beginning. Pay careful attention to the class structure described below and make sure your program follows this structure accurately. The primary class in the program encapsulates the notion of a Game. A game in turn contains several components, including (1) a GameWorld which holds a collection of game objects and other state variables, and (2) a play() method to accept and execute user commands. Later, we will learn that a component such as GameWorld that holds the program’s data is often called a model. The top-level Game class also manages the flow of control in the game (such a class is therefore sometimes called a controller). The controller enforces rules such as what actions a player may take and what happens as a result. This class accepts input in the form of keyboard commands from the human player and invokes appropriate methods in the game world to perform the requested commands – that is, to manipulate data in the game model. In this first version of the program the top-level Game class will also be responsible for displaying information about the state of the game. In future assignments, we will learn about a separate kind of component called a view which will assume that responsibility. When you create your CN1 project, you should name the main class as Starter. Then you should modify the start() method of the Starter class so that it would construct an instance of the Game class. The other methods in Starter (i.e., init(), stop(), destroy()) should not be altered or deleted. The Game class must extend from the built-in Form class (which lives in com.codename1.ui package). The Game constructor instantiates a GameWorld, calls a GameWorld method init() to set the initial state of the game, and then starts the 2 of 13 game by calling a Game method play(). The play()method then accepts keyboard commands from the player and invokes appropriate methods in GameWorld to manipulate and display the data and game state values in the game model. Since CN1 does not support getting keyboard input from command prompt (i.e., the standard input stream, System.in, supported in Java is not available in CN1) the commands will be entered via a text field added to the form (the Game class). Refer to “Appendix – CN1 Notes” for the code that accepts keyboard commands through the text field located on the form. The following shows the pseudo-code implied by the above description. It is important for things that we will do later that your program follows this organization: Game World Objects For now, assume that OnTarget game world size is fixed and covers 1000 (width) x 1000 (height) area (although we are going to change this later). The origin of the “world” (location (0,0)) is the lower left hand corner. The game world contains a collection which aggregates objects of abstract type GameObject. There are two abstract kinds of game objects called: “fixed objects” of type Fixed with fixed locations (which are fixed in place) and “moveable objects” of type Movable with changeable locations (which can move or be moved about the world). For this first version of the game there are two concrete types that fixed objects are instantiated from which are called: Flag and FoodStation; and there are two concrete types that moveable objects are instantiated from which are called: Ant and Spider. Later we may add other kinds of game objects (both Fixed kinds and Moveable kinds) as well. The various game objects have attributes (fields) and behaviors (methods) as defined below. These definitions are requirements which must be properly implemented in your program. • All game objects have an integer attribute size. All game objects provide the ability for external code to obtain their size. However, they do not provide the ability to have their size changed once it is created. As will be specified in the later assignments, each type of game class Starter { //other methods public void start() { if(current != null){ current.show(); return; } new Game(); } //other methods } public class GameWorld { public void init(){ //code here to create the //initial game objects/setup } // additional methods here to // manipulate world objects and // related game state data } import com.codename1.ui.Form; public class Game extends Form{ private GameWorld gw; public Game() { gw = new GameWorld(); gw.init(); play(); } private void play() { // code here to accept and // execute user commands that // operate on the game world //(refer to “Appendix - CN1 //Notes” for accepting //keyboard commands via a text //field located on the form) } } 3 of 13 object has a different shape which can be bounded by a square. The size attribute provides the length of this bounding square. All flags have the same size (chosen by you), assigned when they are created (e.g., size of all flags can be 10). You should also assign a size value to the ant. Sizes of the rest of the game objects are chosen randomly when created, and constrained to a reasonable positive integer value (e.g., between 10 to 50). For instance, size of one of the food stations may be 15 while size of another food station may be 20. • All game objects have a location, defined by Point built-in class of CN1 (which resides under com.codename1.charts.models and uses float values), which is constituted from non-negative X and Y values that initially should be in the range 0.0 to 1000.0 and 0.0 to 1000.0, respectively. The point (X,Y) is the center of the object. Hence, initial locations of all game objects should always be set to values such that the objects’ centers are contained in the world. All game objects provide the ability for external code to obtain their location. By default, game objects provide the ability to have their location changed, unless it is explicitly stated that a certain type of game object has a location which cannot be changed once it is created. Except flags and the ant, initial locations of all the game objects should be assigned randomly when created. • All game objects have a color, defined by a int value (use static rgb() method of CN1’s built-in ColorUtil class to generate colors). Initially, all objects of the same class have the same color (chosen by you), assigned when the object is created (e.g., flags could be blue, the ant could be red, food stations can be green, spiders can be black). All game objects provide the ability for external code to obtain their color. By default, game objects provide the ability to have their color changed, unless it is explicitly stated that a certain type of game object has a color which cannot be changed once it is created. • Flags are fixed game objects that have attribute sequenceNumber. Each flag is a numbered marker that acts as a “waypoint” on the path; following the path is accomplished by walking over on top of flags in sequential order (the flags mark the course of the path on the ground, see the diagram below). Flags are not allowed to change color once they are created. All flags should be assigned to locations chosen by you, when they are created. • FoodStations are fixed game objects that have an attribute capacity (amount of food a food station contains). The initial capacity is proportional to the size of the food station. When the ant is hungry (i.e., running low on its food level), it must walk to a food station that is not empty before its food level becomes zero; otherwise it cannot move. • All fixed game objects are not allowed to change location once they are created. • Moveable game objects have integer attributes heading and speed. Telling a moveable object to move() causes the object to update its location based on its current heading and speed. The movable game objects move simultaneously according to their individual speed and heading. Heading is specified by a compass angle in degrees: 0 means heading north (upwards on the screen), 90 means heading east (rightward on the screen), etc. See below for details on updating an movable object’s position when its move() method is invoked.