Madman wrote on Mon, 23 January 2006 03:02

Eye candy is fine, as long as it doesn't get in the way of usability.

Why to argue about how cool the current interface is. When i saw stars demo first ... was it 1993? I remember fuel was 4th mineral to mine ... i was very amazed what a nice game can be made under Windows. Now its getting somewhat old. Plain eye candy is just the simplest way to burn processor power and i think it often annoys. I wasnot talking about such.

Refreshing trick that may make UI useful and cool to look at is to have some adjustable halfdecent advisors, tools like battle simulator, hints and animated/colored analyse screens (Xtreme Borders +). 16 colors? It is 2 decades old style. Like LEit already said it is probably most accurate and simple to use turn generator code for most of such things and calculations.

Python is OK for simple tools. It is easy to let some macro scripting. Let players to script things and extend the client sounds cool at first. OTOH ... forcing players to program on case they want to win is questionable way to go. If UI is made such that winning depends on "who scripts better?" question then it may cut player base down fast. Freestars is open source, UI-s may be more than one and there will be probably scriptable UI anyway. In order to pare its hypotetic wings the C++ UI must be cooler.

AI support with intuitive interface (lets say for example that it can do most pop and mineral management at intermediate level) on other hand makes stars lot better game. Stars is a complex problem, dunno if python is fine enough. For example huge is 2000x2000 board and the player who competes about victory usually got similar amount of planets like chess game got squares, nothing to talk of minefields, fleets or even ships.

[Updated on: Sun, 22 January 2006 22:42]

Report message to a moderator

Kotk wrote on Mon, 23 January 2006 16:39

Refreshing trick that may make UI useful and cool to look at is to have some adjustable halfdecent advisors, tools like battle simulator, hints and animated/colored analyse screens (Xtreme Borders +). 16 colors? It is 2 decades old style.

Yes, certainly there can be lots of things that can be improved - one of my thoughts was also to put all the Xtreme Borders stuff and more in the client.

Quote:

Python is OK for simple tools. It is easy to let some macro scripting. Let players to script things and extend the client sounds cool at first. OTOH ... forcing players to program on case they want to win is questionable way to go. If UI is made such that winning depends on "who scripts better?" question then it may cut player base down fast. Freestars is open source, UI-s may be more than one and there will be probably scriptable UI anyway. In order to pare its hypotetic wings the C++ UI must be cooler.

Well, you can't stop people either scripting or enhancing with open source tools - I know that if I'm ever involved in such a game with an open source client, I'll start making 'improvements' to reduce MM, like for instance dynamically tweaking the factories/mines/terraforming queue on each planet each turn to maximize overall resources. It's nothing that couldn't be done (painfully) by hand, but it sure is faster to have a program to do it. Unless the client is written in Perl (I am joking here ) which I regard as a write-only language.

I also agree that C++ is the best option for a client, simply on the basis that shared code would prevent odd cases of the client and the server reporting different numbers. If I was starting Freestars from scratch, my choice would probably be Java, but best use what we already have

Report message to a moderator

If I write a client, I will probably write it in Python, simply because I've been looking at Python for a while and wanting to write something cool for it. Part of the code, like the elements you mentioned, would probably be ported directly from the server code, but I think the time savings from using the higher-level language for the rest of it would balance the time lost porting the existing code to Python.

I think PYthon scripting of in-game mechanics is to be avoided - even simple scripting would push the game too far in the "Stars is a programming contest" direction. I was thinking automation would be built into the client - I particularly liked the idea of advisors which can do simple MM for developing colonies. I was thinking things along the lines of "auto build ships" for the production queue, "Find best planet not targeted by a colonizer" for colonizers, etc.

One very important thing to keep in mind, IMHO, is to get it functional *first*, and add features later. I believe the future of Stars lies in FreeStars (especially if Empire has indeed stopped selling the game) and the sooner a working version is released, the more people can be preserved in the community.

Report message to a moderator

Madman wrote on Mon, 23 January 2006 07:35

Well, you can't stop people either scripting or enhancing with open source tools - I know that if I'm ever involved in such a game with an open source client, I'll start making 'improvements' to reduce MM, like for instance dynamically tweaking the factories/mines/terraforming queue on each planet each turn to maximize overall resources. It's nothing that couldn't be done (painfully) by hand, but it sure is faster to have a program to do it.

