02-10-1999 04:46									#31
	Support Apolyton, buy Alpha Centauri

thanks for telling about workshop 3.0, and sorry Mark about saying those things, oops

Well, heres a new plan for everyone, I am going to make a good chating program that has the same design as the clashnet design that we can use for meetings It should take nearly as long, by the end of this month I should have it done, no more ICQ

	25-10-1999 17:16									#32
	Increase Your PM Length

Guys,

I've read through this thread and i still don't get it. WHY do you prefer peer2peer to client/server?
How is combat outcome is going to be determined in your model? Specifically, on which machine? Having rmi server running on each machine is a HUGE overhead and RMI is SLOW.

Concerning server crashes -- first, it is possible to write a server that WON'T crush, and even if it does crush it is fairly easy to implement RECOVERY protocol. Do we want Clash to be a GOOD game or just a bunch of code put together? What if one of the players in peer2peer crashes -- not so fun for him/her, and having a recoverable server he can just restart and get the data.

Well, these are just few ideas. If i'm getting something wrong, please enlighten me

Osiris, about the compiler -- why not use JDK?

Regards,
Anton.

	31-01-2000 11:40									#33
	Full PM-box? Change here!

bump

	08-04-2000 15:57									#34
	Support Apolyton buy from Amazon

First off.. I am back!!
wow, back from the underworld parse..
concerning making a chat program, well,
I can make the networking for it.. it would be nice if I can work with a GUI person for that part.. wouldn't be that hard.

Second off.. concerning saying that having a client/server model is more reliable and faster.. well to put it bluntly.. not in my lifetime..
Starcraft has one of the best Multiplayer designs I have EVER seen, and it has a peer to peer model. and it would be a LOT easier to make a recovery protocol with a peer to peer, now yes for each computer it takes a bit more processing, BUT it takes a lot less on the server, because there really isn't one, basically its not really peer to peer, its server to server, and every machine is a server(except when you are setting up the game) but when you launch the game then every host becomes a server and the person that started the game no longer matters.

	18-10-2000 20:42									#36
	Put an end to popups!

For what it's worth, I absolutely favor a 'client/server' approach -- or, more accurately, I favor a 3-tiered approach, with the game engine running on a server, the game's Interface running on the client, and a 'middle-tier' server that interfaces between the two (which in a perfect world would be on a seperate machine/group of machines).

This is how the game is currently planned. A 'database' server for the game engine code, a servlet-based middle tier running on it's own server (or many servers, for balancing the load, if/when traffic becomes heavy). And an 'applet' front-end.

The applet and servlet will communicate thru a socket.

Does this sound reasonable? Any suggestions/corrections?

	19-10-2000 03:06									#37
	Help yourself to an AD-FREE life

robin:

An official welcome to the project .

I'm really glad you brought this thread back to life!

I think getting MP up fast is very important, because that way we can defer the AI till later and still really test out the game elements. So its great this is where you want to work, very timely.

All:

On the specifics... It looks like we need something thats scalable up to lots of players if F_Smith is to have his mega-game vision which does sound fun as an alternative. So that says client/server to me. But we need to make it so somebody's PC can be the server for a small game. So long as that can be achieved I'll be happy, and accept whatever the pros say.

