Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Stars Supernova Genesis Beta

802 views
Skip to first unread message

jox...@gmail.com

unread,
Aug 2, 2005, 3:20:39 PM8/2/05
to
Was anyone here a beta tester for Stars Supernova Genesis? Is the beta
version available anywhere, or would anyone be willing to make it
available? :) :)

antar...@tlen.pl

unread,
Aug 4, 2005, 3:02:15 AM8/4/05
to
You can ask on:
http://starsautohost.org/sahforum/
I think that you will have more chance to find it...
I'm interessing too ;)

Antares

antar...@tlen.pl

unread,
Aug 4, 2005, 3:01:59 AM8/4/05
to

Russ Lewis

unread,
Aug 4, 2005, 1:51:30 PM8/4/05
to

I was a beta tester, but they made me sign a Non-Disclosure Agreement
about it. :(

jox...@gmail.com

unread,
Aug 5, 2005, 10:21:35 AM8/5/05
to

Russ Lewis wrote:

> I was a beta tester, but they made me sign a Non-Disclosure Agreement
> about it. :(

lol...o well. At least you can share your unique experiences with us...

What was the beta like? was it fully playable?

swp

unread,
Aug 5, 2005, 11:35:09 AM8/5/05
to
with whom did you sign the agreement? are they still in business? is
the agreement still valid? was there a time restriction on it?

is the beta release playable? are there any major flaws? minor flaws?
do errors ever appear on the screen?

does the Claim Adjuster PRT still have to be banned? Is everyone now
an equal "resource monster" with the automated features built into the
game?

does anyone care?

swp

Russ Lewis

unread,
Aug 5, 2005, 1:16:33 PM8/5/05
to
swp wrote:
> with whom did you sign the agreement? are they still in business? is
> the agreement still valid? was there a time restriction on it?

Frankly, I don't know if it is still valid, but I figure that I need to
be conservative.

I would gladly share my experiences, if I could. So, unfortunately, I
won't be able to say anything more.

Aldaron

unread,
Aug 9, 2005, 8:17:22 PM8/9/05
to

Depending on how the NDA is worded it could have an indefinite time period

Time Periods

Some agreements require that the receiving party maintain the secret
information for a limited period of years, including language such as
"the receiving party shall not use or disclose the secret for a period
of five years from the date of execution of the agreement." You can
often negotiate the time period. Disclosing parties want an open period
with no limits; receiving parties usually want a short period. Five
years is a common length in American nondisclosure agreements, although
many companies insist on only two or three years. In European
nondisclosure agreements, it is not unusual for the period to be as long
as ten years. Ultimately, the length you decide to use will depend on
the relative bargaining power of the parties.

Nats

unread,
Aug 12, 2005, 2:23:26 PM8/12/05
to
But does a non disclosure agreement still have legal redress when a firm
isnt in existence any more. And surely even if it did theres nothing wrong
with some modders getting together and creating the game themselves as long
as its not for profit.

Nats

"Russ Lewis" <spamhole-...@deming-os.org> wrote in message
news:CAsIe.12$do2...@news.uswest.net...

Nats

unread,
Aug 12, 2005, 2:28:55 PM8/12/05
to
Yeah but you have to look at the redress that the injured party would seek
to get due to damages. I mean firstly there must have been some damage
cuased by the disclosure and secondly they must be able to determine who
actually did the disclosing. Therefore is the beta was disclosed on the web
in secrecy and the disclosure didnt do any damage then the authors of the
game will not have any redress.

I must admit I dont know the ins and outs of the contract myself but I cant
see any reason for any beta tester not being able to disclose the source
code for modders to work on as long as noone is named. And once the source
code is out there its fair game for the modders IMO!! :-)

If the original developers had any plans for the code it would have been
done by now. Its obviously a dead parrot.

Nats

"Aldaron" <ald...@charter.net> wrote in message
news:VIbKe.4804$0E5....@fe05.lga...

Piratelord

unread,
Aug 14, 2005, 6:21:09 AM8/14/05
to
Could whatever artwork produced Genesis be used by other people for not for
profit projects?

"Nats" <nst...@nstutt.freeserve.co.uk> wrote in message
news:ddiper$c66$1...@news8.svr.pol.co.uk...

Timothy Little

unread,
Aug 14, 2005, 6:30:37 PM8/14/05
to
Piratelord wrote:
> Could whatever artwork produced Genesis be used by other people for
> not for profit projects?

After you contact the copyright holder(s) and obtain explicit
permission to do so, sure!

Without getting explicit permission, it can be used by anyone who
accepts the risk of an expensive lawsuit being brought against them.
Non-profit use may reduce the potential damages you pay for
infringement compared with commercial use, but is not a defense.


- Tim

RJLadd

unread,
Aug 26, 2005, 8:18:25 PM8/26/05
to
On Tue, 09 Aug 2005 19:17:22 -0500, Aldaron <ald...@charter.net>
wrote:

>> I would gladly share my experiences, if I could. So, unfortunately, I
>> won't be able to say anything more.

Mare Crisium still exists.. But as one of the developers of SN, I'm
quite certain that Jeff would not prosecute anyone for breaking the
Supernova NDA at this point, at least as long as nobody posts slander,

Its been quite a while; it seems reasonable that the story can and
should get told. The short version is that Empire (the publisher)
refocused their attention on other kinds of games, and lost interest
in Supernova. The relationship between Mare Crisium and Empire had
always been somewhat rocky, for a number of reasons.

Empire owned (and still owns) the artwork for SN. Mare Crisium and
Novelty Hill Software (i.e. me) co-own the code. Too much of the code
was specific to the artwork for us to finish the game without Empire,
and they of course could not (and weren't interested in) writing new
code for the art.

Work on the code continued for a while, but after a few months was
shut down for lack of development money. Empire had provided part of
the funding; Jeff and I provided the rest.

We tried hard for about a year to find a new publisher. Many
conversations; some looked promising, but the tech meltdown hurt a
lot. Any new partner/publisher would've had to negotiate with Empire
for the artwork, and Empire wasn't very interested.

We continued having sporadic conversations with possible publishers
after that, but it would have been hard to restart the project. All of
the SN team had needed to find other work, although at least some
would have come back if the project had gotten going again.

At one point, I think it was in 2003 (2002?), Jeff and I started work
on a 32 bit update to the original Stars. The original code base,
though, is VERY Win16 specific, so the project morphed into a largely
redesigned game. The game engine architecture was superior even to
Supernova (we had learned a few things along the way), but the
graphics were to be just a bit better than the original Stars.
Unfortunately, real life got in the way. Both Jeff and I needed to
recover from the financial loss of SN, and as other opportunities came
along, we didn't have time to puruse the new, speculative, development
effort.

That's where things stand today. Jeff is still working at Mare Crisium
on other projects. I'm currently a Principal Firmware Engineer at an
embedded systems company in the Seattle area. The other former
Supernova people are mostly still in the Portland, OR, area, doing
various other things.

If Empire still even remembers that they own the SN artwork, I'd guess
that it could be purchased from them today very cheaply. Jeff and I
both still have copies of it, and the entire SN source code, but no
work has being done on it for quite a while.

In my Copious Free Time(tm), I'm still working on the "Stars 3" that
Jeff and I started after Supernova. Its very slow going, though, since
my day job takes most of my time. No idea if or when I'll ever be able
to finish it.


Jim Lane

(The return address on this post is not valid. Use the name of SN game
spelled out (just the first two words; don't include "genesis"), at
the name of my company (all three words, with no spaces or other
punctuation), dot the-short-version-of-"commercial".)

Piratelord

unread,
Aug 27, 2005, 8:47:24 AM8/27/05
to
Shame to hear all that.

I took part in the testing of the 32bit stars! rewrite but then it just sort
of died.

I'm sure that there would be massive support for some updated form of Stars!
and people would by it. You still get people buying serial numbers for the
original Stars! and there are many clones being worked on out there.

Personally, I think Stars! 3 would be good enough for everyone so that more
designs for ships are available.
I've written two very well known (I think) programs for Stars! and if Stars!
3 could have these features too (plus features from other software out
there), it would be amazing.

SN had many amazing new features, but minor improvements to the base Stars!
code would be great. I'd like to see a bigger Battleboard, more flexable
ship designs and improved graphics. No interested in seeing planets that
reflect the current hab/terraform values, that's just nice eye candy.

Pirate Lord
www.piratesretreat.btinternet.co.uk

"RJLadd" <nos...@mouse-potato.com> wrote in message
news:ccavg1tk1tqhm8utg...@4ax.com...

Dirk Thierbach

unread,
Aug 27, 2005, 1:32:44 PM8/27/05
to
RJLadd <nos...@mouse-potato.com> wrote:

Thanks a lot for sharing all those information.

> Empire owned (and still owns) the artwork for SN. Mare Crisium and
> Novelty Hill Software (i.e. me) co-own the code. Too much of the code
> was specific to the artwork for us to finish the game without Empire,
> and they of course could not (and weren't interested in) writing new
> code for the art.

Just out of curiosity: Would it be possible to use the code with
some sort of schematic substitute for the images? Eye candy is nice,
but personally for me not necessary, and I would be happy to play
SN without eye candy. You probably wouldn't be able to sell the
game to a wide audience, but at least that would be better than
no SN at all. And if SN gets played even in this crippled for by
people, you'd have a strong argument to convince a publisher -- if
you're still interested.

Next question, also out of curiosity: Since you and Mare Crisium co-own
the code, would it be possible to open source it? I can understand
if you don't like to, but again, an unfinished open source code would
be better than no game at all. Of course, this option will stop any
chance to ever make any profit from it, so it's probably not something
that would be easy for you.

> If Empire still even remembers that they own the SN artwork, I'd guess
> that it could be purchased from them today very cheaply.

Did anybody try? What amount of money would "very cheaply" translate
to, roughly, in your estimation?

- Dirk

RJLadd

unread,
Aug 28, 2005, 6:00:22 PM8/28/05
to
On Sat, 27 Aug 2005 19:32:44 +0200, Dirk Thierbach
<dthie...@usenet.arcornews.de> wrote:

>Just out of curiosity: Would it be possible to use the code with
>some sort of schematic substitute for the images? Eye candy is nice,
>but personally for me not necessary, and I would be happy to play
>SN without eye candy.

Personally, I agree about eye candy. I originally got into Stars! 2
for the gameplay, not the graphics. :-) But publishers are very keen
on eye candy, so much so that the graphics and UI are usually the
first things to be developed, well before the game engine and
gameplay. Since Jeff McBride originated the project, gameplay was
important right from the beginning, but even Jeff had to go along with
Empire to some extent. Thus, the code related to eye candy and UI is
very nearly finished, but the gameplay related code needs more work.

>And if SN gets played even in this crippled for by
>people, you'd have a strong argument to convince a publisher -- if
>you're still interested.

The market for indie games has gotten much worse since the SN project
ended. It would be nice to find a publisher, but it isn't realistic to
think that its possible. Jeff and I were planning to go back to
Stars!' roots and self-publish Stars! 3 via a web site.

>Next question, also out of curiosity: Since you and Mare Crisium co-own
>the code, would it be possible to open source it? I can understand
>if you don't like to, but again, an unfinished open source code would
>be better than no game at all.

Possible? Sure. Not likely, though. A large fraction of the code is
specific to the particular graphics that were done. Either all of that
code would have to be rewritten, or new grahics would have to be
created to match. Both would be hard. Also, Jeff and I each invested
quite a bit of money into the project. Speaking for myself, although I
realize that not releasing it at all means not recovering any of that
investment, I would still be reluctant to give it away.

>Of course, this option will stop any
>chance to ever make any profit from it, so it's probably not something
>that would be easy for you.

We never expected to make a large profit, but we did at least hope to
recover our investment.

>> If Empire still even remembers that they own the SN artwork, I'd guess
>> that it could be purchased from them today very cheaply.
>Did anybody try? What amount of money would "very cheaply" translate
>to, roughly, in your estimation?

Your guess is just as good as mine. Empire's investment in the artwork
was mid-six-figures. Obviously they, too, have little chance to recoup
any of that. Being a busness, and considering that their investment
was a smaller matter to them than ours was to us, they probably have a
more pragmatic attitude about it. Given the relationship betten some
of the key MC and Empire people, I doubt if Jeff could approach them
even now, but a third party might be able to pick up the artwork for
pennies on the dollar at this point.

Of course, there's still several months work to be done on the code,
and neither Jeff nor I is in a position to guarentee to be able to
finish the work in any practical amount of time.

During the year or two after the break with Empire, there were a few
conversations with potential angel investors who considered trying to
buy the art and funding finishing the code. Obviously none of those
conversations worked out.

I suppose it might be possible to come up with some kind of deal,
either to fund having us finish the project, or to buy out our rights
to the code, but I haven't given any thought to it for quite a while.
Personally, I'm more interested in Stars! 3, although I don't know
if/when it might ever be finished, either. Not soon, anyway.


Jim Lane

Nats

unread,
Aug 28, 2005, 7:00:39 PM8/28/05
to
"RJLadd" <nos...@mouse-potato.com> wrote in message
news:ccavg1tk1tqhm8utg...@4ax.com...
> On Tue, 09 Aug 2005 19:17:22 -0500, Aldaron <ald...@charter.net>
> wrote:
>
> Mare Crisium still exists.. But as one of the developers of SN, I'm
> quite certain that Jeff would not prosecute anyone for breaking the
> Supernova NDA at this point, at least as long as nobody posts slander,
>
> In my Copious Free Time(tm), I'm still working on the "Stars 3" that
> Jeff and I started after Supernova. Its very slow going, though, since
> my day job takes most of my time. No idea if or when I'll ever be able
> to finish it.
>
>
> Jim Lane

Thats was very interesting reading. I would say then that the easy part ie
the graphics are the things that are mainly missing from the SN game if they
are owned by Empire. Im sure there would be loads of people who would be
willing to put in time to get new graphics done. If the two main developers
could actually agree to arrange a select group of interested talented
modders to finish off the game Im sure the game could be finished quite
easily with a possible commercial result at the end for all involved.

You've just got to look at Falcon 4 Allied Force and the Rome Total War
Realism Mod to see what a talented modding fraternity can quickly do with a
game.

Nats


Morten Lassen

unread,
Aug 29, 2005, 4:12:30 AM8/29/05
to
Very interesting reading.

I hope somthing good happens some day :)

/Morten


Russ Lewis

unread,
Aug 29, 2005, 12:56:19 PM8/29/05
to
RJLadd wrote:
>>Next question, also out of curiosity: Since you and Mare Crisium co-own
>>the code, would it be possible to open source it? I can understand
>>if you don't like to, but again, an unfinished open source code would
>>be better than no game at all.
>
> Possible? Sure. Not likely, though. A large fraction of the code is
> specific to the particular graphics that were done. Either all of that
> code would have to be rewritten, or new grahics would have to be
> created to match. Both would be hard. Also, Jeff and I each invested
> quite a bit of money into the project. Speaking for myself, although I
> realize that not releasing it at all means not recovering any of that
> investment, I would still be reluctant to give it away.

How about a ransom? Perhaps you and Jeff could work out some dollar
amount that you would consider a reasonable recouping of your losses (or
part of them); then you set up a Paypal account with the note "We'll
open source the code when the total reaches X."

The RDL would be worth a significant ransom, all by itself. And the
battle model was quite nice, as well.

Patrick Holthuizen

unread,
Aug 29, 2005, 5:01:12 PM8/29/05
to
Dear Jim,

It has been a long for this news to come. Thanks for sharing the
story!!! Oh oh my hopes are up again... ;-)

Gandalf Parker

unread,
Aug 29, 2005, 6:03:28 PM8/29/05
to
RJLadd <nos...@mouse-potato.com> wrote in
news:v7b4h1966bd2o6h19...@4ax.com:

> The market for indie games has gotten much worse since the SN project
> ended. It would be nice to find a publisher, but it isn't realistic to
> think that its possible. Jeff and I were planning to go back to
> Stars!' roots and self-publish Stars! 3 via a web site.

Please look into Shrapnel Games. I no longer work for them.

Its a publisher started by a strategy game programmer who didnt like the
choices out there. So instead of boxed shelfware and lots of money in
marketing, they love indie programmers and do web-site sales with lots of
publicity.

The publishers they have now seem very happy with their support and the
only ones Ive seen leave were ones willing to put up with long waits for
profits trying the shelfware thing.

www.shrapnelgames.com

Gandalf Parker

RJLadd

unread,
Aug 29, 2005, 11:05:45 PM8/29/05
to
SN had a full-time art director. Trying to replace all of that art
(there's a LOT of artwork) and make it all fit the requirements of the
code would be a very large job. Even assuming that all of the itself
art was free, someone would need to put a many months to coordinate
the effort. I don't think that anyone who was not directly involved
(or who has not worked on another AAA game title) can really
appreciate the scale of the effort.

Then there's the question of compensation for the artists. If Jeff and
I were to earn money from a completed SN, artists might reasonably
feel that it was unfair for them not to earn something, too. But that
would be another complicated issue to deal with.

Then there's the fact that Jeff and I are both very busy, and could
not commit to any particular schedule, or even to finishing at all,
would could also lead to hard feelings from artists who did work which
might be delayed for a long time, and might never be published at all.

Ideas like these was discussed after Empire bailed, but Jeff and I
have seen too many well-intentioned pro-am efforts turn into major
disasters. A disaster would not be a certainty, but its a big risk.
After the risk that was taken (and lost) over SN, another risk seemed
to be too much.

Better to start over. Stars! 2 was done by two people (Jeff and Jeff),
working part time. The original concept for a sequel was relatively
modest, but Empire persuaded Jeff to aim for a triple-A title. Going
back to the original concept of a smaller, simpler (than SN) game that
can be done part time seems like a better idea. If/when it is finished
(don't hold your breath; my progress has been pretty slow, given that
I have a more-than-fulltime day job), there could be opportunities to
add the fancy stuff later.

As for modding communities...yes, we were well aware of them. A great
many SN modders would likely have come up with things that we had
already considered, tried, and discarded, but there's no question that
some fraction of a SN modding community would have developed ideas
superior to anything we had time for. That was the major purpose of
the RDL - to allow modders to invent new game ideas that we would not
think of during the course of the project. There was quite a bit of
flexibility in certain parts of the artwork, too; things like race
portraits and emblems could be replaced by players. The UI specific
art is different, though. Much of it is very tightly tied to the UI
code, and vice versa. Jeff created a fairly unique UI paradigm for SN
that imposed very strict requirements on the UI related artwork.

Perhaps its just because I'm a software engineer, not an artist, but I
think a better route is a better-than-SN game engine, even with
inferior-to-SN graphics. User replaceable skins within the framework
of a comparitively simple UI would not be too hard, though.

But the appeal of Stars! to the long time players seems to have been
much more the gameplay than the (complete lack of) eye candy.

Jim Lane

RJLadd

unread,
Aug 29, 2005, 11:36:10 PM8/29/05
to
Re "ransom": Its a nice idea in theory, but it would be a nightmare in
practice. Not to mention that SN is a large body of code, so some
group of people would end up co-owing a unfinished work that would
take two or three (at least) professional software engineers a few
months to finish. I have a compiler background. (At one point, in the
early 1990s, I worked on a port of MS' Visual C/C++ for the DEC Alpha
chip, and I've worked on a number of other compiler projects.) The
technology used in the RDL is pretty simple by commercial compiler
standards, but it would probably take someone with a Master's in CS or
equivalent experience to work on it. People would feel they'd been
ripped off when they realised that they'd put up money for something
that needed significant work by experienced engineers to complete.

Sure, there are some very talented engineers in open source, and some
of them may be willing. But in practice, it might be easier and better
for any such group of people to start from scratch with their own
ideas, rather than trying to finish ours. There have been a few open
source attempts to write a Stars-like 4x game, but AFAIK none of them
have (yet) gotten very far.

Writing a 4x game is a major commitment of time. Few people are likely
to be able to afford to donate that much effort for free, Landlords
and mortgage bankers don't generally accept open source fame for rent
(although if you find one who does, let me know :-)

---

The RDL was a somewhat late addition to the SN game engine, and never
quite fit as well as it could have. The newer Stars 3 game engine
concept is built around an "RDL 2" from the ground up. Stars 3,
if/when (emphasis on "if", please), has a less ambitious scope than
SN, but is more extensible.

Jeff and Jeff and I (and Jeff...the inside joke was that your first
initial had to be "J" to work on SN, and the various Jeffs weren't
always too sure about letting in a "Jim" :-) are not the only people
who can write a sequel-in-spirit to Stars! 2. I happen to think that
Jeff and I have a deep understanding of how to do a good 4x game, but
since SN didn't ship, I could be wrong. Perhaps we would have blown
it. A number of people have tried to produce 4x games; some have
succeeded brilliantly, others haven't. And some that released very
fine games later did less fine sequels. There's no proof where Jeff
and I, et al, would have ended up on that scale.


Jim Lane

RJLadd

unread,
Aug 29, 2005, 11:38:40 PM8/29/05
to
I've bookmarked them. If/when there is a Stars sequel, and if they
still exist in that far off time, I'll talk to them.


Thanks,
Jim Lane

send_an...@hotmail.com

unread,
Aug 30, 2005, 10:46:55 AM8/30/05
to
Hi,

RJLadd wrote:
>
> Mare Crisium still exists.. But as one of the developers of SN, I'm

<snip>

> Empire owned (and still owns) the artwork for SN. Mare Crisium and
> Novelty Hill Software (i.e. me) co-own the code. Too much of the code

<snip>

> At one point, I think it was in 2003 (2002?), Jeff and I started work
> on a 32 bit update to the original Stars. The original code base,
> though, is VERY Win16 specific, so the project morphed into a largely

What about the code for Stars 2.6 itself? There's a handful of
well-known bugs/nuisances that look as they could be easily
patched/overcome. Is there anyone who could do it?

Thanks & good luck!

Gandalf Parker

unread,
Aug 30, 2005, 11:52:00 AM8/30/05
to
RJLadd <nos...@mouse-potato.com> wrote in
news:tgh7h1plmce68p5sk...@4ax.com:

> SN had a full-time art director. Trying to replace all of that art
> (there's a LOT of artwork) and make it all fit the requirements of the
> code would be a very large job.

Just a thought...

Space Empires IV has had a long and fruitful run. Still going also. What
I find amazing is that now when I look at what is on the disc it seems
like a demo. It came with 8 races and a small galactic map. But it was
majorly setup for modding. The player went nuts on it. Now my copy has
over 300 races available, 10 times as large a galactic map with many more
randoms, more techs, more ships, better AI, etc etc etc. Like I said, the
original looks like a demo.

Anyway, with a good game base and as much of the game as possible in bmp
or txt files and a mindset to allow the game to read in 100 times more
files than you ever think it will need, you might be surprised.
Just a thought

Oh and you can get on board with Shrapnel while in the development stage.
They can be quite helpful. Their community has artists and writers and
dedicated beta testers etc etc

Gandalf Parker

Nats

unread,
Aug 30, 2005, 5:05:44 PM8/30/05
to
Yeah surely at this point with such an old game the original Stars code
could be released to the community to work up couldnt it? It would keep the
fans happy, get more interested in your game franchise (possibly!) which at
the moment is dying a slow death and enable modders to upgrade the graphics
and resolution of the game. That would satisfy most of us in the short term!
And it may just turn into a full blown sequel in the future just like Falcon
4. You never know how these things can take off.

At the moment the Stars! game's going nowhere, the community is drifting
away and all it will probably take will be a great new 4x game to lose the
fans entirely. Arent you interested in your game's future?

Nats

<send_an...@hotmail.com> wrote in message
news:1125413215.4...@o13g2000cwo.googlegroups.com...

RJLadd

unread,
Aug 30, 2005, 11:01:50 PM8/30/05
to
I have an ownership stake in the SN code, but not in the Stars! 2
code. I've got the Stars! 2 code, but I can't release it.

Jeff and I had intended to at least release a version of Stars! 2 with
no copy protection, but I don't have the right to do that myself,
either.

Stars! 2 requires Visual C version 1.5 to compile. If there is a ghod,
Jeff and I should be the only people left on the planet who still have
VC 1.5 available. You might think that it would be easy to modify the
source to compile under a more recent version of VC. From personal
experience, I can assure you that you'd be mistaken. Very mistaken.

Stars! 2 is not and never was my game; that was Jeff and Jeff's. I
came in some time after the SN project started.

Agreed that its a shame to see the community disbanding. OTOH, the
main reason that I'm still doing anything at all with Stars 3 is
because I WANT TO PLAY IT. If someone else comes up with a great 4x
game that preempts S3, they'd be saving me a lot of work...

I figure there's a reasonable chance that I could earn enough off a
Stars 3 game to justify the time spent on it. Maybe not at my usual
hourly rate, but good enough. You're right, of course, that the more
time goes that goes by, the less likely that is. Not much I can do
about that. Worst case, I would still get to play it myself and
perhaps with a few friends.

Jim Lane

RJLadd

unread,
Aug 30, 2005, 11:20:02 PM8/30/05
to
I tried to do that at one point. You'd find it hard to believe how
difficult it is to fix those bugs.

Stars! 2 was a Win16 game. Yup, Win16, with all its segmented memory
glory. 64K segments. Nowadays, a 64M segment sounds small. S2 was
written originally as a part time fun project by a couple of people
who were bored by their work on the guts of Excel, and who were
experts are wringing the last tiny bit of performance out of the
segmented Win16/8086 architecture. Shoehorning a universe the size of
a S2 game into Win16 took a great deal of skill. When they started,
they never expected that it would become a product, and didn't care at
all about code maintainability.

You've heard of Cthulhu? The more you know, the more insane you
become? I think Lovecraft had a premonition of what the Stars! 2 code
would look like. :-)

The bugs that are still there are mostly still there because they
would require a major rewrite/rearchitecting of substantial parts of
the code to fix. That may not seem plausible, given the apparently
simple nature of some of the bugs, but I've seen what it would take,
and I value what sanity I have left.

The Stars 3 project actually began as an effort to rewrite Stars! 2,6
to be native Win32. Jeff was always dubious about that idea, and it
didn't take too long for me to agree that starting over from scratch
was much easier.

I *do* have idea that might perhaps maybe work to convert S2 to Win32,
but it would be hard, and the result would still not be a good base
for future development. S3 is easier to work on, and is designed to be
extendable and moddable. And besides, Cthulhu isn't the only nasty
lurking in there...


Jim Lane

Ken Reed

unread,
Aug 31, 2005, 6:08:59 AM8/31/05
to
What a nice thread!

I discovered Stars! quite late in its life but really enjoyed playing it. A
true classic. It's been good to hear the history of why it never progressed
further.

I'd love to see an updated version but I think Jim has nicely explained the
practical problems as to why that hasn't happened. By the way, if you forget
about the "eye candy", putting together a clone isn't hard these days. I
wanted to learn C# and used Stars! as a learning project. Two or three
weekends when the weather was nasty let me put together about 25% of the
original game. I picked up the various algorithms (such as population
growth, ship fuel consumption, etc.) from the Google newsgroup archive and
put together the basics of the game. No combat, but you can design and build
ships, mine, colonise, explore, transfer cargo, etc.

You can find a screenshot here:

http://www.lakotamcc.co.uk/ken/screen1.jpg

By the way, I find the resolution to be very poor when I pop this page up in
IE. Hitting the zoom icon seems to fix the problem though.

When winter rolls around again I may get some time to take it further.
However, if there are any budding programmers out there who would like a
copy of the source code, I'm happy to pass it on. However, you'll need
Visual Studio 2003.

Ken

MSCHAEF.COM

unread,
Aug 31, 2005, 9:36:56 AM8/31/05
to
In article <4j6ah197bivrcf8e4...@4ax.com>,
RJLadd <nos...@mouse-potato.com> wrote:
...

>Stars! 2 requires Visual C version 1.5 to compile. If there is a ghod,
>Jeff and I should be the only people left on the planet who still have
>VC 1.5 available. You might think that it would be easy to modify the
>source to compile under a more recent version of VC. From personal
>experience, I can assure you that you'd be mistaken. Very mistaken.

I'm assuming that this is because there are a bunch of 16-bit dependancies
in the code? The very little I've heard about the 16-bit Stars 2 code base
indicates that is full of structures with layout specified down to the
bit level, etc.

Can you comment more on this? Perhaps it's a theoretical exercise only,
given the current state of licensing/ownershihp, but it'd be interesting
to hear more from an insider.

-Mike
--
http://www.mschaef.com

MSCHAEF.COM

unread,
Aug 31, 2005, 9:38:46 AM8/31/05
to
In article <nd7ah19hejf8nk00t...@4ax.com>,

RJLadd <nos...@mouse-potato.com> wrote:
>I tried to do that at one point. You'd find it hard to believe how
>difficult it is to fix those bugs.
>
>Stars! 2 was a Win16 game. Yup, Win16, with all its segmented memory
>glory.

Did it ever run in real mode?

-Mike
--
http://www.mschaef.com

send_an...@hotmail.com

unread,
Aug 31, 2005, 11:02:46 AM8/31/05
to
Ken Reed wrote:
>
> I discovered Stars! quite late in its life but really enjoyed playing it. A
> true classic. It's been good to hear the history of why it never progressed

100% agree.


> original game. I picked up the various algorithms (such as population
> growth, ship fuel consumption, etc.) from the Google newsgroup archive and
> put together the basics of the game. No combat, but you can design and build

It looks pretty! :-D

You might want to go to AH's forums for up-to-date algorithms, for
example:

http://starsautohost.org/sahforum/index.php?t=thread&frm_id=4&rid=625&S=4b0043785cd1bbf28cd3bcd65ff80c07

http://starsautohost.org/sahforum/index.php?t=thread&frm_id=54&rid=625&S=4b0043785cd1bbf28cd3bcd65ff80c07

About your source code, it would be interesting, lest your HD blows
up... ;-)

C U!

send_an...@hotmail.com

unread,
Aug 31, 2005, 11:09:34 AM8/31/05
to
RJLadd wrote:
>
> The bugs that are still there are mostly still there because they
> would require a major rewrite/rearchitecting of substantial parts of
> the code to fix. That may not seem plausible, given the apparently
> simple nature of some of the bugs, but I've seen what it would take,

Uh oh. I was kinda hoping it would not be so bad. :-(

OTOH, that might be a good reason to open-source the beast. If ID
Software got away with it...

In any case, please count me in when/if betatesting of Stars3 starts!
:-D

C U @ the Board!

Gandalf Parker

unread,
Aug 31, 2005, 12:56:15 PM8/31/05
to
RJLadd <nos...@mouse-potato.com> wrote in
news:nd7ah19hejf8nk00t...@4ax.com:

> You've heard of Cthulhu? The more you know, the more insane you
> become? I think Lovecraft had a premonition of what the Stars! 2 code
> would look like. :-)
>

I heard one programmer say that the problem with his code is that it was
not designed, it was not developed, it evolved wildly in spurts of
spontaneous mutations :)

Gandalf Parker


Ken Reed

unread,
Aug 31, 2005, 2:56:34 PM8/31/05
to

Piratelord

unread,
Aug 31, 2005, 3:00:33 PM8/31/05
to
Just like to add (now that I can) that a collegue and myself have a work in
progress clonish stars! game.
We are going to make it open source soon to get some speed on it, as at the
moment time is one problem.
It's in Visual Basic 6, since this is a language we both know the best and
we've got a fully working race design interface and game setup interface,
and are just starting the first turn files being produced.


Gandalf Parker

unread,
Aug 31, 2005, 3:10:34 PM8/31/05
to
"Piratelord" <stua...@btinternet.com> wrote in
news:df4uog$4cv$1...@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com:

Is it going to be good for solo play or good for multiplay?

Gandalf Parker

Piratelord

unread,
Aug 31, 2005, 3:23:52 PM8/31/05
to
Multiplayer only. Only "AI" to worry about then are battle instructions

"Gandalf Parker" <gan...@most.of.my.favorite.sites> wrote in message
news:Xns96C37BDBE93...@208.201.224.154...

Loren Pechtel

unread,
Aug 31, 2005, 4:45:30 PM8/31/05
to
On Tue, 30 Aug 2005 22:05:44 +0100, "Nats"
<nst...@nstutt.freeserve.co.uk> wrote:

>Yeah surely at this point with such an old game the original Stars code
>could be released to the community to work up couldnt it? It would keep the
>fans happy, get more interested in your game franchise (possibly!) which at
>the moment is dying a slow death and enable modders to upgrade the graphics
>and resolution of the game. That would satisfy most of us in the short term!
>And it may just turn into a full blown sequel in the future just like Falcon
>4. You never know how these things can take off.

The problem is that passwords are obviously security by obscurity.
Release the source and you bust the password system.

RJLadd

unread,
Sep 1, 2005, 3:00:47 AM9/1/05
to
VC 1.5 supports the Win16 features that the Stars! 2 code depends on.
It isn't just 16 vs 32 bit ints (although that's a significant issue).
There are the different kinds of pointers for near and far data, the
different memory models, etc. Not to mention the Win16 API itself,
which newer versions of VC do not include. (Windows continues to
support the Win16 API via the compatibility box, but the VC compiler
no longer supports writing to that API.)

