Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

shortcuts: hit alt+s to submit/post or alt+p to preview

Please read the rules before you post!


Topic Summary

Posted by: planetfall
« on: September 16, 2017, 09:22:43 PM »

I think it would be really nice if instead of made up elements like duranium you used real ones like iron, nitrogen, carbon etc.  I also think it would be cool if you could gradually disassemble whole planets and turn it into Dyson swarms of rotating habitats.  Also just a small tweak I'd really like is if you could install a pair of mass drivers inside a jumpgates so that you don't need to use ships to ferry goods between them.  As for ships I think it would be cool if you had a 3d building system like Children of a Dead Earth so you can see what your doing, kind of far out there but that is what this thread is about.
Posted by: mrwigggles
« on: January 24, 2017, 02:52:45 AM »

The Heat Pump would take one Heat from ship to nother. So you could have Combat Ships, with Heat Sinks but with little to no Radiators. (Yea, better word.) ANd so you can multiple ships service by one Support Ship cooling them off. 

FACs may be weaken quite a bit with heat. Though if they could return to a Support Ship where they can off load their Heat, this would mitigate it.

The Stealth Tech themselves would generate heat, and would already doing its job at lowering the heat profile of the ship regardless. This wouldnt really need to be changed mechanically. Its numbers would need to be tweaked. This would make Stealth maybe weaker, but more interesting as it'll be limited by how long it can be an oven.

This may also require to generate an ambient heat map of a given system. It may be fast enough to know how warm the dead of space is compared to the distance (and stats of the star). The further away you are, the more efficient radiators are.
Posted by: iceball3
« on: January 23, 2017, 05:34:53 AM »

Some thoughts on heat, if implemented -

Heat Loss components could properly be called radiators. 

There might be special shield and weapons tech that actually reduced heat, as an interesting design possibility.

I'm not sure what purpose exactly heat pump tech would serve.

The amount of heat being actively radiated could of course add to thermal signature.  There could be a 'stealth mode' toggle where ships turn off their radiators temporarily and let heat build up, like the shields up/down or sensors on/off toggles.
I imagine heatpumps would be specifically designed around moving heat from critical components into more massive heatsinks, where it could either be stored within or transferred to radiators.


Speaking of which, would it be reasonable for ships to convect their heat against atmospheres (at variable efficiency, depending on heat/pressure) of planets they're stationed at by coasting off the top, or even perhaps straight into the ground if fully docked?

Also, I gain great amusement knowing that with a heating system, someone's probably going to take the newly re-balanced beam weapons (designed to be smaller and otherwise cheaper/more potent to compensate for all these new effectively-logistics-nerfs to them) and make the space 4x equivalent of the giant robot in this video:
Posted by: TaliesinSkye
« on: January 22, 2017, 02:48:45 PM »

Some thoughts on heat, if implemented -

Heat Loss components could properly be called radiators. 

There might be special shield and weapons tech that actually reduced heat, as an interesting design possibility.

I'm not sure what purpose exactly heat pump tech would serve.

The amount of heat being actively radiated could of course add to thermal signature.  There could be a 'stealth mode' toggle where ships turn off their radiators temporarily and let heat build up, like the shields up/down or sensors on/off toggles.
Posted by: mrwigggles
« on: January 16, 2017, 07:30:54 AM »

HEAT.

Mass Effect lore is pretty great.  One of the things they brought up that I had never really considered before is heat during ship combat.

Basically, Beam Weapons of the kinds of power we're talking about would generate significant amounts of heat.  Additionally, shields could also generate heat during use.  Engines and Powerplants could be additional (albiet, much lower) sources of heat.

Here's a telling quote from Mass Effect's Codex

This could be used to balance shields.  If heat can't be dumped while shields are up, and taking shield damage generates heat as shields get used, then ships with large, quickly recharging shields with tanker support can no longer tank indefinitely.  As heat builds up, components could fail, crew could die, etc.

This is a great idea.  Shields take damage, the damage is turned into waste heat.

This would be a very neat energy tech line to have. Heat Sink Batteries, Heat Loss, and Heat Pump. The tech should be a simple linear efficiency. And these would be components you add to ships. No design would be needed.

All weapon systems when engage should produce excess heat, active sensors should produce excess heat, and shields while running should produce excess heat. Or if a simpler binary 'in combat' can be detected, then the ship produces heat as a function of its tonnage. And the components that produce heat would be a function of its hull space. I would keep this rate pretty flat. More advance components would more then likely need more joules of energy and it would get hotter, but active and passive cooling would probably keep it about the same.

