"Jeff on Supernova" compiled by James McGuigan

From Stars!wiki
Jump to: navigation, search
This was the featured article on 20 March 2012.

From the Advanced and Technical FAQ, as edited by James McGuigan:


Supernova is the next version of Stars. It will be significantly different from the game as it is today. Check out what the authors have to say about it on the 'Supernova' page at Waypoint Zero.

For further hints as to what the game will be like, read 'Jeff on Supernova' It's a collection remarks about Supernova that Stars! co-creator Jeff McBride has posted to the newsgroup, in no particular order. I will update it from time to time, but for the freshest, juiciest info, read the newsgroup yourself, of run your own deja news power search for articles by Jeff.

Jeff on Supernova

Jeff responds to comments about the MT:

> >Or, you are totally insignificant and not worth their attention so they

> >toss you some children's toys, pat you on the head and go on their way.


> I don't really beleave this. First of all WHY do they do that? If they are

> really so tough

> WHY would they contact us, why would they trade with us? Also when you

> trade with them the amount of advances they give you DEPENDS on the amount

> of minerals you give them. This means that they want those minerals, right?

What would you think if I told you that the MT had no use for the

minerals whatsoever? In fact, they have direct energy-matter-energy

conversion. Any particular form of matter is just as good of an energy

source as another. I suppose they convert your minerals (and ships) into

energy but it isn't even much of a snack for their ships.

> If you want something that someone lower than you has what do you do? If you

> want meat that the cow has you aren't going to go trade with the cow, right?

> If you want a whale oil you dont trade with the whale, you hunt it, unless

> someone more powerfull than you (government in this case) wants those whales

> alive.

Has it ever occurred to you that your own personal universe is a very

dark place? How would it feel if you got something for nothing? Would you

be more paranoid or less?

> >In Stars! Supernova you will get a better idea of the scale of the MT

> >ships and the level of their technology. You still won't be able to fight

> >them but then anyone who wants to fight something 100 times the size of a

> >dreadnought and several thousand years ahead in technology would deserve

> >what they got I suppose.


> I have no idea about the scale of MT in SN, but even if you are right, even

> if they have ships 100 times bigger than what we have, WE CAN'T just sit

> here and wait till that someone who protects us stop doing so.

> WE CAN'T totally depend on someone. WE CAN'T be slaves.

You are only a slave to your own mind.

> You are right we

> have no chance to win against the race that has ships 100 times bigger, but

> we can't invent the things they can, we can't go beyond level 26 in tech,

> this means we will have no chance in the future because they will never

> teach us anything really good that can show us the world in the different

> angle and let us reach their level of tech. They will never give it to us,

> unless we come and take it ourselfs.

This, of course, is the "Machine guns for Bushmen" theology.

> If this operation fails this will be

> the last day for our race, but if it succeds we will get a CHANCE to live

> with those guys in peace as an EQUAL race, not a pat. If we don't get this

> chance our race will never go beyond its present level and will disappear

> soon.

With this as a guiding philosophy, the day you gained the the MT's level

of technology would indeed be the last day of your race. Has it occurred

to you that perhaps the MT themselves are not the oldest or most powerful

race in existence? Has it occurred to you that there might just be a lot

more going on than you can see?