You're right about the bit-mapped structures. In addition, since
everything had to fit into 64K segments, larger data structures are
very carefully packed into 64K. Some of the game limits (16 players,
max number of ship designs, etc.) are due to the bit packing in
structures, and some (like the limited number of fleets or minefields
that can exist) are due to packing arrays of structures into 64K
segments.

All of these limits can, in theory, be releaxed. But the code, by a
couple of young and foolish Microsofties, was not written to be
maintainable. There are places where bit packed structures are packed
or unpacked by code that uses shift-and-mask operations with immediate
constants, i.e. "(foo & 0x1C) >> 2". That's a lot of lines of mostly
uncommented code to go through, finding, understanding and replacing
mysterious constants. There's a lot of implicit retyping of data via
pointer abuse. Also, given the extremely tight memory constraints (no
more than 640K available in the entire machine), there are global
variables that are used and reused many times for many different
purposes.

Understanding what the code is trying to do is hard enough. Changing
it without breaking things is harder. Much of the code makes very
little sense unless you remember the oddities of the Win16
environment.

Keep in mind, again, that Jeff & Jeff did not start writing Stars!
intending it to be anything more than a part time diversion for
themselves and a few friends. Stars! 2 was hacked together, not
engineered.

Over time, as Stars! evolved from the first demo for J&J and friends
through Stars! 2.6, the game design reached a remarkable level of
quality. IMNSHO, Stars! 2 is the best multiplayer 4x game ever
written, and its quite good for single player, too. No 4x game has
good AI, although some cheat enough to make their AI look better than
Stars! 2. (AFAIK, with one small exception, Stars! 2 AIs don't cheat
at all. SN AIs cannot cheat; they have exactly the same access to
exactly the same info as any other players. No Stars 3 AIs have been
written, but they would also be incapable of cheating. Really good
strategic AI is incredibly hard to write; perhaps impossible.) But the
code, frankly, is a nightmare.