The only problem with this, is that Fighters, and  FACs would probably be pretty dampen in combat time by heat. This may not be a bad thing.

Heat Sink Batteries, would be components that just absorb heat. The maximum amount of heat it would sink, is how many hull spaces it was given multiplied by its current technology level. I would also say as soon as it 90 percent capacity, that it starts to have a failure chance, adjusted by the ships overall failure chance. And I would probably start with letting then have a max heat sink of 150 to 200 percent over capacity before it is destroyed.

I dont know if internally the game recognizes the difference between equipment failure and being damage in combat, but I would say that if it was destroyed in combat then the heat it contained would disappear. If it failed because it melted the heat would radiate to the rest of the ship.

As the ship gets hotter, it affects morale. Or it affects crew efficiency. The goal would be that everyone does their job on the ship worse because their being baked. Once the ship overall has taken heat to its tonnage or hull space, it'll start to cause system failures else wear. It would trigger maintenance failure checks with the heat exceeding the ship hs or tonnage, as a multiplier to this chance with it being multiplied by the ship overall failure chance.

Depending how you view things Lore wise, this can then cause fuel to ignite and missile to detonate.

As this is happening, every pulse that the ship is over its hs or tonnage, its killing crew. I would probably make this an exponential curve. The goal being that the ship crew can be literally baked but the ship itself can be recovered and repaired then restock with new ingri... crew.

Heat Loss components, would disperse stored heat from the sinks over time. They cant be used while shields are up. Lore wise, this would be miles and miles of tubing that the ship would push into space to increase the ship surface area. The tubes would be filled with some TN medium for pushing the heat.

Heat Pumps would be a support ship component. This component would let Support Ship pump the heat from the Combat ship, into the Support Ships own Heat Sinks, and use its own Heat Loss system. The transfer would be at the same rate, and rule as Heat Loss.

Hangar Components are assumed to come with Heat Pumps. Docked Ships would pump their heat into its Mothership, unless told otherwise. Docked Ships cannot disperse heat while docked, unless its pumping it into the Mothership.

And for spoiler races. They can ignore these rules. Star Swarms would defiantly need to for their well, swarms.

I am also curious if this is taken on, if just hitting ships with IR lasers or resonate frequency microwaves or something would you let you cook ships.

PDCs would assume to have infinite cooling and infinite heat absorption. Since their build on planets. This would also be true for PDC with hangars.
Posted by: Mor
« on: March 09, 2016, 07:20:48 PM »

we generate orbits with a constrained eccentricity and within the habitable zone of the star in order to be able to easily balance the number of number of habitable worlds in the game.

That sounds interesting and full of promise.

Maybe anyone developers of "Pulsar 4x" know russian language and can help me  for breaking "language barrier"?
Not a developer nor Russian. But I understand Russian as well as English (both are second languages). I recommend that you keep trying.. every now and then you'll get *twitch* or two from the natives, but its the best way to practice in non english environment.
Posted by: exdeathbr
« on: March 09, 2016, 06:47:45 AM »



4.  Maybe adding 3D to system map ?
This would be awsome as frakk.
In my opinion this is sort of a must to turn spaceship games into really spaceship games, instead of "futuristic planes" game
Posted by: littleWolf
« on: March 09, 2016, 03:55:28 AM »

Quote from: Rod-Serling link=topic=5177.   msg87759#msg87759 date=1457463300
Again, your grammar makes this impossible to decipher.    I don't have to change physics to Newtonian, because I decide how the game universe works.    I decide how the game physics work, and right now they work with orbits that never change and ships that move in a TN manner.   

Sorry, my english too bad for open community,  but i good C++ programmer with great experience in mathematic modelling.    And i have some knowledge in space flight and celestial mechanic.   

Maybe anyone developers of "Pulsar 4x" know russian language and can help me  for breaking "language barrier"?
Posted by: se5a
« on: March 08, 2016, 02:52:57 PM »

I'd like a 3d system map. but definitely not in this iteration.
Newton is not getting any more of a lookin in this iteration either.

The engine will currently handle 3d orbits, but as rod as pointed out, UI controls for that need to be done right.
We need to triage and get something out that's somewhat playable. 
Posted by: Rod-Serling
« on: March 08, 2016, 12:55:00 PM »

