Using Codename One in Java

If you can provide a skeleton of the program it would be fine

Game World Objects For now, assume that the 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 kinds of abstract 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: Base and EnergyStation; and there are two concrete types that moveable objects are instantiated from which are called: Cyborg and Drone. 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 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 14 changed once it is created. As will be specified in the later assignments, each type of game object has a different shape which can be bounded by a square. The size attribute provides the length of this bounding square. All bases and all cyborgs have the same size (chosen by you), assigned when they are created (e.g, size of all bases can be 10 and size of all cyborgs can be 40). 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 energy station may be 15 while size of another energy 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 values X and Y which initially should be in the range 0.0 to 1000.0. 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 bases and cyborgs, 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 CN1s built-in ColorUtil class to generate colors). All objects of the same class have the same color (chosen by you), assigned when the object is created (e.g, bases could be blue, cyborgs could be red, energy stations can be green). 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. Bases are fixed game objects that have attribute sequenceNumber. Each base is a numbered marker that acts as a waypoint on the track; following the track is accomplished by moving over on top of bases in sequential order. Bases are not allowed to change color once they are created. All bases should be assigned to locations chosen by you, when they are created. Energy stations are fixed game objects that have an attribute capacity (amount of energy an energy station contains). The initial capacity of the energy station is proportional to its size. If the player cyborg is running low on energy, it must go to an energy station that is not empty before it runs out of energy; 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 objects position when its move() method is invoked. Some movable game objects are steerable, meaning that they implement an interface called ISteerable that allows other objects to change their heading (direction of movement) 4 of 14 after they have been created. Note that the difference between steerable and moveable is that other objects can request a change in the heading of steerable objects whereas other objects can only request that a movable object update its own location according to its current speed and heading. Cyborgs are moveable and steerable game objects with attributes steeringDirection, maximumSpeed, energyLevel, energyConsumptionRate, damageLevel, and lastBaseReached. The steeringDirection of a cyborg indicates how the steering wheel is turned in relation to the front of the cyborg. That is, the steering direction of a cyborg indicates the change the player would like to apply to the heading along which the cyborg is moving (the steering direction actually gets applied to the heading when the clock ticks given that the cyborg moves, e.g., the cyborg did not run out of energy or does not have the maximum damage or zero speed). The steering mechanism in a cyborg is such that the steering direction can only be changed in units of 5 degrees at a time, and only up to a maximum of 40 degrees left or right of straight ahead (attempts to steer a cyborg beyond this limit are to be ignored). The maximumSpeed of a cyborg is the upper limit of its speed attribute; attempts to accelerate a cyborg beyond its maximumSpeed are to be ignored (that is, a cyborg can never go faster than its maximumSpeed). Note that different cyborgs may have different maximumSpeed values, although initially they all start out with zero speed value. The energyLevel of a cyborg indicates how much energy it has left; cyborgs with no energy would have zero speed and cannot move. You should set this value to the same initial reasonable value for all cyborgs. The energyConsumptionRate of a cyborg indicates how much energy the cyborg would spend each time the clock ticks. You should set this value to the same reasonable value for all cyborgs. The damageLevel of a cyborg starts at zero and increases each time the cyborg collides with another cyborg or a drone (see below). The program should define an upper limit on the damage a cyborg can sustain. Damage level affects the performance of a cyborg as follows: a cyborg with zero damage can accelerate all the way up to its maximumSpeed; cyborgs with the maximum amount of damage would have zero speed and thus, cannot move at all; and cyborgs with damage between zero and the maximum damage should be limited in speed to a corresponding percentage of their speed range (for example, a cyborg with 50% of the maximum damage level can only achieve 50% of its maximum speed). When a cyborg incurs damage because it is involved in a collision (see below), its speed is reduced (if necessary) so that this speed-limitation rule is enforced. The lastBaseReached of a cyborg indicates the sequence number of the last base that the cyborg has reached in the increasing order. Initially, the player cyborg should be positioned at the location of base #1 (initially lastBaseReached is assigned to 1) and its heading and steering direction should be assigned to zero and speed should be assigned to an appropriate positive non-zero value. Later we may add other kinds of game objects to the game which are steerable. Drones are moveable (but not steerable) objects which fly over the track. They add (or subtract) small random values (e.g., 5 degrees) to their heading while they move so as to not run in a straight line. If the drones center hits a side of the world, it changes heading 5 of 14 and does not move out of bounds. If a drone flies directly over a cyborg it causes damage to the cyborg; the damage caused by a drone is half the damage caused by colliding with another cyborg but otherwise affects the performance of the cyborg in the same way as described above. Drones are not allowed to change color once they are created. Speed of drones should be initialized to a reasonable random value (e.g., ranging between 5 and 10) at the time of instantiation. Heading of drones should be initialized to a random value (ranging between 0 and 359) at the time of instantiation. The preceding paragraphs imply several associations between classes: an inheritance hierarchy, interfaces such as for steerable objects, and aggregation associations between objects and where they are held. You are to develop a UML diagram for the relationships, and then implement it in CN1. Appropriate use of encapsulation, inheritance, aggregation, abstract classes, and interfaces are important grading criteria. Note that an additional important criterion is that another programmer must not be able to misuse your classes, e.g., if the object is specified to have a fixed color, another programmer should not be able to change its color after it is instantiated.