The code in the SN engine (written in C) is quite a bit better than
Stars! 2 (also in C). The Stars 3 code (in C++), what there is of it,
is very clean and maintainable. But Stars! 2 has the minor advantage
of being complete and available. :-)


Jim Lane


On Wed, 31 Aug 2005 08:36:56 -0500, msc...@eris.io.com (MSCHAEF.COM)
wrote:

send_an...@hotmail.com

unread,
Sep 1, 2005, 5:09:54 AM9/1/05
to
Hi,

RJLadd wrote:
> VC 1.5 supports the Win16 features that the Stars! 2 code depends on.

There's bound to be some museum, library or scrapyard where that
ancient VC can still be found.

<snip>

> maintainable. There are places where bit packed structures are packed
> or unpacked by code that uses shift-and-mask operations with immediate
> constants, i.e. "(foo & 0x1C) >> 2". That's a lot of lines of mostly
> uncommented code to go through, finding, understanding and replacing
> mysterious constants. There's a lot of implicit retyping of data via
> pointer abuse. Also, given the extremely tight memory constraints (no
> more than 640K available in the entire machine), there are global
> variables that are used and reused many times for many different
> purposes.

Well, it sounds bleak enough. However, all is not lost. I remember
FreeCiv (of Linux fame) undergoing a similar stage. It took **years**,
but in the end the deed got (mostly) done. =:-O

Also, I bet I'm not the only ASM jockey out here that's been there and
done that, bitpacking and abusing bits to cram outrageous programs
inside arcane machines with 8, 16 or 32 kbytes of *total* RAM, MSDOS
TSRs, drivers, and the like. It's a dirty job, but someone's bound to
love it. ;-)


> Understanding what the code is trying to do is hard enough. Changing

Some of us have done extensive black-box testing on many of Stars!2
workings just for fun. Having a peek to the real source code of our
favorite game would be a boon. And there would be no lack of testers
for broken things.


> IMNSHO, Stars! 2 is the best multiplayer 4x game ever written

100% agree. :-D


> strategic AI is incredibly hard to write; perhaps impossible.) But the
> code, frankly, is a nightmare.

We know/suspect several of Stars!2 AIs are "broken". There's no lack of
people wanting to waste endless hours improving/fixing them, either.

By the way, Blizzard seems to be doing a nice work of making "dumb" AIs
be competitive and even fun to defy. Time for making true AI
competitors later. ;-)

Though I would agree Stars 3 is the sanest way to use all that free
time, some would argue that Stars!2 is still alive and kicking, already
there, and still keeping an enthralled fan base which is, by many
accounts, highly intelligent as well as mostly insane.

If there was a way to pool all our resources to the task at hand, what
could we not accomplish?

Just my 3 cents.

Piratelord

unread,
Sep 1, 2005, 1:44:37 PM9/1/05
to
Sounds like Stars! developed in the same way as my Xtreme Borders.

First version was just Borders, and to make it better I had to basically do
a rewrite to make Xtreme Borders.
Still a bit of a nightmare to understand what is exactly going on in the
code.....

"RJLadd" <nos...@mouse-potato.com> wrote in message
news:mu6dh1pneqqpjj9c5...@4ax.com...

MSCHAEF.COM

unread,
Sep 1, 2005, 2:20:44 PM9/1/05
to
In article <mu6dh1pneqqpjj9c5...@4ax.com>,
RJLadd <nos...@mouse-potato.com> wrote:
...

>(Windows continues to
>support the Win16 API via the compatibility box, but the VC compiler
>no longer supports writing to that API.)

They gave that one up a long time ago.

>There are places where bit packed structures are packed
>or unpacked by code that uses shift-and-mask operations with immediate
>constants, i.e. "(foo & 0x1C) >> 2". That's a lot of lines of mostly
>uncommented code to go through, finding, understanding and replacing
>mysterious constants.

That and the reused global variables are the scariest part, IMO.

>Understanding what the code is trying to do is hard enough. Changing
>it without breaking things is harder.

And hard to test, to boot.


Thanks for the information.

-Mike
--
http://www.mschaef.com

PricklyPea

unread,
Sep 1, 2005, 7:13:07 PM9/1/05
to
I don't mine the shift/mask ops since it doesn't look too different in
assembly anyway. But the reuse of variables is a real PITA. :(

I think I might have the old VC somewhere, but doesn't Empire own the
code now anyway?

RJLadd

unread,
Sep 2, 2005, 2:41:48 AM9/2/05
to
On 1 Sep 2005 02:09:54 -0700, send_an...@hotmail.com wrote:

>RJLadd wrote:
>> VC 1.5 supports the Win16 features that the Stars! 2 code depends on.
>There's bound to be some museum, library or scrapyard where that
>ancient VC can still be found.

My comment about VC 1.5 being gone was mostly wishful thinking.

>We know/suspect several of Stars!2 AIs are "broken". There's no lack of
>people wanting to waste endless hours improving/fixing them, either.

I don't know the S2 AI code at all, but I don't recall any of them
being broken in a strict sense; they do what they are designed to do.
Some of them are broken in the looser sense of being designed to do
stupid things, though.

>Well, it sounds bleak enough. However, all is not lost. I remember
>FreeCiv (of Linux fame) undergoing a similar stage. It took **years**,
>but in the end the deed got (mostly) done. =:-O

Of course its possible. But:

>Though I would agree Stars 3 is the sanest way to use all that free
>time,

Exactly. Working on the new code is more fun, and the result (if/when
there is one) will be better.

>some would argue that Stars!2 is still alive and kicking, already
>there, and still keeping an enthralled fan base which is, by many
>accounts, highly intelligent as well as mostly insane.

True on all counts. :-) I agree that a 32 bit S2 would be good for
the Stars! player community, and I wish it could be done with a
reasonable effort. I don't believe that it will ever be open sourced,
though. Remember that Jeff McB only half-owns the S2 code; Jeff J
co-owns it. Jeff J lost interest back in the 90's.

I don't have rights to the S2 code (I might be able to argue the
point, but I'm not very interested), and even if I did, its a dead
end.

The first step in Stars 3 was originally to be a 32 bit port of S2.
Not for release; just as a base for the next stage. Jeff McB had no
interest at all in trying to wade into the S2 code again, until I got
it about half working. Unfortunately, that was the easy half. Porting
the rest would have been too much work, so he convinced me to change
course and we started a something-like-50% rewrite. That effort faded
in the press of earning of living. I went back and removed the last
remnants of Stars! 2-isms, and have been puttering with it since.

On 1 Sep 2005 16:13:07 -0700, "PricklyPea" <Prick...@gmail.com>
wrote:


>I think I might have the old VC somewhere, but doesn't Empire own the
>code now anyway?

AFAIK, Empire owned the trademark, "Stars!". There was a bit in the
contract where the rights to that TM reverted some period of time
after they ceased selling it. In effect, some period of time after
Jeff and Jeff received their last royalty check. That time has passed.

And AFAIK, Empire never had any rights to the Stars! 2 code or
graphics.


Jim Lane

iztok_...@yahoo.com

unread,
Sep 2, 2005, 3:01:01 AM9/2/05
to
Hi!

> Release the source and you bust the password system
I'm affraid fhe password sistem is already busted. Ther's an utility
that allows any person that has access to M file to read it regardless
of password. This is the reason you have now the PWD check to _downlad_
M file from AutoHost.
BR, Iztok

Russ Lewis

unread,
Sep 2, 2005, 12:31:36 PM9/2/05
to
This is actually a good thing, IMHO. If we could see the internal
structure of those M files, we could start working on 3rd party AIs that
interact with the existing Stars client.

Dirk Thierbach

unread,
Sep 3, 2005, 3:20:52 AM9/3/05
to
iztok_...@yahoo.com wrote:

> I'm affraid fhe password sistem is already busted. Ther's an utility
> that allows any person that has access to M file to read it regardless
> of password. This is the reason you have now the PWD check to _downlad_
> M file from AutoHost.

How many people would you estimate have actually seen this utility?
Does this utility also allow to mess with the X file (which is more
dangerous, because you could trigger bugs when the host is generating
the next turn?)

- Dirk

Timothy Little

unread,
Sep 3, 2005, 9:03:46 PM9/3/05
to
Dirk Thierbach wrote:
> How many people would you estimate have actually seen this utility?
> Does this utility also allow to mess with the X file (which is more
> dangerous, because you could trigger bugs when the host is generating
> the next turn?)

I haven't seen it, which may be a little reassuring (i.e. not everyone
has seen the utility in question).

However: some months ago I decided to play around with Stars! again,
and discovered that I had forgotten almost all my previous race
passwords. A few weekends (some of which was spent learning how to
use a debugger and disassembler on Windows executables in Linux) was
how long it took to recover them. Obviously I wasn't interested in
fiddling with .x# files, but I don't think it would have been as
difficult.


- Tim

Dirk Thierbach

unread,
Sep 5, 2005, 3:26:06 AM9/5/05
to
Russ Lewis <spamhole-...@deming-os.org> wrote:

> iztok_...@yahoo.com wrote:
>>> Release the source and you bust the password system