> Pretty sad, but thats what it is :-(

Up the dosage.

In fact, it all does make sense if you know what's going on. You have a

few of the clues already. Reread the Stars! story line. This is pre-

history as it was handed down from long ago. How do the Mystery Traders

fit into the history of the universe as you know it? Is it possible that

your history isn't 100% accurate? What if more than one bubble of space-

time did survive? How would you know? Could these other theoretical

bubbles contain their own star systems, races and petty conflicts?

If the Mystery Traders represent one or more races that survived the

destruction of the metaverse, what else has survived? What is the Mystery

Trader's motivation for going around giving candy to babies? Clearly

taking minerals from fledgling races is a calming tactic. Young, violent,

races couldn't understand their real motives so they pretend to be

"traders". If these young races learn something about non-violent

solutions, so much the better.

The true story is long and fairly complicated. As it turns out, Stars! is

part one of a trilogy. In Stars! Supernova you will learn much more about

the true nature of the universe and your place in it. The final answers

and possible solutions will have to wait for Stars! Apocalypse.


(How's that for a tease of the month?)

In article <367f5283.0@d2o101.telia.com>, sb@vip.cybercity.dk says...

> This subject has perhaps been discussed before. I simply wondered why repair

> is a percentage? It means that e.g. a space station spends as much time

> repairing 10% scoutdamage as 10% dreadnought damage. Not very sensible. Why

> isn't repair a fixed (max.) amount of dp? Say 10k for a spacestation and 1k

> for fuelxports? It would too put more emphasis on the role of support

> vessels.

Because it is stored in 7 bits today. Supernova will store exact values.


In article <756vij$5en$1@news.asu.edu>, johnose@research3.asu.edu suggests the MT distribute a toy that increases a races growth rate:

Sorry, the Mystery Trader doesn't sell Viagra.


In article <19981128204626.01125.00002012@ng-ft1.aol.com>,

jmcclave@aol.com says...


> Also, if a player wants to play a more experienced player, he could get a

> handicap of a few hundred points or so ;-)

You're just looking at it backwards. Have the experienced player throw

away a few hundred points if you want to even the playing field a bit. As

soon as you start solving "leveling" problems by allowing players to make

more powerful races you start an escalation war that just won't end. It

plays havoc with balance. Any system that allows arbitrarily powerful

race creation is going to be inherently unbalancable.

For Stars! Supernova this will be a feature of the Race Wizard.

Experienced players will be able to buy "handicap" points using Advantage

Points. These handicap points won't affect game play in any way but will

use up some of their Advantage Points.

What's the point? Well, your handicap value is public information. All

players (and the host) will know the handicap value of every player. For

example, let's say that you want to set up a game with both expert and

intermediate players. The host decides that expert players should submit

races with a handicap of no less than 5 (equivalent to throwing away 500

points). You're feeling macho so you submit a handicap 7 race and blow

everyone away. Now that's a solid victory.

Eventually players will rank themselves by the level of handicapping they

use against other players. Kind of the "I can beat you with one arm tied

behind my back" idea. Hosts will be able to setup games for mixes of

experience levels and players will declare the experience level by

submitting an appropriately handicapped race.

I can also see people setting up tournaments to see who can beat a given

scenario with the most handicapped race and so on.

Naturally you can do something similar today except that there is no way

to publicly distribute the handicap information without making your race

visible to at least the host if not all players.

For many scenarios involving races starting at different levels of

development it will not be necessary or even desirable to use "super"

races. You will be able to set up ownership, population levels and so

forth of each system in the scenario editor. For example, an "evil

empire" v/s "rebel alliance" game would be better suited to a bunch of

normal races, one with vast holdings at the start and the rest in a

preformed alliance and one colony each.

We do understand the desire to occasionally set up scenarios with "super"

races owned by the host or an AI or even a player. It is highly likely

that Stars! Supernova will support this using "Elder" races.

Elder races would have negative handicaps. The trick is that the host

could choose what kind of game they wanted to run. Elder races can be

disallowed, allowed to play but not win or allowed to play and win. And,

like any other "handicap" level, everyone will know what's being played.

Elder races will still be governed by the same rules as any other race.

They will just have more points to spend. We'll never allow races with

all of the advantages of multiple PRTs. With enough points, however, you

would be able to have total immunity, every good LRT, maxed out tech, and

so on. For most scenarios involving Elder races it would probably make

sense to have the elder race have a very low growth rate so that their

holdings remain relatively fixed. The scenario editor will allow you to

set give them as many starting colonies at whatever level of population

and industrialization you want from day one. Even a single world Elder

race would be a force to be reckoned with if it started the game with

max'd out population, res/colonist and tech levels.

I say that the Elder races feature is "highly likely" because we are

implementing it and we will play test it this way. We have some concerns

about the introduction of Elder races. Specifically, the question is,

will we end up with most multiplayer games being populated entirely by

Elder races? As Supernova will be balanced for normal races, not Elder

races, we feel that such an outcome would be very unfortunate. One

solution is to never allow Elder races to actually win. In other words,

they can make you lose but they, themselves are never declared the winner

even if everyone else dies.

That way, in an "all elder" game there would never be a winner, just a

bunch of losers which seems appropriate somehow. :^D

JeffIn article <19981129140800.20815.00002539@ng29.aol.com>, jmcclave@aol.com


> ...will the PRTs we see now be toned down and made into LRTs...

Uh. Not sure if you've got the wrong medication or not. I suggest upping

the dosage.

Some of the new PRTs will be radically different such as the Synthetic

one I mentioned earlier. There will still be recognizable War Mongers,

Super Stealths and so on. The details will change to accommodate the new

game model and feature set but most of the existing PRTs will still exist

in one form or another.

Under no circumstances will we ever LRTize War Monger, Super Stealth,

Space Demolition or so on. That would defeat the whole purpose of having

PRTs and LRTs. The only thing that matters is that every PRT needs to

have at least one unique "must have" feature and at least one

disadvantage. As long as players feel the frustration of not being able

to get everything they want, we've done the right thing.

Many of the existing LRTs are going away or being changed beyond

recognition. Many new ones are being added.


Here's one to chew on for a while. One of the new PRTs for Supernova is

"Synthetic" which means mechanical, manufactured or artificial. In other

words, the race was originally designed (in a non-organic way) by some

other race long ago. You can think of them as robots, cyborgs or androids

if you like.

In many ways they are as different as AR races are today. For example

they do not have a population growth rate. They build their population

in the production queue using minerals and resources. Environmental

conditions affect their efficiency at production, research and so on.

Naturally the cost and efficiency values are adjustable in the Race

Wizard and, as with AR, there are many other differences from "normal"

races as well. For example, Synthetic races are immune to Plague....


in article <364F8A92.E7E61240@wherever.com>, bchicoin@wherever.com


> errr? i thought my eyes were bad, i only have a 17" monitor and i use 1152x864

> and can see most of the galaxy at 100% zoom and read the names with no

> problems... hmm i'm starting to feel a little better, i was gonna go for

> glasses, but maybe not now... 8-)

> > > >>>You should see Stars! on a 19inch at 1600x1200.. I can zoom in quite a

> > > >>>ways and still see the entire map on a huge universe.

> > BTW, 1280x1024 on 19" is working pretty good for me too. Of course,

> > our old eys have more problems with 1600x1200 than some of these

> > young whippersnappers'.

So, I guess 1800x1440 on a 21" is right out then? Unfortunately my video

card will only do that in 16bit color which is fine for Stars! but not

for Supernova development so I generally stick to 1600x1280 at 24bits.


PS Did I mention that anything beyond three feet in front of me is a

blur? <grin>In article <728bn5$fo4$1@nnrp1.dejanews.com>, jasoncawley@msn.com says...

> In article <MPG.10b1088ff08ea379896a0@news.teleport.com>,

> crisium@teleport.com (Jeff McBride) wrote:

> The trick is coming up with the best way to

> > determine which fleets and which classes of ships, for which upgrades are

> > available, are the most critical to work on. Suggestions?


> How about if the computer looks at the tech difference in the two designs,

> and favors upgrades with the widest difference


> The only danger I can see to favoring the big ships and weapons in this way

> would be perhaps blocking things up if the planet can't afford to do the job

> quickly. But I don't know if that would be a problem, since I don't know what

> all the player options are for altering things.


> I think 90% of the time people will want the big weapons-effecting upgrades

> on their best warships first. Large-scale upgrades to very old designs would

> also be favored over tweaks to fairly modern ones, at least for vessels of

> similar size.

Pretty good idea Jason. I've been thinking along similar lines but want

to place a bit more importance on the age difference.

For Supernova we are storing the design year, number built, number in

service, number destroyed in combat and so on for each design so it isn't

difficult to take one or more of these items into account.

In your example, let's say that the "Ramilles" was designed on year 3657,

the "Warspite" on year 3668, the "Miner-36" on 3639 and the "Miner-54" on


Okay, say the current year is 3669.

Ramilles is 9 years older than the Warspite design and any ships of that

type may be up to 10 years old.

Miner-36 is 25 years older than the Miner-54 design and any ships of that

type may be up to 30 years old.

Okay, given the "tech" values you came up with of 336 for the Ramilles

upgrade and 10 for the Miner-54 upgrade, there are a couple of


Let's multiply each value by the number of years old ships of that type

might be and see what happens:

Ramilles would get a value of 336*10 = 3360.

Miner-36 would get a value of 10*30 = 300.

This would still favor the warships the way that Jason wanted but also

give an edge to weeding out the older designs.

Another option would be to take the total number in existence into

account. Remember that, the way that upgrades work, you can't design a

second upgrade until all of the original base design have been upgraded,

scrapped or destroyed in battle. So, it might make sense to give that a

little weight. Let's say that you've got 40 of those Ramilles ships

floating around and only 4 of the Miner-36's left. You have to upgrade