Does this means potential for great FUN with elliptic orbits where you settle at the point furthest away from the star in nice cosy temperatures and then have your colonists roasted alive as it passes closer to the star?  ;D

Not right now. I think planet temperature is currently set by the SemiMajorAxis. Additionally we generate orbits with a constrained eccentricity and within the habitable zone of the star in order to be able to easily balance the number of number of habitable worlds in the game.

1.   Simplify model to Keplers  make calculations easier, but  prevent some interrest possibilites - changing for bodyes orbit, space disasters (collide and other). 

Yeah it does. But it's also easier and faster to program and easier on run speed. Trust me, I would simulate every atom in the entire universe if it were possible. In the end every game has to make considerations for both the hardware its running on and the gameplay considerations we actually want. Personally I don't see a whole lot of added value in doing stuff like radically changing a bodies orbit. To do so would require massive amounts of energy (both in terms of kinetic energy to change the orbit, and programmer energy actually implementing it). Space disasters and collisions would be cool, but just not worth the programming and runtime cost.

 
2.   For Kepler orbits need gravity focus.   Orbit Moon around Earth, orbit Earth around Sol.  .   Need new parameres - gravity weel radius for switch between focuses. 

I know. I wrote the orbit code in Pulsar. We calculate the gravity between the star/planet based on mass and we use that to generate a sane orbit for the body in a place where we want it to go. I don't know what you're trying to say with the last third of your message.

3.   We have TN-physics, any ships ignore inertion force.   But if ship no have powered TN engine or reactor, he must change physics to newtonian without save TN speed (maybe remaining speed = TN speed / sqrt(mass) and save direction of speed vector), and moving by Kepler orbit. 

Again, your grammar makes this impossible to decipher. I don't have to change physics to Newtonian, because I decide how the game universe works. I decide how the game physics work, and right now they work with orbits that never change and ships that move in a TN manner.

4.  Maybe adding 3D to system map ?

Maybe. We haven't ruled it out. It's more of a long-term "Maybe we'll eventually do this once everything else is done" thought on our minds right now. As Mor said, the biggest limitation is creating a good UI to use it. I've seen a lot of space games mess up in the 3D UI controls. I'd rather have a nice 2D UI than a 3D one with bad controls.

Lol.   I read source codes - you already use 3d vectors !:)  Need only polish 3d engine for real 3d navigation - and add mouse interact with displayed objects:)

Oh all we need is a polished 3D engine? We also need more programmers, maybe some 3D modellers, maybe some guys good at texturing and other asset design...

You have to remember that Pulsar is a game that's currently being built mainly by two people. Se5a and myself. Nathan's working on another branch and is kind of doing his own thing. Most of the other contributors are extremely irregular. We've had some hopefuls show up, but nobody seems to really stick with it save for se5a and myself. We not a game studio. We have real jobs and college and lives. We don't get paid for doing this and likely never will (at least not anything significant). Pulsar is our free-time hobby just like Aurora is Steve's free-time hobby. We don't even have a 2D display yet, let alone a polished 3D game engine. We can't do everything and it's unrealistic to set our goals that high.
Posted by: Mor
« on: March 08, 2016, 06:05:47 AM »

Sounds interesting.

Does this means potential for great FUN with elliptic orbits where you settle at the point furthest away from the star in nice cosy temperatures and then have your colonists roasted alive as it passes closer to the star?  ;D

After thinking about it, I am not certain that they should. Modeling the intricacies of realist-ish orbits is no small challenge. like you said, it can lead to variable temperatures->colony cost, or collisions and eventually become a performance hog when you need to calculate hundreds of bodies in every system.

In games that focus on space flight, with realistic propulsion (like karbal) such things would be an integral parts of mission planning and add depth, but in 4X strategy game, that span multiple system, it might be a distraction and cause of UI confusion and might be better to abstract with circles.

Same goes with 3d, the question isn't whether they can model it, but what would it add gameplay wise and how well can they design the UI to account for it.
Posted by: littleWolf
« on: March 08, 2016, 03:22:43 AM »

its really easy mathematic !

Create or use exists 3D point type (maybe OpenGL standart vector types) and adding  set Z=0 to default class constructor.     Then with directive #define or #typedef  replace vector2D (or Point2D) to your new  3D type.   