>> I'm affraid fhe password sistem is already busted. Ther's an utility
>> that allows any person that has access to M file to read it regardless
>> of password. This is the reason you have now the PWD check to _downlad_
>> M file from AutoHost.

> This is actually a good thing, IMHO. If we could see the internal

> structure of those M files, we could start working on 3rd party AIs that
> interact with the existing Stars client.

Ok. I've been sitting on this for quite a number of years now, because
the Jeffs asked me to, but as there have been a number of announcements
that other people have cracked the encryption, and the M files on AH are
now password protected, I'll guess it's not longer necessary.

I have written a little C program that dumps the M, X, R and HST files. I've
reverse engineered a number of records and their most important data fields.
Unfortunately, I've lost both the file with my notes and a proposal
for a corresponding text file format (yes, it was that long ago :-),
but I guess about half of that made it in the program itself, which
I still have.

If anyone wants to set up a website with wiki etc. to discuss and
document the internal format, I'd be happy to participate, though I
don't have the time at the moment to help reverse engineering the
missing fields and records.

However, if there's some going to be some text file aequivalent if the
I would like to propose some subset of YAML
http://yaml.kwiki.org/?YamlInFiveMinutes instead of XML or some other
bloated format. YAML is easy to read and write for humans, and a
parser for a subset of it is not difficult to make. (I have a
restricted one in OCaml, if anyone is interested; there is a complete
one for Ruby, and also Python bindings for it).

The Jeffs said that the X file format is somewhat brittle, and if
an external AI is going to produce them we will probably see a number
of new bugs, which may lead to new cheats, but I guess we'll just have
to put up with that now. Better bring this in the open, so everyone
knows, instead of waiting until someone discovers new cheats for himself.

- Dirk

PricklyPea

unread,
Sep 5, 2005, 7:21:57 AM9/5/05
to
Quite a few. It was apparently posted on a Russian stars site. Also, it
is trivial for anybody with elementary reverse engineering experience
to break it so there are probably several other people who have this
ability. I also know of several people who have independently been
playing with the turn files etc.

send_an...@hotmail.com

unread,
Sep 6, 2005, 5:30:24 AM9/6/05
to
Hi!

Dirk Thierbach wrote:
>
> I have written a little C program that dumps the M, X, R and HST files.

Cool!

Is it good for the JRC4 patch? Could that program be made
available/downloadable somewhere?


> If anyone wants to set up a website with wiki etc. to discuss and
> document the internal format, I'd be happy to participate, though I

AH's forums or even here could be a place to start.


> don't have the time at the moment to help reverse engineering the
> missing fields and records.

Perhaps some kind (and lightly insane) souls would volunteer to help
with that. ;-)


> The Jeffs said that the X file format is somewhat brittle, and if
> an external AI is going to produce them we will probably see a number
> of new bugs, which may lead to new cheats, but I guess we'll just have

There's some "turnchecker" utilities in progress, I've heard.


> to put up with that now. Better bring this in the open, so everyone
> knows, instead of waiting until someone discovers new cheats for himself.

100% agree.

- - - - -

send_an...@hotmail.com

unread,
Sep 6, 2005, 5:45:11 AM9/6/05
to
Hi,

RJLadd wrote:
>
> My comment about VC 1.5 being gone was mostly wishful thinking.

;-)


> Some of them are broken in the looser sense of being designed to do
> stupid things, though.

Like not expanding beyond 8 or 10 planets, for example? That's what I
meant.


> Exactly. Working on the new code is more fun, and the result (if/when
> there is one) will be better.

Thing is, that depends on the stamina and free time of only one person,
at the moment. Whereas the prospect of tinkering with Stars2 sources
could appeal to perhaps more people right now.


> I wish it could be done with a reasonable effort.

"Reasonable" might be less absolute than you believe. Specially among
computer addicts. ;-)


> I don't believe that it will ever be open sourced, though.
> Remember that Jeff McB only half-owns the S2 code; Jeff J
> co-owns it. Jeff J lost interest back in the 90's.

If he lost interest, wouldn't he agree to release the whole thing for
others to worry about with?


> The first step in Stars 3 was originally to be a 32 bit port of S2.
> Not for release; just as a base for the next stage. Jeff McB had no
> interest at all in trying to wade into the S2 code again, until I got
> it about half working. Unfortunately, that was the easy half. Porting
> the rest would have been too much work, so he convinced me to change
> course and we started a something-like-50% rewrite. That effort faded

Makes a lot of sense, of course. Sadly. :-(

We all wish you get a Stars3beta out somewhere "soon"...

- - - - - -

Dirk Thierbach

unread,
Sep 6, 2005, 7:21:33 AM9/6/05
to
send_an...@hotmail.com wrote:
> There's some "turnchecker" utilities in progress, I've heard.

Do you have any pointers?

- Dirk

send_an...@hotmail.com

unread,
Sep 6, 2005, 10:43:31 AM9/6/05
to

Wumpus, IIRC. Perhaps others.

PricklyPea

unread,
Sep 6, 2005, 1:04:44 PM9/6/05
to
Yes. Wumpus is working on it. I would like to do so too, but I'm
working on various mods etc. for the moment. Dirk: could you email me a
copy of your tool? You'll need to change the extension and zip to get
past gmail's filters. Thanks.

Dirk Thierbach

unread,
Sep 6, 2005, 12:44:59 PM9/6/05
to

> Wumpus, IIRC. Perhaps others.

It's hard to find that with Google (too many hits). Could you be more
specific, please?

- Dirk

PricklyPea

unread,
Sep 6, 2005, 3:06:05 PM9/6/05
to
Try: http://sourceforge.net/projects/stars-util

However, Wumpus has decided not to share information on turn files etc.
due to fear of abuse by players.

RJLadd

unread,
Sep 6, 2005, 11:26:10 PM9/6/05
to
On 6 Sep 2005 02:45:11 -0700, send_an...@hotmail.com wrote:

>> Some of them are broken in the looser sense of being designed to do
>> stupid things, though.
>Like not expanding beyond 8 or 10 planets, for example? That's what I
>meant.

That;s one example of what I meant, too. There are other examples.

>> I don't believe that it will ever be open sourced, though.
>> Remember that Jeff McB only half-owns the S2 code; Jeff J
>> co-owns it. Jeff J lost interest back in the 90's.
>If he lost interest, wouldn't he agree to release the whole thing for
>others to worry about with?

I see that you've never met Jeff J.

For S2, I'm the wrong person to talk to. Maybe Jeff, or Jeff, but not
me. Maybe Jeff M could talk Jeff J into it, but I couldn't.

>We all wish you get a Stars3beta out somewhere "soon"...

Me, too. But I'm not the only person who could write something like
it.


Jim Lane

send_an...@hotmail.com

unread,
Sep 16, 2005, 7:29:45 AM9/16/05
to
Hi,

RJLadd wrote:
> On 6 Sep 2005 02:45:11 -0700, send_an...@hotmail.com wrote:
>
> I see that you've never met Jeff J.

That must be it. ;-)

<snip>

> >We all wish you get a Stars3beta out somewhere "soon"...
>
> Me, too. But I'm not the only person who could write something like

I'm curious: Just what kind of improvements can we expect from the new
version? More design slots? Bigger universes? Revamped battleboard? Pop
redistributing itself to colonies?

Thanks,

send_an...@hotmail.com

unread,
Sep 16, 2005, 7:31:44 AM9/16/05
to
Dirk Thierbach wrote:
> send_an...@hotmail.com wrote:
>
> > Wumpus, IIRC. Perhaps others.
>
> It's hard to find that with Google (too many hits). Could you be more
> specific, please?

Sorry, I thought it was obvious: search for him in Google groups,
specially this group.

send_an...@hotmail.com

unread,
Sep 16, 2005, 7:34:49 AM9/16/05
to
Dirk Thierbach wrote:
>
> I have written a little C program that dumps the M, X, R and HST files.

I'd very much like to have a peek to that tool. My "advisor" scripts
could have a field day if coupled to something like that. :-D

Thanks,

RJLadd

unread,
Sep 18, 2005, 5:09:31 AM9/18/05
to
On 16 Sep 2005 04:29:45 -0700, send_an...@hotmail.com wrote:
>> >We all wish you get a Stars3beta out somewhere "soon"...
>> Me, too. But I'm not the only person who could write something like
>I'm curious: Just what kind of improvements can we expect from the new
>version? More design slots? Bigger universes? Revamped battleboard? Pop
>redistributing itself to colonies?

Since it isn't done, the feature set isn't fixed. But as for general
directions...

No required limits on number of game objects (fleets, ship, ship
designs, mine fields, races per game, start systems, etc.), but the
ability to place limits on a particular game during set up, if
desired. Stars! 2 is limited by the Win16 API. This version assumes a
32 bit (or better) CPU.

Deeper race design, using something similar (but more flexible than)
SN's idea of physiologies and social models.

Hull designs are not specified by the game engine. Like other limits,
they can be fixed by the scenario, or it can be made possible to
design new hulls during the game.

More variation in galaxy creation, similar to SN.

More variation in, and more meaningful, winning conditions. Doing this
really means setting up a fairly sophisticated system for triggering
game events in general, with one possible action for a trigger being
to declare a victor. A key point that goes along with this is that it
is possible to create non-zero-sum games.

The possibility for more than one universe per game, possibly with
different physics. Might not be fully implemented at first, but the
game engine does not preclude implementing it later (I hope).

Completely revamped tech. Separate FTL and normal space engines, very
different types of offense and defense, etc. All of this is
implemented in terms of lower-level primitives that can be recombined
in a variety of ways. For example, weapons inherently have certain
characteristics: range, damage, mass, various costs, interactions with
other tech (i.e. defenses),rate of fire, accuracy, velocity,
maneuverability, local / remote tactical intelligence, etc. At a game
engine level, a "beam weapon" is a manufactured device that can
perform an action (create a beam) at a given rate while consuming
defined resources. The beam itself, once it has been fired, is a
separate game object that has a constant velocity, a constant
direction of travel (inherited from the projector that created it), no
tactical AI, and has particular effectiveness formulas vs. different
kinds of defenses. Each aspect of the projector and the beam can be
separately influenced by the technological knowledge of the
projector's builders, and by it's operators. All of these
interrelationships are defined by RDL, and can be very simple, very
complex, or anywhere in between.

A more sophisticated version of SN's RDL, more completely integrated
into the game engine.

The ability to play at more than one level of abstraction. In a
beginner's game, many different decisions are coupled together for
simplicity. . An advanced game gives the players direct control over
the underlying game controls. This is essentially the same idea as
"governors" used in many other games, but the scripts are in RDL 2 and
are available for modding. There will be at least two levels of
abstraction, and perhaps three.

A deeper way to specify orders to units, based more directly on a
real-life military model. Units get doctrines that are triggered by
various circumstances. The doctrines, the triggers, and the actions
taken to implement a doctrine are all in RDL, and can be modded. The
tactical AI is based on a flocking model; advanced players have
control over the flocking rules.

The battle engine is similar in concept to SN's: distances are
measured in meters, not "squares", movement is Newtonian.

A more complete economics model, allowing for trading without
wolf-lamb, ship scraping, etc. I'm not sure I've figured out how to do
it yet, but I'd like it to be possible to defeat an opponent without
ever firing a shot, by economic warfare.

Better game security, based on published crypto techniques.

Better support for Autohost'ing, although not as complete as SN had
planned.

---

There are some things that I have no plans to change:

One species per stellar object (planetary system, etc.).

The basic concepts of game set up, race design, ship design, fleet
design, etc. Players must have enough degrees of freedom to support a
Stars! like complexity of game play.

The basic idea of interacting compound interest formulas, although the
details are different.

No game-enforced contracts between players. Backstabbing will always
be possible.

The AIs have exactly the same information available to them as the
players. It is not possible for them to cheat. (As a result, there
will be a handicapping system, which can be applied to any player in
the game.)

One of the key, and very difficult, ideas is that there should never
be any single winning formula. Stars! 2 was not quite perfect at this,
but it was extraordinarily good. The intent is to create
sissors-paper-stone loops in every area of the game.

2D, not 3D. There is no gain in depth of gameplay in a 3D universe,
and the UI is much harder.

Turn based 4X. Jeff and I had discussed the idea of a variable
simulation period; a game could be set up to play at different amounts
of game time per turn, possibly varying it over the course of the
game. Using a very short simulation clock, one could approximate an
RTS, but the game engine remains fundamentally turn based.

---

I'm sure I've left out a lot. I'm willing to consider alternate ideas,
but please understand that I have a vision for this game, and there
are some popular ideas that don't fit that vision. I'm working on the
game that I want to play, and hope that others will enjoy it, too.


Jim Lane

Nats

unread,
Sep 18, 2005, 6:59:18 AM9/18/05
to
Sorry to be blunt but isnt this a little bit of a case of reaching for the
moon? I mean Genesis never got finished did it - mainly because the plans
for the game grew massively out of proportion to the ability of the design
team in terms of money and time. And isnt this Stars 2 looking likely to go
the same way?

Being purely sensible and realistic for a minute - you have a game that runs
well and is still quite good fun to play - why not expand on that and
upgrade it, Im sure its what everyone would want. Theres absolutely no need
to reinvent the wheel. We dont need a brand new massive plan for a game that
wont get finished again. You also have Genesis which is probably more than
50% finished and yet you are chucking it all away without even any attempt
to get back all the artwork etc? Why? Whats the reasoning behind this? Seems
to me like the Stars team - if there is still one - dont have the slightest
idea about reality and dont have any real plans to ever get a game finished.

Again sorry to be blunt but we've heard all this before!

Nats

"RJLadd" <nos...@mouse-potato.com> wrote in message

news:7j7qi1piodckcv32b...@4ax.com...

Piratelord

unread,
Sep 18, 2005, 11:56:20 AM9/18/05
to
True. To me, the following list is what I think people would like on top of
the existing Stars! in order of priority.

* Greater or no limit on ship and starbase designs
* More Diplomacy settings (Instead of Friend/Neutral/Enemy)
* Map share with Friends (depending on Diplomacy setting)
* Improved battlegrid
* More map features
* More random events
* More MT Items
* More Components
* Split research resources from construction resources, introduce
laboratories.
* Better graphics
* Better sounds

Personally I would also like the following:
* Increase cost of wide hab ranges
* Increase cost of components
I feel at the moment that you can have too many planets and way too many
ships. It should be a challenge to build a large fleet of battleships.


"Nats" <nst...@nstutt.freeserve.co.uk> wrote in message
news:dgjha5$ord$1...@newsg4.svr.pol.co.uk...

RJLadd