Sure. Major target audience however are the non-programmers. They just want to play a game and have fun. Explore, expand and what there was... in sci fi style and NOT painfully. TBS got its forgotten plusses it gives time to think, negotiate and roleplay. No reflexes needed. We got to avoid: reproducing them skeleton UI in a 2 decades old 16 color graph + spreadsheets fashion extending it with sophisticated possibilities to script the details and leave painful loads of unassisted MM in. It will probably not attract much players and we simply waste our efforts if we emphasise on developing such thing.

crr65536 wrote on Mon, 23 January 2006 08:40

I think PYthon scripting of in-game mechanics is to be avoided - even simple scripting would push the game too far in the "Stars is a programming contest" direction.

Like Madman said you got no way to stop it. Python program is a text file, open source too so anyone can edit it and you cannot avoid them to script it whatever you do. Only way is to provide good enough assistants so its competive without need to script.

[Updated on: Mon, 23 January 2006 03:28]

Report message to a moderator

crr65536 wrote on Mon, 23 January 2006 19:40

If I write a client, I will probably write it in Python, simply because I've been looking at Python for a while and wanting to write something cool for it. Part of the code, like the elements you mentioned, would probably be ported directly from the server code, but I think the time savings from using the higher-level language for the rest of it would balance the time lost porting the existing code to Python.

If it was just the porting time, I'd agree with you (and I'd be off writing a Java client). There's also correctness and maintainability though. You really don't want to have the client say there is enough fuel for a trip and the server say no, or have a client say 2 years for a trip when the server says 3 (this sometimes happens in Stars! btw). And you'd better be prepared to _exactly_ track any changes or bug-fixes that get made to the server.

On the other hand, having a client is better than not having a client, and if you could get something usable out quickly, then good luck to you. Open source works by people doing the things they are interested in. I'd regard something like that as something interim until there is a C++ client though.

crr65536 wrote on Mon, 23 January 2006 19:40

One very important thing to keep in mind, IMHO, is to get it functional *first*, and add features later. I believe the future of Stars lies in FreeStars (especially if Empire has indeed stopped selling the game) and the sooner a working version is released, the more people can be preserved in the community.

Agree completely, even if we have to cut the odd corner to get there (as long as we _know_ which coners we cut so we can get back to them).

Kotk wrote on Mon, 23 January 2006 21:20

crr65536 wrote on Mon, 23 January 2006 08:40 I think PYthon scripting of in-game mechanics is to be avoided - even simple scripting would push the game too far in the "Stars is a programming contest" direction. Like Madman said you got no way to stop it. Python program is a text file, open source too so anyone can edit it and you cannot avoid them to script it whatever you do. Only way is to provide good enough assistants so its competive without need to script.

Well, the fair way is for those of us who can write scripts like that to contribute them back so anyone can use them ... they might eventually become part of the advisers, and if they get powerful enough, could be of some use in creating an AI. It might change the game a but if _everyone_ is optimizing their planet queues, or only loading freighters up enough that they can make the trip back without cargo, but losing MM is a good thing IMO - it might even make the game more accessible for the non number-crunchers.

A fun (but side) project would be to create an AI that duplicates my play-style (without the mistakes) as much as possible.

Another idea I've had is to create a strategy game that _encourages_ script writing, even to the point of having the game engine run some of the scripts. That is a completely different project than Freestars though.

Now back to the real world ...

Report message to a moderator

Report message to a moderator

Report message to a moderator

Madman wrote on Tue, 24 January 2006 00:42

I suppose one solution would be to have a copy of the server locally, and feed it some sort of XML message (this would require extra code in the server to handle client queries and probably a socket interface, such as "what is the fuel use for this fleet with this race and this cargo to go between these two points?", or (for the battle simulator) "given these two sides of ships, return the result of a battle") and look at the responses, but unless done very carefully, that would be _s_l_o_w_.

Now I've written it down, I actually like that idea in some ways ... if we really want lots of different clients, this makes kind of a perverse sense, as a copy of the server still gets to handle the game logic.

I'll now go and put a kevlar helmet on for when _other_ people want to beat me around the head

[Updated on: Mon, 23 January 2006 06:49]

Report message to a moderator

Report message to a moderator

Report message to a moderator

Report message to a moderator