reilithion / gridrover-experiments Goto Github PK

Experiments leading up to a working version of GridRover

License: GNU General Public License v3.0

Java 100.00%

gridrover-experiments's Introduction

GridRover is a game designed to teach programming skills.

-- Building --

There are two supported build systems for GridRover.  Ant and Waf.  In most
cases, they should produce identical results.  If you have problems with one
it might pay off to try the other.

To build GridRover, you will need the Java JDK version 5 or greater.

To build GridRover using Ant, you will need Ant.  From the GridRover root
directory, type "ant" (without the quotes, of course).  Ant should put the
resulting .jar file in the dist subdirectory.  This section is small not because
building with ant is necessarily simpler than building with waf, but because
thorough testing has not been done with ant yet.  A different command might be
needed under Windows, for instance.

To build GridRover using the included waf tool, you will need Python 2.x
installed on your system.  Depending on what form of GridRover you want
and what OS you use, there are a few different ways to build it.
Make sure you have the build-requirements met, or waf will complain.

Linux/Unix
	To build the .jar file:
		Make the root directory of the project your working directory
		Type "./waf configure" (waf complains if it can't find javac)
		Type "./waf"
		The program is now located at ./_build_/default/gridrover.jar
	To build the native executable:
		Make the root directory of the project your working directory.
		Type "./waf configure --native" (waf complains without gcj)
		Type "./waf"
		The program is now located at ./_build_/default/gridrover

Windows
	Get to a command prompt
	Make sure the directory that has python.exe is in your PATH *
	Make your working directory the top directory of the project
	Type "python waf configure" (waf complains if it can't find javac) **
	Type "python waf"
	The program is now located at .\_build_\default\gridrover.jar
	
	*  This step is optional, so long as you're willing to type the whole
	   path to python.exe every time you use it.
	** If waf can't find javac.exe, find out where your JDK is installed and
	   set the JAVA_HOME environment variable, like so:
	   set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_11\
	   (Replace that path with the one to your JDK) Then run waf configure
	   again as shown above.

Mac OS X
	Honestly, I don't know how you'd go about this, but it's probably
	similar to Linux/Unix.

You can probably also compile a native version of GridRover for Windows
if you have MinGW or Cygwin installed.  Just make sure gcj is floating around
somewhere on your system where waf can find it and try a command like
"python waf configure --native".  If waf complains, it's probably because
it can't find gcj, or possibly your JDK.

-- Running --

In order to run GridRover, Java must be able to find the Apache Commons Digester
(and its dependencies) in your classpath.  This may make it tricky to run
GridRover from, say, the commandline.  This is one way known to work on
GNU/Linux:

java -classpath .:*:/usr/share/java/* gridrover.GridRover

This assumes that the Apache Commons Digester and its dependencies are all
found in /usr/share/java/ and that GridRover.jar is in the current directory.
Figuring out how to start up GridRover on your own system should be a matter of
replacing my directory structure with yours.

-- Credits --

GridRover was written by "Lucas" Adam M. Paul <[email protected]>
Much help was generously contributed by:
- Ackypi
- Commissioner.moo <[email protected]>
- Karasu <[email protected]> (contributed to the data files; Thanks!)

Special thanks are due to the University of Utah ( http://www.utah.edu ) for
the original idea of a rover simulator and making a program to be a player.
It was their Cassini rover simulation that inspired this project and on which
GridRover is based.  In particular, I owe thanks to the following people at
the University:
Robert Kessler - Professor in charge of HSCI, where I first used Cassini
Stan Shebs - original author of Cassini
Eric Muehle - FROBS and forward-chaining rule system
Eric Eide - Cassini's keeper for oh-so-many years

-- License Information --

GridRover is licensed under the GPL 3.0.  The full text of this license
can be found in the file LICENSE.TXT in the top directory of the source
tree.

gridrover-experiments's People

Contributors

Stargazers

Watchers

Forkers

ackypi

gridrover-experiments's Issues

Implement SpectrumType

SpectrumType should enumerate all the different sensor spectra that are simulated in GridRover. This could be done as an enum or possibly as an xml data file and a class into which to load the data. In either case, the default spectra should include the following:

Visible
Infrared
Ultraviolet
Microwave (Radar)
Radio
X-ray
Audio

Implement LanderLandEvent

A LanderLandEvent (or whatever it gets called) will put a Lander on the map. The Lander should deploy its rover and add the initial rover CommandEvent to the event queue. Since every rover has exactly one lander it belongs to, this will allow both lander and rover to be created at once and makes their insertion onto the map an event, so it can happen at any time, including in the middle of the game.

Remove commented code

Some previous commits have left commented code blocks scattered around. They should be removed now that they are no longer needed.

Create separated, generic XML file parser

Create a XML file parser that is separated from GridRover.java (where the current implementation of it is) and is able to parse any XML file given to it according to a list of Extractors or similar objects that state what is desired from the XML file.

Implement a way for a rover to peer into neighboring squares

A rover needs to be able to look toward an adjacent square to be able to determine if it is safe to travel in that direction. The command responsible for this won't provide as much information as the familiar LOOK command does about the current square. It won't provide a list of the square's contents, for instance. It does, however, have to reveal a rough estimate of that square's elevation and any obvious obstructions or dangers to the rover's passage from its current square into that square.

Implement Rover Modules

A Module is a Thing that can be attached to a Rover to provide that Rover with capabilities. A Module has everything a Thing has (it extends the Thing class). A Module also has:

A number of wheels (which may be 0)
A storage capacity in cubic meters (which may be lass than or equal to 0.0)
A carry capacity in kilograms (which may be less than or equal to 0.0)
A maximum energy capacity in joules (which may be less than or equal to 0.0)
A current energy

A Module may or may not also have:

A robotic arm
A laser defensive weapon
A cutting tool
Any of the several sensors and emitters

The laser and each emitter has an energy consumption rate in joules/second.

Expand list of items to scatter across map

The data/physical_objects.xml file contains a list of objects that are randomly scattered across the map during game initialization. As of the creation of this Task, there are 1 (count 'em, O-N-E) items in this file. It needs to be expanded. This initial data set doesn't need to be a reasonable, realistic, or even sane representation of real objects one might find on another planet. I was thinking of complementing the already existing "Rock" with "Fruitcake" and "Zombie". One constraint is that most of these items do need to have mass and bulk less than that of the default rover so that they can eventually be picked up (when picking things up is implemented). The catalog doesn't need to be too big, but it needs at least 3 items.

MapGrid.scatterItemsRandomly throws IndexOutOfBoundsException

MapGrid.scatterItemsRandomly() does not properly check to see if the ArrayList it is given has elements before attempting to process them. As a result, it can throw IndexOutOfBoundsException if the ArrayList is empty, which can happen if GridRover was unable to load a physical_objects.xml file.

Consolidate user input code

Right now, there are a couple of different places in the code where console input is gathered from the user. This has resulted in code duplication and just a little breakage of MVC. The code that gathers input from the user should be consolidated into a class, either specifically for console input or for input in general, thus restoring MVC.

Robustify resource file location

As of the time of the creation of this issue, GridRover clumsily tries to locate data files in the following two ways:

GridRover attempts to retrieve a String from its Preferences resource and interprets it as a relative path to the directory containing the data files.
Failing that, GridRover prompts the user for a relative path to the directory containing the data files.

The first method is mostly useless because GridRover doesn't currently store any paths it is given into its Preferences resource, so the Preferences resource is always empty. The second method should be a last resort since users cannot be trusted to know where data files are located.

This Task proposes, as a solution, a class or function utilized by GridRover's initialization to reliably locate resources. It should use the following resource-locating techniques, in this order:

Try to locate the desired resource at the location specified as a command-line argument to the GridRover program. Naturally, this technique only applies if command-line arguments were supplied.
Try to locate the desired resource using the ClassLoader.
Try to locate the desired resource from a path in the Preferences resource. This will be useful in situations where an installation of GridRover could not add the data directory to CLASSPATH but the data directory is in a predictable place.
Try to locate the desired resource in the current directory. System.getProperty("user.dir"), I believe, can be used to determine the current directory. Alternatively, a File object created from a String will either be an absolute path or a relative path from the current directory depending on how the String starts.
Try to locate the desired resource via the relative path, "./data/". A call such as new File("data"); can accomplish this.
Prompt the user for the location of the desired resource. This is, as noted above, a last resort.
Fail miserably and complain loudly.

At each step, the Resource Locator should establish whether the resource can be accessed using the given technique. If it can, the Resource Locator should return an InputStream object for the resource. If it cannot, it should move to the next technique. I do not believe a ResourceLocator class would need to be stateful, so it could be implemented as static, or even as a static method of the GridRover class. But then, I've been known to be wrong.

Implement LookEvent

Stop cheating and make rover looking an actual event that consumes time and can be preempted by fortuitously timed events (i.e. other events can happen between a rover issuing a look command and the look actually happening).

Update README.TXT for ant build instructions

Now that GridRover can be built with ant, the build instructions in README.TXT should be updated.

Implement Sensor Data for Things

Things should have spectrum data. Each Thing should have a shape, color, and intensity for each of the spectrum types. Intensity could be expressed as a double, but shape and color may either need their own objects, or be represented as Strings. Note that Strings would not be type-safe. Things should provide a way to query their various spectrum data.