unread,
Sep 18, 2005, 4:49:31 PM9/18/05
to
On Sun, 18 Sep 2005 11:59:18 +0100, "Nats"
<nst...@nstutt.freeserve.co.uk> wrote:
>Sorry to be blunt but isnt this a little bit of a case of reaching for the
>moon? I mean Genesis never got finished did it - mainly because the plans
>for the game grew massively out of proportion to the ability of the design
>team in terms of money and time. And isnt this Stars 2 looking likely to go
>the same way?

That isn't what happened to SN.

>Being purely sensible and realistic for a minute - you have a game that runs
>well and is still quite good fun to play - why not expand on that and
>upgrade it, Im sure its what everyone would want. Theres absolutely no need
>to reinvent the wheel.

Expanding on Stars! 2 is not an option. Read my earlier posts.

>We dont need a brand new massive plan for a game that
>wont get finished again. You also have Genesis which is probably more than
>50% finished and yet you are chucking it all away without even any attempt
>to get back all the artwork etc?

That isn't what happened to SN. Finishing SN is not a viable option,
at least not for me alone. Read my earlier posts.

>Why? Whats the reasoning behind this? Seems
>to me like the Stars team - if there is still one - dont have the slightest
>idea about reality and dont have any real plans to ever get a game finished.

There is no team. There's just me, and I'm building what I feel like
building. If/when I finish it (no guarantees), and if other people
like it too, that's gravy.

If you want to take a different approach, by all means do so.

>Again sorry to be blunt but we've heard all this before!

To be blunt in return, I'm not working on this for you. I'm doing it
because I'm enjoying working on it. Even if it is never finished, I
will still have had fun working on it. Finishing the game I'm working
on would be a Good Thing, but it is not a requirement. I do software
engineering because I like it, not just because it pays the bills.

Notice that I only posted information about the design in response to
a direct question. I'm not trying to pre-publicise a commercial
product, and I've been careful to point out the very real possibility
that what I'm working on will never be shipped.

Much of the additional depth of the game I'm working on comes from
writing simpler code, not from extra effort. Instead of trying to
design and implement complex game behaviors, I'm implementing a set of
simple primitives, plus a means of combining them into game-useful
groups.

Jeff and Jeff were working on MS Excel when they wrote the original
Stars, and it shows. They took a spreadsheet-like approach to many
elements of the game. My background is more in compilers and
interpreters, and that also shows. This game engine is based around an
interpreted language, with game behaviors expressed as language
primitives.


Jim Lane

RJLadd

unread,
Sep 18, 2005, 5:12:11 PM9/18/05
to
On Sun, 18 Sep 2005 15:56:20 +0000 (UTC), "Piratelord"
<stua...@btinternet.com> wrote:

>...the following list is what I think people would like on top of

>the existing Stars! in order of priority.
>* Greater or no limit on ship and starbase designs

The code that I'm working on allows a sedation to impose such limits,
but the game engine does not require them. There are practical limits
due to memory constraints, but it isn't likely that anyone will ever
run into them.

>* More Diplomacy settings (Instead of Friend/Neutral/Enemy)

I agree, but I haven't thought that one through yet. How should it
work?

>* Map share with Friends (depending on Diplomacy setting)

Agree that sharing and/or trading information is important. Map info,
technology, designs of parts and ships, etc. should all be eligible.
The new game engine allows for it.

>* Improved battlegrid

Jeff (L, not Jeff M or Jeff J) did a very nice battle display for SN.
He has far more of a graphics background than I do, but I'd like to do
something at least in that ballpark.

>* More map features

Such as?

>* More random events

Such as?

>* More MT Items

No MT as such, but a more flexible concept of NPCs. Since tech parts
are implemented as collections of more primitive characteristics, its
easy to give one NPC species better parts than anyone else can get.
Trading is built in, so the MT becomes just an NPC race with otherwise
unobtainable tech designs that will trade with the players.

This is an example of the approach I'm taking. Instead of special
purpose code to handle the MT, I've got a bunch of simpler principals
that can be combined in a way that results in the MT. But those same
principles can also be used to implement other features, like
palyer-to-player trading, or technology that is race-specific.

>* More Components
>* Split research resources from construction resources, introduce
>laboratories.

Done. Stars! 2 has essentially a single economy. My model does not
limit the number of possible economies. An "economy" is simply a set
of compond-interest curves, defined in RDL, with defined kinds of
inputs, accelerators (like factories or schools), and the opportunity
to siphon off the results.

>* Better graphics

Nope. Well, maybe slightly better, but still at the same overall
level.

>* Better sounds

Er...kind of. At least the sounds can be replaced by the player.

>Personally I would also like the following:
>* Increase cost of wide hab ranges
>* Increase cost of components

All controlled by RDL, and changeable per scenario.

>I feel at the moment that you can have too many planets and way too many
>ships. It should be a challenge to build a large fleet of battleships.

Also controlled by RDL.

I'm not going to try to create perfect game balance in C++ code in the
game engine. That method leads to far too much maintenance. Instead,
as much as possible (which is quite a lot), game balance is controlled
by the scripting language, and is open to modification by players, on
a per game/scenario basis.

But I'll say it again, and again, and again, until it sinks in: don't
count on me to ever finish it. This is a hobby for me, not a living.
I'm discussing my intentions here simply as a member of the community
of Stars! fans, not as some kind of authority figure. If you want such
a game, write it yourself. If you finish before I do, perhaps I'll
drop mine and play yours instead.


Jim Lane

Dirk Thierbach

unread,
Sep 19, 2005, 2:30:30 AM9/19/05
to
RJLadd <nos...@mouse-potato.com> wrote:
> On Sun, 18 Sep 2005 15:56:20 +0000 (UTC), "Piratelord"

>>* More Diplomacy settings (Instead of Friend/Neutral/Enemy)


>
> I agree, but I haven't thought that one through yet. How should it
> work?

>>* Map share with Friends (depending on Diplomacy setting)
>
> Agree that sharing and/or trading information is important. Map info,
> technology, designs of parts and ships, etc. should all be eligible.
> The new game engine allows for it.

Just to throw in one idea: In a game, it's often important to
define borders and zones. Of course, one can do that externally,
but it would be nice to be able to just draw on the map, and
communicate (a subset of) these drawings to different players.
One could couple this with different diplomatic behaviour, e.g.
attack all ships (even friends) in some core zone, tolerate friendly
ships in another zone, and so on.

I remember a discussion in the past where it has been suggested to
realize this by concrete game objects, i.e. beacons that have to be
dropped by ships, by I think that this increase micro management quite
a bit.

BTW, zones could also be useful for giving game commands: Draw a zone,
and then give the command to route all ships of a certain designs,
whether present or built in the future, to some destination via the
fastes route. Or let all ships of a certain design in a zone return
to the nearest starbase to resupply. And so on, and so on.

- Dirk

send_an...@hotmail.com

unread,
Sep 19, 2005, 4:18:12 AM9/19/05
to
Hi,

RJLadd wrote:
>
> Since it isn't done, the feature set isn't fixed. But as for general
> directions...

That's quite an impressive list of goals. You're not just "rewriting"
good ole' Stars2. No wonder it's taking some time. ;-)


> really means setting up a fairly sophisticated system for triggering
> game events in general, with one possible action for a trigger being

Starcraft's triggers come to mind. Simple, yet amazingly flexible.


> Completely revamped tech. Separate FTL and normal space engines, very
> different types of offense and defense, etc. All of this is

Very interesting! :-)


> tactical AI is based on a flocking model; advanced players have
> control over the flocking rules.

I believe that kind of battles will significantly alter the "feel" of
most of the gameplay. Which might be good.


> it yet, but I'd like it to be possible to defeat an opponent without
> ever firing a shot, by economic warfare.

That could enshrine economy as *the* road to success.


> game. Using a very short simulation clock, one could approximate an
> RTS, but the game engine remains fundamentally turn based.

Surely not short enough to influence an in-process battle? :-O


> are some popular ideas that don't fit that vision. I'm working on the
> game that I want to play, and hope that others will enjoy it, too.

I wonder if it would be possible to reach a "working" game before some
of the advanced concepts are fully implemented.

send_an...@hotmail.com

unread,
Sep 19, 2005, 4:44:32 AM9/19/05
to
RJLadd wrote:
> On Sun, 18 Sep 2005 15:56:20 +0000 (UTC), "Piratelord"
> <stua...@btinternet.com> wrote:
>
> >* More Diplomacy settings (Instead of Friend/Neutral/Enemy)
>
> I agree, but I haven't thought that one through yet. How should it
> work?

I'd say decouple right to gate from right to travel through minefields,
or refuel, for starters. Shared intel should be a higher state than
just joint battles. "Teammember" comes to mind. Ability to transfer
ships, or accept transfers. Disclosure of own designs to friends.
Capacity to grab minerals from each other, perhaps...

Better yet, allow everyone to define their options by selecting a bunch
of checkboxes essentially covering most of your own control over your
own empire. For some, "ally" means the "shared gates" is checked, while
others would keep that one unchecked. A pirate bunch would check the
"joint battle", the "refuel" and the "shared scans" but not others such
as one's own map... and so on. Also, the allies would know what kind of
options they're granted, thus gauging the trust placed on them.

If these things still have a meaning in the new game, that is. ;-)


> Agree that sharing and/or trading information is important. Map info,
> technology, designs of parts and ships, etc. should all be eligible.
> The new game engine allows for it.

What about transferring half-built or obsolete ships and allowing the
receiver to complete/upgrade them?


> >* More map features
>
> Such as?

I bet he means something like what Xtreme Borders offers. ;-)


> But I'll say it again, and again, and again, until it sinks in: don't
> count on me to ever finish it. This is a hobby for me, not a living.

But of course, Stars! is only a hobby, not a living, ain't it? ;-)


> I'm discussing my intentions here simply as a member of the community
> of Stars! fans, not as some kind of authority figure. If you want such
> a game, write it yourself. If you finish before I do, perhaps I'll
> drop mine and play yours instead.

As long as this is not a commercial effort, why not join forces instead
of going everyone on his own?

Also, early, barely playable "betas" could jump-start the fine-tuning
process for balance and gameplay, perhaps even allowing flashy but
unimportant concepts to be dropped, and others to be discovered/added.

Awww, well, my new Warp11 engine beckons me from the garage...

iztok_...@yahoo.com

unread,
Sep 19, 2005, 5:05:39 AM9/19/05
to
Hi!

> Since it isn't done, the feature set isn't fixed. But as for general directions...
I play Stars for quite some time and I still find it a great game. So
as first I'd like to thank you for making it so great. As second, thank
you for sharing your knowledge about the current game and background
story of the SN. It was a nice reading. Now, when I'm through with
upkissing ;-) I'd like to tell what changes I'd like to see. There
aren't many of them.

> No required limits on number of game objects

In larger games there's that nasty limit on 512 fleet slots, and for SD
the 512 minefields. Those two should IMO be increased (or give the
ability to sweep/destroy own minefields). Other limits I see more as a
game feature. The "nastiest" (IMO for other players) is 16 ship design
slots. But I'm happy to have it, as it results in much less MM when I
play. Allthough it involves a hard decision when to start buiding
ships, when it is made, I just build, and wait until next mayor tech
breakthrough is achieved. I remember playing another 4x game SE4 where
I got constantly involved in upgrading all objects (ships, weapon
platforms, troops ...) when I got new tech, AND optimizing them for
build queues performance (usuall 2k with each "mineral"). That job had
became so tedious I lost interest in playing that game.

Another feature I'd like to see is some bonus for more active players.
IMO current game tends to favor players that just sit and grow, until
they got some big advantage, or they maxx important tech. When an
active player involves in an early war, he (maybe ;-) gets some more
space, but ends lagging in everything else. What his empire gets (and
current game doesn't include), is experience in conducting warfare.
Experience could be calculated from value of destroyed/taken stuff, in
comparision with players' current economies (so the side that lost
would also get some), with a treshold where no exp is gain (so just
tech-trading sites would not give it). That accumulated experience
should result in a certain percentage better attack, defense,
initiative and(or?) movement.

There are also usual demands about balancing PRTs /LRTs, but those will
be probably done with RDL. I'd just like to propose "standard" settings
to be included/hard-coded in the game, so it could be played without
hassle with mods and versions.

And please include anti-cheating checks.

BR, Iztok

MSCHAEF.COM

unread,
Sep 19, 2005, 11:49:52 AM9/19/05
to
In article <7j7qi1piodckcv32b...@4ax.com>,

RJLadd <nos...@mouse-potato.com> wrote:
...
>No required limits on number of game objects (fleets, ship, ship
>designs, mine fields, races per game, start systems, etc.),

Without a required limit on the number of game objects, how does your code
identify the object during gameplay? The nice thing about integer indices
into arrays is that it's O(1) for retrieval and integers are easy to use.

-Mike
--
http://www.mschaef.com

RJLadd

unread,
Sep 20, 2005, 2:58:28 AM9/20/05
to
On Mon, 19 Sep 2005 08:30:30 +0200, Dirk Thierbach
<dthie...@usenet.arcornews.de> wrote:
>Just to throw in one idea: In a game, it's often important to
>define borders and zones. Of course, one can do that externally,
>but it would be nice to be able to just draw on the map, and
>communicate (a subset of) these drawings to different players.
>One could couple this with different diplomatic behaviour, e.g.
>attack all ships (even friends) in some core zone, tolerate friendly
>ships in another zone, and so on.

I like the idea, but I'm not sure how to implement it. You can't just
draw a border; you need some way of knowing what is going on across
it.

The engine I'm working on does give the players the ability to draw on
the map, and various ways to mark out regions. Marked maps can be
shared.

I'd thought of using the marks as a part of order-giving, though.
That's a good idea.

>I remember a discussion in the past where it has been suggested to
>realize this by concrete game objects, i.e. beacons that have to be
>dropped by ships, by I think that this increase micro management quite
>a bit.

That was more-or-less the SN model. I was never really satisfied with
it, but I didn't have a better idea.

Since then, though, and given the capabilities of the new game engine,
I'm thinking about allowing scanners to have a maximum total area, but
with a controllable shape. There are some problems with this from a
game balance POV, but it might be possible to make it work.

>BTW, zones could also be useful for giving game commands: Draw a zone,
>and then give the command to route all ships of a certain designs,
>whether present or built in the future, to some destination via the
>fastes route. Or let all ships of a certain design in a zone return
>to the nearest starbase to resupply. And so on, and so on.

Waypoints as regions instead of exact points. I hadn't thought of
that, either, and I like it quite a bit.

Some good ideas here. Keep it up. :-)


Jim Lane

RJLadd

unread,
Sep 20, 2005, 3:14:34 AM9/20/05
to
On 19 Sep 2005 01:18:12 -0700, send_an...@hotmail.com wrote:
>That's quite an impressive list of goals. You're not just "rewriting"
>good ole' Stars2. No wonder it's taking some time. ;-)

