theunreplicated/coloradocollegegame

Automatically exported from code.google.com/p/coloradocollegegame

coloradocollegegame's Issues

Change parser, addPlayer, setPosition, &c., to Deal With int[]

Currently, parse receives an array of ints passed between client and server
and then uses the first int to decide on the function in World to call.
When it calls it, however, it passes individual ints (e.g.,
"addPlayer(message[1], message[2], message[3] ..."). It would make more
sense and be easier to manipulate later if we instead made parse pass the
array and an int telling the function where in the array to start looking
(e.g., "addPlayer(message, 1)"). That way, if we change the way addPlayer
works (say, it takes another variable), we don't have to change the parse
function at all.

Original issue reported on code.google.com by [email protected] on 1 Feb 2007 at 5:07

Client connects only to Mathserver

Make it so both port and host can be passed to the client through the
command line.

Original issue reported on code.google.com by [email protected] on 1 Feb 2007 at 4:56

Change Representation to Extend World

We want the Representation (e.g., Canvas2D) to hold an array of
GraphicalElements, while the World class only holds Elements (so that it
can handle text-based elements as well) without bothering with the if-check
we now have to do in World's addPlayer function. If Representation extends
World, then it can overwrite the World's addPlayer function to add a
GraphicalElement instead of an Element.

Original issue reported on code.google.com by [email protected] on 1 Feb 2007 at 5:01

Can only move in cardinal directions

The java MousePressed and MouseReleased events aren't behaiving as would be
expected.  

Presently you can't hold down left and up and head in a North West 
direction.  

Presently if you hold down the up key (for example) for a minute it will
repeateedly call the MousePressed and then MouseReleased events, instead or
only calling MousePressed and MouseReleased once.

So if I press down on the up key and then down on the left key, the
KeyListener will only receive KeyPressed and KeyReleased events for the
left key, not the up key.  

So if, in the game, you are moving up and then push left, you will not
continue to move up, but you will only move left.

Testing on KeyListener is needed or a work around discovered.

Original issue reported on code.google.com by [email protected] on 1 Feb 2007 at 5:15

ElementFactory only uses default Position, Facing, and Bounds

Someone who gets the XML better than I do (I'm looking at you, Omer) needs
to change ElementFactory so it doesn't only assign default position,
facing, and bounding box.

It needs to look through the XML for the proper tags and then construct the
values. Only use the defaults if the tags haven't been specified.

The tags should be:
<element>
   <center>x
   <center>y
   <center>z
   <rotation>rotX
   <rotation>rotY
   <rotation>rotZ
   <bounds>x-length
   <bounds>y-length
   <bounds>z-length

Original issue reported on code.google.com by [email protected] on 14 Mar 2007 at 5:40

[resoloved] NullPointerException on keyboard input

I can run the program as specified. It brings up a blank (white) Frame with
nothing in it. When I hit one of the arrows, I get a NullPointerException.
If there is something I'm doing wrong, then that should be specified in the
instructions.

Terminal output below:


jross@IT-20F4Y21-0610 ~/coloradocollegegame
$ java Server &
[1] 1784

jross@IT-20F4Y21-0610 ~/coloradocollegegame
$ java Client &
[2] 3344

jross@IT-20F4Y21-0610 ~/coloradocollegegame
$ Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at World.nudgeElement(World.java:47)
        at ClientIO.moveSelf(ClientIO.java:66)
        at ClientIO.keyPressed(ClientIO.java:98)
        at java.awt.Component.processKeyEvent(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown
Source)

        at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown
Sour
ce)
        at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown
Sour
ce)
        at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown
Source)

        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)

Original issue reported on code.google.com by [email protected] on 2 Feb 2007 at 3:28

Up and Down (3rd dimension) not yet supported

Our current implementation of the "nudgeElement" function in World.java
(which moves a player in a cardinal direction) can only move in two
dimensions. At some point, we should think about how we would add
functionality for the 3rd dimension. (e.g., if I as a user press some key,
like 'u', my character's position on the z-axis increases.)

To do this, we'll need two new variables in the Constants class to
represent vertical up and vertical down. We'll then need to change how
"nudgeElement" works. It would probably also be a good idea to make the
function a bit less convoluted (maybe to use a switch statement instead of
crazy math).

Original issue reported on code.google.com by [email protected] on 1 Feb 2007 at 5:15

Choose a genre

Games fall into a genre.  Ours should too.

Original issue reported on code.google.com by [email protected] on 31 Jan 2007 at 10:13

solvor

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?
Our group's idea to reach this goal is using a heap. The heap contains all 
the local time of the players' machine. Here the time is the time when 
players request a movement. Then we take the earliest one to operate, also 
sending all the players' positions so that the one we are operating can 
take those positions as spots of wall. Therefore it can run well on that 
player's machine. Then we get the infomation back to the world, then the 
next player in the heap. In addition, we can use several threads to do 
both things: operating and dealing with the heap.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 6 Feb 2007 at 3:51

XML authentification

At some point we're probably going to want to specify _which_ XML tags are
required to be specified in the .ccel and .ccw files. For example, we'll
need to have <name> tags on everything in .ccel, and <position> tags on
everything in .ccw (or not). We should set up the Factories to make sure
these tags exist, and not load stuff if they're missing a vital tag. And
then if a tag is not required (like rotation or scale or something), then
we need to make sure that the variable is set to default and not left
undefined.

Not a big rush (since the errors get thrown and caught by us anyway), but
it would be good to have in the future. Maybe a project for 8th block.

Original issue reported on code.google.com by [email protected] on 6 Apr 2007 at 2:08

Change name of GraphicalElement to Element2D

This is a more logical name.

This makes it so that we can have other kinds of elements, like ElementText
or Element3D

Original issue reported on code.google.com by [email protected] on 1 Feb 2007 at 5:02

Divorce user/client from client/server communication

As far as I can tell, currently the code that handles user<-->computer
interaction (like drawing output and listening for keyboard input) is in
the same file (ClientIO.java) as the code that handles client<-->server
interaction (passing information over the net).

These should be split into different classes.

There should be a single class that handles keeping the client-side world
and keeping that sync'd with the server-side world. Then any instance of a
"client program" would reference/include/extend this class. A "client
program" would deal with the user--taking input and giving output. So when
the user hits a key, the "client program" class passes a message to the
client-serverIO, which then communicates with the server.

The main advantage to this is that different people (other than us) could
write a "client" program (kind of like how there 2^x clients for vsn) which
either extends or include our code without actually haven't to look at our
code, and everything will still work the exact same way. Similarly, we
could change our code (how the implementation works) without affecting any
other clients that use it. It makes it easier to distribute and later
change if we have to.

Original issue reported on code.google.com by [email protected] on 1 Feb 2007 at 6:48