jhester / distributedga Goto Github PK

Currently we are pickling the list part of the map data class and sending that, then creating a different map class clientside and modifying the class in an unsafe way. We need a better system to send/reconstruct map data.

There should be very little to add to the program at this point, hopefully we have a graphical client for students to run, but if not they can each run an observer.

Right now there are plenty of functions that aren't used, if we are turning in the code do you think it needs to be cleaned up a little? or are the extra functions not so bad...

Ok so Ive been looking through our code and we seem to be having issues synchronizing the observer and the game, the thing is that the observer is realtime and the actual game can be played much much faster. This is causing problems because we are updating the player list mid way through the observer walking players around the map, its making for some freaking wierd behavior. I think we need all the while loops we have going on to be synced, cause right now theyre not. time.sleep may not be the answer to this.

This might make the presentation better, if we could have a version of the player client that uses pygame, it could look exactly like the observer (maybe the overlord is controled by the client instead of user) and we can see the world from a clients perspective, which would be a nice wow factor. It could also display a bar graph with 5 bars 1 for health, 4 for AI variables.

Also we could let people in the class room attempt to launch this pretty client...

We need a class for packing the map into a string and a class for packing the players into a string that need updating.

is giving me a connection refused error. is there something im not doing right in running it? Maybe someone can put some run instructions in the readme. thanks!

Hello, under what license is this project released under ? I would like to study it to learn from it. Thank you.

Some balance is needed in the client AI now because players with a low courage tend to survive to the end and then never attack... I'm thinking the server is done now, so I'll start focusing on the client?

We need a separate class to manage adding/removing updating and spawning players on the server. The same manager should be used for the observer?

Just a heads up, I was talking to someone who took this class last semester, and they told me we should have at least 10 slides in our powerpoint.

Having 5-10 maps as text files would be best I think, it cuts down on network traffic. The map files should still be really easy to parse so the clients could read the map data to get the "local" information. Then the server only has to send local player positions to the clients (and a map number/position to use), same goes for observers.

I made some changes but cant push to here for some stupid reason. ill email the code....

So we need to decide on a few variables, I'm thinking 4-8 will give us enough variety for a GA.

Any ideas on variables?

I think it would be very helpful for our presentation and paper if we could get some graphs and stats on how much we are taxing the network and CPU. I'm not sure of the best way to do this, should be too hard if we run it on the lab machines (while sitting at them). We might also want to know how much affect just a client or observer has.

We are still have problems getting data from the socket. recv doesn't always get all the data, which then messes pickle up. If we fix this then I think our client dropping issues will stop. Right now if the same computer is hosting the server and clients they never drop, which means we have a network issue

We need a packer/unpacker class (either 1 per class, or 1 that handles all classes). Packer should be able to pack into a string, unpack into a class, or unpack a string and update an existing class. I'm not sure the best way to do this, we need condor so downloading new modules isn't really a good idea (right?) we could use 'struct' but I think it has site limitations. Struct seems to be designed for single variables which might work for the players as they are just id, xpos, ypos, health (int,int,int,byte) right now.

We might need to just write our own function to pack into bytes and create a string...

Players are always created at (2,2) and sometimes that inside a wall...

We need to split up the server.py into multiple files again, perhaps one for player connection handler and observer connection handler?

Right now when the server starts a round it just sets a flag and waits for the clients to start playing, which means they end up starting at random times, should we bother putting an event in to have all clients start at the same time? or is it not worth the effort?

We might have to look into another source of clients, I have been having trouble getting condor to give more than 20-30 clients.

When creating additional players after the observer it doesn't seem to get data on the new player. Also there seems to be lots of lag (I blame pickle) after you add more than 1 player.

Ok I think we need a timer for a maximum round length, 2minutes? In case all the players decide to be campers and no one ever attacks... I'm not sure what to do as a GA when that happens. Should we make new players using the old winners, or new players using the current players?