I'm writing a completely new game that is strongly inspired by Stars!
2 and SN.

>> Completely revamped tech. Separate FTL and normal space engines, very
>> different types of offense and defense, etc. All of this is
>Very interesting! :-)

There's more than one kind of FTL engine, with different advantages
and disadvantages. The interesting part is looking at all of the
engine ideas and coming up with a set of more primitive
behaviors/characteristics that allow them all to be expressed.

Normal space engines are used during battles. If the hull allows for
it, a ship could carry both, but there are costs. Thus, with good
scenario design, the players must trade off between FTL capability and
battle speed.

>> tactical AI is based on a flocking model; advanced players have
>> control over the flocking rules.
>I believe that kind of battles will significantly alter the "feel" of
>most of the gameplay. Which might be good.

Battles need to be predictable enough to allow players to tune their
fleet designs and the doctrines given to the different units, but
shouldn't be 100% deterministic. I've read some real world military
texts on naval fleet engagements to try to get a feel for it. There
are some "laws" (really more like rules-of-thumb) that should at least
roughly apply.

>> it yet, but I'd like it to be possible to defeat an opponent without
>> ever firing a shot, by economic warfare.
>That could enshrine economy as *the* road to success.

If it does, then that possibility will be removed. But note that
economic warfare is not necessarily the same as economic output.

>> game. Using a very short simulation clock, one could approximate an
>> RTS, but the game engine remains fundamentally turn based.
>Surely not short enough to influence an in-process battle? :-O

Battles are on the S2 model in the sense that they happen off stage.
You can reply them, and you can play out mock battles where you
control the initial conditions, but actual battles can only be
observed.

>> are some popular ideas that don't fit that vision. I'm working on the
>> game that I want to play, and hope that others will enjoy it, too.
>I wonder if it would be possible to reach a "working" game before some
>of the advanced concepts are fully implemented.

Probably, but not yet. And no, I'm not going to discuss when it might
be. Better to assume that it will never be done than for me to seem to
make a promise and then not keep it.


Jim Lane

RJLadd

unread,
Sep 20, 2005, 3:42:10 AM9/20/05
to
On 19 Sep 2005 01:44:32 -0700, send_an...@hotmail.com wrote:
>I'd say decouple right to gate from right to travel through minefields,
>or refuel, for starters. Shared intel should be a higher state than
>just joint battles. "Teammember" comes to mind. Ability to transfer
>ships, or accept transfers. Disclosure of own designs to friends.
>Capacity to grab minerals from each other, perhaps...

Granting/withholding specific information and privileges is the easy
part. But there is also the idea of responses to events that I'm not
sure about. S2 has a problem with multi-way battles, where there are
transitive friend/enemy states, for example.

>Better yet, allow everyone to define their options by selecting a bunch
>of checkboxes essentially covering most of your own control over your
>own empire. For some, "ally" means the "shared gates" is checked, while
>others would keep that one unchecked. A pirate bunch would check the
>"joint battle", the "refuel" and the "shared scans" but not others such
>as one's own map... and so on. Also, the allies would know what kind of
>options they're granted, thus gauging the trust placed on them.
>If these things still have a meaning in the new game, that is. ;-)

There are differences in details, but the general concept is similar.

>> Agree that sharing and/or trading information is important. Map info,
>> technology, designs of parts and ships, etc. should all be eligible.
>> The new game engine allows for it.
>What about transferring half-built or obsolete ships and allowing the
>receiver to complete/upgrade them?

SN had a ship update model. Implementing it turned out to be rather
complex. How much change to a design can be done before the ship is
scrapped and a new one built? There are ways to do this, but when you
think through all the cases, it gets harder.

But the new game engine doesn't require transferring ships to trade
tech, You can simply hand over the knowledge, assuming that the other
party is capable of understanding it. That last part, BTW, gets pretty
interesting.

>> >* More map features
>> Such as?
>I bet he means something like what Xtreme Borders offers. ;-)

Haven't played it. Care to educate me?

>> But I'll say it again, and again, and again, until it sinks in: don't
>> count on me to ever finish it. This is a hobby for me, not a living.
>But of course, Stars! is only a hobby, not a living, ain't it? ;-)

Even S2 at its peak was not a living for Jeff and Jeff. But its
amazing how many people seem to think that a software author (or any
other kind of author) owes them something as soon as the author
discusses their ideas in public.

>> I'm discussing my intentions here simply as a member of the community
>> of Stars! fans, not as some kind of authority figure. If you want such
>> a game, write it yourself. If you finish before I do, perhaps I'll
>> drop mine and play yours instead.
>As long as this is not a commercial effort, why not join forces instead
>of going everyone on his own?

I would consider that, but it would have to be just the right people.
As I said, I have a vision for what I'm doing. Jeff M had a vision for
SN, and it turned out that his vision and mine were close enough to us
to enjoy working together,

Although...the other people working on SN had a habit of finding other
places to be when Jeff and I got into a design discussion. These
"discussions" had a tendency to be long, fast paced, and quite loud,
to the point where some people figured we were going to kill each
other. Nobody really understood that Jeff and I could argue vehemently
without actually getting ego-involved. We each had too much respect
for the other not to take each other's POV seriously. And when it was
over, we'd go for lunch, still friends.

Anyway, I didn't say that it would not be commercial. If/when I finish
it, assuming its good enough that I want to publicly put my name on
it, I'll probably self-publish it via a web site. I can't justify the
writing of this on economic grounds (I might make more per hour at a
fast food place), but extra income is still nice to have.

>Awww, well, my new Warp11 engine beckons me from the garage...

SN was planning to have a new MT part called the "Spinal Drive" (it
goes to 11 :-).


Jim Lane

RJLadd

unread,
Sep 20, 2005, 4:00:13 AM9/20/05
to
On 19 Sep 2005 02:05:39 -0700, iztok_...@yahoo.com wrote:
>> Since it isn't done, the feature set isn't fixed. But as for general directions...
>I play Stars for quite some time and I still find it a great game. So
>as first I'd like to thank you for making it so great.

Thanks on behalf of Jeff and Jeff, but I had nothing to do with the
writing of Stars! 2.

>> No required limits on number of game objects
>In larger games there's that nasty limit on 512 fleet slots, and for SD
>the 512 minefields.

Right. The only limits are what can fit into memory, or what the
scenario calls for, Keep that last in mind, though, because I think
that some of the best scenarios are ones that place strict limits on
resources.

>The "nastiest" (IMO for other players) is 16 ship design
>slots. But I'm happy to have it, as it results in much less MM when I
>play. Allthough it involves a hard decision when to start buiding
>ships,

And forcing that decision is often a good thing, IMO.

>Another feature I'd like to see is some bonus for more active players.
>IMO current game tends to favor players that just sit and grow, until
>they got some big advantage, or they maxx important tech.

I don't intend to reward or penalize players for any particular
approach to a game. If sitting and growing works well and isn't too
boring, do it. Scenario writers (aka the person who sets up the game
parameters) would have some ability to discourage/promote particular
behaviors, though.

>Experience could be calculated from value of destroyed/taken stuff, in
>comparision with players' current economies (so the side that lost
>would also get some), with a treshold where no exp is gain (so just
>tech-trading sites would not give it). That accumulated experience
>should result in a certain percentage better attack, defense,
>initiative and(or?) movement.

Not planning on any kind of in-game experience system at the moment.
That's more of an RPG kind of thing.

>There are also usual demands about balancing PRTs /LRTs, but those will
>be probably done with RDL. I'd just like to propose "standard" settings
>to be included/hard-coded in the game, so it could be played without
>hassle with mods and versions.

If I can create RDL that seems to result in a balanced game, then I
have to keep trying. But one thing that Jeff and I learned from Stars!
2 was that collectively, the player community is smarter than the
game's authors. When (not if) balance flaws are discovered, it will be
possible for the player community to try to fix it without waiting for
me.

>And please include anti-cheating checks.

Absolutely. No game can entirely prevent cheating by a clever enough
hacker who is willing to spend enough time with an assembly language
debugger. But it can be made hard, anyway. And as long as the hacker
does not have access to the turn server, it can be made *very* hard.

S2 used a very cheap form of encryption. I'm using Blowfish at the
moment, and I'm thinking about RSA for communication between the
host/server and the player/client/UI. The NSA will probably be able to
crack the files, but I'm not really too worried about that. :-)

Jim Lane

RJLadd

unread,
Sep 20, 2005, 4:08:10 AM9/20/05
to
On Mon, 19 Sep 2005 10:49:52 -0500, msc...@eris.io.com (MSCHAEF.COM)
wrote:

Not hard. At the moment it is using tries based on a unique 32 bit
identifier. Its a C++ class, though, so I can easily change it to a
hash or some other kind of tree if I don't like the tries.

O(1) is admittedly very nice, but not usable over the course of a
game. Every object ever created in the game has a unique id; ids are
never reused. (4 billion ids is probably enough, even for a large
game. :-) But the id space becomes sparse over time, making O(1)
lookup impractical. So I settle for log(N).

There are enough N^2 algorithms in use that I'm not too worried about
id lookup.


Jim Lane

send_an...@hotmail.com

unread,
Sep 20, 2005, 4:59:54 AM9/20/05
to
Hi,

RJLadd wrote:
> On Mon, 19 Sep 2005 08:30:30 +0200, Dirk Thierbach
> <dthie...@usenet.arcornews.de> wrote:
>
> I like the idea, but I'm not sure how to implement it. You can't just
> draw a border; you need some way of knowing what is going on across it.

If memory serves, there's loads of algorithms for checking "collisions"
or "intrusions" in any given closed polygon. Their flexibility or speed
would be another matter, though.


> That was more-or-less the SN model. I was never really satisfied with
> it, but I didn't have a better idea.

Why not use the stars that are already there?


> Waypoints as regions instead of exact points. I hadn't thought of
> that, either, and I like it quite a bit.

Again, Starcraft comes to mind. ;-)

send_an...@hotmail.com

unread,
Sep 20, 2005, 5:11:50 AM9/20/05
to
RJLadd wrote:
> On 19 Sep 2005 01:18:12 -0700, send_an...@hotmail.com wrote:
>
> There's more than one kind of FTL engine, with different advantages
> and disadvantages. The interesting part is looking at all of the
> engine ideas and coming up with a set of more primitive
> behaviors/characteristics that allow them all to be expressed.
>
> Normal space engines are used during battles. If the hull allows for
> it, a ship could carry both, but there are costs. Thus, with good
> scenario design, the players must trade off between FTL capability and
> battle speed.

Fascinating. :-)_

If you ever need a test pilot for those, I'd like to apply! :-D


> Battles need to be predictable enough to allow players to tune their
> fleet designs and the doctrines given to the different units, but
> shouldn't be 100% deterministic. I've read some real world military
> texts on naval fleet engagements to try to get a feel for it. There
> are some "laws" (really more like rules-of-thumb) that should at least

Wonderful. I actually meant it will no longer be a matter of shields
plus armor minus beams and missiles. Battle speed and manoeuverability
will matter a lot more. :-)

Who knows what new "rules of thumb" can be evolved... ;-)


> If it does, then that possibility will be removed. But note that
> economic warfare is not necessarily the same as economic output.

I hope not. I also hope fine-tuning the balances does allow for some
kind of economic warfare, too. ;-)


> Battles are on the S2 model in the sense that they happen off stage.
> You can reply them, and you can play out mock battles where you
> control the initial conditions, but actual battles can only be
> observed.

I'm relieved. ;-)

<relaxes itchy trigger-fingers>


> Probably, but not yet. And no, I'm not going to discuss when it might
> be. Better to assume that it will never be done than for me to seem to
> make a promise and then not keep it.

Of course. I was thinking of helping things along with feedback and
such, not of setting yet another hurdle. :-P

send_an...@hotmail.com

unread,
Sep 20, 2005, 5:42:55 AM9/20/05
to
RJLadd wrote:
>
> Granting/withholding specific information and privileges is the easy
> part. But there is also the idea of responses to events that I'm not
> sure about. S2 has a problem with multi-way battles, where there are
> transitive friend/enemy states, for example.

Ouch. I can glimpse how complex things can get with the "doctrines" and
"triggers" and such.

I guess I'd try to keep things simple at first until a time came when
they could be evolved to the desired level of complexity...


> SN had a ship update model. Implementing it turned out to be rather
> complex. How much change to a design can be done before the ship is
> scrapped and a new one built? There are ways to do this, but when you
> think through all the cases, it gets harder.

Funny, that. I believed a starting point of a fixed hull where you
attach the parts would allow for easy upgrades, similar to what S2 does
with starbases. :-?

I was thinking more of allowing specialised hulls or parts to be built
by some races and turned over to their clients for further specialised
parts. Now that would be fun! :-)

It could also tie in some ways with the concept of "capturing"
perhaps-partially-destroyed hulls or parts.


<snip>

> assuming that the other party is capable of understanding it.
> That last part, BTW, gets pretty interesting.

Now that you mention it, yes it does. I guess it would be based on some
kind of "smartness" or "learning" factors as some RPGs do?


> >I bet he means something like what Xtreme Borders offers. ;-)
>
> Haven't played it. Care to educate me?

It's not a game, but one of the most well regarded tools for Stars!2
itself.

As he (the author) himself posted just a thread away, the place to
check is:

http://www.pirates.retreat.btinternet.co.uk/indexpr.htm

I haven't extensively used it, but IIRC it's geared toward displaying
map and fleet info in readily ways, such as "biggest is best", spheres
of influence, danger vectors and the like.

Eyecandy such as animated maps over time and statistics of econ growth
or battle prowess over the history of a given game come to mind, too.


> Even S2 at its peak was not a living for Jeff and Jeff. But its
> amazing how many people seem to think that a software author (or any
> other kind of author) owes them something as soon as the author
> discusses their ideas in public.

Might be part of the role-playing, I guess. Or some fandom thing.
People who build 1000+ nubian fleets for a pastime must have other
quirks as well. :-?

Which could explain why superb games where their authors didn't get
involved with the "community" have faded away while this humble
time-waster is still alive, methinks. ;-)


> I would consider that, but it would have to be just the right people.
> As I said, I have a vision for what I'm doing. Jeff M had a vision for
> SN, and it turned out that his vision and mine were close enough to us
> to enjoy working together,

Heh. Not easy, that. Here you would have some kind of authority, I
guess.

There's also the tale of that finnish guy who started with a kernel...
;-)


> "discussions" had a tendency to be long, fast paced, and quite loud,
> to the point where some people figured we were going to kill each

Fortunately, sound carries poorly over Usenet. ;-)


> Anyway, I didn't say that it would not be commercial. If/when I finish

Your game, your rules. :-D


> SN was planning to have a new MT part called the "Spinal Drive" (it
> goes to 11 :-).

Those crafty aliens... :-O

send_an...@hotmail.com

