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.
Jeff
(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.
Jeff
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.
Jeff
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
says...
> ...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.
Jeff
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....
Jeff
in article <364F8A92.E7E61240@wherever.com>, bchicoin@wherever.com
says...
> 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.
Jeff
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
<snip>
> 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
3664.
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
possibilities:
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
year.
Jeff
In article <728ud2$uvk$1@nnrp1.dejanews.com>, aharding@my-dejanews.com
says...
> 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.
Jeff
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.
Jeff
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
situations.
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.
Jeff
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
fleet.
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.
Jeff
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.
Jeff
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
queue.
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....
Jeff
In article <36448460.18917453@news.magma.ca>, sirius@magma.REMOVE.ME.ca
says...
> 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
AR.
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
solution.
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
want.
Jeff
Greetings,
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
movie.
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
says...
> 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.
Jeff
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
loopholes.
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
outstanding.
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
back to FAQ