400 of the Ramilles ships before you can design something to upgrade

Warspites to. You only have to upgrade 4 of the Miner-36s before its

upgrade slot becomes available...

So, there are 10 times more of the Ramilles ships than the Miner-36's

left. If we wanted to give preference to the ships with fewer remaining

instances (of the base design) we could multiply the Miner-36's score by

10 to get 3000.

We would still upgrade the Ramilles class ships first. The story would be

different if there were a few more Ramilles in existence or a few less

Miner-35s or if the Warspite design was closer to the Ramilles or ...

I'm not looking for a final formula right this instant. Just tossing out

a few ideas for you guys to gnaw on for a while. Obviously, the

multipliers I tossed out for age and rareness wouldn't have to be 1 to 1.

I think it does make sense to take both factors into account however.

Without some kind of multiplier for age the lowly Miner-36s could get

stuck there for a very long time becoming more and more obsolete year by



In article <728ud2$uvk$1@nnrp1.dejanews.com>, aharding@my-dejanews.com


> Another thing about messages - I want to be able to send messages to myself

> to arrive x turns from now. That way if I'm pressed for time when I need to

> make a known and pre-planned change to orders I will get a reminder. Even

> just allowing messages to myself one turn ahead would be useful. Naturally, a

> message to everyone shouldn't get echoed back to me but I would like to have

> my own name available in the 'send to' box.

In Supernova, you can attach text notes to just about everything and set

triggers to remind you of a note in X years.


In article <3647334A.5FB@here.com>, me@here.com says...

> If you had a group of DD that is 75% damaged that went in for an upgrade

> would all the damage be repaired in the upgrade? would that cost in

> minerals/resources be figured in or would it be free?

For Supernova, major repairs will always cost minerals and resources.

There is no free lunch.


In article <36471A60.938EC788@dc.SPAM.net>, leonard@dc.SPAM.net says...

> Consider the problem of keeping *multiple* reserve fleets, perhaps local

> missile forces which are not gateable. Again, you want to only upgrade

> as many as can happen in a turn, to keep flexible, but this time you

> have to do it for all of N fleets. Whereas with autoUpgrade (and all N

> fleets at a major planet with that order in the Q), all you need to do

> is change the design -- you never even have to know which fleets it

> applies to! Clearly, this is more MM saved -- the need to slap on a

> filter to go find all the ships of a class, then order all of them at a

> reasonably major planet to upgrade. The ones not at a major planet, of

> course, are a MM pain no matter how you slice it.

Hi Leonard,

You make a good case for having a second mechanism. In fact, better than

you know, as one of the other new waypoint tasks is Garrison. Garrisoned

fleets are filtered out together. In other words, you show or hide all of

your garrisons at once in the map or in reports. When garrisons do show

up the fleets that make up the garrison are on a Garrison sub-menu off of

the main right click menu at the colony.

When you assign a fleet the Garrison waypoint task it automatically takes

on the Garrison battle plan and then returns to its original battle plan

when you give it other orders. The default Garrison battle plan focuses

on protecting the starbase if it exists which means trying to keep armed

opponents from getting close enough to attack, taking out their ship with

longer range weapons first and so on.

I don't have a serious problem with having a production queue item like

Auto-Upgrade Ships. I am hesitant to make it more complicated than that.

I don't want to add a dozen new queue items (Auto-Upgrade Bombers, Auto-

Upgrade Colonizers, etc). The trick is coming up with the best way to

determine which fleets and which classes of ships, for which upgrades are

available, are the most critical to work on. Suggestions?

Does it make any sense to allow "Auto-Upgrade Ships ... Up to 10"? or

should Auto-Upgrade Ships work like Auto-Build Mineral Alchemy in that

all remaining resources and minerals would be spent. Doesn't really make

a big difference except in the small additional U/I complexity of having

"up to X". Either one will take about the same amount of documentation.

Whichever ships were chosen would be pulled from the fleet(s) at the

start of the year and placed in the queue. At the end of the year the

ships would be placed back in the original fleet(s).

It is entirely reasonable that those ships are not available for work, be

it mine laying or combat or whatever, if they are scheduled for refit.

Naturally, if the fleets no longer existed due to battle or whatever,

they would form a new fleet.

So, if we did this then you could easily upgrade your garrisons and other

stationary ships. You could force a particular fleet to upgrade and

either have it wait until the upgrade was finished or just drop off the

obsolete ships and move on. All three of these things seem like common


Fortunately, other than the code to choose which fleets/ships are

"worthy" of upgrade right now, the rest of this feature is trivial given

the current design.


In article <36482c56.1155194@ftl.msen.com>, grywzrd@home.msen.com says...

> lost.remove-this.txns@tiac./no.spam/.net (Boyd Gochenour) wrote:

>Agreed - the flat list data view is cumbersome. I believe an explorer

>tree view would be preferable.

