In Supremacy, I think all four quadrants will be represented in some game modes.

Also, the supernova event IS in, but we could make special considerations for the Kaelon. There could be an increased risk. And it would be a known risk. Besides perhaps the major home systems, any other random system could go nova, but the risk of any specific system going nova is low because there are so many other systems that share the same chance of going nova. For example, if the Supernova event has a 1% chance of occuring on any given turn and there 100 systems (a low number for Supremacy in larger game modes as far as I know), then there is a 0.01% (a 1 out of 10000) chance any specific system could go nova on any given turn. The more systems that exist, the less likely any specific system will get destroyed since the random generator could easily pick a different system.

But with the Kaelon, the risk wouldn't be NEARLY that low. It'd be really high like say... a 50% chance of going nova at some point during the game. In fact, the game could determine IF the system will go nova when the game is started. Then, it's just a matter of determining what turn to go nova on. That's far and away much worse than the "normal" supernova random event.

In exchange for the inherent risk in investing into the system, there needs to be a good reason for the player to not ignore it.

of course, statistics say there is a slight chance even at winning the lottery so a nova event will most probably occur in a usual game but I'd like it to be very special cause I don't want 2 or more occuring, it disrupts gameplay too much IMHO.

The one month "rule" is not something that has been specifically calculated and stuck to - but if you want, you can test it.

The Defiant era is roughly 70-80 years after the Kirk era. There are 12 months in a year, so 12*70 is 840 turns. If you go with 80 years that figure is 960 turns.

I know this is a relatively short game (By my standards anyways! ) but I know that there are many people on the forums who play games of about 200 turns at most.

These figures then give a mid-length game. By doing it this way, you keep more people happier - and the more happy people there are, the more people that are gonna play. It's all about balance.

If you don't like the game, just mod it by increasing research/build costs, or by lowering the return from your science and industrial buildings. There's nothing that's gonna stop you and you'll be able to upload your mods to the forums so other people can try them!

For obvious reasons, the "timings" won't be the same on different size maps either. Big maps = more systems = more research = shorter games. That's partly the reason why we've increased the tech levels from 10 to 12 - but again, this can be modded to however many you want. Aaages ago I made a list of different techs that I thought could be in the game, and I came up with 30 different weapons levels alone!

The game is going to be moddable, so any arguments that the game isn't "right" don't matter. We should be focussing on ideas rather than on the nitty-gritty which the programmers have no doubt already taken into consideration.

a single variable would be needed to solve that problem, let people utilize a "modifier" in the game options, a factor of 1 is normal game length, a factor of 2 would make things go twice as fast, etc...

But we're wondering off the Random Events subject

would be a possible solution. I made a mistake above, it's three decades not a year (a year would have been if he said day instead of month). well, my idea and I hope it's gonna be implemented in bote is the introduction of the good old stardate which is calculated by current mean tech levels and turnwise advancements of all major players. With that you have a floating but exact timeline.
Only problem occuring is when research sabotage hits all majors extremely bad and simultaneously you might actually go back in time but since this is a mankind's dream, no problem.
btw. matress, a 960 turns botf game I only play in MP, in SP matches I have the Defiant at round 500 at last and now you get into swimming with your months calculation

btw, it's totally moot to think about since nobody cares anyway when playing..

one last thing, if a turn really is constant in time, then the ship movement from one sector to another screws up cause at warp 1 in the beginning you need some 2-3 years to get to the next sector "nearby"(which actually means 20 light years away) and that would take us some 24-36 turns for starters, a bit long don't you think?

The only problem with the Stardate idea is that since, as proposed, it depends on the game's overall research level, the actual date will be different between each game. The cool thing about simple counters, like turns, is that they are consistent. Turn 178 is turn 178 regardless of what game you are playing. So, if you aim to be at certain goals within X turns, you can track that because 1 turn is the same length of time for each and every game.