struct s3fVector
{
   double X;
   double Y;
   double Z;
   s3fVector (double x, double y, double z)
      :X(x),Y(y),Z(z)
   {};
   s3fVector ():
      X(0),Y(0),Z(0)
   {};
   s3fVector (const s3fVector& v2)
      :X(v2.    X),Y(v2.    Y),Z(v2.    Z)
   {};

   double modul()const {return sqrt(X*X+Y*Y+Z*Z);};
   bool operator ==(const s3fVector &v2)const
      {return(X==v2.    X)&(Y==v2.    Y)&(Z==v2.    Z);};
   s3fVector operator + (const s3fVector& v2) const
      {double x=X+v2.    X; double y=Y+v2.    Y;double z=Z+v2.    Z; return s3fVector(x,y,z);};
   s3fVector& operator += (const s3fVector& v2)
      {X+=v2.    X; Y+=v2.    Y; Z+=v2.    Z; return *this;};
   s3fVector operator - (const s3fVector &v2) const
      {double x=X-v2.    X; double y=Y-v2.    Y;double z=Z-v2.    Z; return s3fVector(x,y,z);};
   s3fVector& operator -= (const s3fVector& v2)
      {X-=v2.    X; Y-=v2.    Y; Z-=v2.    Z; return *this;};
   s3fVector& operator = (const s3fVector &v2)
      {X=v2.    X; Y=v2.    Y; Z=v2.    Z; return *this;};
   s3fVector operator * (double M) const
      {double x=X*M;double y=Y*M;double z=Z*M;return s3fVector(x,y,z);};

   double operator * (s3fVector v) const
      {double r=X*v.    X+Y*v.    Y+Z*v.    Z;return r;};

   s3fVector& operator *= (double M)
      {X*=M; Y*=M; Z*=M; return *this;};
   s3fVector operator / (double D) const
      {   if (D==0) return s3fVector(0,0,0);
         double x=X/D;
         double y=Y/D;
         double z=Z/D;
         return s3fVector(x,y,z);
      };
   s3fVector& operator /= (double D)
      {   if (D==0) {X=0;Y=0;Z=0; return *this;};
         X/=D;Y/=D; Z/=D;return *this;};
      bool operator > (const s3fVector &v2) const
      { return modul() > v2.    modul();};
      bool operator < (const s3fVector &v2) const
      { return modul() < v2.    modul();};
   s3fVector vmult(s3fVector v2) const
      {
         double x=Y*v2.    Z - Z*v2.    Y;
         double y=Z*v2.    X - X*v2.    Z;
         double z=X*v2.    Y - Y*v2.    X;
         return s3fVector(x,y,z);
      }
};


Lol.   I read source codes - you already use 3d vectors !:)  Need only polish 3d engine for real 3d navigation - and add mouse interact with displayed objects:)
Posted by: iceball3
« on: March 08, 2016, 02:22:38 AM »

we have now 2d coords - X and Y.   Adding Z - is not too hard work, simply change Point2d to Point3d class with same metods (set, get, getRange)and operators.  (add, substact, scalar and vector multiply and anoter needed). 

in first time we can simple set Z coord to 0.

Why we need Z coords ? 
1.  For some calculation (btw angle velocity)  most using vector multiplycation ( elliptic orbit:  V x R = const).   
2.  For suitable observation of star system  point view (players eye) must have a variable Z coord and angle of view.  Zooming and moving realize very simple - by apply transform matrix to scene.
3.  in future Steve may simple add Z coord field for upgrade game to true 3D 4x.
I think you are overstating the simplicity of the matter.
Posted by: littleWolf
« on: March 08, 2016, 02:17:25 AM »

we have now 2d coords - X and Y.   Adding Z - is not too hard work, simply change Point2d to Point3d class with same metods (set, get, getRange)and operators.  (add, substact, scalar and vector multiply and anoter needed). 

in first time we can simple set Z coord to 0.

Why we need Z coords ? 
1.  For some calculation (btw angle velocity)  most using vector multiplycation ( elliptic orbit:  V x R = const).   
2.  For suitable observation of star system  point view (players eye) must have a variable Z coord and angle of view.  Zooming and moving realize very simple - by apply transform matrix to scene.
3.  in future Steve may simple add Z coord field for upgrade game to true 3D 4x.
Posted by: iceball3
« on: March 07, 2016, 05:42:27 PM »

4.  Maybe adding 3D to system map ?
You wot?
I am 99% sure that is not the direction this project is intended to go, though, I'm not really a major contributor. Still, though...