>organize by race.hull-type.design or race.ship-type.hull-type.design (

>ship-type being warship, bomber, capital ship, etc.

An explorer style tree is hardly optimal for this. There are three

controls to select what you are viewing in the ship designer for Stars!

Supernova. A dropdown to select who's stuff you are interested in. A

second dropdown to select what kind of stuff you want to see. And, a tall

listbox to show the names of those designs.

For example you might want to look at:

Enemy Bombers or Allied Warships or Your Starbases or whatever.

The "who" dropdown includes the name of every race and every team as well

as Friend, Enemy and Neutral. The "what" dropdown will include broad

categories like Ships and Starbases as well as finer options like

Escorts, Colonizers and Bombers.

The listbox shows about 20 designs at a time. For you own ships, the

current "Upgrade" design that is available in the production queue is

listed in black with the older "Base" design listed in grey immediately

above it.

This gives you the ability not only to quickly look at one or more

specific designs for a specific player but also whole categories of ships

belonging to multiple players that are related in some way such as being

your allies or enemies or belonging to team X.

> >I would also love seeing an explorer view on the message queue.

> OH!!! OH!!! OH!!! Yes!!! Excellent suggestion!!!

Again, an explorer style tree would be very cumbersome for viewing

messages. It is not a solution that I would choose to use in this case.

However, we are doing several things to make sifting though messages

significantly easier.

First, we are adding message categorization with a dropdown to select the

message category to view. You'll be able to quickly view only Battle

messages or Production messages or Correspondence and so on.

Second, every page of the Emperor's notebook that refers to something you

might get messages about includes a tall listbox displaying every message

you have received this year that refers to that object in any way. For

example, a message about one of your colonies building a new ship would

show up on the page for the colony and the page for the destination


Message filtering in the notebook will work similar to but be separate

from filtering in the main U/I. For example, you might want to filter out

all mine laying/sweeping messages from the main U/I but still see them in

the Notebook when looking at fleets. In fact, there will be many more

summary messages than there are today. By default, most of the fine

detail messages will be filtered out in the main U/I.

For example, by default population growth messages for each colony will

be filtered out from the main U/I and visible in the Notebook. In the

main U/I you would see a message summarizing the total population change

for the Empire. That message would also show up on the Empire Summary

page of the Notebook. And, naturally, population decrease messages would

not be filtered by default and, obviously, you can change the filtering

at any time. Many other message types such as new mines and factories,

refueling and so on will default to being filtered out in the main U/I.

Finally, there will be a Messages Report which will allow sorting by

message number, category, message id, Goto target and so on.

Also, many reports will allow filtering to be turned on and off. For

example, with filtering enabled for the Messages Report, you would only

see messages in the report that have not been filtered out in the main

U/I. Enabling filtering for your Fleet report would make it follow the

filtering on the map and so on.


In article <3645759c.15114809@news.demon.co.uk>, steve@steve-

law.angel.co.uk says...

> How about a log file for messages. You can maybe save individual

> messages, but I think all corespondences should be automatically saved

> (with year of course). Then you can flick through them whenever you

> want. Select all messages from race X - "ah-ha, I knew we'd agreed on

> Stinky Socks and not LGM 1 - that's war that is!"


> As it is you have to cut and paste them into notepad and save. (And

> sometimes you can't select the message so you have to copy it out by

> hand).

Chronicling, both manual and automatic, is available on a message type

and specific message basis. You can also auto-chronicle other information

such as scoring data, Imperial statistics, personal notes and so on.

The chronicle is stored in HTML format to simplify future publication.

Naturally, the chronicle can be disabled for hot seat games and other

cases where privacy of your local files is not guaranteed.


In article <364359FC.1B0FD0F1@dc.SPAM.net>, leonard@dc.SPAM.net says...

> Jeff McBride wrote:

> > Starbase design slots will also consist of Base and Upgrade designs.

> > There will be a production queue Auto Upgrade option which will behave

> > like an Upgrade to... when a new upgrade is available for the current

> > starbase design.


> You mention an auto-upgrade build-q item for starbases (a great idea!!),

> but not for ship types. Will it work there as well? What I would like,

> in other words, is an autobuild item that will examine the local stock

> of minerals and resources and, if there is enough of all, automatically

> upgrade any upgradeable ship found overhead.


> Clearly this would not allow "fine grained" control over which ship

> types are upgraded, but it would nonetheless be quite handy

Nope. I certainly don't want my starbases arbitrarily ripping ships out

of my fleets that are just there to refuel on their way somewhere else.

The current design makes the choice to refit your ships a fleet task. You

choose which fleets you want upgrade and where it should happen. You

never need to worry about fleets getting side tracked or delayed just

because another fleet is being upgraded at one of its waypoints.

When a fleet has the Upgrade task at a starbase then the starbase

automatically pulls each type of ship out of the fleet for which there is

an upgrade available and inserts them into the production queue. If the

fleet is not emptied by this action it will wait around until the ship

upgrades are finished and then continue on its way.

Naturally you have the option to force the fleet to move on without

waiting for the upgrades to finish. They just leave the ships behind. If

an upgraded ship's fleet has moved on it is placed into a new fleet which

then becomes the destination for any other upgraded ships in the same


The important point here is that while the ships are being upgraded they

are not in any fleet. They are back in the shipyard in an unfinished

state. If the starbase is destroyed while ships are being upgraded those

ships are destroyed just as a brand new 99% complete battleship would be.

> I like the

> idea of being able to induce an upgrade merely by ordering my ships to a

> certain place (home planet, most likely).

Which is exactly what you get.

> I also rather like the idea

> of putting such an order in a queue template, to be used on most fully

> developed places. That way, many upgrades could be done simply by

> changing the design to have an Update -- all the actual build-queue

> action would happen automatically (assuming all fleets of that ship type

> were in garrison, which happens reasonably often). I think it would be

> reasonable to make the autoupgrade for ships prefer to upgrade any ship

> overhead that *also* have the upgrade order set for their fleet, as

> compared to those that might be upgraded but don't have the order set.

When a ship upgrade is in the production queue it is an actual physical

ship that is sitting there in the queue waiting for work or being worked

on. It isn't something you can make a template for. If you want to give

all of the fleets at a specific location, or that contain a specific

design, orders to upgrade at their current location it's just a couple of

clicks of the mouse in the Fleet Report. Reports in Supernova support

multi-select and group actions....


In article <36448460.18917453@news.magma.ca>, sirius@magma.REMOVE.ME.ca


> Personally, I rather they just get rid of colonizers altogether (in

> Supernova). Make invasion and colonizing the same thing. Thus, no

> confusion.

In fact, colonizing and invading are very similar in Supernova except

that you colonize with a colonizer hull and you invade with a troop ship.

In both cases the fleet is dismantled at the destination to construct the

base of operations, basic supplies and tools needed for the job.

There is no confusion because you can never colonize with a troop ship

nor can you invade with a colonizer. And, of course, AR can not invade

nor be invaded so the only way to take over an AR world is to destroy

them and then colonize the planet. That's true even if you are also an


Your colonists or troops are removed from the production planet when the

colonizer or troop ship is built just as if they were a required mineral.

It is the only way to force colonists or troops to go somewhere in

particular and you can only get them out of the ships by colonizing,

invading or scrapping at the destination. And, of course, colonizers and

troop ships will be very expensive.

Naturally this begs the question, "Then how do I move my people around?".

The answer is that you don't. They move themselves via standard

commercial travel. Just as, in real life, your government doesn't tell

you which city you must live in, you as Emperor don't worry about which

colony has which colonists in it.

You will have controls which will influence their behavior just as the

governments do today. Provide jobs (mines, factories, defenses, etc).

Make the environment livable. Make the colony safe. There will be many

factors that control the flow of colonists.

If one of your worlds is being bombed there will be a tendency to

evacuate. It won't happen all at once but as the bombing continues from

year to year the evacuation will accelerate. In other words, you had

better do something about the threat or they will eventually abandon the

colony all together. Of course that is only partially true. If a blockade

is in effect they will not be able to leave at all.

And, of course and as always, when I drop a tiny sliver of information

like this the cries stream forth of "Oh No! That can't work." That would

be true if the entire rest of the Supernova feature set was the same as

Stars! is today.

Just assume that Stars! Supernova is an entirely different game that just

happens to have a few elements in common with Stars!. Stars! Supernova

has no freighters or cargo or Transport waypoint task. It doesn't need

them. On the other hand, it has far more things to occupy your mind than

Stars! does today.

Jeff McBrideIn article <3645693b.1101187@ftl.msen.com>, grywzrd@home.msen.com says...

> If I read the information that Jeff provided earlier this year

> correctly, he was trying to fit the entire business into a 64K data

> limit. This limit isn't quite as hard to get around now in a 32-bit

> environment. Also, I'm assuming that Jeff's learned a thing or do

> about dynamic arrays. GRIN

Uh, not quite. The array of pointers to fleets, which is dynamic, had to

fit at its largest size in a single 64k segment because Stars! is a 16bit

app. This resulted in a cap on the maximum number of fleets in the game.

We felt that it would be inappropriate to allow one player to have more

than their fair share of fleets, at the possible expense of another, so

we hard coded Stars! to limit each player to 512 even if the array hasn't

reached its maximum size yet.

Naturally we could have provided a separate array of fleet pointers for

each player or made them linked lists but either one of those options

would have greatly slowed down every aspect of turn generation and

significantly increased the complexity of every single routine that

touched a fleet.

Naturally no such limit exists in the 32bit world. For Stars! Supernova,

any limitation we place on the maximum number of fleets per player or

ships per fleet or minefields per player and so on will be based on

balance and game play issues rather than arbitrary restrictions imposed

by the architecture of the CPU.

JeffIn article <720vna$6gi$1@pegasus.csx.cam.ac.uk>, njb35@spam.ac.uk says...

> Kitarak wrote in message <19981106055318.01919.00002747@ngol04.aol.com>...

> >What I would really like to see is a sort of production queue, but for

> >research. For example you could say "Research 3 levels propulsion, 2

> Biotech, 5

> >weapons" and also you would be able to set a default. This would be

> especially

> >useful for force generated games.

> Also useful for those times when you have the resources to make those three

> final tech levels you've been waiting for....in three different fields. The

> "next field to research" is a damn good function, not just to save resources

> but also time, but I would like "next field after that" maybe.

We thought about having a research queue in Stars! Supernova and even

mocked up a couple of variants of the interface for it. We certainly

understand the desire for better automation of your research path.

However, in general, people have a specific technology or set of

technologies in mind when they are making research decisions.

In the end we decided to allow you to choose a target technology instead.

So, you have all of the options you have today plus the ability to pick

the next tech item you want to work towards regardless of the number of

tech fields or levels it requires.

The game will automatically research the required levels of the required

fields in the most efficient manner possible such that intermediate

technologies will be learned as quickly as possible.

This gives you nearly the same level of control that a full research

queue would give you but with a much less complicated user interface and

without forcing you to look at the tech browser and say "Let's see, I

need 4 levels of this and 2 levels of that..." It is a more elegant


While a queue for tart technologies would be useful we decided not to

implement it because research, for the most part, will be far slower in

Stars! Supernova than it is today. You won't be leaping ahead multiple

tech levels in a single year. It just won't happen.

Players in Jump games will almost certainly choose "Lowest Field" as the

option because every tech field will be, on average, equally important.

Naturally for any specific PRT there will be some tech fields they care

about more than others. The point is that there will be no field that you

can totally ignore.

There will also be a replacement for ABBS which will allow you to choose

how developed the players are at the start of the game. Not only will

this affect starting populations and installations but it will also

affect starting tech levels and so on. When combined with the Scenario

Editor you will be able to set up games that start just about any way you




There has been a lot of speculation and no small amount of whining

recently about the 16 slot ship design limit.

One of the original goals was to limit the amount of clutter in the user

interface. We wanted to force fleets to have a small, countable, number

of unique ship types. There are dozens of places in the interface where

the display of the fleet composition would get seriously out of hand if

an arbitrary number of designs were allowed at once.

One good example is the dialog for moving ships back and forth between

fleets. An arbitrary number of designs would also seriously clutter your

production queues. Finding the ship you want to build would be a pain.

Even today the list of other players' designs in the Ship Designer is

totally out of hand. Imagine what it would be like if every player had an

unlimited number of design slots available.

Another, equally important, goal is gameplay and balance. We feel that it

is important for players to have to make good decisions about what to

build. What to research. When to scrap. When to redesign. When to stop

building and so on.

When we designed Stars! 1.0 we picked a number of ship design slots that

allowed players to do all of the tasks that were required of them and

then some. Although there were a few complaints even then, 16 design

slots was quite sufficient for the feature set at the time.

Since that time a lot has happened. For example, mine layers didn't exist

in 1.0. You couldn't give ships away even in 2.0 and so on. For Stars!

2.6/2.7, the 16 slot limit is anywhere from barely adequate to not nearly

enough depending on the race you are playing and your style of play.

So, why haven't we changed it in one of the myriad patches that have come

out in the last few years? That's where the coding concerns come in.

Stars! was designed with the game's memory footprint and file sizes as

one of the primary concerns. Most data structures in Stars! are packed to

the bit level and, due to the initial design of Stars! 1.0, in many

places hull id numbers are stored in 4 bits. In hindsight, we probably

should have changed this for 2.0 but it didn't seem worth the effort at

the time.

Because of the critical role that ships play in this game the number of

places the code would have to change to support more than 16 designs is

far too large to consider for a 2.x patch. The fleet structure is also

not well suited today for more than 16 designs. Changing the fleet

structure to support more than 16 designs would either require a complete

redesign or would greatly increase Stars!' memory usage. The U/I changes

required would also be significant.

Fortunately, Stars! Supernova is pretty much a rewrite from the ground

up. Everything has changed. The above concerns no longer apply. We still

believe that a limited number of ship design slots is appropriate. The

limit for Supernova, however, will take into account all of the ship

tasks players will need to accomplish as well as upgrading and trading.

Furthermore, the new data structures will allow adjustment of that number

during play testing.

Each ship design slot will hold two designs: Base and Upgrade. The player

starts by designing the Base design. It is available for production and

the player goes on about their business. Later, when it comes time to

improve the design, they go back to the ship designer, select the Base

design and choose to design the upgrade. They can start with a copy of

the Base design or from scratch. The cost of upgrades will be calculated

much like they are for starbases today. Once they have designed an

Upgrade, it is available for production and the Base design can no longer

be built.

Assuming we didn't change the number of design slots this means you would

be able to have 32 designs in play but only 16 in production at a time.

You will give a fleet the Upgrade waypoint task at a starbase. All ships

for which upgrades are available will automatically be pulled out of the

fleet and placed in the production queue as "Upgrade to...". Once the

upgrades are completed the upgraded ships are placed back into their

original fleet, if possible, or a new fleet if not. Once all ships of a

Base type have been upgraded, scrapped or killed in battle that design is

automatically deleted and the Upgrade design becomes the Base design

allowing you to design yet another Upgrade in the future. The exact

number of slots allowed will be determined during play testing.

Starbase design slots will also consist of Base and Upgrade designs.

There will be a production queue Auto Upgrade option which will behave

like an Upgrade to... when a new upgrade is available for the current

starbase design. It will also still be possible to manually change from

any design to any other design as you can today.

Ships that you are given or that you steal from others will be stored in

a separate list and will not take away any design slots. Due to the

elimination of freighters for Stars! Supernova and the separation of

buildable designs from "gift" designs, it is likely that the number of

ship designs allowed will not increase all that much. As I said above,

even if we kept the limit at 16 you would still be able to have 32

different designs in play. It is conceivable that during play testing we

may decide to take this number up to, perhaps, as many as 20 in

production and 40 in play. I wouldn't bet on it though.

Jeff McBride

referring to tech trading, Jeff says:

Hi Everyone, (teaser time)

You can't imagine how much I enjoy getting rid of this nonsense for

Stars! Supernova.

There will still be a slight chance of gaining tech through battle but it

will be based on both the difference in tech levels and the total tonnage

destroyed. Victors and bystanders at major battles will have a chance to

sift the wreckage and discover something but you will *not* be able to

use battle or scrapping or invasion to trade tech. Just won't happen.

Gain will never be in whole levels.

On the other hand, there will be an automatic tech osmosis that happens

between friends where you will gain a small amount each year in the field

your friend exceeds you in the most. Think of it as just being around

them and being observant. The gain will be proportional to the difference

between your tech levels, perhaps something like 2% of a level per level

of difference.

Allies will do the same thing and will also be able to automatically

share part of the tech research they do each year. For the purposes of

this example, I'm using some simple numbers. The actual values and

formulas will differ greatly in the real game.

Let's say that you are researching a field and spend enough to gain half

a level (50%). For each ally you have reduced the effectiveness of your

research by some small amount due to having to keep them "in the loop"

and due to having to study the stuff they send you. Lets say you lose 5%

per ally for now. So, if you had two allies you would lose 5+5=10% of

your 50% investment giving you 45% of a level instead of 50%. The lost

effort gets doubled and given to your allies. So, in this case, both of

them would gain 10% of a level in that field. Naturally we only count

allies into this calculation who have the same or lower tech than you in

the field you are researching.

Now let's say that your ally is also studying the same field. He spends

enough to make it 70% of a level. Again, 5+5=10% of this is 7% so he

accomplishes 63% of the level but also gets the 10% from you for a total

of 73%. You and your other ally would each get 7+7=14% so you would go up

from 45% to 59% of a level.

Let's say your other ally also studied the same thing and spent enough to

go up a full level (100%). He ends up with 90% + 10% + 14% = 114% which

means he goes up one level and 14% of the way to the next level. You

would go up 45% + 14% + 20% = 79% of a level. Your other ally would go up

63% + 10% + 20% = 93% of a level.

What happens if you have a higher tech level in the field you are all

studying? You would still lose the 5% to your allies but would not gain

anything from them. So, you would end up with a net 45% gain in the

field. The ally that spent 70% of a level would only lose 3.5% instead of

7% for a net gain of 86.5%. The one that spent 100% would lose 5% instead

of 10% for a net gain of 112%.

As you might be able to tell from these numbers, it will be very unusual

for a player to ever spend enough to go up a whole level in one year with

or without allies.

Try some numbers with 4 allies or 8 allies. It gets very interesting very

quickly. Naturally you have to keep in mind that lower tech races can't

teach higher tech races anything so research strategy will be an

important part of team play in Supernova.

in article <362A03BA.73@erols.com>, crobers@erols.com says...

> Jeff McBride wrote:

> > In article <362524fe.5539662@news.mpinet.net>, csubich@ibm.net says...

> > > On Mon, 12 Oct 1998 18:59:45 GMT, crisium@teleport.com (Jeff McBride)

> > > >The only thing it doesn't do, which has been requested from time to time, is allow the host to replace a dropout who wasn't courteous enough

> to resign. There isn't much we can do about that without opening up

> serious loopholes.

> > > A host CAN remove a player's password (resign them) only if all of the other players have submitted their turns.

> > > The game would then send a meggage to all players telling them that

> > > the host has resigned player x.

> > > The password, however, would only be removed the next time all

> > > (active) players submit (valid) turns, meaning no inactive

> > > (unresigned) players.

> > > Even though there is nothing preventing a host from resigning people,

> > > the all-turns-in qualification gurantees that all of the players know

> > > about it.

> > This doesn't close the loophole. It just makes the host jump through a

> > few more hoops to cheat. We have looked at every reasonable solution and, no matter what convoluted steps you take, either the host can crack

> a player's password or not. Either the loophole is there or not. We

> choose to not have the loophole.

> > Have you explored the idea of automatically removing the password once

> _________ turns have been missed AND __________ percent of player files

> are in? I don't see the loophole in that. Further, you could prevent a

> host that is playing in the game from submitting .x files for the dropped

> player by having the program compare footprints.

The exact same loophole is still there. Make N copies of the game. Every

time a player submits a turn copy their .x file into N-1 of the game

directories such that for each directory only one player is missing a

turn. Rest is left as an exercise for the reader...

In article <707p7g$ig4$4@news.metronet.de>, Tocis@gmx.net says...

> The translation has not been an easy process indeed. There are expressions

> in the original that just don't translate without significant problems, like

> Bleeding Edge for example. There is no _short_ expression in German that

> could be used here, or at least we could not come up with a good idea.

> (I was one of the Beta testers of the German version)

Yup. And, that's not nearly as bad as the problems we had with some of

the other names.

Americans think of a Jack of All Trades as being someone who is

reasonably good at anything they try to do. There is no such concept in

German. The closest we could come up with was something like "a guy who

can't master anything." Admittedly "master of none" is the phrase that

normally follows "jack of all trades". Americans tend to focus on the

implied flexibility as a positive thing and Germans see the inability to

"master" something as entirely negative. Same denotation. Very different

connotations. This was a case where we came up with a technically correct

translation but couldn't get the feeling across. Any translation which

implied "generalist" ended up somewhat insulting.

Fortunately the translator knew the meaning of "Blackjack" but said that

"Over here, we call it 21." ROTFL

I didn't even realize until after we shipped that "Daddy Long Leg", a

popular name for a local variety of long legged spider, ended up in

German as "Daddy's Long Leg" which is an entirely different thing and not

to be confused with "Daddy Long Legs" which was a pretty good Fred Astair


We've pretty much come to the conclusion that we aren't going to try to

translate the race attribute and tech item names for Supernova. We will,

however, attempt to find some names that are, perhaps, a little less

prone to cross-cultural confusion.

In article <362400b7.133362460@ftl.msen.com>, grywzrd@home.msen.com


> jeager@bellsouth.net wrote:


> >In article <MPG.108bf141a2f106fa98968a@news.teleport.com>,

> > crisium@teleport.com (Jeff McBride) wrote:


> >> For Stars! Supernova, players will have the option to Resign. The act of

> >> resigning automatically turns the player into an inactive player AND

> >> removes their password. The host could make the race active again if a

> >> replacement was found. All other players would receive an appropriate

> >> message when someone resigns.


> >The removal of the password may cause problems if the game is on AutoHost or

> >a similar medium. Perhaps there could be an option for the host to set a

> >"resign" password at the beginning of the game, that only he knows. When a

> >player resigns, instead of removing the password, it would be changed to the

> >one set by the host. Possible?


> I agree with this. It would be much more secure.

Not really. The player is made inactive at the same time the old password

is removed which gives them an effectively invulnerable password. Sure,

the host could change the player back to active and open the file but

they could also do that if we used a password that they supplied. I'm not

totally opposed to the idea of a "default" host password for such cases

but I'm not convinced that it is necessary.


Hello everyone,

I've been working on a better way to deal with dropouts for Stars!

Supernova and have come up with something that should solve most of the

"dropout" problems hosts and players have been having.

For Stars! Supernova, players will have the option to Resign. The act of

resigning automatically turns the player into an inactive player AND

removes their password. The host could make the race active again if a

replacement was found. All other players would receive an appropriate

message when someone resigns.

Hosts would not have to get involved unless they wanted to insert a

replacement. The switch to "inactive" would be automatic.

Resigning players wouldn't need to worry about finding a replacement or

passing along their password. For large healthy empires, the simple AI

that would take over their race is not ideal as a long term replacement

especially if the player is part of a team. For races on the verge of

death it would be just fine.

Yes, it would still be polite to also find a replacement if you are

leaving your allies in a bad state but that isn't something that can be

automated or regulated.

I believe that it is totally reasonable to ask players to formally Resign

if they are going to quit a game. It isn't much of a burden on them and

doesn't leave the host or other players in a permanent bind.

Admittedly, they could do pretty much the same thing today by submitting

one last turn with a change password order setting the password to

nothing, sending email to the host asking to be made inactive and a

message to all players saying they are leaving.

The only real advantage of the Resign feature is that it does everything

automatically in one quick and easy step and everyone would know the

rules ahead of time so there would be fewer arguments about it.

The only thing it doesn't do, which has been requested from time to time,

is allow the host to replace a dropout who wasn't courteous enough to

resign. There isn't much we can do about that without opening up serious


In article <01bdcdf7$1cd550c0$422412c0@prchb01>, too@much.spam says...

> Has anyone (like the Jeffs :-) kicked around the idea of active/passive

> scanners? Active would be more likely to detect the enemy but also

> broadcast your own position. Passive would be less effective scanning-wise

> but allow you to be more stealthy. Just a thought...

We've considered the idea but resisted so far due to the computationally

expensive nature of the problem. If we do decide to make some scanners

active and some passive for Supernova the obvious solution would be that

"normal" scanners are passive and "penetrating" scanners are active.

There wouldn't be any need to add additional terminology and the

functionality matches the current description quite well. This would

make scanner choice a lot more interesting.

I'm not promising that we'll do this for Supernova but it is the solution

we'll use if we do.

JeffIn article <35D990F7.F6B9A063@bigsky.net>, marlowe@bigsky.net says...

>> Joey Hung wrote:

>>> After looking through all the wonderful Art designs for stars at

>>> http://members.aol.com/omonubi/stars-r-us_frame.html I realize how

>>> much graphics can add to game playing. Better graphics can always

>>> stir more imaginations.

>>> Here is my idea: How about adding some nice pictures or even some

>>> animations along with the message that you receive each turn? For

>>> example, when one receives a colonization message, a pop-up screen

>>> will show a space ship landing slowly onto a planet, and your

>>> colonists walk out and set up a flag or something. Also, you can

>>> have some pictures for different races. For those who perfer only

>>> text, you can add an option that disable all these pictures.

>>> How is this sounds? Comments are more then welcome!

>To be honest, I don't think this would add much to the game in general.

>To have decent animations of this sort, unless they're going to be very

>simple and small, you'd have to either A) put them on your HD, driving

>up your install size unnecessarily, or B) put them on the CD-ROM, thus