Another issue to keep in mind, is with the complicated models there will be a lot of BW needed to send the info back and forth. For MP we may eventually need to cut down the model detail, at least until everyone has a hi-BW connection. F_Smith is convinced its not a problem (I hope I'm characterizing this correctly) while I'm not so sure about that. Anyway, for background info, I'd ideally like the turns to take max 10s to execute in 'streaming' mode, including all the communication that will go on. So all the info that needs to be there for each turn needs to take something like 2-3 sec Max. Thoughts on this?

One more thing. I would Really like to use the clients, at least those with enough muscle, to run AI processes also. My AI concept allows parallel processing, and the more computational power we can give the AI, the better it will be.

[This message has been edited by Mark_Everson (edited October 18, 2000).]

	19-10-2000 06:50									#38
	Enter the AD-FREE zone

Obviously I don't know about this programming aspect, but I do know about how the models interact with each other so I thought I'd throw out an idea:

If we do them right, the models will be "black boxes" that crunch numbers internally and then send a smaller amount to info to the other models. Could we fix things so that each machine is responsible for number-crunching a particular model? FE one computer could run the ecology and disasters model, another could run all the technology models, and so on. That way, the CPU and memory load is split up and less data has to be transmitted. The computers only need to share the data that has a direct effect on other models.

I'd also like to welcome robin. We need all the technical expertise we can get.

	19-10-2000 23:24									#41
	Increase the size of your Attachments

Mark:

Bandwidth can be a problem, but I think we easily can get around it by only sending the variables in 'gamedata' that change back to the clients.

* * *

robin:

Absolutely, you are correct. The db does not need it's own box until traffic gets heavy.

I use Oracle 8i at work, just storing everything as a blob. They say Oracle promises that 9i, which is 100% java, will outperform any other database by 3 times or else they'll give you a million $$s. Have you heard that yet?

Sounds incredible, to me.

I agree about only using canned routines. SQL direct from client to server is only for DB programmers!

And I don't really trust them, all the time . . .

Yes, a 'servlet' is just a java 'cgi'. It's a specific type of server-side program designed to be used with a webserver. A 'stand-alone' server, like a 'chat' server, is not a 'servlet'. They're excellent, the little differences are astounding.

	21-10-2000 02:11									#43
	Help yourself to an AD-FREE life

Hey Robin:

"I'm assuming that the server platform will be a flavor of Unix and not an M$ product"

Woah there! I hope I've misunderstood you... Perhaps for F_Smiths huge dream games your quoted assumption will be true, but for pickup games the server Needs IMO to be able to be a MS box. Thats what almost the whole world has! I'll wait for further confirmation/denial of this before I put my foot in it further .

	29-10-2000 09:16									#46
	Put an end to popups!

Hi, Guys:

Absolutely we should extend HTTPServlet, I think.

And I also don't mind using the Unix shell, but I've got to warn you, I'm a Unix idiot. But I definitely am interested in gaining some working knowledge, so this is great. I just bought a copy of Red Hat Linux, and am going to install it on an old machine next week, at work, for the experience, and for a test bed.

That will help me here, won't it? Or am I mistaken?

	01-11-2000 19:48									#48
	Support Apolyton, buy Civilization: The Boardgame

Robin:

I'm sorry, I don't understand.

Why do we want to build our own server, instead of using a servlet?

We'll need to use a web server -- I like the Java Web Sever, personally, of course. But isn't that better than having to write all that server code ourselves? I don't understand the gain of using sockets in this case. I was thinking we'd be using doGet and doPost to pass data to the servlet, and just printing any response data (serialized) to the HTTPServletResponse, via a PrintWriter.

Are there reasons this would not work?

I've written a chat server and applet, it runs on our internal Project Office web page and gets used regularly. I've got the code for that, if we absolutely need to build our own server.

And later, I was absolutely hoping to migrate to a Bean architecture, which will absolutely require an App Server. Does this sound like a good idea?

	02-11-2000 12:14									#49
	Put an end to popups!

Hi guys,

quote: Originally posted by robin on 11-01-2000 08:02 AM NO, NO, NO, if you extend _any_ servlet class you _must_ use a webserver to fire them off, this means having to handle cgi/http streams (both in client & server). What we are trying to build is a _server_ (like apache, gets socket requests and replies on that socket (with http packets in this case)), and hads a main method just like a normal java program.

	04-11-2000 23:06									#53
	Support Apolyton, buy Civilization 2

The http protocol is plenty fast enough for our purposes, isn't it? I've got some servlets doing heavy doPost parsing, and its very, very fast. The parsing delay is only a few dozen milliseconds.

I agree that there it might be possible to get slightly faster response time using some other methods, but the Web Server actually does more than just manage the socket connection, giving us other features that will be big bonuses for enhancement -- like session tracking and Bean managment.

From what I understand of 'Jini', it's design for running on small hand-held devices. I'm not sure I understand why it would be useful for the AI. Can you help me out with that?

I was thinking RMI and/or Corba, perhaps. RMI Allows us to use the processor on the client to actually process the AI methods on the client.

	04-11-2000 23:23									#54
	Put an end to popups!

Bernd:

Yes and no.

The game data will all be held in a single object called 'GameData', which will be shared by all players.

The idea I was working with at this point is that the clients build 'TurnHandler' objects from all the orders given by the player. We then send that data to the servlet via a doPost. The servlet processes the turn, applying the turn orders to the game database, and then builds a new 'GameData' object, then serializes back out to the client the new 'GameData' object.

Does this sound workable?

	04-11-2000 23:44									#55
	Help yourself to an AD-FREE life

Am I right in understanding that all the turn handling will be done in the server? If so, will all commands be sent to the server, enabling all players acting together, or will a full turn be sent to the server, most certainly forcing all players to make thrie moves separately? Two more questions for the list. I still have no access to the cvs repository (but already sent my key to robin), so excuse me if I ask a silly question: are you alredy at the point where I would place the ongoing discussion about which protocols to be used? If not, do you both agree in the way I suggested us to work?

	04-11-2000 23:50									#56
	Support Apolyton, buy Civilization III: Complete

I'm sorry I left it out in my first reply, yes, it sounds workable.

	09-11-2000 17:33									#60
	Support Apolyton, buy Galactic Civilizations

I have added all code that i have to the cvs repository, i need a copy of the current client code (@ whatever state its @). People really now need to be using cvs so that we all have a current copy of the code, please send me you keys or i will make you one and send it to you (instructions on cvs can be found @ www.clash.ukshells.co.uk).

Is there any code documentation for the client, is it worth having a policy on this??
I guess its worth having some design diagrams so people know what object does what, any preferences over format (SSADM??)?

For now, i think we should just get the server doing the two basic functions (recording movement, resolving conflict).
Basic flow:
Client: completes turn, user hits 'End turn button';
Client: Send object* containing the position of all units, status of citys and conflicts this client has _caused_*;
Server: Get Turn packet (TurnPacket);
Server: if have TurnPacket from all clients, start turn processing***;
Server: Turn processing....
Client: Request new world data packet;
Server: if TrunProcessing complete, sent WorldPacket else refuse request;
Server: Send deny;
Client: Wait b4 trying again;
Server: Turn processing....
Server: Turn processing complete;
Client: Request new world data packet;
Server: if TrunProcessing complete, sent WorldPacket else refuse request;
Server: Send WorldPacket;
Client: get WorldPacket;
Client: update map;

* Example object format (PS this is an _example_ please don't comment on syntax!):
public class TurnPacket implements Serializable
{
Vector unitPositions = new Vector(); //vector of {object unit}.
Hashtable cityStatus = new HashTable(); //hash of {cityID}->{object city}.
Vector conflict = new Vector(); //vector of conflict object.
}

public class Unit implements Serializable
{
int unitUniqueID; //an unique id assigned to each unit, defined by client: clientID.unitID
Position unitPosition; //where on the map the unit is (now).
}

public class CityStatus implements Serializable
{
int cityUniqueID; //unique city ID defined by the client: clientID.cityID
CityData cityData; //city data??
}

public class Conflict implements Serializable
{
int unitUniqueID; //same as Unit.unitUniqueID
Position position; //disputed map position
}

** A client causes a conflict by moving a unit onto the same position as another non-allied players unit or city.
The conflict is only valid if the other players unit or city is still in the same place @ the end of turn (i.e. all players will be moved b4 resolving conflict! If two non-allied players collide @ end of turn (you moved you unit to the same place as another player) then a conflict occurs.

*** Turn routines not yet defined!

**** Example WorldPacket format (PS this is an _example_ please don't comment on syntax!):
public class WorldPacket implements Serializable
{
Vector unitPositions = new Vector(); //vector of _all_ {object unit}.
Hashtable cityStatus = new HashTable(); //hash of _all_ {cityID}->{object city}.
Vector resolvedConflicts = new Vector(); //vector of conflict results.
}

public class ResolvedConflicts implements Serializable
{
int unitUniqueID; //same as Unit.unitUniqueID
Position position; //disputed map position
boolean survived; //is this unit still alive?
}