unread,
Sep 20, 2005, 5:58:31 AM9/20/05
to
RJLadd wrote:
>
> Right. The only limits are what can fit into memory, or what the
> scenario calls for, Keep that last in mind, though, because I think
> that some of the best scenarios are ones that place strict limits on
> resources.

... thus disallowing many "surefire" recipes to win. I thought I would
never say this, but some limits kinda might be the best thing, all
things considered. :-O


> Not planning on any kind of in-game experience system at the moment.
> That's more of an RPG kind of thing.

If I could beg for just one feature, that would be at least some simple
kills counter for each ship/crew/whatever. From that humble starting
point, many interesting things could come (in their own sweet time, of
course!).


> debugger. But it can be made hard, anyway. And as long as the hacker
> does not have access to the turn server, it can be made *very* hard.

As long as the creation of "Weapons of Mass Deception" can be made
nigh-impossible, the vast majority of players could relax and enjoy
wasting their time. ;-)

Dirk Thierbach

unread,
Sep 20, 2005, 4:21:49 AM9/20/05
to
RJLadd <nos...@mouse-potato.com> wrote:

> I like the idea, but I'm not sure how to implement it. You can't just
> draw a border; you need some way of knowing what is going on across
> it.

For the game mechanics, polygons (including the map border if necessary)
are sufficient to define regions. For communications, just make
those regions or parts of it visible to other players.

> The engine I'm working on does give the players the ability to draw on
> the map, and various ways to mark out regions. Marked maps can be
> shared.

I meant something like this. Sounds good.

> Since then, though, and given the capabilities of the new game engine,
> I'm thinking about allowing scanners to have a maximum total area, but
> with a controllable shape.

Mpf. At first glance, I'd say it just increases MM, without making the
gameplay more interesting.

> There are some problems with this from a game balance POV, but it
> might be possible to make it work.

If this could be made balanced, there should be a "stone-paper-scissors"
approach to it. But I can't see how.

If it was may game, I'd probably put it into the feature pit :-)

BTW, since we're talking about "stone-paper-scissors", one important
consequence of the limit for ship designs is also that you get the
"design wars". You need to counter-design a given enemy design, he
needs to counter-counter-design, and you cannot do this ad infinitum
because of the limit. So this is a limit I like, though it could be
relaxed for utility ships, and maybe one could "soften" it in some
respects (make designs upgradable, or introduce a tax based on the
active number of warship designs, or something like that).

>>BTW, zones could also be useful for giving game commands: Draw a zone,
>>and then give the command to route all ships of a certain designs,
>>whether present or built in the future, to some destination via the
>>fastes route. Or let all ships of a certain design in a zone return
>>to the nearest starbase to resupply. And so on, and so on.

> Waypoints as regions instead of exact points. I hadn't thought of
> that, either, and I like it quite a bit.

I didn't meant it like waypoints. More like rules that give default
behaviour. If the fleet is in zone X, use battle plan Y. If a new
ship of design Z is built in a zone A, calculate the shortest route
into zone B for it, but set the explicit waypoints. On drawing a new
zone, calculate new waypoints for some of the fleets inside it.
Or set research tax. Or some planet queue elements. And so on.

There are two important principles that show that it's better to keep
a simple list of specific waypoints and orders for each fleet. One is
the principle of least surprise: As I player, I want to be able to
know in advance what my fleets are going to do. It's not good if they
start to move in unexpected directions, because the computer
interpreted their complex orders differently than I did. The second
is that that it should be possible to control the behaviour in great
detail, but one should be able to keep it as simple as possible in
the general case. So when the fleets get orders because of "zone rules",
I still have the option to tweak it for single fleets in ways I like,
if I want to spend the time doing it.

- Dirk

Dirk Thierbach

unread,
Sep 20, 2005, 4:26:20 AM9/20/05
to
RJLadd <nos...@mouse-potato.com> wrote:
> SN had a ship update model. Implementing it turned out to be rather
> complex. How much change to a design can be done before the ship is
> scrapped and a new one built?

Why not keep it simple? The hull must be the same, and the cost of
the update is the cost of all new parts minus the scrap cost of the
old parts, all per slot.

I still see ship update mostly important in connection with some
limit on the number of designs.

>>> >* More map features
>>> Such as?
>>I bet he means something like what Xtreme Borders offers. ;-)

> Haven't played it. Care to educate me?

Xtreme Borders is a utility for Stars!. I'd guess it's a least mentioned
on Autohost somewhere.

- Dirk

Dirk Thierbach

unread,
Sep 20, 2005, 7:00:06 AM9/20/05
to
RJLadd <nos...@mouse-potato.com> wrote:
> On 19 Sep 2005 02:05:39 -0700, iztok_...@yahoo.com wrote:

>>And please include anti-cheating checks.

> Absolutely. No game can entirely prevent cheating by a clever enough
> hacker who is willing to spend enough time with an assembly language
> debugger. But it can be made hard, anyway.

That is security by obscurity, which doesn't work in the long run.

> And as long as the hacker does not have access to the turn server,
> it can be made *very* hard.

There's no point in making encryption hard to protect against cheating.
Encryption (esp public key encryption) protects against the other players,
so they cannot have a look at your files. It cannot protect against
a malevolent host. So you have to trust your host, or use a third-party
hosting service like Autohost, or a non-playing host.

> S2 used a very cheap form of encryption. I'm using Blowfish at the
> moment, and I'm thinking about RSA for communication between the
> host/server and the player/client/UI.

Any public key scheme will do, but the most important thing to protect
against cheats is to verify everything in the input files to the
server. If the input file doesn't contain sensible values, just reject
it.

That also helps a lot with finding bugs :-)

- Dirk

Loren Pechtel

unread,
Sep 20, 2005, 12:27:41 PM9/20/05
to
On Tue, 20 Sep 2005 10:21:49 +0200, Dirk Thierbach
<dthie...@usenet.arcornews.de> wrote:

>because of the limit. So this is a limit I like, though it could be
>relaxed for utility ships, and maybe one could "soften" it in some
>respects (make designs upgradable, or introduce a tax based on the
>active number of warship designs, or something like that).

I've done some thinking on this in the past. How about the following:

While ship hulls are built out of general industry at a shipyard,
components that go on them are not. Instead you must use general
industry to make a factory that makes the component, the factory then
turns out the components at a fixed rate for incorporation into ships.
This adds inertia to your production system--when the next weapon
comes out of the labs you can't just suddenly shift all production
over to it.

Furthermore, refit costs are radically changed. Any shipyard can swap
out systems for improved versions *SO LONG AS THEY ARE NOT BIGGER* at
minimal cost. You need the new system in inventory to do this,
though, and when it's done the old one ends up in inventory.


Also, for research:

There would be two types of research, basic and applied. Basic
research increases your tech level and exposes new
equipment/miniaturizes old equipment but it produces no new systems
itself.

Instead, once the basic research has exposed an option you must do an
applied research project to actually develop *THAT* option. You have
a tech-10 beam but you're now at tech-30. The beam still costs
exactly what it did before unless you do a new applied research
project to develop a miniaturized version of it.

Again, the effect is to introduce inertia and variety. Nobody's going
to develop everything.

Piratelord

unread,
Sep 20, 2005, 12:36:59 PM9/20/05
to
Xtreme Borders isn't a game, but a Stars! Utility.

Visit my stars! page to download (if interested).
http://www.pirates.retreat.btinternet.co.uk/indexpr.htm

Just to correct what has been mentioned in other posts.

Fleet information isn't used, just planet info.
Works best using NewReports and can use multiple players files.
There was also going to be a "animated" map feature, but I scrapped the
idea.

There is no readme, but it's fairly simple to use.


The other program of mine that has peoples interest is StarEd, which allows
you to mod stars! by changing the data tables in the exe. One of the Stars!
Jeffs even contacted me and helped me with some areas I was stuck on.


Dirk Thierbach

unread,
Sep 20, 2005, 1:35:09 PM9/20/05
to
Loren Pechtel <lorenp...@remove.hotmail.com> wrote:

> While ship hulls are built out of general industry at a shipyard,
> components that go on them are not. Instead you must use general
> industry to make a factory that makes the component, the factory then
> turns out the components at a fixed rate for incorporation into ships.

If you have to manage all components, won't that mean lots and lots
of MM?

> This adds inertia to your production system--when the next weapon
> comes out of the labs you can't just suddenly shift all production
> over to it.

But the inertia is already there -- you'll need to move your newly
produced ships to the front.

> Instead, once the basic research has exposed an option you must do an
> applied research project to actually develop *THAT* option. You have
> a tech-10 beam but you're now at tech-30. The beam still costs
> exactly what it did before unless you do a new applied research
> project to develop a miniaturized version of it.

Again, I think that introduces just MM with enhancing gameplay.

- Dirk

send_an...@hotmail.com

unread,
Sep 21, 2005, 5:25:49 AM9/21/05
to
Hi,

Piratelord wrote:
>
> Fleet information isn't used, just planet info.

Heh, if I had used it oftener, I'd have noticed.

Would be nice to have some "biggest is best" for fleets, too, wouldn't
it?

If you manage to decode that pesky "direction" byte in the report, of
course.

send_an...@hotmail.com

unread,
Sep 21, 2005, 5:38:26 AM9/21/05
to
Dirk Thierbach wrote:
> Loren Pechtel <lorenp...@remove.hotmail.com> wrote:
>
> > While ship hulls are built out of general industry at a shipyard,
> > components that go on them are not. Instead you must use general
> > industry to make a factory that makes the component, the factory then
> > turns out the components at a fixed rate for incorporation into ships.
>
> If you have to manage all components, won't that mean lots and lots
> of MM?

It could be nice as a general underlying concept, perhaps not so as
game mechanics proper.


> > This adds inertia to your production system--when the next weapon
> > comes out of the labs you can't just suddenly shift all production
> > over to it.
>
> But the inertia is already there -- you'll need to move your newly
> produced ships to the front.

And that after you have waited a whole bloody year to get them built!
:-P


> > Instead, once the basic research has exposed an option you must do an
> > applied research project to actually develop *THAT* option. You have
> > a tech-10 beam but you're now at tech-30. The beam still costs
> > exactly what it did before unless you do a new applied research
> > project to develop a miniaturized version of it.
>
> Again, I think that introduces just MM with enhancing gameplay.

General vs Applied research is a common theme in many games. Just
calling the same things by another name and/or allowing some shortcuts.
It would certainly help differentiate everybody's approach to research
w/out introducing too much hassle.

I.e: you *need* Prop20 to get your uber-gate, but you don't *need* to
research all the nifty engines that come with it. OTOH, the pirate HE
bunch next door has no need/means (higher dimensions being barred to
their fragile minds/bodies) to research the gate, but *needs* the nifty
engines for their horde.

Ties nicely with the MT theme, even, where you can get, say, the
Jumpgate, but still need to research to be able to *build* it.

Just 2 cents,

christoph...@gmail.com

unread,
Sep 21, 2005, 12:11:05 PM9/21/05
to
RJLadd wrote:
>
> Since it isn't done, the feature set isn't fixed. But as for general
> directions...
>

Hi Jim. I'm glad to hear that you're working on this. Good luck with
it. :-)

I'd like to make two suggestions if I may.

1) do the tactical battle engine first and release it in some beta
form. Even if people have to manually edit input files to specify what
type and how many ships are involved, having the battle engine out
there early will let you work out bugs in it. It really is one of the
critical parts of the game. I makes sense to get it out early and let
people think about those balancing issues. As a bonus, it will stir up
added interest in the game.

2) consider making the some part of it open source, and then calling
that part as a library. The whole game doesn't have to be open source,
and anyone who works on the open source portion would have no claim to
any royalties if you end up selling the game. The only effect would be
to help you out. You might open source the battle engine, or the
graphics libraries, or whatever you can.

I also have a question. Have you considered making use of the idea of
"star lanes" rather than direct travel between stars? I wont try to
sway you either way. You've already stated that you're making the game
you want to play and that's certainly understandable. I just
personally find that the strategic possibilities associated with choke
points and such make the game more fun. Also, the concept of
interstellar mine fields is patently ridiculous.

Loren Pechtel

unread,
Sep 21, 2005, 6:26:46 PM9/21/05
to
On Tue, 20 Sep 2005 19:35:09 +0200, Dirk Thierbach
<dthie...@usenet.arcornews.de> wrote:

>Loren Pechtel <lorenp...@remove.hotmail.com> wrote:
>
>> While ship hulls are built out of general industry at a shipyard,
>> components that go on them are not. Instead you must use general
>> industry to make a factory that makes the component, the factory then
>> turns out the components at a fixed rate for incorporation into ships.
>
>If you have to manage all components, won't that mean lots and lots
>of MM?

You have to build the factories that make them. I'm thinking that all
inter-planet transport should be handled partially in the background.
You tell the game where you want the stuff and behind the scenes
freighters move it there by any safe route. Players only operate
freighters when they need to move in war zones.

>> This adds inertia to your production system--when the next weapon
>> comes out of the labs you can't just suddenly shift all production
>> over to it.
>
>But the inertia is already there -- you'll need to move your newly
>produced ships to the front.

I'm increasing it.

>> Instead, once the basic research has exposed an option you must do an
>> applied research project to actually develop *THAT* option. You have
>> a tech-10 beam but you're now at tech-30. The beam still costs
>> exactly what it did before unless you do a new applied research
>> project to develop a miniaturized version of it.
>
>Again, I think that introduces just MM with enhancing gameplay.

I'm trying to avoid everyone following the same technology track. In
the real world the old technology hangs around for a while when the
new comes out.

RJLadd

unread,
Sep 22, 2005, 12:21:16 AM9/22/05
to
On Tue, 20 Sep 2005 10:21:49 +0200, Dirk Thierbach
<dthie...@usenet.arcornews.de> wrote:
>RJLadd <nos...@mouse-potato.com> wrote:
>
>> I like the idea, but I'm not sure how to implement it. You can't just
>> draw a border; you need some way of knowing what is going on across
>> it.
>For the game mechanics, polygons (including the map border if necessary)
>are sufficient to define regions. For communications, just make
>those regions or parts of it visible to other players.

That wasn't what I meant. The drawing part is easy, but what does a
drawn border mean? If its just a line on a map, no problem. Polygons,
splines, whatever. But SN had a concept of a border that would notify
you if anyone crossed it. That heads in a harder direction.

>> Since then, though, and given the capabilities of the new game engine,
>> I'm thinking about allowing scanners to have a maximum total area, but
>> with a controllable shape.
>Mpf. At first glance, I'd say it just increases MM, without making the
>gameplay more interesting.

Interesting game play is, at heart, about limits and working within
them. The game must cause players to make choices. If there is only
one correct choice, then its just micro management.