>making it necessary for you to have it in the drive, and wait for spin-

>up every time you colonize a planet. This is a very petty gripe, but one

>of the things I really like about Stars! is its lean simplicity -- no

>superfluous bells and whistles, just a great game.

>If such a feature were added, I would definitely want the option to turn

>the animations off, because that's precisely what I would do. Just my

>two cents...

We just say NO to FMV. The only "video" sequence in Supernova will be the

intro segment when you boot the game which will tie in to the storyline

of the tutorial. It's in the works now and looks like it's going to be


The art in the game itself will be predominantly still images. Lots and

lots and lots of them. In fact, it looks like we may not be able to fit

it all on a single CD. We'll probably end up with an install CD and a

play CD. Just to give you an idea, each player will have their own line

of ships with unique images. There will be places in the game where you

can rotate through 8 orientations of these ships at 400x400 pixels each.

With 40 hulls per player and 8 frames per hull we end up with 5120

images. Assuming 24bits per pixel and no compression that comes out to

about 2.5Gb of space. Naturally, we'll have some good compression.

We're also looking at shipping 8, 16 and 24bit art so you'll be able to

choose between high resolution art and disk space. We're not entirely

positive that we can get everything to display to our satisfaction at 8

bits but we haven't given up yet.

Naturally, the 500x500 planets, 200x200 tech items, 300x400 race