However, the research levels of the entire game can be very different from game to game. This makes the Stardate idea relative to the players in the game and where they are deciding to focus their resources. Thus Stardate XXXXX.X won't neccessarily be the same "length of time" as it was last game or will be in your next game. While it adds flavor, the Stardate idea cannot be used for anything important, it'd simply be in to look cool. Because, if based off of research and if everyone simply stops researching for whatever reason, time (stardate-wise) would stand still. That... doesn't make a whole lot of sense, in addition to research sabotage that was mentioned above.

Simply replacing turns with a stardate counter would be the only solution I could see. Thus, each click of the turn button would incriment the stardate instead of a turn counter. There would need to be an easy way to determine what turn you are on, though. Given that, I would probably argue that using a simple turns counter and forgoing the stardate idea would be better off; it's a simplistic way to determine how far the game is along which will be easier for more casual players.

Under no circumstances will I even consider implementing a stardate system in which the date depends on non-constant factors (i.e. research level). Not only is it an inconsistent solution, but there is no elegant way to reconcile the different tech levels of all the empires.

k to make it short, it does not work without upper and lower boundaries in which stardate-turnwise-advancement takes place, i.e. you need a minimum (and maximum) time advancement of course. Take a "wide-meshed mathematical discretisation", namely put a fixed stardate increasement values to the current overall mean tech level. The latter is a fixed number changing(increasing) most of the time and can very well be used to define a monotonically decreasing step-function with domain in the tech level intervall (= calculated current mean techlevel) - let's say [0..9] float numbers - and range between [14...731] days. Rewrite it in stardates, done.

This function then represents a non-volatile/non-problematic time advancement that changes every turn but does not stop or reacts too strongly on userbased research decisions. If you wish use a maximum boundary as well to be more on the safe side.
You can even dismiss the tech advancement(!) factors in your calculation totally. They aren't needed, they just would make the stardate appear even more unpredictable/fluctuating within the borders set, of course.

Hope that clears it up a little. Happy holidays.
Malvoisin

you don't tell me to write a LaTeX-made pdf for ya containing some integrals and sublinear Hahn-Banach-functionals don't ya?! ;)
joke's aside, that solution above is consistent in every axiomatic way except maybe non-standard analysis theory but I doubt that plays any role here ;)

what you will have in the end is a turnwise counter and optionally a stardate resp. days counter displayed directly below the turn number.

as I said the function f:[0,9]->[14,731]€{whole numbers}, f(x):=min(731,max(14,trunc(743-x^3))) will most probably do the trick.

set class.time.stardate.day(......)=f(current.meantech);

upgraded way with tech advancements:

set y:=current.meantech.diff=current.meantech - lastturn.meantech;
f:(N,R)->Z, f(x):=trunc((1-y)*min(731,max(14,743-x^3)))

set class.time.stardate.day(......)=f(current.meantech,current.meantech.diff);

this last function is very raw but effective in generating a bit more fluctuations. the other function above is polynomial, which is okay for the time decrease and of course I don't win the fields medal for this..
Btw. Azhdeen, time is of course running constant but a turnwise game and every turnwise game takes snapshots from the timeline and the time intervall between those snapshots can of course differ from each other, but shouldn't too much, that's for sure.

I think that the TURN counter is far better. However, if people want to see a stardate on the screen then why can't you simply do something like:

TURN
128
STARDATE
50421.3

?

that's the way it's gonna be. only the stardate has to be calculated first, otherwise it's not funny or seems a bit lame just to have an additional number with no real change except turnwise fixed additions and no meaning after all.

hm, I got a bit into the stardate calculation stuff and I must say, I'll go with the easy version 1 century = 100.000 points and all that in the Julian Calendar System (like our standard gregorian but with the leap year gap at 400). Therefore an hour is roughly 0.1 in stardates. The beginning stardate would be 01/01/2121 (or 2161 if you like it canon) and that would make for stardate 121000.0. the leading 1 here could be dismissed to make it more tng like cause a typical tng episode stardate was something 5-digit-like 47309.5 which is about 04/10/2447 at five o'clock in the morning, so the century could be shown in the normal year display.

it would look like this:

Turn: 383
Stardate: 47309.5 (or 447309.5 with the century mark)
Year: 2447

I think one can live with that