But consider a game where you can have only one scanner per start
system, and can control its shape as long as its total area is
constant. Do you leave it as a circle, so you can see things in all
directions? Are there particular directions that are more interesting?
If you point it long and narrow at an emery, and the enemy figures
that out, will they go around it and hit you from a blind direction?
Can you make an enemy think that you are doing that, while actually
covering the blind sport some other way, and ambush them?

But I'm not yet sure how to make the tradeoff between extra strategy
and extra workload worthwhile.

The entire idea falls apart if you can have many scanners per
location. But the game engine is designed to permit things, instead of
imposing arbitrary (and complex to implement) restrictions. The
limitations that make the game interesting are, and should be,
properties of the scenario design / game setup.

>If it was may game, I'd probably put it into the feature pit :-)

At the moment, the idea is in limbo.

>BTW, since we're talking about "stone-paper-scissors", one important
>consequence of the limit for ship designs is also that you get the
>"design wars".

From a game designer POV, the 16 design limit is one of my favorite
features in Stars! 2. Forces the players to make choices and
tradeoffs.

>>>BTW, zones could also be useful for giving game commands: Draw a zone,
>>>and then give the command to route all ships of a certain designs,
>>>whether present or built in the future, to some destination via the
>>>fastes route. Or let all ships of a certain design in a zone return
>>>to the nearest starbase to resupply. And so on, and so on.
>> Waypoints as regions instead of exact points. I hadn't thought of
>> that, either, and I like it quite a bit.
>I didn't meant it like waypoints. More like rules that give default
>behaviour. If the fleet is in zone X, use battle plan Y. If a new
>ship of design Z is built in a zone A, calculate the shortest route
>into zone B for it, but set the explicit waypoints. On drawing a new
>zone, calculate new waypoints for some of the fleets inside it.
>Or set research tax. Or some planet queue elements. And so on.

Drawing a zone and saying that being in / entering the zone triggers
some status change in your units is already planned. Likewise, drawing
a zone and saying that the occurrence of some event in that zone (such
as another player's unit being seen in it) triggers some actions on
the part of your units. These are outgrowths from the poorly designed
S2 patrol orders.

>There are two important principles that show that it's better to keep
>a simple list of specific waypoints and orders for each fleet.

Using a zone as a pseudo way point does not really change this. If a
ship is required to pass through some zone as part of its orders, it
will pick a specific point in that zone via a simple rule, and set
that as a way point.

>So when the fleets get orders because of "zone rules",
>I still have the option to tweak it for single fleets in ways I like,
>if I want to spend the time doing it.

Certainly. Zone rules of any / all kinds are a form of automation,
intended to relieve the player of having to manage the zone
themselves. But all of the automation, outside of the battle engine,
is designed on the idea that it makes a choice for you, tells you
about that choice (if you want to hear about it), and lets you
override if you like.

I haven't done any work on the AIs yet, but much of this automation is
provided by scripts that are intended for eventual AI use.


Jim

RJLadd

unread,
Sep 22, 2005, 12:24:16 AM9/22/05
to
On Tue, 20 Sep 2005 10:26:20 +0200, Dirk Thierbach
<dthie...@usenet.arcornews.de> wrote:
>RJLadd <nos...@mouse-potato.com> wrote:
>> SN had a ship update model. Implementing it turned out to be rather
>> complex. How much change to a design can be done before the ship is
>> scrapped and a new one built?
>Why not keep it simple? The hull must be the same, and the cost of
>the update is the cost of all new parts minus the scrap cost of the
>old parts, all per slot.

A possibility. Jeff and I came up some with odd cases using that
approach, though. I don't remember them at the moment (I'd have to
check my old email), but I recall that there were some problems.

>> Haven't played it. Care to educate me?
>Xtreme Borders is a utility for Stars!. I'd guess it's a least mentioned
>on Autohost somewhere.

Thanks. I haven't actually had time to play a S2 game for quite a
while, and haven't kept up with everything.


Jim Lane

RJLadd

unread,
Sep 22, 2005, 12:27:47 AM9/22/05
to
On 20 Sep 2005 01:59:54 -0700, send_an...@hotmail.com wrote:
>RJLadd wrote:
>> On Mon, 19 Sep 2005 08:30:30 +0200, Dirk Thierbach
>> <dthie...@usenet.arcornews.de> wrote:
>> I like the idea, but I'm not sure how to implement it. You can't just
>> draw a border; you need some way of knowing what is going on across it.
>If memory serves, there's loads of algorithms for checking "collisions"
>or "intrusions" in any given closed polygon. Their flexibility or speed
>would be another matter, though.

They are fundamentally N^2 (e.g. slow), but there are some fairly easy
tricks that help. And there are a number of other N^2 algorithms in a
4X game.

But that's not the problem. The issue is the semantics of a border.
Why is should drawing a line on a map do you any good from a game
engine POV? There must always be some counter to any game action; what
is the counter to a border? Depends on how the border works, and
there's ther problem.


Jim Lane

RJLadd

unread,
Sep 22, 2005, 12:38:33 AM9/22/05
to
On 20 Sep 2005 02:11:50 -0700, send_an...@hotmail.com wrote:
>RJLadd wrote:
>> Normal space engines are used during battles. If the hull allows for
>> it, a ship could carry both, but there are costs. Thus, with good
>> scenario design, the players must trade off between FTL capability and
>> battle speed.
>If you ever need a test pilot for those, I'd like to apply! :-D

Not until I get back. :-)

>> Battles need to be predictable enough to allow players to tune their
>> fleet designs and the doctrines given to the different units, but
>> shouldn't be 100% deterministic. I've read some real world military
>> texts on naval fleet engagements to try to get a feel for it. There
>> are some "laws" (really more like rules-of-thumb) that should at least
>
>Wonderful. I actually meant it will no longer be a matter of shields
>plus armor minus beams and missiles. Battle speed and manoeuverability
>will matter a lot more. :-)

Speed, acceleration, ship volume and mass, maneuverability, electronic
defenses, active point defenses, passive defenses, vs various weaps
technologies, weaps that travel in a straight line at constant or
varying velocity, weaps that can maneuver, weaps with local tactical
intelligence (hard to jam, but not so smart), weaps with remote
tactical IQ (smarter, but easier to jam), weaps that are hard to see
but easy to stop if you can see 'em, and vice versa, ...

Lots of variations. The best part is that I don't have to write C++
code for each of these. I just have a set of simple to implement
primitives that can be combined in various ways. Designing it this way
gives me an exponential number of possible devices from the primitives
I define.

>> Probably, but not yet. And no, I'm not going to discuss when it might
>> be. Better to assume that it will never be done than for me to seem to
>> make a promise and then not keep it.
>Of course. I was thinking of helping things along with feedback and
>such, not of setting yet another hurdle. :-P

If/when it is playable enough to feel like a game, I'll look for early
play testing feedback and alpha / beta testing.


Jim Lane

RJLadd

unread,
Sep 22, 2005, 12:53:29 AM9/22/05
to
On 20 Sep 2005 02:42:55 -0700, send_an...@hotmail.com wrote:
>RJLadd wrote:
>> Granting/withholding specific information and privileges is the easy
>> part. But there is also the idea of responses to events that I'm not
>> sure about. S2 has a problem with multi-way battles, where there are
>> transitive friend/enemy states, for example.
>Ouch. I can glimpse how complex things can get with the "doctrines" and
>"triggers" and such.
>I guess I'd try to keep things simple at first until a time came when
>they could be evolved to the desired level of complexity...

Or...you could put off deciding all of it until later. Sometimes being
lazy is a good thing; maybe I or someone else will have a brainstorm.
or maybe a good approach will be more obvious once other pieces are in
place.

>I was thinking more of allowing specialised hulls or parts to be built
>by some races and turned over to their clients for further specialised
>parts. Now that would be fun! :-)

Yes, but better. Race A can build a ship and give it to race B. Race B
may be able to operate it, but perhaps not very well. If race A
tolerates lots of radiation and race B doesn't, B might be at a real
disadvantage trying to run that ship. Ditto if race A is
carbon/organic and race B is silicon based.

Haven't figured out all of this yet, but that's one part of my race
design ideas. Being carbon based means that you care about particular
properties of a system, and like particular resources. Being silicon
based means you care about different properties, and perhaps like at
least some different resources. Maybe you can mine the resources you
don't have much interest in and sell them to your neighbors.

>> assuming that the other party is capable of understanding it.
>> That last part, BTW, gets pretty interesting.
>Now that you mention it, yes it does. I guess it would be based on some
>kind of "smartness" or "learning" factors as some RPGs do?

I was thinking of more basic characteristics. An AR race may not be
capable of understanding non-AR physics, and vice versa. A mechanical
race may have no use for organic medicine themselves, but they might
be able to use it as a weapon or as trade goods.

>> >I bet he means something like what Xtreme Borders offers. ;-)

...


>I haven't extensively used it, but IIRC it's geared toward displaying
>map and fleet info in readily ways, such as "biggest is best", spheres
>of influence, danger vectors and the like.
>Eyecandy such as animated maps over time and statistics of econ growth
>or battle prowess over the history of a given game come to mind, too.

Eye candy is low on my priority list, but things like displaying
spheres of influence, as computed by various methods, is an important
part of making the player's workload easier.

>> Even S2 at its peak was not a living for Jeff and Jeff. But its
>> amazing how many people seem to think that a software author (or any
>> other kind of author) owes them something as soon as the author
>> discusses their ideas in public.
>Might be part of the role-playing, I guess. Or some fandom thing.
>People who build 1000+ nubian fleets for a pastime must have other
>quirks as well. :-?

You may be on to something there. :-)


Jim Lane


RJLadd

unread,
Sep 22, 2005, 12:59:22 AM9/22/05
to
On 20 Sep 2005 02:58:31 -0700, send_an...@hotmail.com wrote:
>RJLadd wrote:
>> Not planning on any kind of in-game experience system at the moment.
>> That's more of an RPG kind of thing
>If I could beg for just one feature, that would be at least some simple
>kills counter for each ship/crew/whatever. From that humble starting
>point, many interesting things could come (in their own sweet time, of
>course!).

You've got a hard slog ahead of you to convince me that I want to do
that. Not saying that its impossible, but it won't be easy.

>> debugger. But it can be made hard, anyway. And as long as the hacker
>> does not have access to the turn server, it can be made *very* hard.
>As long as the creation of "Weapons of Mass Deception" can be made
>nigh-impossible, the vast majority of players could relax and enjoy
>wasting their time. ;-)

Odd you should put it that way. I would like to create an in-game way
to lie. Consider it a form of espionage, where I can make your
scanners report that my main battle fleet is just a single harmless
scout ship, or that my brand new latest tech ship design is really
just my same old boring design that you beat last turn.

There are major playability and balance issues with this. Jeff and I
worked on it quite a bit for SN (he was determined to add spies to the
game), but I was never entirely satisfied with the design. Still, I'd
like to figure out a way to implement at least some of it.


Jim Lane

RJLadd

unread,
Sep 22, 2005, 1:16:51 AM9/22/05
to
On Tue, 20 Sep 2005 13:00:06 +0200, Dirk Thierbach
<dthie...@usenet.arcornews.de> wrote:
>RJLadd <nos...@mouse-potato.com> wrote:
>> On 19 Sep 2005 02:05:39 -0700, iztok_...@yahoo.com wrote:
>>>And please include anti-cheating checks.
>> Absolutely. No game can entirely prevent cheating by a clever enough
>> hacker who is willing to spend enough time with an assembly language
>> debugger. But it can be made hard, anyway.
>That is security by obscurity, which doesn't work in the long run.

Teach your grandma to suck eggs, too, while you're at it. :-)

>> And as long as the hacker does not have access to the turn server,
>> it can be made *very* hard.
>There's no point in making encryption hard to protect against cheating.
>Encryption (esp public key encryption) protects against the other players,
>so they cannot have a look at your files. It cannot protect against
>a malevolent host. So you have to trust your host, or use a third-party
>hosting service like Autohost, or a non-playing host.

I'm using Blowfish (and SHA) mostly because I can just grab a
reference implementation in C/C++ off the web. I'm a big fan of
stealing from the best. :-)

S2's order giving model was fundamentally broken. Mine is not. S2
depended on the client to check the legality of actions. Mine depends
on the server. S2 was written for a bunch a of friends in the
Microsoft Excel group to play at lunch. I don't have any friends in
the Microsoft Excel group at the moment.

As for looking at files, I plan to publish the file format. Well; sort
of: the files are straight human readable text, compressed to save
space, and encrypted for transmission. You can look at your own files
any way you like. The game will dump them for you if you ask it to.
You can write any tools you wish to help you use the information in
your own files. The files, oddly enough, look a lot like RDL.

The transmission encryption is to prevent anyone else from being able
to look at your files. At the moment it is also Blowfish, but I'll
probably change to public key.

Files kept on the host are encrypted and have various internal
consistency checks. I can't entirely prevent a dedicated host with a
lot of free time from cracking them, but I can make it harder.

>That also helps a lot with finding bugs :-)

Bingo!


Jim Lane

RJLadd

unread,
Sep 22, 2005, 1:23:44 AM9/22/05
to
On Tue, 20 Sep 2005 09:27:41 -0700, Loren Pechtel
<lorenp...@remove.hotmail.com> wrote:
>While ship hulls are built out of general industry at a shipyard,
>components that go on them are not. Instead you must use general
>industry to make a factory that makes the component, the factory then
>turns out the components at a fixed rate for incorporation into ships.
>This adds inertia to your production system--when the next weapon
>comes out of the labs you can't just suddenly shift all production
>over to it.

Between research times, production times, and travel times, there is
already some inertia. I could maybe see some way to control this more,
like allowing for a changeover time/cost for a given facility to "tool
up" for a new part/design, but it would have to be done without adding
to player micro management.

>Furthermore, refit costs are radically changed. Any shipyard can swap
>out systems for improved versions *SO LONG AS THEY ARE NOT BIGGER* at
>minimal cost. You need the new system in inventory to do this,
>though, and when it's done the old one ends up in inventory.

In my game engine, ships have volume, as well as mass. In general, a
larger ship is an easier target in battle. Ship hull slots and the
parts that go into them also have volumes.

>Also, for research:
>There would be two types of research, basic and applied. Basic
>research increases your tech level and exposes new
>equipment/miniaturizes old equipment but it produces no new systems
>itself.
>Instead, once the basic research has exposed an option you must do an
>applied research project to actually develop *THAT* option. You have
>a tech-10 beam but you're now at tech-30. The beam still costs
>exactly what it did before unless you do a new applied research
>project to develop a miniaturized version of it.

I've seen versions of this in other games, but I've never seen it be
anything other than a nuisance for the players. Still, I understand
the attraction of the concept, and I'd like to find a model that would
make it work.


Jim Lane

It is loading more messages.
0 new messages