portraits, 128x128 race emblems, assorted astronomical art, event

illustrations and so on also take up a bit of space. However, even all

together, they don't come close to the space needed for the ships.

With disk space now under 4 cents a megabyte and memory down under a

dollar a meg we just don't see any reason to scrimp on the artwork. Think

of it like a good German car. Sure, you expect quality engineering under

the hood but you don't mind having the leather seats, woodgrain dash and

nice paint job. Fit and finish is never a substitute for engineering but

we believe that they can happily coexist.

In article <1998081701160200.VAA13155@ladder03.news.aol.com>,

himshu@aol.com says...

> Scoop noticed my distain for some some members of the playing

> community who wish keep the game in a static state, but didn't

> comment on the difficulty I have with authors who are trying to

> follow the followers.

I'm a little confused by this. Our decision to not make any more balance

changes to Stars! 2.x is based on a couple of very simple ideas.

1) We'd rather have all players and hosts using the same version to

reduce confusion and support issues.

2) Any small changes we made would shift the imbalances around but would

not make any fundamental change in the overall playability of the game.

3) And, most importantly, we'd rather be working on Supernova. After

about 4 years of mucking around, Stars! 1.0 shipped in May of '95.

Version 2.0 shipped in Oct of '95. Version 2.5 was, as I recall, May of

