also see full discussion starting at http://games.groups.yahoo.com/group/stellarcrisisclub/messages/21075
Version 3.0
To: stellarcrisisclub@yahoogroups.com
From: "empire_ah" <no_reply@yahoogroups.com>
Date: Mon, 27 Nov 2006 13:10:18 -0000
Subject: [Stellar Crisis Club] Re: SC v4.0 (was SC PHP 3.0)
Ralof wrote:
> I am going to be a bit brutal here.
No worries. :-)
> I think the Almonaster has the best structure and is the best base
for "SC 4.0".
There is a lot to be said for Almonaster, and one big thing to be
said against it. My understanding is that Almonaster runs it's own
http server, which means it can't be set up using the inexpensive
hosting options available today. I got started with Aleks' PHP/MySQL\\
version just because I could get hosting for it.
> But SC 4.0 must be open source and based on free server software.
> MySQL seems like the obvious choice for the db and the Java/JSP or PHP
> for the rest. To make it possible for several developers to develop it
> more or less independantly (while still cooperating) an object
> oriented structure is necessary. I seem to remember that Almonaster is
> already object based?
Andy's SC 4.0 name tag nay have led people to believe that I am doing
a complete rewrite. Not true. I am taking a copy of the Iceberg code
(a couple year old copy at that) and adding 3.0 ships into it. I
actually started this project a couple years ago (hence the date of\\
the split with Iceberg) but didn't have time to finish it then.
While I agree that an object oriented approach would have advatages,
that's not the way Iceberg was written. Nor is it really necessary.
The UI is handled screen by screen, so people can work simultaneously
on different screens quite easily. The update processing is stickier,
but since most changes from here on will likely be additions to it,
probably not a big problem either.
However, now it is my turn to risk being "a bit brutal". I think if
we try to set this up as a big collaborative project then nothing
will happen. I have some time available to fiddle with the code. I
don't really want to give up the fun of working with the code to be a\\
project manager for this. I do enough project management in "real
life".
I've shared the code with Andy and Greg-- that way we can be sure it
won't just vanish again. I know Andy is going to start looking at it
with an eye to eventually migrating Lug to the PHP version (and
thereby signifcantly reducing his hosting costs). Experience tells me
that two people can work on this code at the same time if they are
careful and communicate well. (Afeter all, Aleks and I did.) I'm not
really up for more chaos than that.
Which doesn't mean that others can't help. I'm enjoying the
discussion here, and the comments will enter my thinking as wwork on
the code. The suggestion has been made by a couple people about
documenting differences between the versions-- that would be
EXTREMELY helpful. People with UI ideas could do some mock-ups/
samples to review and comment on. And I can see some other projects--
one of which I'll probably throw up here soon.
And, oh yeah, SC desperately needs a comprehensive FAQ/instruction
update- any takers?
> The two paths can be proceeded independantly of eachother by different
> people. Maybe it would be good to split those discussions already at
> this stage?
> Three threads:
> SC 4.0 Programming
> SC 4.0 Gameplay
> SC 4.0 General (for those subjects that can comfortably be put in one
>of the other two)
This is where bulletin board systems have it all over Yahoo Groups.
I've thought about setting one up, but haven't really wanted to
fracture the discussion. (We already have half of this conversation
going on in Misery Loves Company 1.) Perhaps we could set one up that
automatically copied digests of the postings into the SC Room?
-Ah
Andy,
After reading 4d. and the "note 4" below I thought there was a
good chance that an empire that was being being nuked would not have
his ship-orders for nuking carried out (just as engineer orders,
etc. are not carried out). Wishful thinking I guess: I just traded
my colony for Lafrog's HW in Doom's RX 39 (you had a ship there,
btw).
An inconsistency, it seems, with respect to orders being carried
out. I'm not concerned about that but wonder if that would always
happen or if, in some cases, the empire is nuked out and his ships
won't nuke an opponents sys.
>--- In stellarcrisisclub@yahoogroups.com, empire_ah <no_reply@> wrote:
> I just want to verify the correct processing sequence during an
> update in 3.0.
-- In stellarcrisisclub@yahoogroups.com, lugdunum_sc <no_reply@...> wrote:
Brad, the only thing you had missed out was annihilation (what
doomsdays doom), which comes between nuking and invading.
It's a little bit more complex than just doing the list of things in
order, though.
1) for each empire
1.a) add tech-devel to tech
1.b) update diplomatic status with each other empire
1.c) for each planet belonging to this empire
1.c.1) multiply population by ag_ratio (and fix up) (Note 1)
1.d) for each ship belonging to this empire
1.d.1) multiply ship's BR by maint_ratio (and fix up) (Note 2)
1.d.2) process build/dismantle, cloak/uncloak, morph and movement orders
1.d.3) record, but do not yet process, the special actions ordered for
this ship (Note 3)
2) combat (a research paper in itself)
3) minefields (explode or get swept)
4) process the recorded special actions of any ships that survived
combat and mine explosion
4.a) planet building
4.b) stargating
4.c) jumpgating
4.d) nuking (Note 4)
4.e) annihilation (Note 4)
4.f) invasion (Note 4)
4.g) colonization
4.h) terraforming
4.i) engineering (closing then opening)
5) for each empire, check for other forms of death
5.a) ruins
5.b) surrenders
5.c) calculate new ratios (maint, fuel, ag, tech_devel) to be used
next update.
Notes:
1) The actual calculation is:
pop = (int) ((float) pop * ag_ratio)+1;
if (pop > max_pop) pop = max_pop;
if (pop < 1) pop = 1;
This is what Brad said when correcting me, after I'd suggested a
ceil() function was used. It doesn't actually use floor(), but the
effect is the same.
2) The calculation is:
br = br * maint_ratio;
if (br > max_br) br = max_br;
The maint_ratio used here has not yet been recalculated to incorporate
the effect of the population change at 1.c.1. So Damascus is right, in
effect, and I think it would be OK to move the population change step
to after combat. I think it shouldn't be after minefield explosion,
though, as it's the new population, not the old, that gets halved when
the mine goes off.
3) Recording the special actions includes recording *where* they were
set. Although the ship can't order a move in the same turn that it
orders a special action, it can be moved by a gate, so it's important
to have the location of the action at hand when the action is
processed, not just the location of the ship.
This explains Greg's comment, that he thought engineering was
processed before gating. The engineering action takes place at the
original location of the ship, even though the gating action has
already happened. I'm not sure whether that means the effect would be
the same if the gating actions were moved down the order to after
engineering.
4) The nuking, annihilation and invasion steps include the code that
tests to see if the target planet was a homeworld, and if so, clears
away the dead empire's ships. Therefore, if your colonies,
terraformers or engineers are set to act on the turn you are nuked,
annihilated or invaded out of the game, those actions won't happen. If
they are so set on the turn you surrender (ruin doesn't apply, I
think), they *will* happen - if the relevent ships survive combat. Of
course, that doesn't affect you much, but it might affect remaining
players. You might prevent someone else from colonizing that turn, you
might leave a sweetly terraformed planet ready for the next person to
colonize it, and you certainly might open or close a jump in the turn
that you surrender. However, you can't prevent the nuke action by
surrendering.
Hope this helps,
Andy
One "feature" that comes to mind that v3 has and SC PHP doesn't is
what I called "Cluster-Balanced" map generation. It wasn't a very good
name but I couldn't think of anything better.
I know the PHP version has balanced maps, but they work differently.
Brad and I both worked on the problem at the same time, almost
independently, and came up with totally different solutions.
One or two people have complained that they've had horribly unbalanced
maps from my method. But my experience with it is that it's mostly
quite good, might be better with some tweaking, and immensely better
than random generation for bigger grudges. Amanda's Revenge was
unplayable before (IMO) but now it's usually pretty fair.
I'm not sure how Brad's "Balanced" method works, but I don't think it
takes into account planet resources or planet clustering at the
border, as mine does. I also don't know if it applies only to grudges
or to multi-player maps as well.
Should we try to keep both options? Does anyone have an opinion about
how successful the two approaches are, whether the results are
different enough to warrant keeping both, etc.
I've heard it said that Kefka won't play at Lug *at all* now, because
he once felt cheated by a map that claimed to be Cluster-Balanced. I
hope it isn't true. It seems like a bit of an over-reaction if it is.
Are there ever any complaints about SC PHP's Balanced maps?
Andy
