Home » Stars! Clones, Extensions, Modding » FreeStars » A modest proposal to make clients easier
| Re: A modest proposal to make clients easier |
Fri, 03 February 2006 23:20   |
|
 Madman |
 | Officer Cadet 1st Year |
Messages: 228
Registered: November 2003
Location: New Zealand | |
|
| Kotk wrote on Sat, 04 February 2006 16:52 |
Not sure if you get it fully ... the thing does tons of calculations. For example the research prognose you said is "pretty easy" calculates one year build for all queues. click to that research percentage and all queues recalculated to find out new research prognose.
|
Perhaps I'd better say what I meant by 'easy' - I meant an easy interface, as the calculations have to be done regardless of that the interface is.
| Quote: |
I am no way supporting "calc it all in your clients, dudes" idea.
|
I liked this idea a few months ago, then I thought about it a little bit ...  . OTOH, if someone starts a client with that idea, why try to prevent them - just get them to move to a better way of doing it, or at worst, take their code and retrofit it.
| Quote: |
On the contrary, i believe that needed interface will be quite large and may happen that we are underestimating the task. Very probable that MSQI will need lot more than 5 or 10 different queries. 
|
Quite possibly - MSQI is really easily extensible though. One thing I'd try and do for efficency is try to make the queries 'big' ones, so you query a particular planet, and it gives you the hab, mining rates, growth, queue finishing times etc., all in one query. Well, possibly queue finishing times might be a separate query if that is slow to calculate.
Once there are one or two queries, adding a new one is pretty quick.
| Quote: |
Yes, people have different taste. For example me ... i always feel that it takes special treatment in "managed" languages to get some resources deallocated and freed timely. In C++ i feel safe, usually some STL container or smart pointer takes care, no special "dispose()" or other tricks needed. 
|
I've gone the other way - I consider memory in the same way as register allocaton - except in pretty special circumstances, I've very happy for the garbage collector to deallocate things for me in it's own time. Unless you use smart pointers or such (and that requires discipline), about 1/3 of a C/C++ program can be to do with freeing memory. That's more coding, more debugging, and     if you get it wrong (apologies in advance for gratuitous use of smilies).
Anyway, for a volunteer project, it's best if possible to let people use the tools they are happiest with - you get more volunteers that way.
Report message to a moderator
|
|
|
|
| Re: A modest proposal to make clients easier |
Sat, 04 February 2006 00:24 |
|
|
|
This client-server/calculator interface thing is getting to be somewhat of a mess...I have an idea of how to clean it up somewhat...
Using sockets(or whatever other method people care to write for server/client interface)
Have the client send the player's xml info to the server(all of it! including the known enemy info)(or even just a MSQI(pat pending) load these files command)
then using MSQI(pat pending) allow the client to send data updates and info queries. Because of the structure of the xml player files referencing individual bits of data shouldn't be too hard.
When all is done retrieve all the info and write to files(or send a MSQI(pat pending) write files command.)
I'd recommend keeping the command set as small as possible, but still flexible, any single command that could be done with several others shouldn't be included.
read <files> (from disk)
write <files> (to disk)
clear (wipe the slate clean and start over (probably followed by a read command)
poke <data> (no reason why this shouldn't be a large xml data piece eg an entire production q or a fleet with contents and orders et)
peek <data> (this would be the interesting one - getting a player order or other "static" game fact would simply return that order, but getting things like projected fuel consumption, remaining RW points or resources allocated to research should invoke the calculator.
a typical seesion might then look like:
read game.xy game.m1
poke (xml fed from game.x1)
peek (whatever the root of the data structure is)
poke some change
peek some effect
etc
clear
read game.xy game.m1
poke (xml fed from game.x1)
peek (whatever the root of the data structure is)
poke some other change
peek some other effect
etc
write game.x1
In the client interface and in writing the .x files you'd need to diffentiate between player orders and other game data...so that you are able to poke game data(eg combat orders for enemy fleets) but this data shouldn't of course be sent to the hot for processing. Perhaps two clear commands... clear and clearall, where clearall wipes the slate clean, and clear resets just the game data and not the player orders.
read and write are somewhat superflous, since the client can read/write the info to/from files and poke/peek the data to/from the server, but hey...a use might be found for them yet. lol
Report message to a moderator
|
|
|
| | |
| Re: A modest proposal to make clients easier |
Sat, 04 February 2006 07:11 |
|
| Madman |
| Officer Cadet 1st Year |
Messages: 228
Registered: November 2003
Location: New Zealand | |
|
| gible wrote on Sat, 04 February 2006 18:24 |
This client-server/calculator interface thing is getting to be somewhat of a mess...I have an idea of how to clean it up somewhat...
|
Well, it's not that much of a mess - in my mind I have a pretty clear idea what I want to do, even if the discussion has been a little messy. Your ideas are good though 
| Quote: |
<snip>
peek <data> (this would be the interesting one - getting a player order or other "static" game fact would simply return that order, but getting things like projected fuel consumption, remaining RW points or resources allocated to research should invoke the calculator.
|
Well as I see it with your idea, the local server instance keeps track of everything (which makes good sense), and lets the client get on with displaying it. The only comment I'd have with this is that it then doesn't matter to the client whether the data is static or dynamic - when asking about a planet, things like population and minerals are in the .m file (or equivalent), whereas the projected growth and amount of allowed terraforming are not. The client doesn't really need to care about this distinction - it just says - "give me all the information about this planet". Similarly, getting an order such as a fleet move might as well include ETA, fuel consumption etc.
When I get time, I might try setting up a list of what each peek and poke would do.
| Quote: |
In the client interface and in writing the .x files you'd need to diffentiate between player orders and other game data...so that you are able to poke game data(eg combat orders for enemy fleets) but this data shouldn't of course be sent to the hot for processing. Perhaps two clear commands... clear and clearall, where clearall wipes the slate clean, and clear resets just the game data and not the player orders.
|
No need for two clear commands - just have a routine for pulling out the .x files that automatically only grabs appropriate stuff. Even if you did include orders for other people's fleets, the game server should reject it.
Oh, and no patent pending on MSQI - I don't support software patents  , and I would like to able to license such code under the proposed GPL3.
Report message to a moderator
|
|
|
| |
| Re: A modest proposal to make clients easier |
Sat, 04 February 2006 15:02 |
|
|
|
| Madman wrote on Sun, 05 February 2006 01:11 |
| gible wrote on Sat, 04 February 2006 18:24 |
<snip>
peek <data> (this would be the interesting one - getting a player order or other "static" game fact would simply return that order, but getting things like projected fuel consumption, remaining RW points or resources allocated to research should invoke the calculator.
|
Well as I see it with your idea, the local server instance keeps track of everything (which makes good sense), and lets the client get on with displaying it. The only comment I'd have with this is that it then doesn't matter to the client whether the data is static or dynamic - when asking about a planet, things like population and minerals are in the .m file (or equivalent), whereas the projected growth and amount of allowed terraforming are not. The client doesn't really need to care about this distinction - it just says - "give me all the information about this planet". Similarly, getting an order such as a fleet move might as well include ETA, fuel consumption etc.
|
This is why they are interesting, because things like ETA's aren't in the .m file, they won't have and xml data spot to reference(yet) and if this C-S interface is used, then it will need to be dealt with, probably by adding these to the xml structure(with a "temporary" tag to differentiate it), thats the easy bit - knowing which temporary bits are dependant on what other bits or data could prove a headache tho. A client would be wise to peek root occasionally to make sure nothing is missed.
| Quote: |
No need for two clear commands - just have a routine for pulling out the .x files that automatically only grabs appropriate stuff. Even if you did include orders for other people's fleets, the game server should reject it.
|
The difference is for playtesting enemy movements, battles etc, in fact I'd almost include push/pop state commands as well..tho these could be done with clear and pokes.
| Quote: |
Oh, and no patent pending on MSQI - I don't support software patents , and I would like to able to license such code under the proposed GPL3.
|
hehe I was kidding  I don't even support copyrighting.
Report message to a moderator
|
|
|
|
| Re: A modest proposal to make clients easier |
Sat, 04 February 2006 18:24 |
|
| Madman |
| Officer Cadet 1st Year |
Messages: 228
Registered: November 2003
Location: New Zealand | |
|
| gible wrote on Sun, 05 February 2006 09:02 |
This is why they are interesting, because things like ETA's aren't in the .m file, they won't have and xml data spot to reference(yet) and if this C-S interface is used, then it will need to be dealt with, probably by adding these to the xml structure(with a "temporary" tag to differentiate it), thats the easy bit - knowing which temporary bits are dependant on what other bits or data could prove a headache tho. A client would be wise to peek root occasionally to make sure nothing is missed.
|
Oh, the way I interpreted your approach was different - that the local server (I need to find a better name for that, I think the name has been putting people off! maybe 'game engine') deals with all the .m/.x stuff, and the client gets and updates _all_ it's data (except maybe things that are completely fixed like star names and positions, rules, and race designs) from that using poke and peek calls as required. That way there doesn't need to be any differentiation (at the client end) between stuff in the .m/.x file and stuff that is calculated. This is also very robust to changes in the .m/.x format.
This makes for a relatively lightweight client, with not much extra code in the server. The cost of this is slightly more communication that I had originally envisaged - possibly as much as Kotk's dreaded xml message every click, but depending on speed, that might not be a problem.
| Quote: |
The difference is for playtesting enemy movements, battles etc, in fact I'd almost include push/pop state commands as well..tho these could be done with clear and pokes.
|
What you are moving towards here is not only a battle simulator but a game simulator - something that could let you simulate a few moves ahead (without giving you any new information such as scouting though). The ultimate in testbedding some rule before you try it
It should be doable, but let's not get too far ahead of ourselves here - a client that can do what the curent one does and has room for future expansion along these lines is a good target.
| Quote: |
hehe I was kidding I don't even support copyrighting.
|
Yes I know you were kidding - I suppose I'm a bit sensitive about this software patent thing - quite part from any ethical issues, I think my livelihood as a software consultant is threatened by them.
Report message to a moderator
|
|
|
|
| Re: A modest proposal to make clients easier |
Sat, 04 February 2006 20:14 |
|
|
|
| Madman wrote on Sun, 05 February 2006 12:24 |
Oh, the way I interpreted your approach was different - that the local server (I need to find a better name for that, I think the name has been putting people off! maybe 'game engine') deals with all the .m/.x stuff, and the client gets and updates _all_ it's data (except maybe things that are completely fixed like star names and positions, rules, and race designs) from that using poke and peek calls as required.
|
The client would probably want to be aware of the different kinds of data tho - data that doesn't change(planet positions? I want a W10 planetary engine!!!), data it can't change(except for testing), data it can change(orders), and data that is calculated.
| Quote: |
That way there doesn't need to be any differentiation (at the client end) between stuff in the .m/.x file and stuff that is calculated. This is also very robust to changes in the .m/.x format.
This makes for a relatively lightweight client, with not much extra code in the server. The cost of this is slightly more communication that I had originally envisaged - possibly as much as Kotk's dreaded xml message every click, but depending on speed, that might not be a problem.
|
Its hardly a heavyweight program so I doubt it will matter.
| Quote: |
What you are moving towards here is not only a battle simulator but a game simulator - something that could let you simulate a few moves ahead (without giving you any new information such as scouting though). The ultimate in testbedding some rule before you try it
It should be doable, but let's not get too far ahead of ourselves here - a client that can do what the curent one does and has room for future expansion along these lines is a good target.
|
I'm worried about getting to far ahead, just preparing the way. Keep it extensible. Have a vision.
Report message to a moderator
|
|
|
| |
| Re: A modest proposal to make clients easier |
Sat, 04 February 2006 22:29 |
|
| Madman |
| Officer Cadet 1st Year |
Messages: 228
Registered: November 2003
Location: New Zealand | |
|
| Kotk wrote on Sun, 05 February 2006 15:10 |
If we look into FSServer code (the C++ thing about what we talk here) then there are ~40 "delete something"s in it. I dont think that it leaks memory ... so where is that huge freeing memory burden? 
Maybe you use "C == C++" logic? Its common error. 
|
OK, in my haste to keep the post abbreviated I did make that error, so I'll expand it a bit more, although giving reasons for language preference is getting wildly offtopic.
In the FSServer, there might only be about 40 deletes, but add in all logic around those, and the destructors: it won't be competely insignificant - and certain types of error would be very hard to track down.
However, quickly comparing the memory deallocation burden in 3 different languages:
C: This is the ~1/3 case. All got to be done manually, and very error prone. Of course that didn't stop anyone using it for a very large compiler (gcc), pretty much ever OS kernel (including Linux), and a desktop (Gnome) ... and pretty much every other piece of core software that runs on Linux (and probably Windows too).
C++: Destructors take care of a lot of it. The burden can also be kept lower by using STL for structures wherever possible (which FSServer does) and smart pointers (which FSSever doesn't). The downside is that there's about 3-4 ways of deallocating memory: delete, delete[], free, and I think another one I can't remember right now. Woe betide you if you use the wrong one (I think I once spent a few days tracking down using a delete when I should have used a delete[]).
Java (and pretty much any other langauge with full garbage collection): No code at all required in the program, you often don't even need to think too much about it. Cost is all at runtime - being a little more memory hungry, possibly getting into trouble if you need to reuse a resource quickly (I've never encountered this problem), and slightly higher CPU use if you are running near the memory limits.
See: http://www.iecc.com/gclist/GC-faq.html for more on why I like garbage collection.
Report message to a moderator
|
|
|
|
| Re: A modest proposal to make clients easier (some results) |
Sun, 05 February 2006 19:05 |
|
| Madman |
| Officer Cadet 1st Year |
Messages: 228
Registered: November 2003
Location: New Zealand | |
|
OK, I implemented a test case - using sockets to send a race query from a java client to the server, and returning the growth rate (I was going to return the RW points, but that doesn't seem to be implemented yet). Messages were passed both ways in XML.
I sent the race query 100,000 times, changing the growth rate at the client each time (so there would be no cheating about having to do the XML conversions each way every time).
Timing results:
Machine was: 1.8 GHz AMD64 running Debian 64 bit Linux with 1GB RAM,
Java version: Blackdown-1.4.2-03, no special settings for running
gcc version 4.0.2: using -02 for compiling
100,000 queries took (drumroll ....) about 48 seconds. That's a little under half a millisecond a query. I'm going to call that speed acceptable 
NOTE: It is _vitally_ important to call setTcpNoDelay(true) on the Java socket - otherwise it takes 0.04 seconds per query (thought I was going to have to eat humble pie for a minute there - 0.04 seconds is too slow!).
At the C++ end, I created a separate routine so I wouldn't need to muddy LEit's code (looks like I could do the whole interface like that if necessary, make it a removable layer), and the Socket classes from: http://www.alhem.net/Sockets/index.html (which is _way_ too heavyweight, I'm open to better suggestions for a multi-platform socket library).
At the Java end, I used the built in sockets, and my own hand-rolled XML classes which I always use (I find the built in DOM stuff cumbersome).
It was all a bit of a hack just to test the idea, but I can clean it up a little and send it to anyone that is interested - I've got no idea how portable the C++ end is to Windows, because I can't test it on that.
Report message to a moderator
|
|
|
| |
| Re: A modest proposal to make clients easier |
Wed, 08 February 2006 12:17 |
|
| Orion |
 | Crewman 2nd Class |
Messages: 15
Registered: November 2005
Location: Strasbourg, France | |
|
Writing a client is a huge amount of work. There is a lot of information to display, and many interactions with the user to create.
So any help in writing a client is welcome. Proposing an easy way to have all computation done by an external module is very good idea. The interface of that module should also be easy, if not, many client writers will prefer to duplicate code. But XML is fine by me, I am not afraid of it.
If there is such a module which makes simple computations, roughly every thing that is needed by a client, including a battle simulator (ok, which is not simple computation), I think that the Server should use the same module, and maybe even the same interface.
Solutions are numerous. Just to give an example, there are scripting languages that can be included in many programming languages. I think that we (we, the FreeStars community) should take the one where most energy is invested, and this is currently the solution suggested by Madman.
I am not concerned with performance, neither time nor size. My experience tells me to bother for this when I encounter a problem. Human instinct is quite bad at predicting where such problems will occur. Let's first create something that is working.
Orion
Report message to a moderator
|
|
|
| | | |
| Re: A modest proposal to make clients easier |
Wed, 08 February 2006 15:04 |
|
|
|
| Quote: |
don't think it would require bug for bug compatibility. The server bugs can be fixed e.g. pop steal, N/S E/W minefields etc.
My thought was that it would be easier to work out the format than write a whole client. I think Wumpus has most of the formst done and I know at least one other person who understands a good portion of the formats.
|
Why not write a converter? Then you can have both.
Convert from old stars to free stars and old client can be used with new server.
Convert from new stars to old and new client can be tested with old server.
The conversion program can sit behind a web server if confidentiallity of the file formats is the issue.
So for example, upload a turn in a similar manner to autohost and out comes the xml translation of that turn.
Or in reverse... get the game files converted to xml, use a new client to create xml turn info, then upload the turn to convert to .x file that would work with current stars.exe and autohost.
For the web server/converter setup, if Ron didn't have time then godaddy.com and similar sites will host php, perl and linux binaries for few dollars a month, many of us could set such up if tool was available. (Ansi c/c++ code can be made in windows then compiled into linux binary)
[Updated on: Wed, 08 February 2006 15:36] Report message to a moderator
|
|
|
|
| Re: A modest proposal to make clients easier |
Wed, 08 February 2006 15:39 |
|
| Madman |
| Officer Cadet 1st Year |
Messages: 228
Registered: November 2003
Location: New Zealand | |
|
| multilis wrote on Thu, 09 February 2006 09:04 |
Why not write a converter? Then you can have both.
|
It may work, since the files in this case are _meant_ to contain the same data, but my past experience is that unless formats are designed with conversion in mind, it can be deceptively hard to get to 100% compatibility.
Also remember that the converter would need to do integrity checking if using the Stars! server with a FreeStars client, as the Stars! server doesn't do that very thoroughly at the moment.
As for hiding the server because of confidentially of formats, that has the somewhat unfortunate effect of not being able to release the source code to the world, so being somewhat of an open source advocate, I would require a lot of convincing to help with this.
If someone wants to do this, well and good (as I've said before, that is the way of volunteer projects), but I think long term that there is better bang for the buck working on client and server for the current XML formats.
I'm also looking ahead to expanding FreeStars after version 1.0 (including a new PRT idea I _really_ want to try!), and trying not to break the conversion stuff could have a limiting effect on this.
The discussion does belong in this thread though - it is _another_ proposal to make clients easier
Report message to a moderator
|
|
|
| |
Goto Forum:
Current Time: Fri May 03 17:19:47 EDT 2024
|
Members
Search
Help
Register
Login
Home