'96. Version 2.7 shipped in Dec of '96. Each version we've put out has

been closer and closer to our initial vision for the game.

When we wrote Stars!, it was the game we wanted to play. We've been

playing it for a long time now. It has some great features and has been a

huge amount of fun to write and to play. But, now there is another game

we'd like to play so we're writing it.

> I don't know if Supernova will change this as there are some fundimental

> changes in the presentation of Supernova compared with Stars! It may be

> just like the sequel to a move that aims to capture the popularity of the

> first run but doesnot have the sense of newness.or fails to understand

> the basis of it's former popularity.

That's always a possibility. I suppose that time will tell. It certainly

will not go through major new versions every 6 months like Stars! did for

the first couple of years. It can't. That is totally impractical for a

retail game.

> Well, it did not last for very long. That was a very "exciting" time

> in the history of the game and I have seen nothing like it since. I

> recall seening comments by the Jeffs that they would never again make

> such changes to the game (race wizard) because it would be too

> disruptive to games in progresss.

You came in pretty late in the growth of the game. As the player

community grew and as the game matured there was some pressure to avoid

major changes that would totally invalidate games in progress. It never

occurred to us that people would choose to play "turn a day" or worse.

Stars! was originally designed for LAN play. I can see how it could be a

little odd to be playing a game that has three major revisions before you

