Aurora 4x
VB6 Aurora => Aurora II => Topic started by: Steve Walmsley on October 17, 2010, 02:21:35 AM
-
I am playing around with Visual C# at the moment and I like what I see. As playing around with VB led to Starfire Assistant and Aurora, I am considering what type of programme to try to write in order to keep up my enthusiasm for learning C#. My first inclination was some type of Newtonian-based tactical combat. However, this does have some fundamental issues, as I just mentioned in another post, which is why I avoided it for Aurora. So the more I think about this, the more I think some updated, more realistic version of Aurora may be the way to go without going to full Newtonian mechanics. I am open to suggestions about fundamental changes that would be included in an Aurora II, rather than low level features. Bear in mind this is a LONG-term project. At the moment I am considering:
1) A resolution-independent game so it can be played on laptops and desktops with lower resolutions. The WPF (Windows Presentation Foundation) makes this MUCH easier.
2) Centering the game around the System Map and using popups to replace many of the separate windows in Aurora I.
3) Real-time rather than stepped time. Time will be more like Harpoon or Europa Universalis where you can pause it, or accelerate it. This is isn't as different as it sounds because it will be similar to permament automated turns with the sub-pulses equal to the acceleraton rate and no defined increments. I intend to load everything into memory so the program will avoid any database access as time passes. This will improve performance considerably. You should also be able to watch ships move across the map if I can get the graphics working as I intend.
4) Keeping the basic idea of Trans-Newtonian physics to allow naval-style manoeuvers
5) No jump points <shock!>. There would be actual interstellar travel rather than jump points, based on some form of warp drive equivalent. Stars would have a 'hyper limit' beyond which you can enter hyperspace and head for another star system. Systems would all be generated at game start and you would be able to add extra systems during the game as the SM. This adds a lot of flexibility in terms of detecting things at interstellar distances. At the moment I am considering a model where ships enter a 'warp bubble' and are cut-off from the universe until they arrive in your destination system. The arrival location for each ship will be variable but will be somewhere within a certain distance outside the hyper limit, perhaps hyperlimit radius x 20%. The bearing from the destination star would be based on a bell-curve with the most likely bearing being on a direct line to the star system from which you departed. So there would effectively be a 2D toroid around the destination star where you could arrive with the most likely location somewhere close to the hyper limit on a direct line between the departure and destination system, although you might end up on the far side of the system if you were unlucky. Time of arrival would also be subject to some variance due to the 'vagaries of hyperspace'. This means a war fleet is going to arrive in a scattered way over time and will have to assemble before a centralised defending fleet can defeat them in detail. Although it also means the defending fleet may not be certain about further attacking ships arriving. Due to this method of arrival, interstellar commercial shipping would be scattered around a system rather than concentrated on a single route.
Part of the rationale behind the above thoughts is to create the interest of a jump point assault on a much wider scale without having the movement restrictions and AI issues of jump points. Ships would need existing maneuver engines and hyperspace engines would replace jump drives, although these would likely be smaller in relative terms than jump drives as they would be more widespread. Ships without hyperspace engines would be restricted to their current system, or would have to be transported in carriers. Of course, this means no gravitational surveys.
6) Tracking the mass of ships and changing it as a result of fuel consumption, use of ordnance, dropping off cargo. Max speed would change as a result. This will allow more tactical options. Possibly, also have fuel storage tanks that could be discarded, or even strap-on boosters.
7) Area damage from nuclear explosions. Missiles would detonate based on proximity and damage would be based on warhead yield and distance from detonation. This would obviously create some disadvantages to ships travelling in close formation, as multiple ships would be damaged by the same explosion, and give the player some significant decisions with regard to escort deployment. No more 'Empire State' formations. With no jump points to consider, formations would no longer have some of their current disadvantages and I would add extra functionality to make them easier to manage. It will also reduce the need to build missiles on a 4/9/16 warhead basis as only a proportion of warhead strength will be applied against a particular target. Arriving in a new star system could result in a scattered formation so ship design would have to consider whether specialised units that could be separated for some time are better than multi-purpose units than could fight more effectively in isolation. Ships on the offensive would be more likely to be isolated than ships on the defensive so grand strategy may also influence ship design.
The above are just a few initial thoughts as this is a project that will take a year or more. This will not be a conversion of Aurora to C# but rather a new game that resuses a lot of the database tables and logic from Aurora. For example, I have already written the C# code that loads all the system information (Systems, Stars, Planets, etc.) from my current game into C# objects. This is something that Aurora only does for a single system on the Systen Map whereas my new C# program has all information from all systems in memory. I will probably handle such things as orbital movement on much smaller time-scales. In fact the current 5-day increment will most likely be subsumed into the general passage of time with things happening at different rates. Perhaps construction every 24 hours and population growth every week for example. The game is going to take longer to load and there will be a Save function but it should be quicker to run.
I'll use this thread to keep everyone updated as work progresses. This doesn't mean the end of Aurora though as I will continue to add functionality and release updates. It is unlikely I will make any major upgrades that require a large investment of time though.
Steve
-
That's a courageous undertaking, to say the least, congrats on this move!
I would say that in 2011 and onward, you should really allow player to mod almost everything. It means separating the data base from the saved games files, first and foremost. And then it means opening the database to modding. Either with a tool allowing access, or you propose functions like 'export DB to text' and the reverse 'import text files to DB', whatever floats your boat.
In any case, seeing that an unique file contains both the DB plus all saved game is nearly an heresy for me ;D Plus the fact that you can't mod anything.
And basic graphics please. I'm not asking any more than having the possibility of seeing a 2D bitmap for each ship on the ship design window and ship rosters, and a smaller, stylized icon on the space map. Even symbols are ok, as in Harpoon.
-
This sounds good. I've tried Aurora and like it, just not enough for it to out compete our current games.
Thoughts from someone with VERY limited experience.
You could require grav surveys. Just base the 'hyper drive' use for a destination on exact pinpoint of the other system's gravity well in respect to the current system. This would require detailed analysis of gravatic acceleration and transition from many points at quite a distance from the primary to gain accurate data for using the drive.
Would make jumping in grav ships to the other system in the first waves early on VERY important, otherwise how are your ships going to get home. Can't just build and send battlewagons, you'll need to look after the little guys or build that capability into your warships.
And shooting those little guys could be more important at that point than fighting the big boys. Patrol forces to deal with surveys would be VITAL.
Like the area damage from nukes, but not sure how you plan to apply it. If nukes damage over an area, you might look at AMM's based on larger warhead sizes as they wouldn't require direct (or close) hits. One big nuke might be able to take out an entire salvo if they are clustered. Might force folks to feel out the opposition as to how they shoot down missiles and could make 'energy' weapons more valuable in combat.
Like the idea so far. Anxious to see where it goes.
Might just have to make time for a 'video' game after all.....
-
You could require grav surveys. Just base the 'hyper drive' use for a destination on exact pinpoint of the other system's gravity well in respect to the current system. This would require detailed analysis of gravatic acceleration and transition from many points at quite a distance from the primary to gain accurate data for using the drive.
Would make jumping in grav ships to the other system in the first waves early on VERY important, otherwise how are your ships going to get home. Can't just build and send battlewagons, you'll need to look after the little guys or build that capability into your warships.
And shooting those little guys could be more important at that point than fighting the big boys. Patrol forces to deal with surveys would be VITAL.
Good suggestion. Not sure exactly how I would implement it but the idea that grav surveys could substantially reduce the 'scatter' from a jump makes a lot of sense. Surveyed systems at both ends would be best. If neither system is surveyed, I guess there could even be a chance you could end up in the wrong destination system :)
Like the area damage from nukes, but not sure how you plan to apply it. If nukes damage over an area, you might look at AMM's based on larger warhead sizes as they wouldn't require direct (or close) hits. One big nuke might be able to take out an entire salvo if they are clustered. Might force folks to feel out the opposition as to how they shoot down missiles and could make 'energy' weapons more valuable in combat.
Excellent point. It would certainly solve the massed salvo issue :). I don't think it would take too much coding effort to allow ships to specify a 'spreadout' effect for their salvos so that missiles would move apart during flight before converging on the target. I will give this some thought when the time comes to look at missile combat.
Steve
-
-That should also include realistic Warhead strengths.
Nukes would deal more damage in Atmospheres, the thicker the more damage, but also be limited to the impact space, so no armor penetration, making mirvs more important.
-I think Jumpgates could actually still be possible, to accelerate Travel and have a specific destination. It would be the peak of technological development and allow a race to boost it's economy between any two systems, and thus consume enormous amounts of resources, and require a lot of development and planning. Rare, natural wormholes could still be allowed, working like normal travel, but not requiring hyperdrives.
-If you have jump carriers, why not allow attachment on a wider scale, not only fuel canisters, but things like weapon platforms that can be detached, but only have limited batteries without the carrying ships generators.
-I think if your going to redo everything anyways, why not improve shipbuilding? One could, like in current commercial 4x games, put his ships together on a grid, (I think 3d grids would be too much) and decide what is more protection worthy and fragile and thus go inside. Most weapons would obviously have to be outside.
MIRVs should be able to have various bomblets, like flares, decoy missiles, and actual damage dealers, or maybe deploying small laser satellites, and armor piercing missiles that require energy weapon tech.
Shields could be specialized to specific damage distributions, a Bubbleshield would take more damage from missiles, but due to more covered space be more efficient versus beams, and maybe one could build Guard ships that protect multiple ships under a huge shield bubble.
Armor penetration could also factor that stuff in, if armor is hardened and coherent, maybe hits might deal less damage to it, but deep damage templates could deal more damage after penetrating the outer shell.
-Most important off all, wouldn't the combat distances be different? Currently, point blank range is 10k kilometers, I don't thing a nuke in open space would damage anything that that distance.
-Also, you could revise engines, with a ship ship packing a high efficiency cruise engine for slow, but cheap flights, and a few additional overcharged engines for inefficient, but fast combat maneuvers. You could even have a weaker hyperflight, say, with only double speed, without a bonus to evasion, so you can have more refined flight and movement calculations in combat without having problems like in that other recent thread.
- Life simulation, Free O2 hints at natural wildlife, which might be dangerous, but could also be a factor of economy and tourism. Races might require water, toxic gases, or other stuff to survive (like we breath oxygen), or even radiation (if you think thats too far off, which it isn't, I guess increased modability might allow that).
-Populace sum; war always results in unrest, different economy types might result in quicker growth, but also the possibility of recession.
Genetic modifications might result in unrest, same as high unemployment.
- Conventional Materials. Those could be available in higher spread, and be required for the economy; given that ships calculate fuel and other stuff that is essentially also weight, players could build their ships partially from conventional materials to be cheaper and faster, but also a lot less durable.
-And finally make beam weapons do something versus atmosphere. it doesn't need to be much.
Edit: As for small things, more diplomacy maybe? feints? Intrigues? Reverse psychology? ;)
*frenetic jubilation* well, whatever you do, it will quite possibly be great. I just hope I live to see the day X-D
Good luck, keep on making people waste their time. :D
-
I think you should keep jump points but change them so that they are allot more rare and rather than instant travel that act as high speed corridors so a hyper equipped ship might go anyware between 2X-10X normal hyper speed. They should also require an extensive grav survey (travel to all system bodies much like Geo survey does now) to map the systems grav fields in both of the end point systems to find the corridor.
jump gates should also stay allowing a ship to travel very fast along them like jump points but even faster (artificial tunnel is more smooth / kept clear of spacedust) and rarer but rather than being a starting tech they are a found tech (like plasma torps), should only link to 1 other gate and be fixed for that gate (no traveling the universe like SG1), should take a long time to build 50+ years at the start and have to be found with active sensors. There could also be unlinked gates that you could link with research / xeno teams?
will planets have a hyper limit as well given that a planet outside a stars limit could have a enemy fleet arrive in orbit with no chance of defending it self? what about a hyper jammer that prevents enemy ships from entering/ exiting hyper within a certain range (depending on tech) of an equipped planet.
i think i stop for now and let other people think on a few things
-
I think you should keep jump points but change them so that they are allot more rare and rather than instant travel that act as high speed corridors so a hyper equipped ship might go anyware between 2X-10X normal hyper speed. They should also require an extensive grav survey (travel to all system bodies much like Geo survey does now) to map the systems grav fields in both of the end point systems to find the corridor.
In terms of their rarity and difficulty in mapping, it sounds like what you are describing would bear a strong resemblance to wormholes in the HonorVerse, where only a few systems have them, although they allow instant travel. In fact, something like an Honorverse wormhole junction, even with multiple termini, might be possible under this model. However, it would bring back some of the issues with jump points relating to formations having to compress and the AI. Although in the former case I guess a terminus could cover a wide area so a formation could go through intact.
jump gates should also stay allowing a ship to travel very fast along them like jump points but even faster (artificial tunnel is more smooth / kept clear of spacedust) and rarer but rather than being a starting tech they are a found tech (like plasma torps), should only link to 1 other gate and be fixed for that gate (no traveling the universe like SG1), should take a long time to build 50+ years at the start and have to be found with active sensors. There could also be unlinked gates that you could link with research / xeno teams?
This would be similar to wormholes above, except they would be artifical rather than natural and have a single terminus.
Will planets have a hyper limit as well given that a planet outside a stars limit could have a enemy fleet arrive in orbit with no chance of defending it self? what about a hyper jammer that prevents enemy ships from entering/ exiting hyper within a certain range (depending on tech) of an equipped planet.
That shouldn't be an issue because of the variable arrival point in a new system.
Steve
-
Sounds like a serious undertaking. I like the changes you've mentioned so far, but I am going to miss the jump points. I've been a jump point fan ever since I first played Wing Commander. I think that the model of fleet dispersement is a good way to shift the balance back to the defenders, but I would also like to see a max warp distance before the hyper drives need to reset, or whatever technobabble would need to be used.
I take it Aurora II is going to replace v5.3?
Anyway, based on the quality of work with SA and Aurora so far I can't wait to see what you come up with.
Adam.
-
Systems would all be generated at game start and you would be able to add extra systems during the game as the SM.
I kind of like the evolving nature of Aurora. A direct travel system wouldn't neccessarily mean to abandon that. We see stars based on their luminosity, and there's quite a well possibility taht we haven't discovered some red dwarfs in our near neighbourhood yet because them tricksters just don't shine enough.
So, a pre generated game-map where you see everything that has a certain apearant magnitude from the start, with the possibility of lower luminosity stars becoming visible when your ships are close enough (might also involve specialised observation ships or observatories in new colonies) might be pretty fun. The game map at the start would look pretty dense in the closer vicinity to the starting point, with less and less stars being visible the further you go, until you get a ship there to uncover the dimmer stars you couldn't see from earth.
My first inclination was some type of Newtonian-based tactical combat. However, this does have some fundamental issues, as I just mentioned in another post, which is why I avoided it for Aurora.
I still think that, when you already start to write from scratch, newtons three laws with a few spherical cows might produce the best result in terms of realism. Strong enough engines and constant mass would simplify things enough calculus wise, and would provide a great expierience in the style of Attack Vector or Knight Hawk Vector (both boardgames). Of course, if it's Naval combat in space you want, your solution is the better.
Real-time rather than stepped time. Time will be more like Harpoon or Europa Universalis where you can pause it, or accelerate it. This is isn't as different as it sounds because it will be similar to permament automated turns with the sub-pulses equal to the acceleraton rate and no defined increments. I intend to load everything into memory so the program will avoid any database access as time passes. This will improve performance considerably. You should also be able to watch ships move across the map if I can get the graphics working as I intend.
And at this point I really wonder if it wouldn't be easier to go C++ and use a graphics engine like Irrlicht. That doesn't mean that you have to do fancy graphics, but such an engine will do half the work for you even in a 2-d environment, and Irrlicht is open source and has quite a good GUI that isn't harder to program than the Microsoft GUI. It's a lot faster and would provide you with a lot more freedom. But since you already started coding in C# you probably won't change your mind about it. I know that I wouldn't.
Area damage from nuclear explosions.
Nukes in space are a bit dubious, because the area effect follows the inverse square law. I. e. you have to be awfully close to have any effect, and formations would have to be -very- close to damage two ships at once. Using nukes as a missile defence sounds somewhat cost-ineffective, at least if the nukes are realistically priced.
-
Sounds like a serious undertaking. I like the changes you've mentioned so far, but I am going to miss the jump points. I've been a jump point fan ever since I first played Wing Commander. I think that the model of fleet dispersement is a good way to shift the balance back to the defenders, but I would also like to see a max warp distance before the hyper drives need to reset, or whatever technobabble would need to be used.
I haven't decided about the exact mechanics of the hyper drives. Perhaps a cooldown period, or max range, or fuel use increasing by the square of the hyperspace distance. Whatever I end up with there will be trade-offs in hyper-drive design and it will have multiple research lines.
I take it Aurora II is going to replace v5.3?
No, its much longer term than that. There will probably be several more versions of Aurora before a prototype Aurora II is ready.
Steve
-
You could possibly set the goal to reach version 6, nice even number.^^
But I'll quote myself from up there, as I'm really interested in that:
-Most important off all, wouldn't the combat distances be different? Currently, point blank range is 10k kilometers, I don't thing a nuke in open space would damage anything that that distance.
Add: Maybe a new algorithm for planets. Moons, especially few bigger ones, slow down rotations, thus theres longer days and more moderate weather, but stronger tectonics.
Within a reasonable temperature range, reactive, but likely poisonous gases could spawn wildlife, and a biosphere could hold a planets atmosphere in balance, where a human populace on a hostile planet would permanently need terraformers to keep the oxygen content up until the planet is turned into a second earth.
And Chocolate! Every game needs chocolate! :D
-
I think in the long term its definatly a good idea to move on from VB6.
So I welcome this move. Not sure what to suggest at this moment in time but if i have any ideas i'll be sure to post them
-
Here are a few ideas I've had while playing aurora and reading copious amounts of space fiction (C. J. Cherryh is the best, and some of these ideas are from her universe)
I've written them in the form of statements.
RE: Spaceflight
1. Hyperspace jumping is a very interesting topic conceptually. I'll throw out some points/possibilities that I think are especially intriguing.
- Crew Disabled during hyperspace jumps -- IE if people enter hyperspace without being sedated or drugged, they go insane or are mentally disabled. Ostensibly the field emitted by the hyperdrive interferes with human neurons. Other species are not necessarily so affected.
- Ships exit hyperspace at an extremely high velocity, in the range of 100000 kps or more, and have to re-engage the hyperdrive for a few milliseconds to dump velocity. This requires that the crew be skilled in hyperspace jumps so that they can control the ship soon after exiting hyperspace
- Hyperspace velocity is inversely proportional to proximity to a gravity well. Hyperdrive energy drawdown is directly proportional to proximity to a gravity well. So engaging the hyperdrive on the surface of a planet or close to a star will not propel the ship more than a little bit, but will eat loads of energy. In order to dump velocity, the ship has to dump its capacitor into the hyperdrive when it has gotten closer to the gravity well in normalspace.
- Ships in hyperdrive move in 'packets' which are drawn towards each other. A ship with a larger mass that jumps ahead of a smaller ship will draw that smaller ship forward a small amount. Similarly, a small ship that jumps just ahead of a large ship will be drawn back , effectively slowing it down.
- Hyperspace jumps require good knowledge of the target starsystem's trajectory. If a hyperspace jump is mistargeted and the ship overshoots the target gravity well, it may simply continue forever with nothing to draw it out of hyperspace.
- Sometimes hyperjump scout pilots are endowed with a bit of a 'sixth sense' whereby they can sense gravity wells while in hyperspace. This can lead to the discovery of 'dark objects' such as extinct solar fragments, dark planets, lonely gas giants, or failed star systems.
2. In-system travel
- If a ship engages its engines, its crew must strap down to withstand the change in inertia. If the movement is sudden or unexpected, as in an emergency, crew members may be injured or killed.
- Ships travelling at high velocity need good sensors and navigational shielding to stop rocks and debris from damaging the hull.
- Ships travelling in normal space at relativistic velocities will show up on sensors behind their actual position. Likewise, sensor echoes take time to propagate.
I'm fighting a case of stomach flu, so I'll have to finish this later. . .
-
Steve -
Very interesting. The one thing I would comment on now is something that I've considered for a long time about Aurora. I haven't really said anything about it because it is fundamental to the way that Aurora worked and couldn't be changed, so why talk about it?
At any rate, think about this. Aurora is currently, in terms of space ship movement and combat, a weird hybrid of a strategic game and a tactical game. This has the advantage of being unique, and because it has strengths from both styles. It also has the problem is that it isn't one or the other. It is tactical in that you (the user) must designate weapon/fire con/missile/targets for each ship, but strategic in that you can't actually control movement except indirectly. I ran into this when I tried to stage an ambush in one of my campaigns by surrounding the target from outside its detection range, and then moving inward and cutting it off if it ran. This ultimately didn't work because I didn't have fine enough control of how my ships moved.
I would suggest moving one way or the other. Either strategic or tactical. If you want to control every facet of the game, then retain the current weapon/fire con/missile/target system for each ship and give the player greater control over the movement of the individual ships. If you want more of a strategic focus, then make the base "unit" a squadron. Individual ships would plug into the squadron, which could be given various formation, movement, and attack orders.
Given Aurora's extreme detail focus, requiring individual weapons to be designed from basic systems, it would probably be easier to go for a tactical focus rather than strategic, but that's up to you.
Kurt
-
- Life simulation, Free O2 hints at natural wildlife, which might be dangerous, but could also be a factor of economy and tourism. Races might require water, toxic gases, or other stuff to survive (like we breath oxygen), or even radiation (if you think thats too far off, which it isn't, I guess increased modability might allow that).
I don't think wildlife is worth modeling particularly closely, but generating some biosphere data could be interesting, especially how it could interact with terraforming. Biospheres do quite a bit to shape the atmosphere and albedo of the planet they're on, and interacting with the biosphere would make for an interesting addition to terraforming. Life-bearing worlds would have a couple extra steps in system generation to represent how the native life shaped the planet, generally doing good things like increased oxygen levels and moderated temperature - but on the flipside, sometimes the local biochemistry might release chlorine into the atmosphere.
-
I don't think wildlife is worth modeling particularly closely, but generating some biosphere data could be interesting, especially how it could interact with terraforming. Biospheres do quite a bit to shape the atmosphere and albedo of the planet they're on, and interacting with the biosphere would make for an interesting addition to terraforming. Life-bearing worlds would have a couple extra steps in system generation to represent how the native life shaped the planet, generally doing good things like increased oxygen levels and moderated temperature - but on the flipside, sometimes the local biochemistry might release chlorine into the atmosphere.
Or alien beef. Nothing like the discovery of new biota,even ruins to stimulate other parts of human society like Archaelogists and Biologists. National Geographic sweeps would explode.
-
I would suggest moving one way or the other. Either strategic or tactical. If you want to control every facet of the game, then retain the current weapon/fire con/missile/target system for each ship and give the player greater control over the movement of the individual ships. If you want more of a strategic focus, then make the base "unit" a squadron. Individual ships would plug into the squadron, which could be given various formation, movement, and attack orders.
This brings up a comment I made when crucis first started the long next-generation SF thread (about 6 months or a year ago?). My observation was that the level-of-detail for a strategic, empire-building game is different from the LoD for a tactical game. At the strategic level, you should be much more concerned with building bases, basing units at said bases, and setting up patrol patterns, to avoid getting bogged down in micro-management. My proposal at the time was something very similar to what Red Storm Rising (which I just was able to start playing again, thanks to DosBox - yeah!!!!!) did in the campaign game - have a strategic level movement which would set the start conditions for a tactical game.
I realize that an awful lot of cleverness would need to go into the "boundary" that sets up the scenarios, but it's thought about how to get the epic sweep without getting bogged down in tactical encounters.
John
-
So since Waresky is apparently MIA I shall post the obligatory 'Ground Combat' suggestion! :)
Off the top of my head:
- Hex based top-down combat grid
- PDCs visibly represented on the hex grid (probably have to be to designated a spot when constructed - which could then lead to designating spot were the industry is etc ..)
- fixed defenses which are not PDCs per-se but bunkers with fixed weapons overing a certain arc (maybe you can deploy then on the approaches to a PDC)
-- or, have new tech that you install into a PDC : 'Internal Security' or 'Integrated Weapons Systems' or some such which gives various bonuses to garrisoned units (instead of a flat 'im in a PDC' bonus) and also maybe gives an indirect-fire support capacity. Anything that shots 'out' can be targeted and destroyed without destroying the actual PDC since it isn't necessarily integrated into the armor.
- If you do go hex/tile based then need ranged units
- would terrain factor into a battle were they are using TN tech? Thinking of MI with grav packs and such so they do not need a bridge.
-
- would terrain factor into a battle were they are using TN tech? Thinking of MI with grav packs and such so they do not need a bridge.
As long as there's anything in Orbit capable of firing on the surface, Terrain is THE supreme factor. Anything that gets spotted from Orbit can be zapped more or less instantly, resulting in a kind of "secret war". Stealth and camouflage might become dominating factors for ground units in such a scenario. And one hell of a headache for the logistics corps!
Anyways, I'm usually all in for simulated ground combat in a 4x, but I don't know how well it would work in Aurora. . . The game offers overwhelming complexity as it is, and to implement ground combat in a way worth playing in a game with such a grand scale will be tough at best. To not talk about me handling two space battles, 10 colonies and an army on the ground all at once. . . :P
-
Sounds very exciting, Steve!
I think it is a good idea. Aurora is, feature wise, a very complex and detailed game already. Only thing it needs is some more polishing and bugfixing, really.
So, a new project, a new game? Yay!
I, like others, would miss jumpgates though. I second the suggestin of keeping them in the game as an technologically advanced, expensive thing to build.
I have one big worry.. You sound optimistic about implementing a real-time galaxy. As a long time-Dwarf Fortress player, having seen most of my forts eventually die the FPS-death, I'm kinda worried that later in game, with a lot of races, all having a lot of assets, the game will slow down to a crawl. Also, for 4X games, I kinda like it turn based personally.
Here's a few suggestions that spring to my mind:
- allow fleet construction in space. Think, Homeworld (I loved that game. Turn off unit capping, and build fleet formations until the CPU overheats :) )
Basically, I would like to have motherships / space bases, with onboard production capabilities.
- A new special NPC race, that is not hostile, but trades. Can sell any ship/component/missile that is currently in play. (Not nescessarily all of it at the same time. Their inventory could be randomized each visit)
Ambush your enemy with their own designs! Not cheap, ofcourse. Prices could be calculated by using the research costs of components. Also sells minerals and fuel. Discovering ruins made by this trading race establishes initial contact. After that, any planet with a Trading Centre can call in the traders, which will then arrive after a set amount of time. This would provide more use for currency, and more reason to establish colonies on mineral-poor planets for their population, and income.
regards, martinuzz
-
wee, my third post inhere.
Regarding Modability, this should be an easy task;
Put in some extra variables that aren't necessary. Like a second Hyperlimit, subclasses for weapons (So players could build themselves pulse Lasers and continuous beams, etc), and possibility to add to the interface (like more missily warhead types or the like), so that players can mod their games for RP campaigns without you having to hear demands that would cater to a minority of players only. (Like feces in DF).
-
Hi,
I have to throw in my two cents here. I like a lot of the changes being proposed, from a game play perspective, and appreciate that this is a long term project which won't be coming out in the foreseeable future.
That being said, I'd love to see this game be made accessible to the blind. The only reason Aurora is at all has a lot to do with its idiosyncrasies: being written in VB6 with mostly standard controls and all information being represented textually. I'm a bit unsure of the realtime pausable format. Logistically, realtime games have always been a bit harder to make accessible than turn-based ones, though it has been done: see SoundRTS, (http://jlpo.free.fr/soundrts), for an example. One feature which would help a great deal would be integration of Microsoft SAPI into the game interface to provide audio feedback.
So I'm glad that we're looking at moving forward with a new game, but I'm also glad that Aurora itself will still be developed in the foreseeable future. I hope the blind community doesn't get left behind.
Thanks for listening,
Zack.
-
7) Area damage from nuclear explosions. Missiles would detonate based on proximity and damage would be based on warhead yield and distance from detonation. This would obviously create some disadvantages to ships travelling in close formation, as multiple ships would be damaged by the same explosion, and give the player some significant decisions with regard to escort deployment. No more 'Empire State' formations. With no jump points to consider, formations would no longer have some of their current disadvantages and I would add extra functionality to make them easier to manage. It will also reduce the need to build missiles on a 4/9/16 warhead basis as only a proportion of warhead strength will be applied against a particular target. Arriving in a new star system could result in a scattered formation so ship design would have to consider whether specialised units that could be separated for some time are better than multi-purpose units than could fight more effectively in isolation. Ships on the offensive would be more likely to be isolated than ships on the defensive so grand strategy may also influence ship design.
If we're moving to a more realistic game style, then explosions causing area damage isn't something that should be brought aboard. Per http://www.projectrho.com/rocket/rocket3x1.html#nuke,
Nuclear weapons will destroy a ship if they detonate exceedingly close to it. But if it is further away than about a kilometer, it won't do much more than singe the paint job and blind a few sensors. And in space a kilometer is pretty close range.
Please understand: I am NOT saying that nuclear warheads are ineffective. I am saying that the amount of damage they inflict falls off very rapidly with increasing range. At least much more rapidly than with the same sized warhead detonated in an atmosphere.
But if the nuke goes off one meter from your ship, your ship will probably be vaporized. Atmosphere or no.
George William Herbert says a nuke going off on Terra has most of the x-ray emission is absorbed by the atmosphere, and is transformed into the first fireball and the blast wave. There ain't no atmosphere in space so the nuclear explosion there is light on blast and heavy on x-rays. In fact, almost 90% of the bomb energy will appear as x-rays behaving as if they are from a point source (specifically 80% soft X-rays and 10% gamma), and subject to the good old inverse square law (i.e., the intensity will fall off very quickly with range). The remaining 10% will be neutrons.
For an enhanced radiation weapon (AKA "Neutron Bomb") figures are harder to come by. The best guess figure I've managed to find was up to a maximum of 80% neutrons and 20% x-rays.
The fireball and blast wave is why nuclear warheads detonating in the atmosphere will flatten buildings for tens of kilometers, but detonations in space have a damage range under one kilometer.
Also, if all sorts of things are getting a rework, these links might prove handy--calculators for simulating CIWS and PD-missile to-hit chances based on real-world systems, courtesy of Eric Rozier:
http://www.5596.org/cgi-bin/pointdefense.php
http://www.5596.org/cgi-bin/pointmissile.php
I don't know what math the current calculations for point-defense were based off of, but I figured this was worth passing along.
Finally, a suggestion for yet another factor in ship design: heat. Radiators would be an integral ship component, keeping the ship from cooking the crew alive with heat buildup due to engines and weapons. Easily damaged in combat though--and giving the ship a higher active scan signature (likely, a higher thermal signature as well) when deployed. You could have the option to retract them (to cut signature output and avoid losing them easily in combat), but too long and you'll start facing dangerous heat levels. Radiating armor could be a research option along the way; in the meantime, ensuring your ships have enough radiators or heat sinks to weather the loss of a few and/or be able to rapidly disperse the heat buildup from retracting them (so as to retract them again quickly and minimize detection), would be an important consideration.
-
Planets should at least shield one from thermal sensors, and probably from EM sensors. I can see the gravity-based sensors being sensitive enough to "see through" the planet to detect a ship on the other side. Although bodies of high enough gravity should mask or washout the gravity emissions of puny engines.
-
@ On-Target;
On that note,
A) Why does an X-Ray Laser actual damage? In that sense, a Neutron Bomb would probably indeed deal damage over long ranges, must be some TN technobabble ::)
B) If the Materials are Heatresistant enough, good heat shielding could provide several days at full power, and directed radiation, away from potential enemies, could also be an option.
And, on higher techlevels, engines should become more efficient, meaning, produce less heat per speed.
Em weapons overcharging enemy engines to result in crew damage and internal explosions would also be a possibility.
But that could go on for years.^^
-
Finally, a suggestion for yet another factor in ship design: heat. Radiators would be an integral ship component
The problem is, if you integrate radiators into a game you pretty much have to take realism to the limit, because radiators won't be able to get rid of the heat from a decent scifi-drive unless you measure their area in sqare kilometers. . . And if you enhance the radative capabilities above the theoretical max (black body), you might as well invent a McGuffin that suits your scenario better. A shield that can deflect a laser beam on different wavelengths for example should be perfectly capable of shielding a fusion core and never even let the heat get into the ship (directing it into space straight away), so there wouldn't really be a need for radiators.
A) Why does an X-Ray Laser actual damage?
Because X-Rays are a form of energy just like everything else. focus them on a target, and that energy will be transfered. X-ray lasers are also an argument against nukes: If you already detonate a nuke, you might as well do it to drive an X-ray laser which can focus ALL the energy of the nuke to one point, i. e. no inverse square law, only dispersion. A nuke-powered X-ray laser would be a one-use weapon, missile or drone mounted, but the effects of a hit would be absolutely devastating even on ranges beyond one light minute!
a Neutron Bomb would probably indeed deal damage over long ranges,
Nope. The reaction still spreads spherically, so you loose most of the energy in empty space. Anything that isn't concentrated on a specific point is a waste of energy, really.
-
Well, given the possibility of above light speed travel, I figured those energies should also be able to produce a solar storm or the like.
As for X-Ray Lasers, direct a strong X-Ray laser at a Meter of, say, steel. No need for futuristic materials that can bend the laws of space and time.
After several hours, the piece of steel might have wear on it, but it will essentially still be a piece of metal well capable of surviving a hit with high explosives.
How high would the energy need to be to have a measurable effect on a several meters thick armor of superdense futuristic metal within a few seconds? And is that really worth the effort?
I think we shouldn't start the calculations here and just accept that some stuff is abstracted a little, though I agree that heat shielding shouldn't be too much of a hassle.
Given todays materials are quite able to produce isolation that can keep a difference of over 200 degrees within a few milimeters, and it doesn't even reflect the radiation, with whatever you need to jump between systems, it shouldn't be any harder.
-
In that sense, a Neutron Bomb would probably indeed deal damage over long ranges, must be some TN technobabble ::)
Neutron bombs are probably the ideal nuclear weapon for space combat. I looked into nuclear weapon effects in space several years ago and found out the available information is classified. However, I did some research based on the effects of low and high atmospheric detonations as the effects of nuclear detonations change considerably depending on atmospheric density. In space there would be no blast effect because there is no atmosphere to propagate the shock wave and little thermal effect for the same reason. There would be a lot of radiation however and unlike an atmospheric detonation there would be no physical attenuation of its effects. Which means damage radii in the order of hundreds or miles or more. So while they wouldn't look like a nuclear explosion in the atmosphere (no mushroom cloud, not much visible death and destruction), they would cause significant radiation effects over a wide area.
Much more fun though to take the Aurora route and pretend there would be spectactular explosions and lots of physical damage :)
Steve
-
I kind of like the evolving nature of Aurora. A direct travel system wouldn't neccessarily mean to abandon that. We see stars based on their luminosity, and there's quite a well possibility taht we haven't discovered some red dwarfs in our near neighbourhood yet because them tricksters just don't shine enough.
So, a pre generated game-map where you see everything that has a certain apearant magnitude from the start, with the possibility of lower luminosity stars becoming visible when your ships are close enough (might also involve specialised observation ships or observatories in new colonies) might be pretty fun. The game map at the start would look pretty dense in the closer vicinity to the starting point, with less and less stars being visible the further you go, until you get a ship there to uncover the dimmer stars you couldn't see from earth.
The initial map will likely be based on the real stars data already in Aurora, which maps out a couple of thousand stars near Earth. Their planetary systems won't be visible, with the potential exception of large gas giants, until you reach the vicinity of the star. I will also allow hyperspace travel to individual stars within a multiple-star system, which eliminates the current problem of useless systems around stars you can't really access. I'll also do some reading and see if there are things in nearby space that we wouldn't be able to detect from Earth and add those as well.
And at this point I really wonder if it wouldn't be easier to go C++ and use a graphics engine like Irrlicht. That doesn't mean that you have to do fancy graphics, but such an engine will do half the work for you even in a 2-d environment, and Irrlicht is open source and has quite a good GUI that isn't harder to program than the Microsoft GUI. It's a lot faster and would provide you with a lot more freedom. But since you already started coding in C# you probably won't change your mind about it. I know that I wouldn't.
Part of the fun for me is learning a new language and I used to be a C++ programmer :). Besides, Aurora is really a Windows Application rather than a traditional game. It is a lot closer to Excel than to Modern Warfare and I really would prefer to have functional graphics and a lot of detail rather than spending a lot of time on the graphical side. Although one of the reasons I have gone with WPF rather than Windows Forms is that is lends itself a lot better to the type of graphical functionality I would need for the system map. So I hope the graphics and UI will be a lot nicer than Aurora but to be honest the graphics are not my priority.
Steve
-
I would suggest moving one way or the other. Either strategic or tactical. If you want to control every facet of the game, then retain the current weapon/fire con/missile/target system for each ship and give the player greater control over the movement of the individual ships. If you want more of a strategic focus, then make the base "unit" a squadron. Individual ships would plug into the squadron, which could be given various formation, movement, and attack orders.
By more control do you mean being able to give them a heading rather than a destination, or do you mean detail down to the level of turn rates and facing?
Steve
-
I have one big worry.. You sound optimistic about implementing a real-time galaxy. As a long time-Dwarf Fortress player, having seen most of my forts eventually die the FPS-death, I'm kinda worried that later in game, with a lot of races, all having a lot of assets, the game will slow down to a crawl. Also, for 4X games, I kinda like it turn based personally.
It would be similar in implementation to the way it is now but with a more real time feel. For example, in Aurora if you set an increment size of one hour and a sub-pulse size of one minute and switch on automated turns, that isn't really any different than a 'real-time' system that increments one minute at a time. What I will probably aim for is the user setting a time-acceleration rate (so 60x for one minute increments) and also a 'frame rate', which will be how many increment pass before the map updates itself. For high-end systems you could set a one-to-one update rate so the map is updating more quickly than at the moment. For less capable systems you might set up a 10-1 update rate, so the map would only update after every ten increments, in which case it would function almost identically to Aurora. There would still be some form of interrupts, although I would be thinking about how to implement that from the start rather than trying to add it later as I did with Aurora.
- allow fleet construction in space. Think, Homeworld (I loved that game. Turn off unit capping, and build fleet formations until the CPU overheats :) )
Basically, I would like to have motherships / space bases, with onboard production capabilities.
One thing I will definitely want to accomplish is to decouple production from populations. I intend production to be linked to different types of 'production facilities', regardless of whether those are on planets or in space stations.
Steve
-
Hi,
I have to throw in my two cents here. I like a lot of the changes being proposed, from a game play perspective, and appreciate that this is a long term project which won't be coming out in the foreseeable future.
That being said, I'd love to see this game be made accessible to the blind. The only reason Aurora is at all has a lot to do with its idiosyncrasies: being written in VB6 with mostly standard controls and all information being represented textually. I'm a bit unsure of the realtime pausable format. Logistically, realtime games have always been a bit harder to make accessible than turn-based ones, though it has been done: see SoundRTS, (http://jlpo.free.fr/soundrts), for an example. One feature which would help a great deal would be integration of Microsoft SAPI into the game interface to provide audio feedback.
So I'm glad that we're looking at moving forward with a new game, but I'm also glad that Aurora itself will still be developed in the foreseeable future. I hope the blind community doesn't get left behind.
Thanks for listening,
Zack.
I think my comment about real time may have given a false impression. I still don't intend to allow a command and conquer style interface where you command ships as they are moving. You will give orders while the game is 'paused', just as in Aurora, and then let it run until something happens, just as you currently do with automated turns. In effect I am making automated turns part of the normal function and removing the higher level increments while retaining the lower-level sub-pulses. The function will be internally very similar to the way it is now but the impression should be a smoother-flowing game.
I don't know anything about Microsoft SAPI, although I have just taken a look at their website and it looks interesting. I'll take a proper look at it when I get more into the development.
Steve
-
If we're moving to a more realistic game style, then explosions causing area damage isn't something that should be brought aboard. Per http://www.projectrho.com/rocket/rocket3x1.html#nuke
Thanks for the link. Non-area damage is easier and it would appear to be more realistic too, so I guess I will stick with the existing system.
Also, if all sorts of things are getting a rework, these links might prove handy--calculators for simulating CIWS and PD-missile to-hit chances based on real-world systems, courtesy of Eric Rozier:
http://www.5596.org/cgi-bin/pointdefense.php
http://www.5596.org/cgi-bin/pointmissile.php
I don't know what math the current calculations for point-defense were based off of, but I figured this was worth passing along.
The current math is based on internal consistency rather than real world physics and it seems to work well within the context of the game. I will take a look though. Thanks for the links.
Finally, a suggestion for yet another factor in ship design: heat. Radiators would be an integral ship component, keeping the ship from cooking the crew alive with heat buildup due to engines and weapons. Easily damaged in combat though--and giving the ship a higher active scan signature (likely, a higher thermal signature as well) when deployed. You could have the option to retract them (to cut signature output and avoid losing them easily in combat), but too long and you'll start facing dangerous heat levels. Radiating armor could be a research option along the way; in the meantime, ensuring your ships have enough radiators or heat sinks to weather the loss of a few and/or be able to rapidly disperse the heat buildup from retracting them (so as to retract them again quickly and minimize detection), would be an important consideration.
This is something I hadn't even considered, although the concept is interesting and a little similar to Battletech. My main concern would be the level of micromanagement on a per-ship basis.
Steve
-
As for X-Ray Lasers, direct a strong X-Ray laser at a Meter of, say, steel. No need for futuristic materials that can bend the laws of space and time.
After several hours, the piece of steel might have wear on it, but it will essentially still be a piece of metal well capable of surviving a hit with high explosives.
If it's hit by a few Gigajoules of coherent X-rays in one instant, you bet it would show wear. If it's still there to see and not a million funny molecules drifting through the air, that is ;)
Since the project RHO page about nukes and lasers has already been posted, I don't have to anymore. I'd recommend going there and reading up, it's really a great page (nuke powered X-ray lasers are somewhere in the middle of the page).
So I hope the graphics and UI will be a lot nicer than Aurora but to be honest the graphics are not my priority.
I perfectly understand that, and agree, but you don't NEED to do fancy graphics just because you're using a graphics engine. Apart from providing a flexible and fast environment for your GUI and the system display, it'll also do such annoying things like vector calculations, rotations etc. for you. I perfectly understand if you'd rather go with WPF for the GUI, I'm just saying that a graphics engine that already has a good GUI implementation could make a lot of stuff easier, and doesn't force you to go all shiny. They can draw vector graphics just as well as teh fancy lighting, and a lot faster than the WinGUI can. And if you want to go real-time display, you might need the speed. . .
Plus, you'd have Multi-Platform capability as a bonus.
-
As for graphics, I think the best option would be to go for a symbollic style, the kind you'd see on large screen inside a comand bunker. Actually modelling ships would work against realism greatly due to the -giganormous- size of space. A system similar to what Aurora I has but with the addition of some hollywood-alike fanciness has the potentially to be beautiful while not being very time-intensive. Glowing vector graphics would do that nicely. Think something like this (http://img.photobucket.com/albums/v284/Lynneth_del_Serpentas/AE/Multiverse/Nexus%20-%20Jupiter/Pic003.png) but without the starfield background. Or even with it, for that matter.
-
It would probably go as far as selecting battlegroups on the system map by mouse-over and giving them orders by pressing somewhere in space, given it's two-dimensional.
The problem he described would also maybe need some extra functionality, like a position a certain distance from the target in a heading dependent on the target and the current position, so with just a few clicks and orders you could split up a fleet of ships and surround a slower or unsuspecting enemy without using waypoints.^^
But I'll let him talk ;D
PS: If you go in this direction, why not also allow controlling of crew cycles etc, and moving seasoned crews to new ships, optional as overhauls? :D
PPS: Given we've talked about Neutron Bombs now, shouldn't that include lower damage, but temporary EM?
Like, Missiles effectively doing less permanent damage than now, but shutting down that CiWS for a few seconds or something?
And Missiles having different effects based on atmosphere?
-
Steve,
Have you considered using XNA as an engine? As a graphics engine, I like it, and am using it for a 2d game I'm developing myself. It also has some good stuff around the edges to simplify building the game portions. An added bonus: you can still use windows forms and things with it, so you could have a resizeable system map window, and implement the controls and views and forms as either overlays on top of that, or have pop-out controls as windows forms or windows presentation foundation objects.
-
By more control do you mean being able to give them a heading rather than a destination, or do you mean detail down to the level of turn rates and facing?
Steve
Well, at a minimum course and speed, with destination based orders for strategic movement. Turn rates and facing, with associated blindspots would make a more interesting tactical game, but would also add a lot of complexity.
Kurt
-
Have you considered using XNA as an engine? As a graphics engine, I like it, and am using it for a 2d game I'm developing myself. It also has some good stuff around the edges to simplify building the game portions. An added bonus: you can still use windows forms and things with it
I'm not too much a fan of XNA, but I have to agree that this would be a considerable advantage for a project like Aurora. You could even write in C# for it if I'm not terribly mistaken, which would mean Steve could catch several flies at once: Use his already written code, all the windows API and object-related stuff (like access and so forth, which I think has been heavily used in Aurora) AND have a graphics engine with a decent speed. . . I think this would indeed present an optimal solution that involves all factors that are currently in play.
PPS: Given we've talked about Neutron Bombs now, shouldn't that include lower damage, but temporary EM?
There's not much of an EMP by any nuke in a vacuum, I'm afraid. But a high enough concentration of neutrons would pretty much grill the crew while leaving the whole ship intact, which is certainly an interesting tactical option.
-
I think if ground combat was developed further, adding a hex system on top of Aurora would be jarring - if the movement system for ships and so on was a hex system then yes it would be a good idea.
If you were to develop the ground combat I would keep the same system used for space. Generate a random(?) map of terrain - it would only need an objective (colony/outpost etc) and areas of terrain if the are different from the norm (areas with more/less cover, movement penalties, impassible etc) and then move your unit designs around in the same way as you would any spacecraft. Keeps it simple and the same system used for both combats, the only difference is the addition of terrain modifiers. But, if you include that in the main game for instance certain asteroid types make it harder to detect ships within due to interferance, stars with high activity means ships can effectively hide if they are within 500k km and so on it would essentially be using the same code and for the players the same 'rules' for both types of combat.
If its division scale combat then something along the lines of HoI would fit very nicely, not get too bogged down in minutae of movement/los etc and still give great scope for planetary campaigns.
-
Something I forgot to suggest so far, but I'd really like to see that:
Economy! Like, a heavily industrialized planet importing food.
-
On the strategy vs tactics and deciding on one or the other--I'd sooner leave things the way they are. If I want space tactical combat, I'll pick up Homeworld or a similar game. If I want strategy, there's Sins of a Solar Empire (or a slew of others). Aurora is the only game that lets me handle both strategy and tactics in the way I've desired to for years. When I get into combat, I can see how my strategy dictates the tactics available to me, and the results of that combat drive my overall expansion strategy. It's a beautiful thing that Aurora has and to throw that away seems a terrible waste.
radiators won't be able to get rid of the heat from a decent scifi-drive unless you measure their area in squre kilometers
You say that like it's a problem. Look at our base distance measurement in Aurora. There'd still be plenty of room even in comparatively tight ship formations.
-
Something I forgot to suggest so far, but I'd really like to see that:
Economy! Like, a heavily industrialized planet importing food.
Aurora I already has that to an extent, but I'd like to see this expanded, this might make conventional elements a relevant resource, with populations generating conventional resources similar to how they generate trade goods now, and not only have trade in those but actually have meaningfull shortages. This could mean either simply listing the periodic table, or listing them by application (Ie, fusion fuel, rare metals, etc.), I can still imagine a hightech space hab would run into issues when the fuel supply runs out and they don't happen to be close enough to their parent star for solar power.
-
You say that like it's a problem. Look at our base distance measurement in Aurora. There'd still be plenty of room even in comparatively tight ship formations.
I don't say it's a problem because of lack of space. After all, there's as much space in SPAAACE as you could ever wish for. I'm talking about mass. You could make the radiators a lot more lightweight than they are today, but the areas we're talking about would still easily pack a few thousand tons. Then, you might think about what a few square kilometers of radiators would do to the target cross-section. Add to that that you can't put armor on them for obvious reasons, and I'm sure you'll be able to see that they're not so good an Idea in a game like Aurora, especially if there ALREADY are enough mcguffins that can do the job (like, laser deflecting shields that can just as well deflect the exhaust).
-
How about random things happening?
Like "Financial Crysis" -10% political stability and production, -50% wealth Creation. Effects diminish over a half year.
A suggestion I'd also give is to multiply some of the current values. Like, make ships have 10x as much armor, and weapons deal 10x as much damage.
Allows for a lot finer damage templates, orbital combat, etc.
And while were at it, Hull integrity. So a really big ship has to invest some hull spaces so it doesn't break apart if a big laser cuts straight through it. That will fight big ships being generally the best choice.
-
I'd rather not have randomness messing with my economy. However, I agree that much could be done to make the economy more chalenging. One thing I'm thinking about is actually making unemployment a bad thing. As things are now, you couldn't care less about having too many workers. You can grow a population without having to provide jobs for them, and they still pay taxes.
What I came up with that might add an interesting element is simply having unemployed workers not pay taxes, and marking all workers that are not working in an ACTIVE factory unemployed. Maybe even an optional "tough"-level where they cost you (as they would in real live). The financial crisis could come quite naturally this way: You're forced to terminate some projects because of mineral shortages, so you have to terminate some projects. Fifty percent of an industry on a planet goes unused, making fifty percent of the industrial workforce unemplyed, which might easily result in 20% drop in tax income. If this goes on a while, you might be forced to terminate some other projects because you're running out of money, resulting in more unemployed, and off you go into one hell of a recession.
-
Well if you going to have those things, some policies for colony governors should be in place to help in managing these additions.
Just as a governor that inflicts curfews, alien tolerance, alien intolerance, higher social policies, higher work policies.
These policies will be able to proved some control without complete micro management.
-
The problem there is that it will have absolutely no effect once you have several colonies.
Current, if a planet is 1000 negative a month that can easily be paid for by prospering colonies somewhere else.
-
We're neglecting civillian industry here, it might actually be a very bad thing if your government is employing 100% of its industrial sector, as the production of conventional goods would go down drastically. This would mean that military bases that employ almost all of their population would have to import a lot of things, which I feel would be a nice touch.
-
Interesting.
Maybe just add a third branch, after service, and agrarian, and name it civilian heavy Industry. That one would not take priority over manufacturing. Would solve a lot.
Still doesn't allow for unpredictable things happening, like a financial crisis induced by the breakdown of a bank or something.
I mean, people could still turn it off.
Predictability is boring.
-
Current, if a planet is 1000 negative a month that can easily be paid for by prospering colonies somewhere else.
Which is a great opportunity to bring a bit of mass psychology into the picture: people anywhere usually don't like it when they have to pay for "lazy buts" at the other end of the Galaxy. Taxes could be calculated per colony. If too much of the tax money of a colony gets spent improving another colony instead of theirs, there is unrest. You can fight this by making colonies as self-sufficient as possible, financing propaganda programms (making people feel more as a part of a greater whole etc.) and so on. It would be great if it also would bring a more complex taxation system: set taxes for colony level and empire level (after all, regional and national taxes are customary in most states).
Civil industry would certainly be cool. We already have civilian mining and shipping lines, so industry would be a logical next step.
Predictability is boring.
I thought in a strategy game, EVERYTHING is about predictability, i.e. your ability to predict stuff happening and taking adequate steps to prevent it from happening. Randomness might become a very frustrating factor in a strategy game. I'm not saying it has no place at all (there's a LOT of randomness in Aurora, after all), but throwing your economy upside down without giving you any chance to foresee and prevent it might be a tad frustrating.
For example, I had a financial crisis quite lately in my game. I saw it comming for a while, and had the opportunity to catch it by building financial centers and putting all my research into economy +20%. I had to take a lot of resources off from stuff I'd rather had been doing, but the problem had to be solved. And I solved it, just in time (I went something like 120 into minus). If I had a random economic crisis at that moment, I'd have been screwed. Now, if that crisis occured because I missed some important developements and stats, so be it. That's the game. But if that crisis happens purely out of the random generator, without me having any chance to prevent it whatsoever, I might just get a little frustrated.
Economic crisises usually happen because people are shortsighted and greedy. If a player is either, he has plenty of opportunity to get himself into trouble of any sorts, that to him might come quite unpredicted, while an expert player would have seen it comming long ago and took according steps to never even let it get a real problem. That's the fun of the game, at least for me. that, and exploring... I LIKE exploring in Aurora. It's also a pretty random thing, but it's still not so random that you couldn't saveguard against it. You ships don't blow up randomly, they blow up because you designed them badly, or neglected to watch their maintenance clock, or they get blown up because you didn't take neccessary precautions. For the economy, it should be similiar: a certain degree of randomness, ok. But it should still be predictable in a way system failures on ships are predictable.
If anything should be added randomly, then maybe disasters, that can also have an influence on your economy, but are justly random. There's no way to foresee that your major ordonance factory will blow up tomorrow because some bloke decided to have a smoke...
-
There's no way to foresee that your major ordonance factory will blow up tomorrow because some bloke decided to have a smoke. . .
I'd invest research points into No Smoking signs to minimise that random event from occuring. :o
-
I absolutely dislike complete predictability.
It would basically be part of your playstyle.
Sure, you can have a controlled economy, with modern tech it might actually work, or you could go for uncontrolled free market, with a chance of economic and financial Breakdown, but also higher gains in times of prosperity.
See, to take an off example, if your tank has a 70% chance to penetrate the enemy tanks armor, theres a good chance you win, but theres also a chance to lose. Knowing that fact, you have to take measures to sill beat it.
Also, currently Invaders popping up in your system are a random event.
It poses a challenge.
Random evens like an Ordnance factory exploding would also be a possibility.
While were at it, you could try to research automation, getting high production with few workers, and then establish a utopian welfare state after 100 years, where unemployment is no problem enemy because working is so yesterday.
Of course it decreases the number and moral of your troop supply.
As for psychology:
It gets complex there, because yes, it might be that your paying largely for an other colony, but that might be a military beachhead, or the only supply of a rare mineral, or food.
-
In my humble opinion adding more complexity should be an optional difficulty, like toggling no maintinance. like a realistic economy setting for the planning 100 years ahead pros among the boards.
But one thing i would like to see is the conventional industry getting some popular use. I can think of many reasons why they'd remain popular even in games of multiple colonys spread over a handful of colonys. A Conventional Industry building could be a sourse for the production of comercial shipping. Contracts could be set up to build transnewtionian buildings/components that use the industry. The industry could be used to make use of population not working. As mentioned above non working population wouldn't generate income but if they had CI's then they'd be happily toiling away building and maintain non transnewtionian tech. Like producing civilian goods for trade purposes when not contracted for other things.
When CI is used as part of a contract they'd only have say 1/3 of the base building power of normal factorys and potentially be used to help ballance production of the much larger ships if assistance is contracted out to the civilian sector. Of course Newtionian buildings have population priority over CI if theres not enough population for all the structures
-
See, to take an off example, if your tank has a 70% chance to penetrate the enemy tanks armor, theres a good chance you win, but theres also a chance to lose. Knowing that fact, you have to take measures to sill beat it.
As I was trying to say with ship failures, Such "random events" are totally acceptable, because they're not "random" in a completely unrelated way. Everything still has causes that are accessible, and you can do enough to shift the odds in your favour. It would be completely ok to have a higher chance of an economical crisis occuring if you for example, tax the private industry too high or stuff like that. What I was saying is that actual randomness, i.e. stuff happening completely unrelated to what you can do and can know shouldn't really be in a strategy game.
I didn't know that inaders in your homw system where completely random. I didn't have any so far, so I wouldn't know: surely there is some way to spot them on their way in if you set detectors in surounding systems?
-
Maintenance supply's
One of the few in consisties that i see in aurora is that ships require maintenance supply's but buildings are perfectly constructed, ok some of them might make maintenance supply's for themselves but some obviously can not.
My proposal is this make it so that maintenance supply's are like infrastructure is a trade good and a builderable item the rate of trade production being decided by free industry and maintenance yards but have buildings fail and require supply's to repair them, everything breaks eventually most of the time these should be small things with the occasional large thing requiring lots of supply's a failure without supply's results in a building (type determined when the failure type occurs to allow the fact that factories and mines are more dangerous than finance centres) to go inactive repairing this takes time when supply's arrive to take into account that it would take time to repair a failure that happend some time ago than repairing it as it happened, the trade good section is to allow civilian ships to automatically supply automine planets without having the player constantly resupply his planets manually (talk about a lot of work for a large empire), a minimum limit should also be setable to allow the player to setup military bases to be setup easer by having the civilans transport supplus when they get to low (below the amount set) this would be more realistic as companies (and the military?) probably buy spare parts from the companies that make the products (cheaper and more efficient this way) rather than the government
Another think would it be better to allow civilian ships to transport missiles (which go boom if the cargohold is destroyed in an attack) and ship parts (engines weapons etc) therefor allowing a planet the make the parts and another with shipyards to use them.
Last thing, escort ships allow civilian shipping to build the obsolete warships that you allow them to (tick box) this would allow rich companies to build ships that sit in formation of their ships and protect then from attack when traveling through dangerous sectors these ships would be very expensive to buy 5 to 10 time normal cost to cover licences, insurance, etc (so no private fleets that might compete with the navy) thus rather rare, a trader does NOT want the missiles he is transporting to go BOOM.
Thank you for reading
positive comments welcome, negative ones not so much
-
I didn't know that inaders in your homw system where completely random. I didn't have any so far, so I wouldn't know: surely there is some way to spot them on their way in if you set detectors in surounding systems?
If they approach your homesystem through normal space, i.e. they spawn in another system and then decide to come to you, then yes, you would spot them coming.
Unfortunately, the backstory is, that they are from a different Universe, and come thought a stable wormhole, which forms in a random system. If this system happens to be your homesystem, you´re pretty much screwed (at least early to mid game).
And yes, that´s the one realy random thing, I don´t like (not the Invaders per se, but that they can appear in your homesystem. I usually disable them for a while, until I could handle them tech-wise, because having them hit me after some heavy investment in a campaign is just too frustrating. Now, if there would be a checkbox to only let them spawn at least two systems from any homewolrd, that would be another thing).
-
Maintenance supply's
One of the few in consisties that i see in aurora is that ships require maintenance supply's but buildings are perfectly constructed, ok some of them might make maintenance supply's for themselves but some obviously can not.
My proposal is this make it so that maintenance supply's are like infrastructure is a trade good and a builderable item the rate of trade production being decided by free industry and maintenance yards but have buildings fail and require supply's to repair them, everything breaks eventually most of the time these should be small things with the occasional large thing requiring lots of supply's a failure without supply's results in a building (type determined when the failure type occurs to allow the fact that factories and mines are more dangerous than finance centres) to go inactive repairing this takes time when supply's arrive to take into account that it would take time to repair a failure that happend some time ago than repairing it as it happened, the trade good section is to allow civilian ships to automatically supply automine planets without having the player constantly resupply his planets manually (talk about a lot of work for a large empire), a minimum limit should also be setable to allow the player to setup military bases to be setup easer by having the civilans transport supplus when they get to low (below the amount set) this would be more realistic as companies (and the military?) probably buy spare parts from the companies that make the products (cheaper and more efficient this way) rather than the government
Another think would it be better to allow civilian ships to transport missiles (which go boom if the cargohold is destroyed in an attack) and ship parts (engines weapons etc) therefor allowing a planet the make the parts and another with shipyards to use them.
Last thing, escort ships allow civilian shipping to build the obsolete warships that you allow them to (tick box) this would allow rich companies to build ships that sit in formation of their ships and protect then from attack when traveling through dangerous sectors these ships would be very expensive to buy 5 to 10 time normal cost to cover licences, insurance, etc (so no private fleets that might compete with the navy) thus rather rare, a trader does NOT want the missiles he is transporting to go BOOM.
Thank you for reading
positive comments welcome, negative ones not so much
Hm, except for PDCs and the like, all buildings are considered civilian. Civilian ships don´t need maintenance supplies, so why should buildings? I don´t see the inconsistense here.
PDCs would probably need them, but could be handled like ships in orbit with enought maint-facilities, i.e. just costing some minerals.
I´ll scond the "civillians can transport missiles" and would like to expand this to "all cargo holds can hold missiles as cargo", i.e. not in a "ready to use" form.
I am a bit undecided on the "armed civillian ships".
I could envision something like this if your race is a corporate government or oligarchy, but a monarchy/tyranny/dictatorship? No King/Dictator worth a damn would allow some private corporation to own armed spaceships, whatsoever.
Perhaps make it dependant on the government form?
-
Speaking of which, government forms should have more influence altogether, I can't see a military dictatorship outsourcing the supply of military bases to the civillian sector, at least not on a large scale. Of course some of this is up to the player to RP, but NPRs should take it into account to some extent, and the more in-character options should be somewhat more attractive.
-
Just my two cents. I never have cared for games that throw in completely random events just to make it seem "realistic". I like aurora because I can concentrate on the 4-Es and if my economy crashes it is because of somethig I did or didn't do. So if Steve does add that, I really hope he makes it optional in the set up.
-
That was the plan all around.
And as Uncle said, I didn't voice it properly. Having the risk of economic breakdowns would be a players choice in exchange for higher wealth creation, more trade, and less RP cost to try and prevent it.
-
Random events are not truly random, if an ordnance factory blow up it probably due to lack of maintenance or workers are overworked, or a terrorist attack.
The reason why other games have random events because, is because of lack of detail in there games. Aurora has a lot of detail, its not a complete colony simulation so the events are minimised as they are not taken into account. I am sure with more work around the colony area you will find a lot more event occur, such as ships blowing up in space because they have not been maintained.
-
Yeh, but managing every single facility so nothing goes wrong?
I think that'd be overdoing it.
-
Here are one or two screenshots to show the progress so far. Still playing about really but the system map is starting to take shape. The first picture is a zoomed-in view of the red dwarf at the centre of the Gorshkov system,along with the closest planet
-
System Traffic near Epsilon Eridani II
-
An example of the popup text if you move the mouse over the icon or the label for Carrier Strike Group - Akagi
-
In the new UI you can smoothly zoom in and out with the mouse wheel, centre the map by clicking on a system body or a fleet, or hold the left mouse button down to drag the map around. Down the entire left-hand side of the map are a list of Systems and a list of fleets. Clicking on a system will take you to the last view location in that system. Clicking a fleet will centre the view on that fleet, changing systems if necessary. As you resize the main window, or change resolution, the listboxes will dynamically resize so both will always be in view and the map will recentre on the smaller or larger viewing area.
-
Asteroids in the Wolf 359 system
-
Hostile FACs spotted in the Gorshkov system. This is a temporary label for the hostile icon as I haven't tackled sensors and contacts yet.
-
A hostile frigate spotted in the EZ Aquarii trinary system. The grey dots near the star and in the upper right are asteroids.
-
Same system, showing the popup text when you mouse over a star.
-
Looks great ! .... Can we presume that there will be no more development on Aurora I since it looks like your pretty much got Aurora II going well ?
-
Looks interesting, I am presuming those planets are planets with atmospheres, that why they have the blue hue around them?
I must say I like the orbital rings in the current one I am sure it will be this version but fr some reason make it easier for me to visualise the planets, don't ask me why. <smile>
Looks like the fire is in the belly for version two which is great.
--------------------------------
On ideas for v2
One thing I would love to see in version two is more diplomacy options, alliances, truces, force AI to truce with at war factions, etc.
I think this would add great additions to aurora, it would not be just blast everything off the face galaxy but may have you working with races, to achieve goals.
PS
Steve I have some 3D skills in Maya and worked on mods in the past and present, so if you need anything mocked up in 3D for an images or 3D usage, just ask I be happy to help in anyway I can. I attached a couple of samples, on stuff I am working on at the moment.
-
Maybe it's what were used to, but those new pics feel incredibly detailed. ;D
Looking awesome so far.
-
I must say I like the orbital rings in the current one I am sure it will be this version but fr some reason make it easier for me to visualise the planets, don't ask me why. <smile>
I second that. I hope the Orbitel paths of the planets won't get abolished. Maybe, if it doesn't take too much of re-structuring, even add eccentricity to the orbital elements and go for eliptic orbits. But that would probably need some new code in the planet generator, since you have to take the eccentricity into account when checking for habitability, at least if the eccentricity is significant.
-
I second that. I hope the Orbitel paths of the planets won't get abolished. Maybe, if it doesn't take too much of re-structuring, even add eccentricity to the orbital elements and go for eliptic orbits. But that would probably need some new code in the planet generator, since you have to take the eccentricity into account when checking for habitability, at least if the eccentricity is significant.
3rd'd Op and second bobs idea as well :D
-
Maybe it's what were used to, but those new pics feel incredibly detailed. ;D
Looking awesome so far.
Second with u Unlimited...
slurp..slurp..i CANT wait for V2...slurp...
ok seriously.
Go Steve Go!!!
-
Steve,
Looks amazing so far and you have me pumped about this. I would like to second though having the option to turn on orbital rings too.
Looks great keep up the great work.
-Five
-
Another thing I'd like is proper binary orbits, it feels weird that when you have two stars of near equal mass the jump points are all arbitrarily aligned to one of them. Simply creating an invisible ghost star at the centre and having the other two orbit around that with equal periods should do the trick.
-
Well, considering jump points will be no more, does that still make a difference?
-
It matters for orbits and system the new warp limit, I guess, but you have a point.
-
I would like to see an expansion on ground combat, not sure how exactly. . . maybe some representaion of the ground and your forces pushing across it. . . for 2d planes working from one side to the other i guess. or you could go all out and it can be two games in one. Space game with a ground game tucked inside for those times.
Also i would like a way were populations(along with their buildings) of the same race on the same planet can be combined if you wanted to.
-
Hello everyone joined the forum today nice to meet you all.
Anyways, there is something wrong with this forum, as I can't see images.
Sorry if my English is bad, I'm Brazilian.
-
Another possibility, multiple races living in one population. Due to different environment tolerances population numbers would have to be counted seperatly, but I don't think it makes sense that you have to move a factory to the other side of a planet just so that Cetans can work in it instead of Terrans.
-
My suggestion would be a random race setup without going into SM to do it. I find if I start a race I keep going till I get a more then optimum outcome.
On that note also races which have need of different environmental factors.
-
Variations on hydrospheres: Oceans are all nice and well, but some planets would have oceans not made of water, and some species might need those liquids to survive. It might be a nice touch to add.
-
I would like to see an expansion on ground combat, not sure how exactly. . . maybe some representaion of the ground and your forces pushing across it. . . for 2d planes working from one side to the other i guess. or you could go all out and it can be two games in one. Space game with a ground game tucked inside for those times.
Also i would like a way were populations(along with their buildings) of the same race on the same planet can be combined if you wanted to.
Steve love too TROOP features (as "Fading Sun" like..but much less complex hope.-.:D) so am think Steve r thinking how put them inside game.
apologize my english:)
-
Oh, something I thought of yesterday:
In any kind of non-strategy game to the topic, theres always equipment from different companies, with various advantages etc.
How about a system that mimics that, with an actual economy that might be able to produce stuff for or research through civilian contract.
-
Oh, something I thought of yesterday:
In any kind of non-strategy game to the topic, theres always equipment from different companies, with various advantages etc.
How about a system that mimics that, with an actual economy that might be able to produce stuff for or research through civilian contract.
Interesting idea. I was considering having actual civilian shipyards rather than abstract it and having civilian companies build some warships for the government. I guess civilians could also handle some government-funded research as well.
Steve
-
You even do it that you give out a contract for a new weapon, like "20cm laser", and then various companies randomly generate a design, and some of those might have serious flaws, but be cheaper for the player, so you get a weapon needing 5 energy, but getting 8, with not the highest possible RM, but hey, it's 20% off, I'm going to buy from those guys.
Or as a military joke says; "Your equipment was always made by the lowest bidder." ;D
-
I like the idea of this as well, what you can also do is have a small variance in the outcome of these civilian contracts on research, where the performance might be slightly better or worse then expected outcome.
With my implemented research I give them company names, just for a bit of RPGing
(I tend to think implemented is the final design and theoretical is the stage before e.g Ion Engine, theoretical, Ion Engine E.7 A1, implemented)
I think implemented should be corporate but theroical should be government/uni's like it is really now.
-
I just thought a while about missiles and I think something needs to change.
Nowadays, most missiles have some implemented guidance system, especially of the smaller kind.
In Aurora, though, this is not the case as Sensors take plenty of space that could be used for something else, and warhead size actually matters.
So I figured that this would be a possibility to improve on in the next installment, by differentiating between pure FC and FC+Sensor.
A missile could be build to still require sensor coverage from the big ships, but find it's way into the target automatically.
This could also be used for advanced tactics, like marker beacons to be shot at enemy smegs to still find them.
Also, currently, a Firecontrol can only guide so many missiles at a time, so putting a limit on the total missile size a FC can guide into a target at any given time should maybe be limited.
This would again allow for the good old "park a huge missileswarm somewhere" tactic, but would require the player to invest in massive firecontrols and electronic markers to aquire a target and control that many missiles, and it would make sensor-guided missiles somewhat viable, with a higher homing range.
Even homing missiles that auto-target, but don't aquire a new target on a miss would be a possibility then.
-
I just thought a while about missiles and I think something needs to change.
Nowadays, most missiles have some implemented guidance system, especially of the smaller kind.
In Aurora, though, this is not the case as Sensors take plenty of space that could be used for something else, and warhead size actually matters.
So I figured that this would be a possibility to improve on in the next installment, by differentiating between pure FC and FC+Sensor.
A missile could be build to still require sensor coverage from the big ships, but find it's way into the target automatically.
This could also be used for advanced tactics, like marker beacons to be shot at enemy smegs to still find them.
Also, currently, a Firecontrol can only guide so many missiles at a time, so putting a limit on the total missile size a FC can guide into a target at any given time should maybe be limited.
This would again allow for the good old "park a huge missileswarm somewhere" tactic, but would require the player to invest in massive firecontrols and electronic markers to aquire a target and control that many missiles, and it would make sensor-guided missiles somewhat viable, with a higher homing range.
Even homing missiles that auto-target, but don't aquire a new target on a miss would be a possibility then.
Way back when there was a long discussion about implementing active guidance (as opposed to semi-active). Steve wasn't that keen then, he may have changed his mind. I don't disagree with the idea BTW, I was keen on active guidance. The thing to remember about your example is that active guidance in the real world is incrediably short ranged compared to ship or land (or air for that matter) based platform fire control systems. It is all a question of power aperture available for a missile versus the guiding platform. I agree with limiting the number of missiles a FC can control as well.
-
Ok so I've not been playing this for at all very long but given its seems like a gem of a game and getting new ideas in early tends to make them easier to implement here are a few ideas:
- Would you consider directional damage for weapons combined with some of the earlier ideas of systems placement in ship design? I love the idea of having to decide if I want to heavily armour the front of my ships at the expense of weaker sides etc. Similar for placement of modules with perhaps inner, outer and hull locations
- Weapon arcs for non-turret beam weapons, and firing solution arcs for missiles / PD
- Consumables for ships crew to give them other restrictions on length of use before resupply or some decisions as to whether a portion of crew are in cryo v active for portions of a trip
- I might be early on in the game but it seems that there are not that many opportunities to build different structures that influence population happiness / growth rates
- What about a pollution index and facilities to deal with this to impact population happines / productivity etc
Really like the idea about dropping jump points but still having a use for grav surveys and sticking to a tactical approach to combat
-
Steve will you use "power" for other things then weapons? If you do Batteries might be nice too f. e. for lower maintaince-costs (up to ships without generators which have to refuel power) or powering life-support and the drive while the lasers are draining all the energy from the generator in some kind of battle.
-
Please Don't remove JPs entirely!
They're one of the things that got me truly interested in this game in the first place, and an element that sort of defines it, rather like the Koi and the Elephents in DF!
Perhaps you could have both of these techs exist simultaniously?
Jump Points/Gates:
+Instantaneous
+Jumpgates grant easy commercial access
+Great Fuel Efficiency
+Jump Groups all arrive at the same time
-Requires Grav Surveys to find Jump Points
-Jump capable ships/Jumpgates expensive to build and maintain
-Disables the vessel making a jump (as now)
-Limited Access to star systems (A system could be only 1 light year away and take 6 jumps to get to)
*Jump Points can be anywhere in system.
'Hyperdrive'
+High Accessability (If a system is in range, you can get to it)
+Cheaper to build and maintain, and thus can be mounted on most ship designs
+Can go straight to near by star systems without need to survey for Jump Points
+Ships Arrive in System Grav well fully functional
-Less Fuel Efficiency (Somewhat offset by bringing tankers along)
-Effectively lengthens flight paths for both private and federal sectors
-Commercial ships lacking Hyperdrive are without FTL, so not as easily accessable to commercial market
-Possibility for ships to arrive sporradically in both spatial and temporal relation.
*Grav Surveys present detailed outline of the 'Warp limiter' that marks where the ships can or can't activate their hyper drives, wich will often be beyond midrim at least.
Also, it should be made theoretically possible to expand research in both fields, but made difficult enough that something's going to suffer. Could also include an option to disable one or the other in game, just for varieties sake.
EDIT: OOoooh. . .
Aditional Techs would of course improve utilities. Perhaps some Jump Points are unstable, and can't be accessed until requisite tech is reasearched. Increased Stability in Jump Drives increasing size (in area) of Jump Points and reducing the effect of being disabled or blined by jumping.
Similarly, additional research in the Hyperdrive would increase range, fuel efficiency, accuracy, and decrease the 'limit' radius.
-
As that was just a suggestion for current Aurora that doesn't seem to be that easy, I figured coding that anew from the ground up might resolve that problem.
In A2 how about having a small UI for that to define the standard config of ships, maybe dragging weaponsonto firecontrols to assign them, same with Ammo, and set secondary systems, like a backup firecontrol to take over if the first one is destroyed.
-
I'll make a suggestion for the organic development of Research Institutes. I envision them as akin to universities that develop on planets on their own. For example: an Advanced Propulsion Laboratory could arise on a planet. Placing a PP researcher on that planet would allow his modifier to interact with the modifier for the institute. I see running such labs as substantially more expensive per research point than just placing scientists at research labs, but with two key bonuses. such facilities act as breeders for talented scientists; the better scientists working at the institute, the better grad students they get in their field, and thus higher bonuses for the next crop of leaders in the field. The second bonus is that they can spontaneously provide research points on items not being specifically researched, speeding research on all items in the field-- randomly and organically.
I also suggest them as rather rare-- one could go a whole campaign without ever seeing 2/3 of the institutes arise.
-
Hmm, nice point, that reminds me of something else:
When, for unimportant reasons, I was recently checking something on WW2, It came to my mind that in this war, essentially the same weapons, based on the same technology, were used years in a row and yet steadily increased in efficiency.
Maybe it could be possible to have an efficiency quote for technology applied to the prime function, over the time of use?
So 4 years after developing a reactor tech, it has an 8% bonus output?
-
Dumb question oh great and wise Steve, but are the basic concepts mentioned in the first page already hard coded and set in stone. Because I had a brainwave of sorts about how travel can occur in real time in real space with the inclusion of using jump points as they are now known in aurora the 1st. If theres no interest in including instant travel of any kind I wont stir the pot on that subject. But if so I'm going to need to upload a word/text document and make sure my math doesn't prove Einstein wrong. His ghost has friends in high places :'(
-
Something I'd like to see in any build of aurora is disease. This could be random diseases springing up from contact with aliens and native viruses mutating in new environments, or even weaponised plagues. Those genetic scientists could have something new to research rather than modifying humans (does anyone really bother with that anyway?) And the results could be deployed with a specially made planetary bombardment missile, or perhaps an espionage team.
Random diseases could be picked up by surveyor teams, or warships that pick up alien life pods. They could have a random(ish) incubation period and then start their effects, which for simplicities sake would mean the sickness and death or infected personnel. On a ship this could mean the loss of all hands and it's destruction, but if it gets on a planet (say that ship docked for refueling or maintenance) It could start hitting the population, reducing it and causing economic troubles for the planet.
Could be combated, reducing it's effectiveness by building an installation, "Medical Center" for example. More of these gives your administration a higher chance of finding a vaccine faster, limiting the damage but never entirely preventing it form being a pain.
-
That's a very nifty idea. Another means of transmission could be freighters and such. Say, for instance, some disease springs up on a frontier colony world, but it's asymptomatic at the time a passenger ship comes and picks up some infected colonists. The ship goes to, say, Earth. From there, it could spread in every direction.
-
Hmm, nice point, that reminds me of something else:
When, for unimportant reasons, I was recently checking something on WW2, It came to my mind that in this war, essentially the same weapons, based on the same technology, were used years in a row and yet steadily increased in efficiency.
Maybe it could be possible to have an efficiency quote for technology applied to the prime function, over the time of use?
So 4 years after developing a reactor tech, it has an 8% bonus output?
I confess, one thing i'm less keen about is having to create research projects every single time I need to do an upgrade on every component. But is there a better way to do it? One thing that caught my eye in the ship design thread was someone was naming their components things like "The Pratt and Whitney" engine or whatever. Which gave me an idea. (don't know how viable it is for actual game design).
Once you design a technology, the civilian industry has thus received an order to manufacture it. Over decades, they continue releasing new models and obsoleting old models, incorporating newly discovered technology. Sometimes they'll make something kinda crappy-- like an engine that blows up when bumped, or maybe one that with a crummy power\weight ratio. But thats all you get as a ship designer, you're stuck with that god awful XL-5 engine that makes the horrible grinding noise. Othertimes they'll make something fantastic, like the YF-11 that can take a fricking torpedo in the side and keep humming at full capacity. So the player can design the basic outline of a grav sensor for a fighter, for example, and the low bidder starts making the design. Better richer civilian industry thus translates to tougher, better ships.
I think its awesome, but I don't know that it meshes with the aurora paradigm. Cheers
-
Something I'd like to see in any build of aurora is disease. This could be random diseases springing up from contact with aliens and native viruses mutating in new environments, or even weaponised plagues. Those genetic scientists could have something new to research rather than modifying humans (does anyone really bother with that anyway?) And the results could be deployed with a specially made planetary bombardment missile, or perhaps an espionage team.
Random diseases could be picked up by surveyor teams, or warships that pick up alien life pods. They could have a random(ish) incubation period and then start their effects, which for simplicities sake would mean the sickness and death or infected personnel. On a ship this could mean the loss of all hands and it's destruction, but if it gets on a planet (say that ship docked for refueling or maintenance) It could start hitting the population, reducing it and causing economic troubles for the planet.
Could be combated, reducing it's effectiveness by building an installation, "Medical Center" for example. More of these gives your administration a higher chance of finding a vaccine faster, limiting the damage but never entirely preventing it form being a pain.
This is something I have been considering for a while and along similar lines to what you suggest above. Although I hadn't considered the idea of picking up a disease from life pods. Perhaps ships would need special decontamination chambers for picking up aliens. I have have already done a little preliminary work in existing Aurora for this. There is a KnownSpecies table, which tracks on which species a particular empire has data. Each species is rated as Existence Known, Autopsy Performed or Bio Research Performed. This tracking is already happening in v5.42 but there is no visible sign yet in the user interface.
When you pick up life pods or conquer a population, a species moves into the Existence Known status. My intention was to allow an 'Alien Autopsy' research project for each species with a status of Existence Known. This would provide you with information on their biology, such as environmental tolerances. This would lead to a Bio Research Project, that would be necessary for the creation of tailored bio-weapons. This knowledge would be combined with other genetic warfare projects to allow the creation of specific viruses that had lethality rates and contagian rates. I think there might be a thread about this in the dim and distant past. Natural diseases, as you mentioned above, would also fit into this model, with the possibility of mutating to other strains that could attack other species.
This will probably make it into Aurora I at some point. I haven't done any work on Aurora II for a while, partly because my time has been very limited and partly because I have been working on Aurora I. I am beginning to wonder if some sort of gradual transition might be possible, using C# to replace some key existing parts of Aurora and run a program with elements from both languages. I need to look into this further.
Steve
-
Steve, have you considered switching from MS Access to MS SQL Server? It handles larger databases much better. The Express edition is free and deployable.
-
Steve, have you considered switching from MS Access to MS SQL Server? It handles larger databases much better. The Express edition is free and deployable.
I have the Express version installed as I was considering it for Aurora II. I find Access is a lot easier to play around with but I assume that is just familiarity. The main issue would be changing every SQL query in the program to use SQL server. I am still using DAO at the moment :)
Steve
-
I have the Express version installed as I was considering it for Aurora II. I find Access is a lot easier to play around with but I assume that is just familiarity. The main issue would be changing every SQL query in the program to use SQL server. I am still using DAO at the moment :)
Steve
I would recommend sticking to DAO for SQL as well, honestly. Part of the point of DAO (and DAO.NET) is to provide some database backend abstraction so that you can easily change what the data source is. Of course, in the .NET world, how you'd use DAO would be different, but you've already done some of that work in Aurora II, as I remember.
-
Autopsy Performed
Shouldn't that be "Alien Autopsy Performed"? And shouldn't there be a movie? :)
I am beginning to wonder if some sort of gradual transition might be possible, using C# to replace some key existing parts of Aurora and run a program with elements from both languages.
The good news: since both C# and VB.NET compile into CIL (or CLI or CLR or .NET or whichever of the Microsoft acronyms is correct in this context), you can trivially call a C# assembly (DLL) from VB code and vice-versa.
The bad news: I'm 99% certain that the VB.NET compiler (i.e. the current VB compiler in Visual Studio) won't compile VB6 code without a port. From the wikipedia entry http://en.wikipedia.org/wiki/Visual_Basic_.NET#Relation_to_older_versions_of_Visual_Basic_.28VB6_and_previous.29 it sounds like there might be some auto-conversion tools out there....
John
-
So it's essentially about finding good conversion tools now?
We're not the first to ask for that though... http://bytes.com/topic/misc/answers/588553-how-convert-vb6-code-c-there-any-translator-available (http://bytes.com/topic/misc/answers/588553-how-convert-vb6-code-c-there-any-translator-available)
Aside, wouldn't it be theoretically (I never actually got into those languages deep enough, I'm lazy) possible to split the current Aurora into several chunks of code, convert them, make dlls out of them that are called by the new A2, and then gradualle replace the bits with new code?
On the other hand, the result is the same; if you work on A1, you'd have to do everything again in A2, if you work on A2, it'll result in no actual progress for ever a year until all critical parts are ported.
-
Might I suggest that you outsource some of the more tedious work to people with free time and knowledge of the tools, then they send back their work and you go over it with a fine comb looking for faults and making sure nobodies attempting to "upload a virus into the mothership"? It could save you some time for the more fun aspects and move things along faster and possibly help you learn the language? I've always been tempted to learn to programme just do what you've done which is to make a game of your liking.
-
I'll confess that PC/LAN programming and database handling is a major weak point for me (mainframe background). My specific knowledge of MS SQL Server is next to nonexistent. In my new job, less than a month, we're using it for AdHoc reports only. In my research to figure even that much out is where I can across the issues that Access has with 100mb+ databases and multiple users. With SQL Server handling larger DB's and multiple users it would appear to be a better route to take for Aurora II.
I have no doubt that there are significant hurdles to overcome, and I'm the first to stick with what I already know. This just seems like an nearly ideal point to make is switch if one was going too.
-
Sorry if it has been said already. Multithreading. I noticed this game takes up like 80% of a single CPU on my computer and was like WTF?
-
Curious is Aurora II still on the cards, I noticed Steve still expanding Version 1.
-
Not keen on the real time idea...hate real time games and always preferred turn based....if the game goes real time I'm out.
I would love to see a in depth tactical ground warfare element, not talking hex based map or anything, just the ability to issues high level orders etc....expand the ground warfare and I'd be happy...also be able to issues tactics to your ships during combat which you can train them in to get better at them (esp at fighter level)...you'd have to use your imagination to think up different types of tactics that would be used, maybe look into modern ship combat tactics...or base them on WW2 tactics but in space at greater range, sure there is alot of info out there with regards to this.
Howabout chemical warfare....you meet a new race and then after capturing some be able o research chemical warfare against that particular species...so you can bombard them and wipe them out yet keep all their stuff......or it could all go wrong and they mutate into more powerful beings!!
-
There is already some light chemical warfare in-- don't let alien terraformers sit in orbit.
I feel similar about the real time thing though. The level of complexity is so high... but, being able to set semi-continuous tics would be nice just so long as they're easy to halt and alter.
But whats really needed more than anything is an engine overhaul-- same game, just running with a main window and pop ups instead of fixed height windows. Thats a good plan.
-
It's not "real time" in the normal sense.
From the original post: "you can pause it, or accelerate it. This is isn't as different as it sounds because it will be similar to permament automated turns with the sub-pulses equal to the acceleraton rate and no defined increments."
From a later post: "I think my comment about real time may have given a false impression. I still don't intend to allow a command and conquer style interface where you command ships as they are moving. You will give orders while the game is 'paused', just as in Aurora, and then let it run until something happens, just as you currently do with automated turns. In effect I am making automated turns part of the normal function and removing the higher level increments while retaining the lower-level sub-pulses. The function will be internally very similar to the way it is now but the impression should be a smoother-flowing game."
-
That sounds better....thank god it's not a C&C RTS idea....
Steve is a genius
-
I think this is a very exciting idea. I like the pausible real-time!
My only suggestion, and I know you will hate the idea ;). . . . please document the mechanics somewhat completely for game play.
It seems like your pattern has been to make changes as they occur to you, which is great. But I think it becomes a huge huge obstacle for new players to get into the game if you aren't in at the beginning. There are so many features that are unexplained, and interactions that are opaque, processes that are arcane. . . it just gets a bit messy. Just a single source with 'this item does this by this process' would be super helpful.
-
I think this is a very exciting idea. I like the pausible real-time!
My only suggestion, and I know you will hate the idea ;). . . . please document the mechanics somewhat completely for game play.
It seems like your pattern has been to make changes as they occur to you, which is great. But I think it becomes a huge huge obstacle for new players to get into the game if you aren't in at the beginning. There are so many features that are unexplained, and interactions that are opaque, processes that are arcane. . . it just gets a bit messy. Just a single source with 'this item does this by this process' would be super helpful.
Welcome to the world of Aurora!! It's chalk full of "undocumented features"!! ;D
-
Not keen on the real time idea...hate real time games and always preferred turn based....if the game goes real time I'm out.
There's nothing wrong with the realtime method per sé. It doesn't mean Aurora II will suddenly become StarCraft just because it works in realtime.
While I support pausable realtime with a number of speed settings, I do believe processing must be optimized for that. There's no way any single CPU on Earth could process the first Aurora's calculations in realtime, but I'm guessing it'll be easier for Aurora II with a good deal of optimization, a different coding language and multicore support. There needn't be a significant graphic jump either: just seeing the dots and lines in a tad better quality moving, with simple, clever effects and creative information display would be awesome. :D
-
If we're talking about making the game more realistic, would it be possible to have realistic communications of some sort? It could be optional, like maintenance supplies and fleet crew training. It would basically require you to give ships communications systems which would have a certain range. There would also be the ability to set up communication networks, so you can relay messages through a series of communication arrays on ships and colonies. The communications could be transferred between systems through some sort of specialised system, which might have a higher EM signal than normal sensors or only be able to transmit to and receive from other systems outside the jump limit/jump point(Or whatever interstellar travel method you decide use).
This would provide interesting scenarios and create a necessity for communications networks to be set up, kind of like how Steve often has jump ships sitting on jump points to send messages between systems in his fiction.
-
In a sense, such things are already included - it's just up to the player to roleplay it that way. The only improvement I would suggest is a 'send-message-to-myself' window that automatically calculated the speed-of-light lag for a message from the designated fleet to reach the homeworld. So if my exploration ship encounters a hostile alien, I can send a contact message to my homeworld and the event window will alert me when it arrives, so I can mobilize the Punishment Fleet for a little payback.
-
In a sense, such things are already included - it's just up to the player to roleplay it that way. The only improvement I would suggest is a 'send-message-to-myself' window that automatically calculated the speed-of-light lag for a message from the designated fleet to reach the homeworld. So if my exploration ship encounters a hostile alien, I can send a contact message to my homeworld and the event window will alert me when it arrives, so I can mobilize the Punishment Fleet for a little payback.
That message might take a while to arrive. If you turn on the 'show distances' option in the galactic map you can see there are typically several light years, if not more, between each system.
-
According to the tooltip, that number is billions of km, not light years. (1 Light Year = 9,460,730,472,580.8 Kilometers)
Edit: And I think it's the travel distance using jump points from the star of the selected system to the star of the destination system.
-
Well, Steve wanted to go from JPs to Hyperspace travel.^^
In any case, this stuff can't be implemented into the game that easily because the player is ultimately one person.
-
Well, Steve wanted to go from JPs to Hyperspace travel.^^
In any case, this stuff can't be implemented into the game that easily because the player is ultimately one person.
One of the things which SA had and which was taken out of Aurora (I) was the ability to send a message with a particular time delay. Many of us used this to build a "chinese wall" - we would calculate the time it took for a message to arrive at the command center where we wanted to react to it, then send ourselves a message with that delay saying "ok, now you can act on the information you already know". In Aurora, Steve assumes superluminal communication, but it's a role-playing thing. Those of us who would like to have a house rule restricting in-system communication to light-speed would REALLY like to have this sort of thing back. I know I've put it on the suggestion board in the past, but it's one of those things that just never made it into the game (probably because Steve never stubbed his toe on it because he's not using this rule in his games). I assume that this is what Father Tim was talking about. In the context of Aurora II (assuming no JPs at all), it would be used for in-system communication. For example you'd give a command "send light-speed message from ship X to object Y". The game would record the timestamp and location of X when the message was sent, then every update would check whether it had arrived at the current location of Y (and what the ETA was in case it needed to shorten a pulse). When the message arrived it would pop up as an event and the player would only then give Y orders reacting to the event.
John
-
Steve: will Aurora 2 use a database?
I know one of the major feature changes was that Aurora 2 was going to keep all the game state info in primary memory in order to speed up the game. If you're doing this, is there any particular reason to keep using a database to store the universe's state over just serializing everything out to a file?
I ask because the database, I believe, is the single worst thing about Aurora 1, and stops me from playing it as much as I'd like. (I'm actually kind of afraid to touch it right now.) I get a *lot* of database errors while playing the game - missing fields, invalid data, install errors, etc. And most of my campaigns end because the database gets corrupted. I'd much prefer a conventional savegame system with autosaves at key points which I can restore to if something gets corrupted.
Also, you've been talking about using C#. Have you considered XNA? (MS' game development library, which is written in C#) Its content pipeline is great, and it handles a lot of boilerplate stuff for you so you can worry about the fun stuff. The nice part is it's open enough that you can go back and tinker and replace their stuff, without running into any walls.
-
OR...
you could like, start a company, and work on aurora full time.
I'd totally buy an aurora2
-
OR...
you could like, start a company, and work on aurora full time.
I'd totally buy an aurora2
Absolutely second this !
...and I would even invest a few hundreds euros in that company of yours ;)
-
Absolutely second this !
...and I would even invest a few hundreds euros in that company of yours ;)
The idea of selling Aurora as a commercial product is something that crops up occasionally. I'll try and explain why I don't :)
I have regularly turned hobbies into jobs. I used to play keyboards for fun and eventually became a professional musician. Definitely a lot less fun when you have to to be in a certain place at a certain time and play certain types of music. Sounds glamorous and it certainly has its moments but in the end it becomes just work.
I learned programming for a hobby and wrote SFB Assistant and eventually starting working as a C++/Windows 3.1 programmer. Once I was working as a programmer, I did very little at home because I was programming all day. It become a job rather than fun, although I did start looking at VB3 which led to Starfire Assistant. Once I moved into management, I starting programming for a hobby again and it was a lot of fun (still is!).
Then I learned to play poker for a hobby and that eventually became my job. It can still be fun and you have the freedom to do things like write Aurora :) but when you have to play virtually every day and you have to earn a certain amount per month, it does take on many of the aspects of a job. Also I enjoy playing poker tournaments but there is a huge amount of luck involved. For 'work' purposes I have to play cash games where skill is far more important and I can generate a steady income.
I really enjoy creating Aurora and writing the fiction and I very much enjoy the community aspects of the game. If it became my 'job' I am really concerned that it wouldn't be as much fun. I would have to make a certain amount of money, which would probably involve 'dumbing it down' so it appealed to a wider audience. At the moment, the game appeals to a very small percentage of people who want this level of detail and can't find it in other games. That isn't really a commercially viable strategy. I would also have an obligation to be responsive to people who paid money for the game and while I hope I am responsive now, no one can complain too much if I am not :). Making the game free also opens it up to a lot of people who may not want to pay for it because if the extensive learning curve.
The summary is that I have a lot of fun with Aurora and I don't want to risk losing that fun aspect. One possibility is that I might try and write an Aurora-related novel and try to sell that, or at the least make it available on Lulu or something similar.
Steve
-
Hi Steve,
I get your point there and I should say it is a very good one !
I agree hobbies should not become full-time jobs indeed, keep the fun going on instead.
Best regards
-
From my own experience I can tell that making games as a job can be tremendous fun, but sadly the games aren't necessarily.
Hey folks, you can still donate!
Every dollar steve doesn't have to earn with Poker frees up more time for us! :D
-
Hi.
I would like to ask whether there is any news on Aurora II.
Seems to me that this could be even better than Aurora I.
-
An Aurora-related novel, that sounds pretty cool, actually.
-
OR...
you could like, start a company, and work on aurora full time.
I'd totally buy an aurora2
You know, the amount of people seeing this game isn't ALL that low, 3000 Forum Members is a acceptable number for a free indie game, not counting the dozens of guests that ocasionally appear during a day.
Now about the Money/Purchase question, you guys are forgetting about the other half of players: The ones that don't have much money, but like to play good games. (Like me)
Sure, selling Aurora would get more cash for Steve to spend somewhere else and would give him more free time to spend on the game, but Aurora huge complexity, steep learning curve, almost complete lack of graphics (Not that I care for it, but some people judge a game entirely by graphics, not gameplay or depth) and all those famous bugs and corrupt files would shy people away from the game.
Hell, most of my campaigns don't reach even the 2nd year
That's just my opinion anyways.
-
You know, the amount of people seeing this game isn't ALL that low, 3000 Forum Members is a acceptable number for a free indie game, not counting the dozens of guests that ocasionally appear during a day.
Now about the Money/Purchase question, you guys are forgetting about the other half of players: The ones that don't have much money, but like to play good games. (Like me)
Sure, selling Aurora would get more cash for Steve to spend somewhere else and would give him more free time to spend on the game, but Aurora huge complexity, steep learning curve, almost complete lack of graphics (Not that I care for it, but some people judge a game entirely by graphics, not gameplay or depth) and all those famous bugs and corrupt files would shy people away from the game.
Hell, most of my campaigns don't reach even the 2nd year
That's just my opinion anyways.
Steve has mentioned one reason he is not planning on charging for Aurora, is then he'd have to spend more time on it and it'd be a job instead of his hobby.
-
I know, I read it too, I just wanted to express my opinion about the issue.
-
Hi.
I would like to ask whether there is any news on Aurora II.
Seems to me that this could be even better than Aurora I.
I have been concentrating on Aurora I for the last few months so I haven't got any further with Aurora II. It will progress once I have another burst of enthusiasm for it :)
Steve
-
I have been concentrating on Aurora I for the last few months so I haven't got any further with Aurora II. It will progress once I have another burst of enthusiasm for it :)
Steve
Aurora I r ever a excellent game,Steve.
if u have been concentrating on it,and better performance,for me are OK!!
5.50 are absolutely and strictly AWESOME...and welcome.
We waitn for this..(that?..zzzz..my funny english..:))..)
-
Signed in to say I love the game, and to voice my enthusiasm for a possible Aurora II.
It just makes me very very sad to see such awesomeness held back basically only by the technology of its time. I knowyour dev on Aurora II is on a little hiatus, but I thought I'd just weigh in on it and the advantages of developing it in modern C# over old pre-. NET VB.
1. Themable windows and newer controls. Pretty obvious but the UI elements haven't aged well. Its functional, but UI standards have moved on.
2. Database. It breaks my heart every time I read on forums about some new fancy feature idea, but which isn't done due to performance issues. Much of this I would blame on the Access database. My advice would be using a SQL Express or SQLite database, both of which should give significant performance improvements. The nice thing about Access though is it can be used to access and maintain other databases if the SQL Management Express is undesired, but just have the actual data sit on a better database.
3. nHibernate or ADO. NET Entity Framework. In a previous post storing all the data in memory as opposed in the database to speed up was mentioned. These two, if you are unfamiliar with them, are ways of reaching a compromise. They are basically database middleware that turns rows and columns into actual objects with methods and properties, making it MUCH easier to work with and develop game logic, then afterwards save the objects again as rows and columns, all without even a single line of SQL.
4. Databinding. Right now the multiple windows don't communicate very well. If something changes the other windows have to be manually updated which doesn't always catch everything. By using databinding the controls will update themselves when the underlying data changes, resulting in a lot less code you have to implement.
5. Performance. Modern . NET has changes A LOT of things improving all round performance.
6. Installer. That installer you got leaves MUCH to be desired. Honestly. Installer projects these days are much simpler and allows you create a much better working setup without asking to install so manu useless DLLs.
These are all straight technology advantages received simply by using modern . NET. Honestly you don't have to use C#, you can keep VB, they both use the same libraries, though I would advise C# for the better power.
There have been some suggestions to use XNA, but I must say I don't think its a good idea for Aurora. While XNA is pretty epic if you quickly want to throw together a DirectX game, Aurora isn't 3D and consists mostly of forms and windows, neither of which XNA does well, or at all really.
Now for some game mechanics musings:
As for Jump Gates in a hyperspace world? Way I am imagining it is kinda like EVE accelerators or like existing mass drivers. The jump gate creates a hyperspace bubble around the ship, then launches that ship at high speed at the paired Jump gate, which then catches the ship and pops its bubble. This is why it is important to have them paired, since you need a beacon to aim for, and since systems move pretty fast compared to one another. And naturally you need something to catch you on the other end, which makes the destruction of a catching jump gate while you have ships in transit a pretty scary thing.
These jump gates are created independantly but can be paired with another, perhaps even have its pairing changed multiple times, and perhaps even able to lie INSIDE the hyperspace limit. They are expensive, but allows non-hyperspace ships to hyperspace (much cheaper ships), its fast (though highly performant ships may be faster) and reliable, since all ships will emerge near the endpoint gate.
Its disadvantages would be that they take time to build, can be destroyed and all ships emerge near the endpoint, meaning that the gates can be camped.
So in short, would work same way jump points work now. You find a jump point, take grav jump ship or military vessels through, explore, if you decide you want a colony build a gate which allows your freighters and colony ships access to the system.
-
I would pay a blockbuster-game level price for that game.
-
If there were a donate button I'd certainly consider pressing it, as I have done twice now for Dwarf Fortress. Of course Toady does consider that his job but there's no obligation to it necessarily, people are giving because they love the game. If the 3000 forum members each pitched in $10 that's a decent standard of living. And assuming Aurora 2 has a much better interface surely the fanbase could grow considerably.
-
If there were a donate button I'd certainly consider pressing it, as I have done twice now for Dwarf Fortress. Of course Toady does consider that his job but there's no obligation to it necessarily, people are giving because they love the game. If the 3000 forum members each pitched in $10 that's a decent standard of living. And assuming Aurora 2 has a much better interface surely the fanbase could grow considerably.
Steve does accept donations via PayPal as described in this post http://aurora2.pentarch.org/index.php/topic,2755.0.html
-
Hello,
I just took the time to go though all ten pages of this thread. I look forward to Aurora II. Hyperdrive is a great idea, it will open up many avenues for exploration and travel. I would like to see jump points remain in at least a limited way though. Perhaps in an "Honorverse" sort of way. It would be great to set up a junction system such as Manticore and use grav survey vessels to find a few of the jump points. As technology increases more of the jp's could be found until the "theoretical limit" is obtained.
Lafe
-
Hello,
I just took the time to go though all ten pages of this thread. I look forward to Aurora II. Hyperdrive is a great idea, it will open up many avenues for exploration and travel. I would like to see jump points remain in at least a limited way though. Perhaps in an "Honorverse" sort of way. It would be great to set up a junction system such as Manticore and use grav survey vessels to find a few of the jump points. As technology increases more of the jp's could be found until the "theoretical limit" is obtained.
Lafe
The FTL system I described for Aurora II is almost certainly what I am going to use for Newtonian Aurora.
Steve
-
Just a question in regards to the features you have posted about Newtonian aurora: Will any of the new aspects of Newtonian aurora be ported over to Aurora 2? Like the equations mechanics or balancing. Because I think it would be good if Aurora 2 would be a mixture of both Aurora and Newtonian Aurora, from what I have read about both games. :)
-
Just a question in regards to the features you have posted about Newtonian aurora: Will any of the new aspects of Newtonian aurora be ported over to Aurora 2? Like the equations mechanics or balancing. Because I think it would be good if Aurora 2 would be a mixture of both Aurora and Newtonian Aurora, from what I have read about both games. :)
At this point I don't even know if Newtonian Aurora will actually work :). I hope so but it is an experiment as to what is possible. If it turns out to be playable then I'll make a decision then on what to include in an eventual Aurora II. That is a long time in the future at the moment though.
Steve
-
Hey Steve, I don't know what I am doing half the time in your game but that's why I love it so much (Lots to learn). I wish you the best of luck and hope you get a nice boost of inspiration/creativity/money, whatever you need for your future projects. Looking forward to Aurora 2 to keep my brain turnin'
-
Just wanted to say i love aurora and looking forward to more of the fruits of your hobby
-
I'm curious... what IS Steve's views on open or closed source C# Aurora clones or games inspired by Aurora?
Once the December holidays come up I should have some time I can use to program... unsure whether I'd rather work on one of my other games but if Steve is okay and there is interest from other devs I could put some hours towards it, since it seems Aurora II would otherwise be a long time coming.
-
Huge fan of the game since learning of it over on the Dwarf Fortress forums, and upon reading about Aurora II I decided to make an account and offer some of my comments and suggestions to the game, which I greatly look forward to, although I'm still loving Aurora 1.
3) Real-time rather than stepped time. Time will be more like Harpoon or Europa Universalis where you can pause it, or accelerate it. This is isn't as different as it sounds because it will be similar to permament automated turns with the sub-pulses equal to the acceleraton rate and no defined increments. I intend to load everything into memory so the program will avoid any database access as time passes. This will improve performance considerably. You should also be able to watch ships move across the map if I can get the graphics working as I intend.
First off, I really, really like this idea. Not only will it remove the whole constantly clicking on '30 days' or however time I want to pass, but I also think the transition to real time would be a very smart move. I like the idea of being able to see my ships move back and forth in real time, or in slow motion / fast motion.
One idea that thing brings to mind that you could possibly implement is a limited form of Multiplayer. Since its not stepped time anymore, I would guess that it would be easier to have 2-4+ players in the same game with different empires at once, depending on how the game was hosted. Although a single-player version would certainly allow acceleration and pausing whenever they chose, multiplayer would have a more stable speed, perhaps chosen at start, or chosen by majority vote during gameplay. In this way, it would be akin to a slow-paced real time strategy game.
However, to make combat more realistic for this multiplayer mode, combat would need to be extremely automated. Perhaps it would be possible to 'program' combat maneuvers into each individual ship, task group, or fleet that they automatically carry out upon certain situations in combat, much like the conditional orders that are in the game now. Players could program these maneuvers during peace time, which would simulate fleet training. Ships or fleets without said training or programming would be less effective, but no where near useless, as there could be a 'default' set of combat behaviors they could follow.
Another part of this gameplay is to allow this real-time combat to be able to select a ship/group/fleet from the system map and give them a simple order, such as “Move here at x% speed”, “Attack this target”, etc. Again, this would be similar to a real time strategy.
For single player, such automation wouldn't be required, although having it would still be interesting. It would allow newer players to get into combat easier, but allow more experienced players to personalize their fleets' tactics to their liking. I'm still very new to combat in Aurora I myself, as I often take ages to leave the Sol system and often restart my game before I find any aliens.
As for your other ideas, such as the resolutions, no-jump points, centering around the system map, and area-of-effect missiles, I really like all of these ideas but I don't really have any suggestions to make. The resolution change and centering around the system map are two ideas I particularly like, as my laptop cuts off a small portion of the screens (Even with the current option to shrink the windows), and this would allow people with any size monitor to enjoy the game to its fullest. I think these two ideas alone will bring in a ton more players to the game. The bazillion windows so far are a bit of a juggle and hard to manage at first, and even once you remember where everything is and needs to go, its still a juggle. I find myself closing and opening windows more often than not, although I still enjoy the game immensely.
Again, thanks for making such an amazing game, and I hope your inspiration to continue working on Aurora II comes sooner rather than later. In the mean time, I'll continue with my plan of making an army of genetically superior Viking Marines named the Aesir through experimental genetic modification and dominate our enemies through ship boarding and hails of gauss cannon fire. . >:)
-
) Area damage from nuclear explosions. Missiles would detonate based on proximity and damage would be based on warhead yield and distance from detonation. This would obviously create some disadvantages to ships travelling in close formation, as multiple ships would be damaged by the same explosion, and give the player some significant decisions with regard to escort deployment. No more 'Empire State' formations. With no jump points to consider, formations would no longer have some of their current disadvantages and I would add extra functionality to make them easier to manage. It will also reduce the need to build missiles on a 4/9/16 warhead basis as only a proportion of warhead strength will be applied against a particular target. Arriving in a new star system could result in a scattered formation so ship design would have to consider whether specialised units that could be separated for some time are better than multi-purpose units than could fight more effectively in isolation. Ships on the offensive would be more likely to be isolated than ships on the defensive so grand strategy may also influence ship design.
It seems to me the main focus here is to break up formations and AOE damage is a means to that end. You could add techs specifically for that - gravity warheads? - but theres other ways to do it imo.... Like you could have a parallax bonus for point defense, or missiles with active sensors could have a chance of reacquiring new targets at the same location if they miss. (Of course, that would mean you would have to have missiles that _can_ miss lategame... heh.)
Other thoughts:
* Sensor degredation from overlapping
* Shields penalty from overlapping.
* Warheads/weapons that cause large/temporary penalties to sensors/FC in the region they hit. Microwave-lite but AOE.
-
Is Aurora II in the "concept" stage? Or is it already couple of percents towards the assumed version of a complete product?
-
Concept, AFAIK.
-
There has been some Aurora II work done, but that has been completely halted in favor of Newtonian Aurora that implements much of the discussed systems in the currently existing engine. Unfortunately it will still use VB and all, but the gameplay elements are coming into being.
-
There has been some Aurora II work done, but that has been completely halted in favor of Newtonian Aurora that implements much of the discussed systems in the currently existing engine. Unfortunately it will still use VB and all, but the gameplay elements are coming into being.
I believe A2 and NA are both in C# rather than VB.
-
I believe A2 and NA are both in C# rather than VB.
NA is just a copy of Regular Aurora so still VB.
-
If NA is in C# then this is the first I've heard about it
-
If NA is in C# then this is the first I've heard about it
Steve first mentioned he was using it in the first sentence of this thread.
-
Newtonian Aurora != Aurora II
If you continued reading thread you'd see that Steve decided against doing Aurora II which is C#, and do NA instead, which is a continuation of the Aurora I code, aka still in VB. It uses all of his game mechanics ideas for Aurora II, but without the complete and total rewrite that doing it in C# would entail.
Aurora II is still on the table, it will possibly be made at some time, but as far as I am aware it is not being worked on right now. But as I said before, if it is more active than I thought and actively being devved on, then it is news to me and I would be exceedingly happy.
I've done some programming on trying to link up proper C# WPF with MSSQL (way better than excell) and even sent Steve some of these experiments in the past, though I never received a reply. If Steve didn't want to keep it very closed source I would have been willing to assist to try make Aurora II a possibility.
-
anyone ever considered starting a seperate project that is open source. Seems to beenugh programers around here wiling to step up
-
I've considered it, but there's two issues.
1) It's a hell of a lot of work.
2) I doubt anyone wants to steal Steve's thunder by making an Aurora clone without him, especially when he's done such an amazing job of managing and maintaining the game.
-
Agreed really. Any Aurora II should involve or at least receive Steve's blessing.
Doesn't rule out a new open source game designed from scratch, but a) I sure as hell not willing to do it alone and b) they exist. Just none with as good balance between complexity and playability that Aurora has.
-
As much as I like Aurora and Steve, I hope that would not stifle another project team, working on a product similarly.
No two games would ever play the same. Game designers and developers should only encourage more development in an area not hinder it. I do not believe Steve is the type of guy to get upset by people developing a similar product, as he stated himself he does aurora for his own reasons, we are just the lucky people that get to play from his work.
I would like to see a project similar to aurora 2 however there are meany feature and functionality I would like different. I would like more focus on ground combat and diplomacy. I would like a multiplayer ability, I would like a stronger AI, but with Aurora depth.
--- Hypothetically ---
Although I am a not a coder (I do 3D modelling and game design), I had a fair bit of experience in mod teams and I understand the work it take to get a game from scratch and try to make a team work for common goals. It takes months of game design without a single piece of code written, it takes dedication from a lead coder, cause you lose the lead coder first part from opening to alpha, it all falls apart. And it take a lot of dedication and coordination from people around it. Yes even open source stuff.
So you first need a lead coder willing to take on such a mammoth amount work that this style of game is, and they are not a dime a dozen. Having said that if there was such a coder, I for one would be willing to discuss the opportunity to help them. Aurora style games should be encouraged not hindered. If Steve was open to support and help I would even stick my hand up for him, however I don't see 3D modelling a great need for him. My UI abilities are better then average, but my artistic work is not a beautiful as others, everyone has there own talents.
-
As much as I like Aurora and Steve, I hope that would not stifle another project team, working on a product similarly.
No two games would ever play the same. Game designers and developers should only encourage more development in an area not hinder it. I do not believe Steve is the type of guy to get upset by people developing a similar product, as he stated himself he does aurora for his own reasons, we are just the lucky people that get to play from his work.
I would like to see a project similar to aurora 2 however there are meany feature and functionality I would like different. I would like more focus on ground combat and diplomacy. I would like a multiplayer ability, I would like a stronger AI, but with Aurora depth.
--- Hypothetically ---
Although I am a not a coder (I do 3D modelling and game design), I had a fair bit of experience in mod teams and I understand the work it take to get a game from scratch and try to make a team work for common goals. It takes months of game design without a single piece of code written, it takes dedication from a lead coder, cause you lose the lead coder first part from opening to alpha, it all falls apart. And it take a lot of dedication and coordination from people around it. Yes even open source stuff.
So you first need a lead coder willing to take on such a mammoth amount work that this style of game is, and they are not a dime a dozen. Having said that if there was such a coder, I for one would be willing to discuss the opportunity to help them. Aurora style games should be encouraged not hindered. If Steve was open to support and help I would even stick my hand up for him, however I don't see 3D modelling a great need for him. My UI abilities are better then average, but my artistic work is not a beautiful as others, everyone has there own talents.
I wouldn't have any issues with anyone creating an Aurora-style game. In fact, I would very likely play it :)
There are some difficulties doing something this complex as a team effort though. First, everyone has to work for free because anything with this depth is not mass-market. If you want to make money, a less complex game is a better option. Then either everyone has to maintain their focus for the lifetime of the project, or everyone has to document their work thoroughly so someone else can step in. Finally, with a team effort, a lot of design work has to be done up front so that team members can be allocated tasks within the overall project, plus everyone has to agree the design. I've run several very large IT programme (9 figure budgets, multiple countries) and in a team-based project, planning is absolutely critical. To quote Eisenhower, "Plans are worthless, but planning is everything".
I happily ignore my own advice when working solo though :). When I get a new idea or see something on the forum, I just start coding. As I hit areas that will be affected, I make a note to come back to them. Then those areas affect other things, which in turn affect other things, which get added to the list. During most of this design-on-the-fly process Aurora won't run because I just broke it deliberately. Once I identify all those loose ends (or think I have) I put Aurora back together again and hope it runs. The period of coding while not being able to run the program can sometimes last several weeks. Then the debugging begins.
It's a lot faster than planning ahead (most of the time) but I comment almost every line of code and don't have to work in a team. Try the second method above with a team and I guarantee you will run into trouble :)
Steve
-
Hi! It's been a long time since I've posted, but I'm very curious as I've gotten back into aurora lately, is steve planning on making aurora II a game that supports multiple cores? I'm not sure if this is a easy or difficult task to accomplish, so I wouldn't be surprised of it's a no..It's just, someday I'd like to put the 7 CPU cores that came with this computer to use :D
-
@ardem: Well, if you find your lead coder let me know, I might be able to contribute some stuff.
Hi! It's been a long time since I've posted, but I'm very curious as I've gotten back into aurora lately, is steve planning on making aurora II a game that supports multiple cores? I'm not sure if this is a easy or difficult task to accomplish, so I wouldn't be surprised of it's a no..It's just, someday I'd like to put the 7 CPU cores that came with this computer to use :D
Far as I am aware Aurora II is on the 'TODO' pile for Steve, no real ETA on it. As for multiple cores it depends more on implementation than technology. You can technically do something that works with multiple cores in Newtonian Aurora in VB6. It will just be... easier and faster once the switch to C# is done.
Programming for multiple cores isn't actually that much harder it is just more... complex. The issues with it isn't initial implementation, it is debugging afterwards when stuff goes wrong. That said, I'm pretty sure there is some low-hanging fruit that can be done with multiple cores, I am just not aware of any plans from Steve to do so soon.
-
@ardem: Well, if you find your lead coder let me know, I might be able to contribute some stuff.
Hahaha my post was not directed at me doing the hard slog or pick up the bat and ball and running with it, my post was directed at people dissuading others to attempt it, but also keeping it real.
My lead coder is working on a commercial game at the moment and if I ever get him back I rather him be working on a project we already started working on. Steve is right money always comes first over dreams unfortunately. Sorry not in space.
However I was saying I could contribute, if someone was to pick up a mantle, 3d modellers can contribute without the project falling apart, that is the good thing about us content guys. Coders a totally different kettle of fish.
@steve totally agree with everything you say.
-
@ardem: I know, it was just a form of agreement that a lead coder is needed to carry the project else it will go nowhere. And was referring to a hypothetical lead coder.
I think that Steve's reply can be considered permission to attempt an aurora-inspired game, which alleviates some of the concerns I've had about pursuing any such project, so I am now considering it more.
Of course, I know my own weaknesses, namely lack of design forsight as well as a tendency towards over-engineering which often saps enthusiasm before much can be accomplished. Also I am far more interested in Stellar System generation and been playing and customizing systems like Stargen for a while now, while I have not often been good at stuff like research and unit and equipment design and balancing, something that leans more towards the design side.
I do C# programming professionally so I can offer a good starting point in creating a framework to link WPF with a Entity Framework<->SQL database system, which should eliminate any need for SQL statements in game logic, instead just working with classes and properties. If I take over this specialist part of the engine it should mean that the lead coder only really needs familiarity with WPF, experience with C#, time and most importantly a willingness to pursue it. Since Aurora is mostly a windows forms project any experience earned here is directly applicable to professional C# experience. I'm even willing to mentor. I just don't have the time and mental effort available to take responsibility for this non-commercial project.
It's not a high bar I'm setting here for the position of lead coder, what's needed most of all is responsibility and preferably a design in order to not fall into the traps Steve mentioned.
Anyone interested send me a PM with a basic design and if I'm convinced you won't just drop it the following day I can set this up.
-
a Entity Framework<->SQL database system,
I looked into this 6-8 months ago in the context of a personal project, and it seemed to me that the tools visual studio/.NET provides looked really good in principle, but lacked that last 5% to make them a complete system.
The first issue was "If I change my class structure, how do I update my DB schema in such a way that the data in my existing DB isn't destroyed?" My recollection is that their system will generate an SQL script that you can run to update the DB, but if you e.g. add a column to a table (because you've added a property to an object) then the script essentially executes "blow away the existing table, then recreate it with the new list of columns" rather than "add all new columns, remove all removed columns". In other words, if you already had your class structure it was good at generating DB tables, but if you needed to change the class structures then it was equivalent to starting over.
Do you know how to coax the tools to do this automagically, or is there still a lot of grunt work involved copying things over and editting tables by hand?
The other thing I remember running into was with the non-license version SQL Server that you can ship with executables (SQL Server Express?) I think the issue was that you couldn't add items to a table with a pre-specified key (i.e. you needed to let the table auto-generate the key), which meant that the automated binding tools didn't work right and you had to work around it in your class objects by hand. Do you know if they've fixed this?
Like I said, this was a while back so I might have distorted the details, but the 50,000 foot observation that it didn't seem to fully work out of the box stands. Or is that what you meant when you said "creating a framework" - there's some standard trick to automagically persist your DB information across architectural updates, but that one needs to implement that trick?
John
PS - This is just curiousity, not relevant to your Aurora efforts.
-
Yeah, what you just mentioned is exactly why most database middleware don't save you all that much effort. However, there are ways around it, especially since we're creating and maintaining our own database, and not integrating with some legacy system.
For start, I intend to make full use of EF Code First. This means that the database schema is automatically created for you based on your classes.
http://www.codeproject.com/Articles/318010/Entity-Framework-Code-First-Let-s-Try-It
You get full use of a database without actually touching or working with the database or SQL at all. Recently EF 4.3 allows migrations, which in theory should allow saved games from old versions to be used in new, even if columns or the entire datastructure changes. This is less auto-magical and more a manual mapping in code, but still a nice feature. Your 'basic' database stuff will also be created and initialized in code. Without migrating, it basically wipes and recreates and reenters initialized data whenever the model changes. It works well in my experience. This also works with SQL CE, which is basically a file based database, which should allow transfer of saved games.
Most notably it will be MUCH faster and far less prone to corruption than the current Access implementation in Aurora.
Only real issue I can see with this is portability to linux and mac, due to both WPF and EF being windows technologies. That said, porting to an ASP.NET webserver or silverlight is much easier and allows for web play. A LATER feature of course.
The alternative is using nHibernate (Fluent is a good equivalent to CodeFirst and I've used it before) and a portable windowing system like Qt or something, but I am not very familiar in that.
-
Also keep in mind that persisting to a database-based format isn't the only way to skin this tiger. I'm about 30% into an Aurora-like that persists to xml. All the game files are in xml, which allows modding for people who aren't necessarily DB-literate.
-
I mean no insult to yourself but frakk XML.
Not ever for anything this size.
Settings and initial data MAYBE, but it is a data communication format, not so much a database format.
-
For start, I intend to make full use of EF Code First. This means that the database schema is automatically created for you based on your classes.
http://www.codeproject.com/Articles/318010/Entity-Framework-Code-First-Let-s-Try-It
You get full use of a database without actually touching or working with the database or SQL at all. Recently EF 4.3 allows migrations, which in theory should allow saved games from old versions to be used in new, even if columns or the entire datastructure changes. This is less auto-magical and more a manual mapping in code, but still a nice feature. Your 'basic' database stuff will also be created and initialized in code. Without migrating, it basically wipes and recreates and reenters initialized data whenever the model changes. It works well in my experience. This also works with SQL CE, which is basically a file based database, which should allow transfer of saved games.
Actually, the Code-First stuff you linked to looks like the stuff I tried out. The problem was that I didn't get the "and reenters initialized data" behavior (which I take it to mean "stuff that was already in the table it just wiped out") - the data was just gone.
And yes, it was SQL CE that had the problem with (I think) not being able to specify keys and so having an odd behavior with (I think) Code-First that I had to kludge around....
Maybe I'll take another look at Code First and see if they've fixed the problems.
Thanks,
John
-
Also keep in mind that persisting to a database-based format isn't the only way to skin this tiger. I'm about 30% into an Aurora-like that persists to xml. All the game files are in xml, which allows modding for people who aren't necessarily DB-literate.
Yeah, I'd contemplated using XML as a format for initialization files that could survive class structure changes and/or for save files. I didn't have the energy to grind through the infrastructure to set it up, though. I assume you're familiar with .NET's auto-XML-schema generation class (XMLSerializer, IIRC)? Just initialize it from a class object and it makes a schema with all the public members and i/o code for you - totally nifty. The only downside is that it can't handle circular dependencies, so you have to throw in proxy classes to break the dependency.
John
-
Personally, I'd only use XML for configuration and options. It would be too complex in my opinion to use anything less than a database format.
-
If you HAVE to go XML I would look at Linq to XML. The convenience of working with actual objects rather than having to wrestle with XMLDocument every time you need to know how much population your planet has cannot be underestimated. Alternatively sloanjh's XMLSerializer suggestion, tho I have had issues with it in the past. But yeah, XML is a flat file with no indexing. When storing small non-often read stuff like settings it has a great advantage with being editable by hand. For large databases not just is it storage space inefficient, it is slow. When you have a database the size it needs to be in order to play a game the complexity of Aurora, your HDD will hate you.
Additionally, XML being human editable isn't really a big advantage. Human editable doesn't mean it is in any way nice or convenient to edit. On the other hand, if you wanted to edit a SQL database in case of a save file messing up or something you can use Access or even Excel to edit it. Yes, you won't do it in a text editor, but I find it much easier and convenient to use something with rows and columns.
@sloanjh: Right, yes, it wipes the database upon model change. But it also supplies a way for you to initialize the database:
http://www.dotnetthoughts.net/2012/05/25/how-to-populate-data-in-entity-framework-code-first-on-database-creation/
The Seed function fills it with initial data every time it gets wiped, and you do it by creating .NET objects and adding to a collection, again avoiding having to touch the database at all. You would for instance define your static data and research and all of that this way. While developing this works okay, and when doing a release you can setup a migration for existing saves to allow it to persist database changes. Or if too much effort you can say frakk it and tell them to start a new game when upgrading, either works.
-
For one, I am not reading and writing the xml files with each "transaction." In actuality, the "settings" information and game logic/relationship information is stored in xml files, and game state objects are serialized to XML and then highly compressed. They are only accessed during load/save operations and kept in memory otherwise. I haven't found disk space to be an issue, since hard drive space is cheap and even long-running games take up less disk space than a model archive in a AAA commercial title.
I do make extensive use of LINQ.
-
Well, even after weekend no interest or anyone taking me up on my offer. Perhaps not the best forum for interested devs to stumble over, but I'm not about to go on a recruitment drive without interest displayed. Ah well, I'll upload some code to source control next I have time, like my already mostly developed framework that I have to clean up. I still have work to do on my star generation code and this can be used to showcase that.
@Bgreman:
So your approach is pretty much in-memory storage with simply using an XML file for flat save files. I suppose that the XML eases the read-write burdens in such a case. Your approach certainly isn't wrong, just not the way I would do it etc. Most arguments I can make against your approach might be in miliseconds shaved off of loading and saving as well as using excel to edit save files which is harder with XML, but in the end these are minor quibbles, where other concerns like memory management, threading and algorithm use would have a far greater effect on performance than the use of XML ever could, but I suppose you are on top of that.
Good luck with your efforts, I'd like to see what you come up with.
-
About realism
There is a book rpg with space battle/travel that tries to be very realistic called vanguard rpg, its 100% free pdf but their website is down.
The system use wormhole as the only method to travel FTL.
Wormhole there is not fully understood, its was discovered by accident, but it works.
Not all ships there have wormhole equipament, you have to build ships with it.
Sometimes the wormhole stop to work for some months (the book say this happened with a wormhole near sun).
I dont remember how exactly the wormhole works there, if its instant travel to the other wormhole or instant travel to other specific place in space.
But you said, you dont want wormholes. So you will problably not use it. Just posting how a game that tries to be very realistic deals with having FTL.
-
I for one would love to do a complete rewrite of Aurora into (probably) C#.
Initially I'd propose a straight rewrite with no changes to any of the underlying functionality so that from the point of view of a user there would be no difference between the VB application and the C# one (other than perhaps fixing any obvious bugs which might be found along the way). With that done, I'd then want to look at making it compile and run under Mono (which would have the side effect of making it possible to run on Linux and OS X) - to do that I would imagine that the largest change would be moving from Access to a database like SQLite (cross platform, good performance and pretty much ideal for applications which don't use a huge amount of data and which only need a database to store their own data. It's also got fairly mature tools available to work with the databases. ). My gut feeling is that there wouldn't need to be too many other non-trivial changes given that Aurora is based on fairly old technology at the moment and Mono's weak points tend to be the newer features in dotNet.
From there, I'd look at refactoring the codebase and making sure it's as clean and modularized as possible - some prodding and poking of the current executable suggests that there's a fair amount of scope for refactoring. With that done and moving to something closer to an MVC or MVVC paradigm, it would be a lot easier to rework the GUI to make it resolution aware and more flexible, as well as being able to achieve the goals in Steve's original post like making it multi-threaded and able to run in real-time.
The only sticking point is that to get the initial and most important stage done, you'd really need access to the current source code to use as the reference version and to test against. On the upside, with access to the source, I'd estimate that the initial rewrite could be done in a matter of weeks and almost certainly within the one to two month time frame (especially with the help of some nifty code translation tools and code generation tools), and it's a project I'd happily take on if I had access to the source - I'm going to have a surplus of free time over the Olympics!
For what it's worth, my background is in writing financial software in C# and C++. I've worked for banks and hedge funds predominantly on trading systems, pricing/analytics systems and risk systems - all of which are the sort of complex, highly data driven (and data presentation driven) applications which Aurora is surprisingly akin to!
-
I'll add my name to the list of interested potential contributors.
I'm a newly minted profesional programer (just started work after graduating last May) with previous work experience in C and C++. My talents probably sit with algorithms and code-tracing. I've never used C#, but I hear it's easy to learn if you're already fluent with C. Alas, my knowledge of databases is zilch: so I can't contribute much there.
My suspicion is that we'll never see Steve's code, so anything we make will be a best-effort duplication of the user interface with a cleanly written fan-interpretation of underlying mechanics. A perfect mechanics match isn't going to be critical if we plan on including player-requested features like user-made AI-scripts. Oh, and +1 vote to anything that can be ported to Linux, OSX, and the other Unix flavors.
-
Glad to see the interest.
@MrBear: It does sound like you know your stuff and while it sounds like a good way of going about a port, we cannot really expect to get our hands on the source code, thus any project will likely be from the ground up. Possibly a rewrite using the current ideas and structure and just placing it over to a new C# project directly, or actually redesigning and rethinking a lot of what Steve has been doing, at least interface and flow-wise. But yeah, the assumption atm is any such project will have to be from scratch.
Your experience is definitely relevant, Aurora has more in common with a spreadsheet program or accounting package than many other games at the moment.
I like the idea of keeping it MVC or MVVM. That is how most apps should be programmed these days. I would prefer the WPF/Entity Framework approach, but that has the disadvantage that mono has no chance of porting it to linux or osx. I guess winforms and nHibernate is doable, but I'll have to look up some of that. I do insist on a object<->database approach though rather than working directly with DataTables or something.
As for my own side project, its going well. Generates around 9-13 planets per run around random stars, though in this case out to about 80AU which I need to look at (pluto is max 49AU out). Considering overhauling it AGAIN based on some paper I found detailing water density over a protodisk, but still progress on somewhat realistic planets.
-
A certain amount (well, really quite a lot) of reverse engineering could be done to determine mechanics if need be. However, that does move into what I would consider a bit of a grey area - while mechanics per-se cannot be protected, taking the steps of decompiling someone's code is an intrusion onto what I might consider to be their property. I've got a long going debate between the "Information Wants To Be Free" ideology (which I suppose is a fairly liberatarian ideology) and wanting copyright to be respected.
I agree that some sort of ORM is required, and it would onerous to tackle such a project without. I'm more familiar with LINQ to SQL than I am nHibernate though and I've had a fair amount of experience with regenerating mappings therein - it's a pain in the ass, but totally doable.
-
I don't really think there is ANY need for decompiling Steve's code for mechanics... it is all very well documented on the wiki and this forum with posted well known formulas for practically everything. We don't have the code and algorithms for say timing and how to make say construction and travel invariant whatever timesteps are used, but that can be developed from scratch. Tho yes, would be development and not porting, but a lot of the original Aurora needs to be updated anyway.
By regenerating mappings I assume you mean working with nhibernate XML? Screw that. Take a look at fluent nhiberante, its XML-less inline mapping in the C# code. Since we're creating app first and database second, instead of creating an app that works with a (legacy) database, a lot more options open up and it becomes much easier.
LINQ to SQL isn't a terrible option though, it works. LINQ to XML has even been mentioned earlier in this thread, but I am more comfortable with a database engine than a flat file, even if its a very thin engine like SQL CE or something.
-
If anyone is willing to start a repository I have code I am willing to contribute. As stated previously I simply do not wish the title or responsibility of 'lead' anything.
Git is all the rage these days but in my view it's not as easy to work with on windows, which I assume will be the primary development platform. SVN is an oldie but goodie, just not as good at conflict resolution. My preferred option I use for all my personal projects atm happens to be Mercurial HG, which has a nice Tortoise implementation and good hosting at bitbucket.
For basic solution structure I suggest that keeping with the MVVM approach means at least splitting it into two projects, a lib which contains entities, database setup, game logic... and a frontend project which contains the forms dialog and interaction logic. Splitting it this way would make it easier to allow alternate frontends to be made available (web frontend anyone?), without creating any significant increase in overhead... if proper patterns are followed.
Assuming that access to source is not available makes proper structure decisions at this stage somewhat important.
And then direction I guess... options are an Aurora remake sequal or something simply inspired by it.
I wouldn't have any issues with anyone creating an Aurora-style game. In fact, I would very likely play it :)
This solves most my issues I may have had with detracting from Steve's work by creating a fanwork. This isn't a quick conversion project, but much of the gameplay design we've already seen in action and we know what works, so less risky than an original game.
-
If anyone is willing to start a repository I have code I am willing to contribute. As stated previously I simply do not wish the title or responsibility of 'lead' anything.
Git is all the rage these days but in my view it's not as easy to work with on windows, which I assume will be the primary development platform. SVN is an oldie but goodie, just not as good at conflict resolution. My preferred option I use for all my personal projects atm happens to be Mercurial HG, which has a nice Tortoise implementation and good hosting at bitbucket.
For basic solution structure I suggest that keeping with the MVVM approach means at least splitting it into two projects, a lib which contains entities, database setup, game logic... and a frontend project which contains the forms dialog and interaction logic. Splitting it this way would make it easier to allow alternate frontends to be made available (web frontend anyone?), without creating any significant increase in overhead... if proper patterns are followed.
Assuming that access to source is not available makes proper structure decisions at this stage somewhat important.
And then direction I guess... options are an Aurora remake sequal or something simply inspired by it.
This solves most my issues I may have had with detracting from Steve's work by creating a fanwork. This isn't a quick conversion project, but much of the gameplay design we've already seen in action and we know what works, so less risky than an original game.
Out of curiosity, what languages and development suites are you planning on using? I do not have the time to help right now, too much work on at the moment but I have always wanted to try another language. I do web applications in Coldfusion.
-
Language? C#. Original is in VB, C# is just... better in every way. Don't want low level like C/C++, and I personally dislike Java. C# is also the language Steve himself has/is/prototyping the official Aurora II that is on hold atm.
IDE for C# projects? Esp using .NET stuff? Visual Studio 2010. Doesn't need to be paid, Express version works just as well. There is ah SharpDevelop and other stuff I think? Just havn't worked with it too much.
If serious about multi-platform should look at CMake (I THINK it has C# support?) and so, but I would seriously advise against it at least until later.
-
Ok, I'll temporarily assume the title 'Project Leader'. I might be stereotypical middle management at first, but I'm a fast learner and will be making my own code contributions soon enough.
Direction:
Short Term: I'd suggest we start with a shared google document or coordinate a chat session to clarify expectations and objectives. Or keep posting here for full community feedback.
Midterm: Create an Aurora-light fanwork working game skeleton.
Longterm: Add even more depth than the current Aurora, and enough optional AI-automation that players don't have to learn it all at once and can delegate the bits they don't find interesting.
Flavor: Lets not try for a perfect copy, but add at least one twist of our own. Sort of like Newtonian vs Original. Close enough that the fandom origin is clear, different enough not to compete directly.
Language: C# (Mono (http://www.mono-project.com/Main_Page)), Gtk# .net binding.
Java is very multi-platform friendly, but if we aren't in a rush I think we can do better in a C-varient.
Multiplatform: Yes. See above.
With three developers (Antagonist, me, McBear) the vote is 2:1 for multi-platform. I've used CMake before, but wasn't particularly impressed. McBear's Mono suggestion looks much better.
IDE: Your choice, but MonoDevelop (http://monodevelop.com/Main_Page) looks interesting if anyone doesn't have a favorite.
Repository: If none object we'll give Mercurial (http://mercurial.selenic.com/) a shot. The only one I've used in development has been Perforce, so it sounds like Antagonist has a lot more experience there. Give me a few days to get comfortable and I'll start a repository.
-
If you wish, I can add a forum/section here for you. And create locked down sections for private developer talk.
-
Logistics:
I would be fine with a shared document somewhere to help plan, though I prefer more realtime communication which isn't always possible. I prefer IRC, tho dunno if other devs share this preference.
The most 'official' IRC channel I have found so far is on irc.newnet.net #aurora so I suggest either it, a channel on the network or a Freenode channel for realtime discussion. Personally I am +2 GMT timezone-wise.
So some direction stuffs: My 2 minutes of research leads me to believe that MonoDevelop has a reasonably mature ability to import VS .sln and .proj files. I am however less optimistic that VS would import whatever format MonoDevelop uses. So I suggest the primary project in the repositiory be in Visual Studio Express format, something everyone should somewhat be able to use. If needed maintain 2 different sets of project files but that's unneeded complicated this early.
I have 0 experience with GTK or GTK#, so if that is what you are going for sure. I can hook up some viewmodels properly but unless I actually go and learn GTK I'll leave UIs to someone else. My suggestion of keeping frontend and backend seperated still stands however, so at least 2 project files within the solution.
Short term goal as I see it for me is to get entities like Planets, Suns etc setup asap. A lot of how these link is reasonably intuitive and expanding or modifying them at a later time shouldn't be a problem. Actual random system generation code is lower priority, but getting up a testing solar system of Sol using precalculated defaults should give anyone doing game and UI something to link to and display at least. Then can take my time getting realistic solar systems generating. Database and actually saving stuff is not that important at this stage, but since we already decided on something like LINQtoSQL or nHibernate can design appropriately.
I am a little worried about MrBear. He has offered to help with the conversion or reverse engineering of original Aurora, have yet to hear from him about this somewhat different take on from scratch development.
Name? I dunno, can base it off the original, like OpenAurora, Aurora Rebirth or something, or actually be original about it. My current code is sitting in a project called Pulsar4X which might make an interesting possibility. This is usually something that you need before making a repository so I suppose we should get some opinions about it now.
As said I like Mercurial. There are other options if anyone has a STRONG preference, but I just don't like getting burned when I tried GIT recently.
-
@Erik: A sub-forum would be fantastic.
Name: Pulsar4x has a very nice ring. The names I was thinking of were either bland (AuoraFan) or obscure puns (AuroraSong).
Logistics: Periodic Real time communication helps a lot, but Aurora is global enough to add some challenges. I'm at GMT -4.
Supposedly GTK# supports .NET stuff. Either way I've used GTK and GTK++ before so I can help with UI development. I'll look further into this as soon as I get a repository set up.
Planets And Star Generation: Yes please. We'll need realistic generation sooner than latter. Also, start think about terrain features. We'll probably want to get system/star maps working first: but I'm thinking implementing some planetary mapping for an improved ground combat system would be a great way to add our own twist. Probably the biggest challenge there is balancing object detail with database size/complexity.
-
I'm interested in this, but I don't have much experience with c#. I'll see about getting the glut wrapper for c# to work if you want to display said systems in 3d, obviously nothing fancy though.
-
System generation is my baby, been a personal effort for a while now... I just wish I knew more cosmologists whos brains I could pick and who can point me to the right papers. I wanna avoid doing n-body calculations since that is hard to get right for a GAME, so simplest method I've seen are those based off Dole's work, the accrete/stargen family. Problem is that the last serious development on it was in 80s. Our knowledge about cosmology has changed a lot since then. Already ported it mostly to C# and got rid of the HORRIBLE C-style double linked list and pointer style coding, but still messing with generation and results a lot.
However, getting a 'default' Earth system up to play with quickly is more important than a perfect generation system, so yeah.
I think we should seriously avoid thinking or doing anything to do with terrain and such right now. Way too early, expands and changes on the original model way too much long before we even have any of the basics up.
But... if I have to speculate and advise, I'd take a look at the system Light of Altair has: Simple and not THAT hard to do. Was largely thinking of it for use with biomes and albido calculations, considering that ice has a different albido to ocean and to rock... either way that is a hell of a mission to do accurately but since the method and formulas I've seen calculates and assumes from say x% ice coverage, y% water, z% cloud coverage ANYWAY...
@Nathan_: If you have experience with GL that's enough. The C# bindings are pretty much the same properties and methods, just in C#. Otherwise C# is just syntax almost identical to Java or even C++. I'm a little unsure about using GL though, but it does sound popular and the basic Aurora map def needs a good look at.
-
Maybe take the development talk to the Puslar 4x forum (under Other games). The base forum should be open to all.
-
http://aurora2.pentarch.org/index.php/topic,5176.0.html
Bam. Take all talk on the Pulsar 4X topic here please.
-
It has been quite some time since anyone posted somthing here :-[, however i would like to make a quick question
Is there/Will there be any further development in the game?
-
It has been quite some time since anyone posted somthing here :-[, however i would like to make a quick question
Is there/Will there be any further development in the game?
All development is on standard Aurora for now, although I will get back to this at some point. Unfortunately I have a day job with long hours at the moment so there isn't a lot of time for development.
Steve
-
Day jobs: the bane of all thinking men.
-
Wrong
Day Job: The bane of everything
Sad to hear there is no current progress in Aurora II, but good to hear that its going well with regular aurora
B.
-
Wrong
Day Job: The bane of everything
Sad to hear there is no current progress in Aurora II, but good to hear that its going well with regular aurora
B.
WRONG!!
The Day Job (if has,had,have anyone) ARE the DREAM, actually.
U r all crazy or probable r too RICH for consider those LUCKY...
-
With Iceberg Interactive partnering up with indie space strategy game developers, to publish the games, maybe Steve could talk to them, then his day job would be developing Aurora 2 ;D
-
All development is on standard Aurora for now, although I will get back to this at some point. Unfortunately I have a day job with long hours at the moment so there isn't a lot of time for development.
Steve
If you ever want to change that now is the perfect time. Plenty of successful space-game hype on Kickstarter/Steam. Just let us know and we would pledge $ as well as spread the word to other communities!
If Aurora had a more friendly user interface and basic graphics (look at Paradox Interactive games), I'm convinced it could have a huge fanbase.
If not I would suggest you develop Aurora II on a platform that is mod friendly and allows fans to create custom interface/graphics layers that just jacks into your database and calculation magic.
-
If you ever want to change that now is the perfect time. Plenty of successful space-game hype on Kickstarter/Steam. Just let us know and we would pledge $ as well as spread the word to other communities!
If Aurora had a more friendly user interface and basic graphics (look at Paradox Interactive games), I'm convinced it could have a huge fanbase.
If not I would suggest you develop Aurora II on a platform that is mod friendly and allows fans to create custom interface/graphics layers that just jacks into your database and calculation magic.
Kickstarter would be the way to go if I wanted to do this. However, I have a good job that I really enjoy with a great company that looks after its staff, so that would be difficult to give up. Besides, Aurora is a hobby for me and I don't want it to become a job. I know that might sound strange but I have had three previous hobbies that became jobs and then they weren't as much fun.
-
Kickstarter would be the way to go if I wanted to do this. However, I have a good job that I really enjoy with a great company that looks after its staff, so that would be difficult to give up. Besides, Aurora is a hobby for me and I don't want it to become a job. I know that might sound strange but I have had three previous hobbies that became jobs and then they weren't as much fun.
:)
-
Hi Im new here and have been playing Aurora for a few months now and absolutely love it ive read the OP i was just wondering what the status of this is currently?
-
Hi Im new here and have been playing Aurora for a few months now and absolutely love it ive read the OP i was just wondering what the status of this is currently?
Hibernation at the moment :). I've a lot less free time at the moment and I would probably go back to Newtonian Aurora first.
-
Hibernation at the moment :). I've a lot less free time at the moment and I would probably go back to Newtonian Aurora first.
I Can understand that. Im interested as to what language you might be doing II in?
-
I Can understand that. Im interested as to what language you might be doing II in?
It's in C#
Steve
-
It's in C#
Steve
Awesome Im more of a Java Guy myself but that's what ive been taught so there we go lol Should be able to multi thread nicely though The Slow down is my biggest issue in Aurora I (could you look at possibly improving that in the patches to come for Aurora I :))
-
Aurora 1 is iirc. VB6 based which doesnt work well with Multithreading. One could try to make a C# version of just the pathing (and maybe parts of the database) and then let that be called by the VB6 part.
-
Aurora 1 is iirc. VB6 based which doesnt work well with Multithreading. One could try to make a C# version of just the pathing (and maybe parts of the database) and then let that be called by the VB6 part.
That would be a great idea, but I think Aurora is more of a monolithic design than a distributed one. Semi-off topic, this is what I am doing with the Astra Imperia Aide. Shipbuilding, research, etc are all different DLLs. So if one gets swapped out, it's easy to do.
-
To be honest, I'd rather see Newtonian Aurora than Aurora II, and improved Aurora I functionality is even better (though slowly shifting Newtonian Aurora concepts into Aurora I would be awesome too)
-
To be honest, I'd rather see Newtonian Aurora than Aurora II, and improved Aurora I functionality is even better (though slowly shifting Newtonian Aurora concepts into Aurora I would be awesome too)
All well and good but id rather have a game i can play past 20-30 years before the time passing gets so slow you dont get anywhere any more.
-
Does anyone know what the status of Aurora 2 / Aurora Newtonian is? Is Steve working on it? I seem to remember from some of the other patch-notes that he was porting some features from Aurora Newtonian into Aurora, implying that he was working on it then, but I haven't seen any news or updates from more recently.
-
a request if/when you continue Aurora II: modability.
i assume, many of the values (research costs, tech tree, weapon damage etc) are in the database, and that's password protected. if you move all those values to a different database and give us access to that, we could mod many things. similar games have large modding communities and i think that's a huge benefit to any game.
it would be good for Aurora I too, of course, but i don't know how much effort that would be. it shouldn't be much effort if you keep it in mind from the beginning though.
-
I really doubt open modding is going to happen anytime soon. The reason for that is that Steve doesn't have the time to waste on a billion bug reports made using modded versions of aurora.
Right now you can mod aurora to your heart's desire if you know a bit about decompiling VB6 ( which I do have to say , can be a beast at times ) and some access know-how . Just don't expect you'll get any support out of Steve for it. For example I'm using signature-increasing ECM , laserheads and 15x firecontrols in my current game - but I know that if I mess up I'm th one that's got to figure out what happened.
-
no developer gives tech support for mods. i don't see how modding should be different (or cause more problems) for aurora than for any other games.
-
Im interested as to what language you might be doing II in?
It's in C#
Steve
Aurora 1 is iirc. VB6 based which doesnt work well with Multithreading. One could try to make a C# version of just the pathing (and maybe parts of the database) and then let that be called by the VB6 part.
I'm not sure what the status is of Aurora II or Newtonian Aurora. But I was wondering if Steve was aware of the newer Visual Basic alternatives that exist today.
I ask because if I had written such complex software in VB6, I think I'd prefer to try to port it to a newer language that has the speed and features I need, but is still a BASIC variant that would require very little (if any) actual code changes.
Porting something like Aurora into C# must be a very time-consuming and daunting task. It's almost like rewriting the entire thing from scratch, right?
Both of the following are described as similar to VB to the point of being somewhat compatible and able to use a lot of the code unchanged. Though, I was also impressed by the features and being described as "easy to learn". Also, they are cross-platform, with support for Windows, Linux, and Mac OS X. (From what I read, a lot of players would love to see support for Linux and Mac.)
One alternative I'd mention is now called Basic For Qt (http://www.q7basic.org/index.html) (formerly known as KBasic (http://www.kbasic.com/)):
Qt® is the best C++ cross-platform toolkit available and Basic For Qt® is the easiest way to get cross-platform development without the needs to learn C++ as it combines the expressive power of C++ with the familiarity and ease of use of Visual Basic®. The Qt® API and tools are consistent across all supported platforms, enabling platform independent application development and deployment. Windows®, Linux® and Mac® OS X are supported platforms.
It is an open source project backed by years of continual development. The project is under active development and has a vibrant community.
KBasic - World's most advanced open-source Basic (http://www.kbasic.com/)
...It is a new programming language, a further BASIC dialect and is related to VB.NET™, Visual Basic®, Visual Basic for Application® and Java™. It combines the best features of those tools and comes with built-in backward support for those tools and QBasic® as it is 100% syntax compatible to VB6, VBA and QBasic®.
Another language I would mention is now called Xojo (http://www.xojo.com) (formerly known as "REALbasic"):
Xojo > Frequently Asked Questions (http://www.xojo.com/support/)
- Can you port Visual Basic (VB) projects to Xojo?
Yes! The Xojo language is very similar to VB. We also offer a migration assistant to help move your VB5, VB6 or VB.NET projects. The migration assistant does not change your code, but it does move over the project, forms, etc., which gives you a nice starting point for converting your code.
- If I am familiar with Visual Basic, will Xojo be easy for me to learn?
Yes! Xojo is a great multi-platform alternative to Visual Basic. Read more about it at our Developer Site.
Porting Visual Basic Applications to Linux and Mac OS X: A How-To Guide for Visual Basic Developer (https://web.archive.org/web/20130117095904/http://www.realsoftware.com/support/portingvisualbasic.php)
...quite similar to Visual Basic. It could use much of my Visual Basic code unchanged, and it could read most of my Visual Basic forms.
[snip]...
...In addition, my ported application would include the native interface widgets required to look great. In Windows XP for example, I was surprised that my REALbasic application takes on XP themes automatically!
Also:- Xojo is the spiritual successor to Visual Basic (https://www.xojo.com/resources/visualbasicandxojo.php)
- Migrating from Visual Basic (http://developer.xojo.com/migrating-from-visual-basic)
no developer gives tech support for mods. i don't see how modding should be different (or cause more problems) for aurora than for any other games.
Agreed. I'm not aware of any developer who gives support for mods. And, usually, there is a warning in support threads and on bug tracker pages that mods are not supported and that they should mention or list any mods that are used.
-
I've never attached a profiler to Aurora, but I was a professional game programmer for about twenty years. I'd bet good money that the performance issues on this game have very little to do with the choice of language and everything to do with using a relational database as the runtime store of game state.
The virtue of doing that is that you're perpetually in a saved state. Any crash at any point is very likely recoverable with only negligible loss of game state. That's no small thing, and we all surely know from other games the frustration of losing hours of progress because we neglected to save often.
(Another virtue of doing it that way is that if you're a database guy to begin with, and you set out to create a labor of love, you're just naturally going to build it like the apps you already know how to build. This will be a familiar architecture. And if it leads to some scratching of heads among your puzzled players, they'll just need to understand that a gift horse is a gift horse and that it's ungracious to examine its' mouth too closely or to talk too loudly about what one finds there.)
The cost of doing that, however, is utterly horrifying data access time. I shouldn't be surprised if a bit of profiling reported that this executable spends 99% of its time waiting on blocking data fetches.
It's such an amazingly well-designed game that I happily put up with the poor performance. I do, however, from time to time wish it had been built differently.
-
It occurs to me that another great virtue of this architecture is that it gives you an off-the-shelf browser for your runtime data. That's a huge deal. Picking through your data with a debugger isn't easy. Most developers will have several custom-built tools for the job, and it wouldn't be unusual to invest a few engineer-years in the development of such tools. That's the kind of luxury that a one-engineer team just can't afford, and I could well imagine sacrificing some runtime performance to get it for free.
-
I've never attached a profiler to Aurora, but I was a professional game programmer for about twenty years. I'd bet good money that the performance issues on this game have very little to do with the choice of language and everything to do with using a relational database as the runtime store of game state.
Note that Steve already did a pass of optimization where he only saves to/from DB at the end of an increment, not during the small sub-pulses that the increment is broken up into. And yes, this did result in a significant performance increase. Not disagreeing with your overall thought, just pointing out that he's already gotten a lot of juice out of it.
John
-
I recall someone suggesting there could be a noticeable performance increase if you pop the db into ramdisk before loading Aurora. At the moment I'm using a laptop that can't even handle the processor load so it's not worth testing :p.
-
Hello,
Well I'm going to necro this thread after a few months of it being non-active. I've recently gotten into Aurora, and to say the least, I'm addicted to it. Going through this thread has given me several substantial ideas, and personal wishes have come up in my head that I want to share.
Newtonian flight
It always bothered me that ships simply travel at their rated cruise speed then stop dead cold. Engines should use their thrust rating to climb to the cruise speed, then stop their momentum as they approach their target in the same fashion. However this would limit space flight only to two points, A and B it wouldn't be true Newtonian flight, also during combat sudden changes in flight course would require an onsite braking burn which would leave an ship vulnerable to incoming missiles.
SO in other words, either true Newtonian flight or sticking to Aurora's original system will work without mucking things up. But I do have an proposal for either scenario. I would love the option to choose an point on the 2d map for my fleet or particulaur ship to move. Would add alot more tactical options for engagement.
Also creating patrol waypoints would be great, you could plan out battle actions using this.
Non-superluminal flight mode
No hard-drives, no jump points. Only wormholes and vast monolithic distances in space. Perhaps later very advanced tech, that is unlocked by delving into precursor vaults, or disassembling Invader wormhole gates will give you access to faster space travel. But you will have to earn it. Would add an larger emphasis on strategic decisions, fleet locations, resupply, and planned campaigns involving decades or even centuries(For shorter distanced campaigns, this would be modified in game creation for whatever intent). Such a mode would reckon faster time acceleration though.
Government Customization
Would be nice to not only name your own type of Government, but determine its attributes as well.
Trans-Newtonian Engines
Really simple, an engine with more thrust output than anti-matter. Harnessing the power of particles going faster than light, superluminal, or you could consider it the quintessential Tachyon. Would be available in either mode since even though making an ship travel faster than light is impossible, making particles do so wouldn't be a problem once you had the know how. Would have to be earned through scavenging Precursor, or Invader bosses.
Bussard Ramjet
An electromagnetic net designed to pick up hydrogen in space, overall will be ineffective unless going through an Nebula. Would be ideal for scouts, and all ships in general if you are playing an non jump drive game.
Nano-tech
An industrial overhaul that allows an improved economy and industry output. However the downside is once engaged in Nano-tech you will constantly have to research and create countermeasures for any Nano-plagues that might happen on accident, or caused by enemy Nano-viruses. The upgrade will be just enough to be worth it, say an 10-25% increase, but its downside will make players weigh their options.
Nuclear Ballistics
The use of the energy of Nuclear detonation to propel projectiles hyper velocities otherwise unachievable by conventional cannons. Basically a bigger badder version of the rail gun, with more distance and damage than most weapons aside from missiles and high tier energy weapons. Reloads are much longer akin to missile launchers.
Precursor Caches
Vaults or resource dumps, long forgotten. And sometimes perilous in nature. Mines, deadly robotic guards and even Precursor drone fleets might be hiding in plain site. Requires an geology survey to uncover(Thats if the ship doesn't get blown up first), then an Engineer team to uncover.
Invader Command fleet
Is activated when the player defeats an certain amount of Invader task forces, the Command fleet encroaches armed to the teeth with dreadnoughts, carriers, the whole deal. Not something to take lightly. It starts work on the outermost colonies and works it way to the Player's homeworld.
New NPR races
Some inspiration comes from Sword of the Stars. The RNG factor of the space anomalies was amazing to say the least. Sometimes encountering the unkown could absolutely cripple you, sometimes very rarely you could benefit. Also a few ideas I ripped straight out of books like those written by Alistair Reynolds.
-Inhibitors
An race of Programmed sentient robots that leave beacons in systems to detect space flight species. If these beacons are triggered an task force is sent to exterminate and scour the area for any more links to civilization. They are like Invaders, but will act differently, their strategy will be different ranging from conventional missile spam, to when you get them very riled up by resisting the dismantling of entire stars, or destruction of planets. Would add an great deal of !FUN! for veteran players.
-Von neumon
Traveling flotillas of machines that strip planetary resources that they encounter and produce more of themselves. To avoid the snow ball effect, Von Neumon will be attracted to player/NPR inhabited systems only. Weaponry will mainly be lasers.
-Nano Plague
Wouldn't be an NPR, rather an event triggered by uncovering ancient alien ruins. Or not upkeeping/maintaining you nano-tech infrastructure.
-The ancients
Benevolent or full of malice? Rng will decide the predetermined relation with the player and other NPRS(They will have negative relation with premade NPRs ofc). Older than even the precursors they have shepherded themselves and kept to their own system for years beyond count. Awaiting for an great crisis to pass within the confines of their massive Ringworld. If in good terms they will trade and even offer technology in exchange for completing certain objectives for them(One or two unique techs, the rest will be default higher tier tech). However if hostile will shoot on site. If you manage to defeat them and take over the Ringworld new unique techs will be discovered for research that would otherwise be impossible to access.
-The Fore-runners
An now distant cousin of the precursors. These survivors of the invader's onslaught they have banded together in a great flotilla and travel the stars. They have lost much of their knowledge and all that dwells in their minds is their very survival. They are also however traders, and will give you higher tier tech and even Precursor cache locations for the right price.
Welp that's all I can think of for now just wanted to drop this in here to get Steve thinking on some of the possibilities. I think what is currently missing is an daunting presence of the unknown. Space shouldn't be absolutely crushing filled with baddies that come in and nuke your homeworld. But rather the player should feel he is coming into contact with civilizations wildly different, and usually way older than their own. Creating an sense of scale and even survival amongst the stars.
Of course the NPR suggestions could be recreated using Spacemaster presently, but also they can not be fully realized like they might be able to in Aurora II. Cheers steve, good luck on development!
-
I would love the option to choose an point on the 2d map for my fleet or particulaur ship to move. Would add alot more tactical options for engagement.
You can already do this in the current version of Aurora; add a waypoint in system view and order your task group to move there. I used to make use of survey locations a lot for maneuvers before I found out you could use waypoints.
-
I've never attached a profiler to Aurora, but I was a professional game programmer for about twenty years. I'd bet good money that the performance issues on this game have very little to do with the choice of language and everything to do with using a relational database as the runtime store of game state.
Wouldn't SSD's/RAMdisks improve performance if this was the case?
I recall someone suggesting there could be a noticeable performance increase if you pop the db into ramdisk before loading Aurora. At the moment I'm using a laptop that can't even handle the processor load so it's not worth testing :p.
I've tried that, didn't help. That was on version 5. xx though, but I assume things haven't changed since then.
-
The economic/per 5day processing does use the hard disk heavily, but everything else is more cpu dependent.
-
Is this still in development? or no
I feel like *some* of those features can be implement in current Aurora
-
This became Aurora C#