finish your first game.

However, that isn't why we stopped making major balance changes. Indeed,

even 2.6 had some pretty significant balance changes. When we made the

deal with Empire Interactive we originally tried to pitch the idea of

creating a Stars! 3 exclusively for them and, while it was in

development, continuing to sell version 2 as shareware. They suggested

turning 2.6 into a viable retail product with a few new features first

and then moving on to Stars! 3. We compromised. We decided to add music

and sound fx but to keep the game play features and file format totally

compatible with 2.6. We've been putting out parallel releases ever since.

We figured that we owed our registered shareware customers that.

When we put out a patch today, not only do we have to worry about how it

affects the balance, stability and fun of the game, we also have to worry

about how it affects the online help, printed documentation and strategy

guide. Balance changes are especially bad for this. Yes, this is one

disadvantage of selling retail rather than as shareware. On the other

hand, we were already suffering from this a bit before we went retail so

I suspect that once a product reaches a certain size and level of

maturity there almost has to be a certain amount of solidification.

> Supernova will someday come out also to all the people looking for the

> latest release. But I wonder if there is a subtle but fundimental

> change in the philosophy that Stars! demonstrated when it was originally

> relaease.

Nope. The only real difference is time and budget. We wrote Stars! for

our own pleasure. It was the game we wanted to play. After we had been

writing and playing Stars! for many years we decided to turn it into

something we could sell. Prior to version 1.0 all of the artwork in the

game was done by myself. You REALLY don't want to see that.

In order to turn Stars! into a viable shareware product we added some

nicer artwork, the computer opponents and the tutorial. We tried very

hard to not cause a dramatic increase in the size of the program because

we knew that we were going to be distributing it electronically and on

floppy disks. It wasn't until 2.6 (something) that the exe and help file

wouldn't zip down small enough to fit on a single floppy.

We are writing Stars! Supernova for our own pleasure. However, we know

that we will be distributing it as a retail product on CDs. Knowing this

we can choose to have the quality and quantity of artwork we feel the

game needs. That doesn't mean that we'd ever use artwork as a substitute

for game play. It just means that we don't have to scrimp just because

the artwork is large or costs money.

> Originally it was written tor windows 3.1 and some of the comments

> from the Jeff's have lead me to believe this was a way of reaching

> the most people for the effort. But Supernova will be written for

> the latest hardware and software available.

When Stars! 1.0 came out, in mid '95, very few game players used Windows

and version 3.1 was the latest and greatest version. Stars! required

far more in terms of memory, disk space and video resolution than any

DOS game on the market. If we had cared about reaching the greatest

number of players we would have written for DOS. The problem is that we

hate DOS. We've always assumed that version 3 would be 32 bits.

> I think that when this comes out there will no longer be support

> for Stars!

It depends on what you mean by that. After Supernova ships will we put

out patches for Stars!? Well, if someone finds a significant bug we will.

Of course I doubt that it will be necessary. Well we ever add new

significant new features to Stars! 2.x. No chance. We've moved on.

> This is my point. It is old and has been growing this way for some

> time. It has been things like new race designs and substantial changes

> in the play ofthe game that encourage some to take a fresh look at the

> game. Perhaps after Supernova is released the code for Stars! will be

> sold to some enterprising group who will take up the challenge for

> many of the ideas presented as idea's for supernova but will not be

> included there.

Sorry. Not a chance.

> The present authors don't wish to "rock the boat" and so disturb the

> present group of followers.

Nope. Not it at all. Check the three points at the beginning of this

post. It all boils down to my time, my time and my time.

> Perhaps there will be otheres with a fresh outlook and

> ready for a challenge.

Absolutely. I've said over and over again that Stars! was created out of

our utter frustration with the multiplayer games on the market. There is

room out there for a ton of games in this genre. If you've got an idea

for a game, go write it. I can only write the game that I want to play.

> To the Jeffs I am very greatful for the work you have done on the game.

> It just seems as if there is not the same forward momentium as their

> once was in the game. With my sincere admiration and hope for a

> positive future.

> Himshu

I'm reasonably sure that I did not explain my position to your

satisfaction. However, many of the people reading this group are

relatively new to Stars! and I felt that this was a good chance to

present some of our history and vision.

Jeff McBride