Arcane Game Lore

Notes for tonight's game: TPK!!!

On Space Combat

I listen to several podcasts during the week on my way to and from work and when working around the house.  Most of them are RPG podcasts and one of those is Fear the Boot.  Last week in their bonus episode #60, Dan had a wonderful solo episode where he talked about Capital Ship Combat.  It was more an episode on general space combat and it was great.  I’ve been thinking about writing posts on this topic but Dan hit most of the points and covered it thoroughly. Everything that follows was sparked by comments Dan made.  If you haven’t listened to the episode, you should do so now.  (It’s a little long at ~90 minutes but it is well worth the time.)  Go ahead, I’ll wait…

 

Back?  I told you it was worth it.  Now on to my thoughts.  I was actually listening to this while out grocery shopping over the weekend so my notes are just short jotted down thoughts on my week’s grocery list.  I will probably be revisiting this again in the future but these are the thoughts that stood out.  And I’ll admit up front I’m one of those guys Dan mentioned that is very much into and comfortable with the physics and math involved (B.S. in Physics, M.S. & Ph.D. in Astronomy).

Beam Diffusion

Dan talks about ranges in space combat.  One of the things about lasers is that they spread out.  They don’t stay a tight beam of light forever.  I touched on this a bit in the laser rifle post a couple of weeks ago when I talked about focusing the laser beam at the proper range for the target.  This effect will tend to limit the range of your laser weapons.  So while in theory you could shoot a ship that is orbiting Mars from Earth as Dan talks about, the laser may not have much power when it arrives.  At least not concentrated enough to do any damage.

We use lasers to regularly measure the distance between the Earth and the Moon.  The lasers are fired from Earth to the Moon where they bounce off retroreflectors left by the Apollo missions and the reflected photons are measured to determine the roundtrip time (you can read more about it in this Wikipedia article and this one about a specific experiment at Apache Point Observatory in New Mexico, where I went to school).  The relevant point is, that even over just the distance from the Earth to the Moon, about 385,000 km (or 38 hexes on the Knight Hawks map for you Star Frontiers fans out there), the beam has spread out to be about 6.5 kilometers (4 miles) in diameter.  So while you can hit targets at great distances, there may not be much power left in your beam when you do.

Long Laser Cavity

Which brings us to another topic.  In order to get around the beam diffusion issue you need really long lasing cavities.  This means that the laser weapons inside your ship are going to be long and skinny if you want longer ranges.  Dan talked about the fact that you can have your weapons pointing out any side of your ship and why you might want to do that in his discussions about “broadsides” and he’s completely right.

However, this may be a reason to have long skinny ships with a forward firing laser cannon.  You need that entire length of the ship to hold the long lasing cavity to generate a tight enough beam to get the long range you want.  And depending on how your ship is designed, you might have that equipment running through all your decks.

Using All Your Weapons

That relates to another point talked about, namely bringing all your weapons to bear on a target when the weapons are spaced out all around your ship.  Battery type weapons (that have a 180 degree field of fire) are much better for this.  Half of your weapons can swivel in their mounts to come to bear on the target and to get the others into position, all it takes is a roll of the ship around the thrust axis which can typically be done fairly easily.  So weapons are fired in a 1-2 punch but this can be fairly close together.

A fixed weapon is not so easy as it requires you to orient your ship so that the weapons is aimed at the target which may not be along the direction of thrust.  However, all is not lost.  As Dan points out your ship can point any direction and doesn’t have to be pointed along the direction of motion.  As long as you’re not thrusting to attempt to change your velocity (speed and/or direction) you can have your ship pointing in any direction you want to fire your weapons.

It’s only when you’re trying to maneuver and line up a fixed weapon that you might run into problems. Basically what happens in this situation is that you have to rotate your ship, fire, and rotate back to the proper maneuvering position.  This can be done with or without turning off the main engines.  Turning them off provides more exact maneuvering but reduces the effective thrust you have for that time period.  Leaving them on introduces some randomness into your velocity depending on how you perform the maneuver (which may be a good thing, see below) and still reduces the effective thrust available as you’re now using it in a direction that isn’t where you want to go.

Here what is possible comes down to the details of the game mechanics.  If you’re playing with short time scales and large ships, maybe there will be a significant  loss of capability.  For example, you can still fire your fixed weapon anywhere you want but can only use half of your available thrust.  If your target is in a direction close to where your ship is pointed based on your desired maneuver, then there is no loss.  Of course this requires understanding the physics and orientation of the ship so maybe just a rule that reduces effective thrust when firing the fixed weapon regardless of target location would be easier to play.

On the other hand, if you’re playing a game with long time scales and/or smaller ships, you can just allow the weapon to be fired with no loss of capability.  Once upon a time I was developing a Star Frontiers combat plugin for the Orbiter Space Flight Simulator program.  The plugin was very nearly fully functional but we never released it as we were waiting on a usable multi-player plugin.  All it was lacking was automating the turn, fire, return to orientation maneuver.  In the process of developing that, I looked at what was required to pull that off.  And what I found that even for the largest ship in the Star Frontiers game, the UPF battleship (length 600 meters) you could turn the ship to any direction, fire, and return to your original orientation in less than 90 seconds and never experience more than 0.5g sideways acceleration at the extremities of the ship (I’m pretty sure it was 0.5g and not 0.5m/s/s or 0.05g.  It’s been many years and my memory is fuzzy).  The smaller ships could rotate even faster.  Since the Star Frontiers combat turns are 10 minutes long, this represents a relatively small part of the turn (<15%).  It would have real impact in the computer simulator game but for the table top version, using real vector physics (Star Frontiersman issue 11) we could ignore it and allow the fixed weapons to fire any direction without affecting the capabilities of the ship.

By the way, if you really want to get a feel for what maneuvering in space with real physics is like, grab Orbiter and play with it.  I highly recommend it.

Leading the Target

Dan also talked about leading your target and having to shoot where it will be and not where it currently is or where your sensors say it was when they got a detection.  This is very true and something that modern militaries deal with already.  And while it can be compounded as Dan described by the longer range distances, there is actually a mitigating factor with space combat that makes it easier.  And that goes back to the fundamental difference between the difference between movement in space and movement in an atmosphere or on the ground: no friction.

Unless your universe has ships capable of unbelievably high accelerations without smashing the crews to jelly, they can’t change direction or velocity very quickly and the way they do so is somewhat predictable.  To the first point, let me give an example.  A ship that fires it engines non-stop for one minute at 1g (where I’m using 1g = 10m/s/s instead of 9.8 to keep the math simple) can change it’s position by 18 kilometers (11.25 miles). That may seem like a lot but remember, space is big, and that change is the same regardless of what it’s initial velocity was.  Basically, if you knew it’s original velocity, you know know that it will be somewhere within a sphere 18 km in radius centered on it’s projected position.

But it’s not even as bad as that because of the second point.  If you have some idea of the ship’s design (i.e. you know where the engines are mounted) and you can determine roughly the ship’s orientation, you know which direction it’s thrusting and the number of possibilities for its ending position are greatly reduced because the ship has to obey the laws of physics, specifically Newton’s laws of motion.  The better you can estimate the acceleration being used and the direction the ship is pointing, the easier it is to lead your target accurately.  There will still be some error but it’s not really as hard it you might think.

Sensor Lag

Which brings me to the final point I wanted to mention.  And this isn’t so much commentary (as Dan covered it quite well talking about the time delays involved) but a reading suggestion.  What’s needed is some way to represent the uncertainty involved.  There is an example of this that I have always loved and it is the way I envision it when I think about it.  And that is the sensor displays from C. J. Cherryh’s Downbelow Station.  If you’ve never read this book, I highly recommend it.  The ships are moving at near light speed in the book but the same type of error display would work at the velocities and ranges we’re talking about here as well.

Last Words

Actually I don’t really have much else to add at the moment.  I just wanted a section heading to separate this bit from the section above.  Dan did a great podcast.  Hopefully you enjoyed my ramblings as well.  Feel free to share your thoughts in the comment section below.


Calculating Planetary Orbital Periods

In my previous article on determining the current season, I showed that you needed to know the length of the world’s year in order to track the season.  But what if you don’t know the length of the year.  Maybe you’ve got a setting book that gives the orbital distance but not the year length, or maybe you don’t have anything at all.  In this post I’ll walk you through what you need to know to determine the orbital period of the planet (i.e. its year length) and how exactly to calculate that period.

What’s Needed

In order to calculate the orbital period you actually only need two things.  You need to know the mass of the central star and the distance from the star of the planet’s orbit.  Now, at this point you’re probably thinking “How the heck do I get the mass of the star?”  Don’t worry, it’s actually not that hard.  But I’m going to walk you through the calculating length of year part first and then we’ll go back and talk about finding the information needed.

How Long is a Year Anyway?

plot of planetary period squared against orbital distance cubed

from http://hyperphysics.phy-astr.gsu.edu/hbase/kepler.html

Okay, so we’ve got the mass of our star and the orbital distance, how do we find the length of the year?  Before we answer that, a brief history lesson.  “It’s a warm summer evening, circa 600 B.C. …”  No.  Wait.  We don’t have to go back that far.  In the early 1600′s Johannes Kepler, using the observational data of Tycho Brahe, derived his three laws of planetary motion for planets in our solar system.  The third of which is the one were interested in.  It says that the square of the orbital period (in years) is equal to the cube of the orbital distance (in astronomical units – the distance from the Earth to the Sun).  These laws are true for planets around other stars except the units don’t work for the 3rd law.  Those only work for our solar system and you’re probably not doing that calculation.

Kepler’s work was empirical, he simply fit the data that he had.  It would not be until about 70 years later, 1687, that it would be possible to generalize this to other systems.  1687 was when Issac Newton published Philosophiæ Naturalis Principia Mathematica which described his theory of gravity.  With this law of gravity, it was possible to derive a version of Kepler’s third law that would work for any planetary system.  That’s the one were interested in. (If you’re interested in the actual derivation you can read about it on this site.)  This form of the law looks like this:

Kepler's third law

where P is the orbital period in years, a is the orbital distance in meters, G is the gravitational constant (6.67384 × 10-11 m3 kg-1 s-2), and M1 and M2 are the masses of the two objects.

“Hold on!” I hear you shouting. “You said we only needed the distance between the planet and the star and the mass of the star.  Now we need the mass of the planet too?”  Well, not really.  If you’re calculating the orbital period of an Earth-like planet around a star, the truth is that the mass of the planet doesn’t really matter.  The mass of the sun is about 2×1030 kg (that’s 2,000,000,000,000,000,000,000,000,000,000) while the mass of the earth is about 6×1024 kg (that’s a six with 24 zeros after it, you can write it out yourself if you really want to). Adding those together is 2.000006×1030 which isn’t much different from just the mass of the sun. If the star is much smaller than the sun or the planet is much larger, there might be a small effect but those combinations don’t typically result in habitable planets so we’re not going to worry about it. If it ever is important you have the full equation (and I may just do a post on determining the mass of your planet someday).

Okay, so we treat M2 as zero.  Now it’s just a matter of plugging in the values and crunching the numbers.  Here is an example using the Earth:

The orbital radius of the earth is about 150 million kilometers or 150 billion (US) meters.  We have the mass of the sun and G from above so we get:

P = sqrt( 4 * pi2  * (1.5×1011 m)3 / ( 6.67384×10-11 m3 kg-1 s-2 * 2.0×1030kg))

P= sqrt( 1.33×1035 / 1.33 ×1020 ) seconds

P = 3.16×107 seconds

Divide that by 3600 seconds per hour and 24 hours per day and you get 365.68 days  Which is a little off since I used approximations for the mass of the sun (it is really 1.989×1030 kg) and the orbital distance (it’s really 1.4959787×1011 m).

Other uses

You can also use this to calculate the orbital distance if you know the length of the year and the mass of the sun or calculate the mass of the sun if you know the orbital distance and length of a year.  These take a little bit of algebraic manipulation of the equation but everyone had algebra in high school so we’re all good.  If you don’t want to do the math yourself, there are a number of on-line calculators that will do it for you.  This one has a variety of options for the input and output values (although for some reason it doesn’t have kilograms as a option for mass.  This one doesn’t look as nice but does have kilograms as an input option.

Missing Data

Now it’s entirely possible that you don’t have all the information you need.  I mean how often do game supplements list the mass of the primary star.  They rarely even list the orbital distance.  Without those it makes it really hard to get the year length.  However, all is not lost.

Stellar Data

A Hertzsprung-Russel diagram showing different types of stars and their colorsWhile most system and supplements don’t list out the mass of the star they will often give its spectral type or at least it’s color.  And that’s enough for us to estimate the mass.  Of course, the spectral type is best, but even the color can give us some clues.  The reason this works is that the spectral type is basically just a measure of the star’s color.  The color of the star is directly related to the star’s temperature and the temperature is directly related to the mass.  So knowing the color or spectral type allows us to estimate the mass.

Now blue stars are hotter and more massive while red stars are cooler and smaller.  A yellow-orange star like our sun in kind of in the middle.  Now here I’m talking about “normal” or main sequence stars and not things like giants, supergiants, or white dwarfs.  While it’s possible for these type of stars to have planets around them, these types represent stars that are dying (or have died) and they probably won’t have habitable planets around them.  So for main sequence stars, the color can tell us the approximate mass.

Now given the color or spectral type, we just need to look up the mass.  One good site for this is the Atlas of the Universe’s stellar classification page.  You want to look at the “Main Sequence (V) table”.  The lines are colored the color of the star and the mass is given in multiples of the Sun’s mass (1.989×1030 kg) in the 4th column.  This table isn’t very fine grained, however, and only has a few entries.

If you want a super detailed version you can use this Stellar Classification Table.  This table has an entry for every single spectral type and stellar luminosity class.  I didn’t talk about luminosity class but just know that main sequence stars are luminosity class V.  So the Sun is a G2V star.  When looking at this table you will be interested in the ones that end in V.  This table lists the spectral type in the first column and the mass (again as a multiple of the Sun’s mass) in the second column.  A neat thing about this table is that it give RGB colors for the stars in the right most column.  The color of the numbers is the color of the stars as they would appear to our eyes.

So if you have the color or the spectral type, you can use those tables to estimate the mass of the star.

Orbital distance

This one’s a bit harder to estimate without some prior information.  In fact, to do this correctly we need to talk about habitable zones and stellar evolution and that’s a complete post (or two) all by itself that I’ll be writing in the near future.  For now we need some way to make a back-of-the-envelope estimate.

First, the Earth is near the inner edge of the habitable zone for the Sun.  And that zone extends out nearly to Mars.  So if you have a star like the sun, then the habitable planet is going to be about the Earth’s distance.  Maybe a shade closer if the climate is generally warmer and a bit further out if it is cooler.

Second, as the star gets redder it puts out less energy.  This means that the planet has to be a lot closer in order to get the same amount of total energy from the star.  So the habitable zone moves in closer and the orbital distances will be smaller for redder stars.  The opposite is true for bluer stars.  They put out more energy and so the planet would have to be further away to prevent it from getting fried.

The question is how much closer or further away do we need to go?  The energy put out by the star is proportional to the star’s temperature raised to the 4th power.  Which means doubling the temperature by a factor of 2 increase the energy output by a factor of 16.  Similarly reducing the temperature by a factor of 2 reduces the energy output by a factor of 16.

So that’s how we make our estimate of the distance.  Given the star’s spectral type or color, both of the linked tables give us its temperature.  Take the ratio of the star’s temperature to that of the Sun’s and square it, then square it again (that gives you the ratio to the 4th power).  That value is what you should multiply the Earth’s orbital distance by to get a (roughly) similar temperature range.  Then tweak it as desired for a slight climate variation.  And now you have the orbital distance and can figure out the length of the year.

And Now You Know

That’s it.  Even if we have just the color of the star and the knowledge that the planet is habitable, we can make a reasonable estimate of the length of its year.  The more we know about the system, the better our calculation will be, but even just the stellar color can get us something.

Did that all make sense?  Or was it all Greek?  Are there any tricks you use?  Are there any topics mentioned that you’d like me to go into more detail on?  Let me know in the comments below.


Building a Laser Rifle

Laser guns are a staple of science fiction books, movies, and games.  The questions that always come to mind (to me at least) when thinking about hand held laser weapons are how realistic are they and how long until I can get one?  On that thought, this video wandered across my RSS feeds the other week and I just had to share and talk about it.

Needless to say, I thought this was pretty cool and I want one.  However, it got me thinking again about what it would take to make a traditional sci-fi laser gun and what components it might have that make it tick.  It gives me ideas of what could go wrong with a weapon and what would need to be fixed if one broke.  So here are my thoughts as a gamer and a physicist.

Energy Delivery

Doing damage with a laser is all about delivering energy from the weapon to the target.  So we need a few definitions. Power (Watts in this case) is defined as energy (Joules) per unit time (seconds). So his 40 Watt laser diode array is providing 40 Joules of energy per second.

Really what you are after is increased energy density on the target.  Or the amount of energy per unit area. Anything that increases the energy density delivered makes the laser weapon more effective.  Things that reduce this make it less so.  Let’s look at how the various aspects of this device contribute to that and how that would be different in a sci-fi weapon.

Light Color

This laser gun is made of blue laser diodes.  Blue is good as shorter wavelengths can be focused to a smaller point.  In fact, blue light, at around 400 nm can be focused to a spot half the diameter of red light at 800 nm since the spot size is directly related to the wavelength.

Which means that given the same amount of power, blue light can theoretically provide four times the energy density (cut the diameter in half and the area goes down by a factor of four). This means you achieve a burn faster with blue light than you would with red or with less power consumed.

Another advantage, albeit a minor one, is that blue light has more energy per photon than red light.  This means you get a bonus from the photoelectric effect (the discovery of which won Einstein his Nobel prize in 1921) as blue light is more likely to ionize some of the target material.  Most of the damage is going to come from pure energy transfer in the form of heat so this doesn’t do much but it is an effect.

Ideally a UV laser would be even better but would not look nearly as stunning as you wouldn’t see the beam.

Continuous vs. Pulsed Beams

In sci-fi most lasers fire a “blast” or “bolt” of very short duration (which in movies always travels way slower than it should  for dramatic effect.  Any true light beam would cover the ranges on set in less than the time between a single frame).  This particular laser is continuous which is why he needs to keep moving it around while he’s talking about it.  If he didn’t, he’d be burning a hole in his wall (maybe, see the Lenses and Mirrors section below).

But this gets back to the energy delivery issue.  A continuous beam delivers its full energy every second, in this case 40 Joules.  However, if this were a pulsed beam, you wouldn’t get nearly as much energy.  Let’s assume a pulse duration of 1/10th of a second.  Since the output of the diodes is 40 Watts (40 Joules/sec) a 1/10th of a second pulse only provides 4 Joules of energy.

In order to get the same effect as one second of a 40 Watt system, a system that used 1/10th second pulses would need 10 times as much power capacity or 400 Watts.  However, you’d still be delivering just 40 Watts of power.  (400 Joules * 1/10 sec = 40 Watts)

You’ll also notice in the video that it typically takes longer than a second for him to ignite or pop his various targets.  So he’s delivering more than 40 Joules to the target.  Which means that given a single 1/10th second pulse, you’d actually need even more power capacity in the system.  To get the same effect from a single 1/10th second pulse would probably require about 1000 Watts of power capacity in the diodes.

So why would you want a pulsed blast instead of a continuous one?  A continuous beam system is definitely easier and cheaper to build as you don’t need as much power capacity.  The main reason is time and energy cost. And that goes back to the energy density issue.

With a pulsed system all the energy is delivered in a very short time span, the smaller the better.  This means the target doesn’t have time to dodge or move out of the way. All the energy is delivered to a single spot, thus boosting the density of the delivered energy.

If you’re using a continuous beam system that requires any significant amount of time to deliver the necessary power and the target moves (spins, rolls, whatever), that power is now being delivered to a series of different locations and delivered energy density greatly decreases reducing effectiveness.  And if you have a continuous beam system that can deliver enough power in a short time to do damage, running it any longer than necessary wastes energy, reducing the number of “shots” you can take before you have to recharge.

Laser being emitted from telescope observatory dome

Everyone knows that the large telescopes of the world are part of a space laser defense system. This is actually a picture of the ARC 3.5m telescope at Apache Point Observatory (I’ve observed on this telescope) using it’s laser system to determine the exact distance to the moon.

There is another reason why you’d prefer pulsed to continuous and that is concealment.  With a continuous beam, there is a beam of light connecting the shooter to the target and anyone that happens to be looking will see exactly where the shooter is.  With a pulsed beam, the length of time that connection is visible is much much shorter and thus makes it harder to see where the shooter is.

Energy Flow and Heat dissipation

This is another advantage a continuous beam system has over a pulsed one.  You would think that since the total energy being delivered (40 Watts in our examples) is the same the amount of heat to be dissipated would be the same.  However, there are some additional complications that relate back to the timing.

Since the pulsed system delivers the energy in 1/10th the time, the instantaneous heat generated at the time of lasing is going to be 10 times higher (at least).  Thus whatever we are working with to dissipate that heat has to be able to handle that heat impulse.  This means that there may need to be some different materials use for construction.

Additionally, the shorter time scale mean that we are going to have a higher current flowing through our circuits during the lasing interval to deliver the energy from our power source to the laser itself.  It turns out that this source of heating in the electronics, called Joule heating is proportional for the current squared.  So if we increase the current by a factor of 10 (necessary to get the same energy delivered in 1/10th the time), the amount of heating goes up by a factor of 100.  Now it only lasts 1/10 as long but that still gives us 10 times as much heating as the continuous case.  All that heat has to be dealt with.

For our sci-fi laser weapons, however, there is a help and that comes from assuming we are using some sort of superconductor in our electronics.  The other thing the Joule heating is proportional to is the resistance in the wires.  If we have a superconductor, which has a resistance of zero, then we get no Joule heating.  So if we just have an exotic material with very low resistance, even if it is non-zero, that greatly improves things.

Lenses and Mirrors

I thought one of the best things about the video was his off-hand comment about putting the short range lens on for the demos he was doing.  Since he had 8 diodes, in order for them to work together, they had to be focused to a single point in order to concentrate the power and increase the energy density on target.

The same will be true in a sci-fi laser gun.  If you’ve got multiple laser emitting elements (which makes the power distribution and cooling issues a little easier) or a single element, you’re going to need to focus the beam.  You need mirrors and lenses in your system to control the way the light is emitted.

In the case of multiple emitting elements, you’re going to need to focus the various beams at exactly the right range to hit your target.  This will probably take the form of some sort of deformable lens system that will allow you to change the focus of the lens to adjust the range.  Of course you need to get that range and get it exactly as being off by even a little bit means your laser energy is spread out and you don’t do as much damage because the energy density isn’t high enough.  You could take this as the explanation of why you roll dice for damage, the variation represents how accurate you got the range to concentrate the laser fire. (This is also why he may not have burned through the wall if it wasn’t moving the laser while he was talking.  If the beam was dispersed enough, it’s no different than a really bright light.  But better safe than a house on fire.)

The range finding would need to be mostly automated as the operator probably won’t be able to estimate the distance accurately enough.  However a small ladar system (laser distance and ranging) built in to the weapon would do it.  It could send out a low power IR laser beam, get the return signal and use that to estimate the distance just before firing the main blast.  Maybe the operate has to pick a general range to get the right deformable lens selected (i.e. short, medium, long, etc.) and the weapon does the rest.

For a single beam you still have a focusing effect.  The beam has a “waist” where it is the narrowest and thus has the highest energy density.  You’ll want to adjust the focus of your lens so that the waist is on the target for maximum effect.  The same focusing system described earlier would work here as well.

Backscatter

Finally, you have the issue of backscatter of the light beam.  This is caused by photons in the laser beam reflecting off of surfaces or air molecules along their flight path.  It’s why when you see pictures of people working with lasers, they are wearing dark glasses.  It helps to protect the eyes of the operators from backscatter.  This is also why you can even see the laser beam at all.  If there were no backscatter and all the photons were going forward, you wouldn’t see the beam.  It’s only visible to you because some of the photons are bouncing off air molecules toward your eyes.

In the video, he definitely needed them as he had that big lens sitting right out in front of the beam.  Typical glass reflects about 4% of the light that hits it unless it has had special coatings applied to reduce this value (This is why you can see yourself in a window).  That means that of his 40 Watts of power going out, 1.6 Watts was being reflected back at him from the lens. It was diffuse and not focused, but that’s still a lot of laser power going back.  Just look at his shadow from the laser light.  Upping the power just makes it worse.

In a weapon system, your lenses will be coated to make sure as much light passes through as possible since any reflected light is going back into the belly of the weapon were you don’t want that energy bouncing around.

For a system that is completely enclosed until the beam is emitted, the backscatter to the operator wouldn’t be as bad but there would still be an intense flash of light as the beam left the barrel and some of that light was backscattered.  It wouldn’t be a problem in space but anywhere there is air you’d have this effect.  And more power means brighter light.  Maybe firing a laser weapon requires special eyewear connected to the weapon to prevent spot blindness from the beam or there is a targeting penalty after the first shot as you now are seeing spots.

Final Thoughts

Have you ever thought about how exactly laser guns work in your game?  Is there anything I missed?  Hopefully this gives you some ideas of ways to add a little flavor or color to your games when your characters pull out their blasters and take a couple shots.  There is a lot of engineering that goes into a laser gun.  Do they cost more in your game than more “traditional” weapons?  Should they?  Let me know your thoughts in the comments below.


RPG Blog Carnival – What Season is it Anyway?

This month’s RPG Blog carnival is being hosted by Phil over at Tales of a GM and the topic is Summerland – topics related to the season of summer.  In reading through his post, I realized that dealing with seasons was not something I usually did or even thought about when running a game.

There are probably several reasons for that but the biggest is that it probably never occurred to me to worry about it.  I play science fiction games and characters are not typically on a world for long enough for the seasons to change so thinking about seasons never really was a topic I thought about.  The weather and season were whatever it needed to be for the adventure.

However, in reading Phil’s post for the blog carnival, it got me to thinking.  Adding seasonal highlights (in this case summer ones) would be a great way to add depth and richness to your worlds.  But in the case of a science fiction game that spans several star systems and planets with different year length’s, axial tilts, and stellar types, how do you even know that it is summer in the first place for that system. Not every planet has summer at the same time, you could leave a planet in high summer, jump to the next system, and land in the middle of a blizzard.  By knowing (or being able to quickly calculate) the season when characters arrive on planet you can add depth and flavor to your campaign.

So while this post is not going to be directly about summer, it’s definitely related in that it helps you determine if it should be summer or not.  I’m going to present a (hopefully) simple system for doing just that.  It’s untried and I’m developing as I write but I think that it will work out fairly well.  Heck, if an astronomer can’t figure out how to track the seasons, we might be in trouble.  So let’s get going.

Determining the Season

Okay, let’s dive in and see what we come up with.  To goal is something fairly simple that is easy to use and easy to keep track of, but which can be refined and expanded as needed.

What Do We Need to Know?

The first question that we need to answer is: “what information do we need to get started?”  At the bare minimum, we need the length of the planet’s year and an absolute date (an epoch) for the beginning of one of the seasons.  For example, on Earth we’d need to know that the year is 365.24 days long and that March 21, 1900 was the first day of spring.

A permenant Gregorian CalendarIdeally, you’ll have some way to count days that is a simple count or easy to calculate (our modern Gregorian calendar doesn’t work – can you tell me off the top of your head how many days have passed since March 21, 1900? or even since March 21, 2010?).  Astronomers use the Julian Date for this purpose.  Today (Jun 9, 2015) is JD 2457183 whereas noon on March 21, 1900 is JD 2415100.  So it’s been 42,083 days since March 21, 1900.

In most sci-fi settings there is the concept of a “galactic standard day” and “galactic standard year”.  Maybe not by those names exactly but there is typically some universal time system that is not associated with the individual planets (although it may be based on the calendar of one of the planets – e.g. the capitol world, original homeworld, etc.).  This is exactly what we need.  For example, in Star Frontiers, the standard year is 400 days and the standard day is 20 hours.  So a single standard year is 8000 hours (compared to earth’s year of 365 days x 24 hours/day = 8760 hours).

The final thing you need to know is how long each season lasts as a fraction of the total year.  Ideally, this would be a detail that you have figured out for each world but to first approximation, just assume that each planet has 4 seasons and each one takes up 1/4 of the year.

So we have a date that we know which corresponds to the start of our seasonal cycle, we know how long the planet’s year is, and we know how long each season lasts.  Let’s get started.

Calculating the Season

The first step is to calculate the number of days between the epoch we’ve recorded and the current date.  There is where a standard time system is helpful.  Using the Julian dates on Earth from the example above today is 42083 days since the epoch.  Using my Star Frontiers example, if the epoch was day 32, year 10 and the campaign date was day 253, year 65 we have 368 days in the rest of year 10, plus 400 days for each of the years 11-64 or (400day x 54 years =) 21600 days plus the 253 days in the current year for a total of 368+21600+253 = 22221 days since the epoch. Or assuming a running date count from day 1, year 1, the epoch is day 3632 and the campaign date is day 25853 which gives us 25853-3632=22221 days, just as before.

Animation of Mercury's and Earth's orbitsNext, you simply divide the number of days by the length of the planet’s year.  This gives you the number of local years since the epoch.  For the earth example that’s 42083/365.25 = 115.217.  For my Star Frontiers example, if the planet had a short 287 day year, we’d get 22221/287 = 77.425 years.

Now it’s actually the decimal portion that we’re interested in.  That tells us how far along the current seasonal cycle we are. Assuming four equal sized seasons, then the breaks fall at 0.25, 0.5, and 0.75.  Looking at the Earth example, we see that the decimal part is 0.215 or just at the tail end of the first season.  Since we started or cycle with spring that says that we are almost to the start of summer.  And since it’s June 9th and the solstice is June 21st it worked out just right.  Looking at the Star Frontiers example, we got a .425 decimal portion which says that the planet is nearing the end of its summer, probably the hottest part of the year.  When your characters land, you can describe the weather appropriately.

And that’s all there is to it.

A Season for Every World

In order to do this for  all the worlds in your campaign, you just need to come up with the three numbers: epoch of the start of the cycle, length of year, and break points for the seasons as fractions of the year.

But I’ve got hundreds of planets, how do I do this for every one?

Well, I’ve already given one way to simplify it – assume four equally sized seasons.  That eliminates one set of numbers.  If you go back far enough to set your epoch, you could pick the same epoch for every planet, say day 1, year 1 of the current calendar.  That would give you a single epoch and you wouldn’t have to remember unique ones for each planet.  This is completely unrealistic as the probability of every planet having their seasonal cycle line up is so far-fetched as to be impossible.  However, for game purposes it absolutely doesn’t matter (unless I guess you’re running an intergalactic time-traveling campaign).  Given even a few decades of time since the epoch, and combined with the varied year lengths of all the planets, the local seasons will quickly go out of sync, especially if you’re using fractional day year lengths.

That leaves you with just having to know the length of the year for each planet.  And that information is probably already in your system brief for the planet. If it’s not there, there are ways to estimate it based on the type of star the planet is orbiting but that’s a topic for another post (or maybe two).

With those numbers (or approximations) in hand, now you’re good to go.  When the players arrive on the planet, a quick calculation will give you the current season.  And when they come back a few months later you’ll know how the season has changed and can describe it accordingly – breathing life into the setting in a subtle way that will help it to feel alive and dynamic.

Refinements

That’s the quick and dirty method.  To refine the calculations, all you really need to do is refine the data for each world.

The local year length is pretty fixed and already unique so there’s not much to do there.

You could pick unique epoch dates for each planet.  This is much more realistic but from a practical standpoint doesn’t make much difference.  All it does is shifts the seasonal phase a little.  As I said before, if your epoch is far enough in the past, this won’t matter.  However, if you’re implementing this after the characters have already been on the planet and experienced one of its seasons, you might want to set the epoch at a near date so that the calculations line up with what they experienced and you can remain consistent going forward.

Similarly if the characters have never been to the planet before, and you want them to experience a specific season for the adventure you have planned, don’t use a predetermined epoch.  Wait until they arrive, describe the season you want the system to have and then set the epoch appropriately and use that to calculate the current season when and if they return.

A collage showing an image from each of the four seasonsThe biggest thing you can do to add uniqueness and variety to your worlds is vary the number and length of the seasons that the world experiences.  Maybe there are only three seasons: rainy, normal, and dry.  And the rainy and dry seasons are both short, say each only taking up 20% of the year.  Then assuming you started with the rainy season at the epoch, you have divisions at 0.2 and 0.8.  Any fraction less than 0.2 is the rainy season, anything greater than 0.8 is the dry season and everything else is the normal season, whatever that means for the world.  By determining the unique weather patterns and recording it, you have a way to quickly get at whatever the season is on the world regardless of when the players arrive or return.

A Possible Notation

Finally, it doesn’t take a lot of space to record the information either, two lines at most in your notes, and only one if you’re using a Spring, Summer, Fall, Winter cycle.  Using that season cycle you just need the following

Planet Name – epoch – year length – breakpoints

So for Earth, using Julian dates with March 21, 1900 as my epoch, the entry would be:

Earth – 2415100 – 365.25 – 0.25, 0.5, 0.75

For my fictional Star Frontiers planet, and using a slightly longer summer and shorter winter, we’d have:

DevCo – 3632 – 287 – 0.25, 0.55, 0.80

which gives spring and fall 25% of the year, summer 30%, and winter 20%.  If this planet had the rainy/normal/dry seasons in the example above, it’s entry would be:

DevCo – 3632 – 287 – 0.2, 0.8 – rainy/normal/dry

where the extra information would be added either on the same line for a following one (depending on your formatting) to indicate what seasons are represented by the break points.  You could always include the spring/summer/fall/winter designation but that is assumed if there are three breakpoints.

Final Thoughts

I think the above system is pretty straightforward.  Probably the hardest part is the time system used to calculate the seasons.  If you have a convoluted calendar system, this would be more difficult.

I’ve also ignored the transition times between the seasons.  Obviously a planet’s weather doesn’t suddenly shift from winter to spring-like overnight just because some magical number was reached.  Near the transition points you will obviously have a blending of weather from the two seasons or modulation of one leaning toward the other.  This system is designed to just give you a rough idea of where in the cycle you are.

Does this make sense?  How do you track seasons across multiple worlds?  What would make this system easier/simpler/better?  Let me know in the comments below.  It’s been raining almost every day for the past month; can we have summer now?

 


The Combat Experience: Complexity

I meant to write something up for the April Blog Carnival, but alas time is fleeting away with so many other endeavors about. Regardless, speaking on The Combat Experience is something I do often and will regale you with my wit and knowledge… ok, maybe not, but I still offer my opinion.

There are a multitude of facets to any combat system. I do not think there is a debate for the need of rules to resolve a situation, but there is usually a time when there is an argument about how a rule is interpreted. This brings me to the point of this discussion, the complexity of rules in combat. This is not an argument for more or less rules, but my own experience with multiple rule sets.

When I started role-playing, rules were much lighter and we enjoyed many nights of slaying evil or exploring the galaxy. As the years progressed, I became increasingly interested in making games more complex, adding little nuances for facts about real life that I was an expert in, or thought I knew something about. Like many others, I started developing my own world and my own system, with delusions of grandeur on creating a game that people enjoyed playing.

So I continued to this trend until I played a game that took an entire session to resolve two bullet shots at the same target. The game was so complex, it had rules for deflection from shooting through varying thicknesses of glass, to which bones were hit and shattered as the bullet passed through the body. I forget the name of the game, but I walked away and have never played it again. This also broke my need for a complex rule set.

As my time becomes more valuable, and I have less time for role-playing, I find that I like less rules and more description in my games. There will always be some level of ambiguity in the rules. On top of that, there will always be misinterpretation and derision for someone else’s rule. my personal opinion is that a lighter rule-set will allow more freedom of action and less time trying to find all the applicable rules for a given situation.


3D Modeling – CSS Nightwind – Printing and Painting

By the time you’re reading this, I’m off camping.  Here are the final details on the printing and painting of the Nightwind model.  For details on the creation of the model, you can read my first post from last week.

Printing revisited

In the first post on the Nightwind, I forgot that I had videotaped the printing.  Presented here is a time lapse, speed up by a factor of 16, of the printing of the Nightwind model.  This was the first video I made so I was adjusting the camera height at the beginning to get the best angle.  I also realized afterward that I need an additional light source to illuminate under the print head so you can see better.  But still, it’s pretty cool.  I have videos of some of the other models that I’ll include with their write-ups as well.

And here are some (non-fuzzy) images of the finished model from that print.  Click on them for full resolution.

Two views of the printed Nightwind model

The vertical feature you see on the right in both images is not the break in the cargo bay doors as you might expect.  You can see that it runs up into the head of the ship as well.  This is actually the “z-scar” which is caused by uneven plastic extrusion when the object is moved on the z-axis.  In this case it’s a depression but on some printers it is a bump.  It’s definitely more noticeable on this model than on some of the others I’ve printed.

Removing Supports

Removing the raft and supports that his model was printed on is quite straightforward.  The raft separates quite easily.  There are only minimal supports under the fuselage and the engine struts and these pull off quite easily with a pair of needle-nose pliers

Painting

For this model I decided to go with a basic reflective hull (silver) with some company color highlights.  The Nightwind was designed and developed by the Cassidine Development Corporation (CDC for short) and in my game CDC’s corporate colors are blue and green.  So the plan was to use those colors to highlight bits of the ship and to emblazon the company logo down it’s side.  We’ll see how it turned out.

The Nightwind model painted completely silver.

Nightwind’s base reflective hull. Not the best angle but it does show some of the features of the model.

First I started by applying the base reflective hull. This was done with a silver spray enamel and it was just given a good coating.  I considered buying some silver mirror coating paint for a truly reflective paint coat but the paint was designed for glass and not plastic so it may not have worked very well (Plus I didn’t really want to spend the $$ on it just to test it).

Next I did the engines. Originally I had thought to make the raised portions green with the rest of the engine blue but once I sat down to paint, I decided to just go with a blue stripe down the lower portion of the engine with the upper relief painted green and leaving the body of the engine the reflective hull silver.

Next came highlights around the cargo bay doors and other hatches and air locks.  At least that was the plan.  I did the highlights (in black) around the cargo bay doors but in looking at the model, decided the steadiness of my hand and my painting skill were not up to the challenge of doing the bay doors at the tail of the ship and in the neck.  In the end, I just left those silver.  You can see them but it’s only in natural shadows without any highlights.  I might revisit this bit later after I’ve gained a bit of confidence in my skills.  Here’s a picture of the engines and the cargo bay doors.

The fully painted model as described in the text.

The Nightwind painted.

Finally I did the company logo on the fuselage.  In this case, the logo is just the letters CDC with the same shape being used for the C’s and the D but with it reversed for the D.  I also make the C’s green and the D blue.  Here’s the back side of the ship with the corporate logo emblazoned on it.

Other side of the Nightwind with the CDC logo on it.

I considered doing something with the head of the ship but in the end couldn’t decided on anything.  Normally I’d do the weapons in silver but they already are.  I considered using gold there but didn’t really like that idea.  So for now I’ve just left that entire portion with it’s base reflective hull.  If I have a good idea I can always revisit this portion of the ship later as well.

What do you think of the paint scheme?  What should be added or removed?  Any suggestions for the head of the ship?  Post your comments below.

 


The Role of Miniatures

dnd_Box1stRole-playing games (RPGs) have always been about using your imagination; yet RPGs got its start in tactical miniature games. If you read the history of Dungeons and Dragons (D&D), you will find that “it was derived from miniature wargames”. Often the use of miniatures (minis) has mixed feelings in RPG circles, devolving exciting, imaginative action into a tactical board game.

Role-playing has changed since its inception in the 70s, and the proliferation of minis into the system has developed games like Descent: Journeys in the Dark and even the new D&D Adventure System Board Games that play like the old school dungeon crawls from yesteryear. There was a time when I would advise against this. Having sunk many, many dollars into minis over the years, I would find the up-front costs of such games undesirable. But with the increased price of gaming books, the D&D Player’s Handbook costs $50, and the decreasing price of miniatures, D&D’s Temple of Elemental Evil Game costs $65, the price difference is less of an issue.

There is also the Old School Revival (OSR) that supports a simpler rule set, more storytelling and less tactical crunch in RPGs. Now this might appear to go against the idea of using miniatures, but it’s a matter of how you play your games. We have recently switched to D&D 5th edition, and find the lighter rules more freeing to role-play and worrying less about rules-lawyering. We still use miniatures heavily in our games for two reasons. One, our game master likes to make large maps for encounters. And two, not all of our players are keen on trying to visualize where everything is in a fight.

What about replayability? It’s true that fighting new and mysterious creatures is one of the things I enjoy about any game, and using the same miniature for different types of monsters loses something in translation. There is only so many times you can fight a red dragon until the miniature either means the death of the party, or another pair of dragonscale boots to parade through town with. But that doesn’t mean the figures will never be used again. After nearly twenty years, I finally broke out my old, discontinued game of Heroquest to play with my boys. The box is beat up, some of the miniatures are broke, most are still unpainted, and I had to download the original quest book because I can’t find the two I had at one point. But my boys still love the game.

kickstarter

I recently backed the Kick Starter for a board game called Zombicide. I’ve been a huge zombie fan since I watched George Romero’s Night of the Living Dead in 1983 (the movie actually came out in 1968). I know there have been other zombie games that came out, and I’ve played a couple, but none of them really caught my eye until Zombicide. I’ve played about 8 times, and each time, it gets a little better. While the game is fun, I find that I’m looking for more minis to enhance the feel of the game. I recently found that 28mm minis are about the same size of 1:43 scale models. I have found some really cheap 1:43 scale cars to use in the game that really adds to feel. I also plan to use these vehicles in our Shadowrun game, so they will get some additional use.

You will have to determine if the investment is worth it in your games. You can have years of enjoyment without ever buying a single miniature, but if you have players that need a map drawn on a white board, maybe adding some minis to the game might be more appealing to them. If you decide to go with a game system, you can get a lot more minis than buying them one at a time, and if you have one of those nights where you’re missing too many players to continue the game, you can bust out the board game and still slay some monsters in a nice dungeon crawl.

pimp_mobile


3D Modeling – CSS Nightwind

This is another model of my own design.  I originally designed the Nightwind back in 2012 for the Star Frontiers Virtual Con were it featured as the center piece in an adventure I ran.  It later appeared in the inaugural issue of the Frontier Explorer with complete deck plans and descriptions.  I’m planning on running that adventure again in the upcoming Frontier NetCon 2015 if you’re interested in playing.

As I mentioned in the post on the engines, the work on this model started there.  Once I had engines of the appropriate size, I began working on the rest of the ship.  The design of this ship is fairly simple so I was expecting it to be fairly straightforward.  However, the decks at the top of the ship are not all cylindrical and that may pose a problem.

Main body

The majority of this ship is just cargo space.  So the main fuselage of the ship is just a giant cylinder, 95 meters tall broken in to a few engineering decks at the tail and four large cargo bays.  This was the easy part, just a single object to make up 95 of 130 meters of the ship.

Neck & Head

Here things started getting complicated.  If you look at the deck plans for the airlock deck and upward in the ship, you’ll notice that very few of the decks are circular.  They all have various flattened or bulged out parts that deviate from a circle.  Thus I couldn’t just use a few cylinders and cones to make the head and neck of the ship.  I had to take these various shapes into account.  Plus I wanted the outside of the ship to flow smoothly between these variously shaped decks.  I didn’t want them to just be sitting willy-nilly on top of each other.

The solution here was OpenSCAD‘s hull() command.  What this command does is takes two or more objects and creates a bounding shape (a convex hull) that just encloses them.  The images to the right show an example.  If we create two circles with the commands:

translate([15,10,0]) circle(10);
circle(10);

We get the image on top.  If we then enclose the commands to create the circles with the hull() command:

hull() {
   translate([15,10,0]) circle(10);
   circle(10);
}

We get the shape in the second image.  Thus we can take two arbitrary shapes and create a shape that seamlessly merges the two.

Now my first thought was to just put in the top and bottom of each deck and wrap one big hull() command around them.  This almost would have worked.  The only problem was the neck of the ship, that smaller airlock and vehicle deck.  The hull() command makes a convex hull and since the top of the cargo deck and bottom of the crew deck are larger than the airlock deck, it just made large cylinder over that section and didn’t put the narrowing neck in as I wanted.

So in the end I made the head of the ship in a series of small hull sections, alternating between the decks them selves (3m tall) and the machinery spaces between the decks (2m tall).  For each deck, I just created the deck shape from the deck plans with a 3m height.  For each machinery space section I would take the shape of the deck below and the bottom of the deck above, each set to 10cm high, and join them via the hull() command.  This gave me the smooth transitions between decks that I desired.

The crew section starts with a cylindrical base that narrows down to a small neck and then flares back out to a roughly cylindrical shape with small flat and protruding areas until the tip tapers like an inverted cake cone style ice cream cone.

The crew area of the Nightwind without the weapons added to show the effect of the hull() command

Doing this for each layer resulted in the shape pictured to the right.  You can see the transition between the various decks.  This was really cool to me when I finished it as I had never really drawn out exactly what this looked like and so this was the first time I had seen the exact shape of what the head of this ship would look like.

Attaching the Engines

Since I had already created the engines, it was just a matter of attaching them to the ship.  The Nightwind has three class B engines so I copied the class B engine code into a for() look and rotated them each 120 degrees apart.  I added a simple strut to connect them to the main ship and then shifted them (via the translate() command) to the proper position in the model.

External details

Now that I had the hull of the ship complete, I needed to add in all the doors, hatches and weapons.  Similarly to what I did with the sathar destroyer, I started by removing a little bit around where I wanted each door or hatch to be.  This was done primarily for printing purposes to allow the doors to stand out better when printed at the small scale.  Once that was done, I added in all the doors and hatches.  These consisted of numerous small bay doors for all the vehicles (3 launches and 4 work pods) as well as the two airlocks (in the neck and on the engineering deck) and the for massive cargo bay doors along the body of the ship.

Finally I added the ships weapons (3 laser batteries and a rocket battery and added them to the model as well.

This image shows the complete model as described in the text.

The complete Nightwind model

Final model

The final model is displayed to the right.  You can see the cargo bay doors lining the main body as well as one of the laser batteries (mid right) and the rocket battery (lower left) on the head of the ship along with several of the hatches and airlocks on the bottom of the main body and neck of the ship.

The body of the ship is 132 meters tip to tail and the engines extending out behind it add another 12 meters to the length for an overall height of 144 meters.

Printing

The final step was to print the model and see how it turned out.  Since I’m printing these at 1/3000 scale (i.e. substitute millimeters for meters and divide by three), the model ends up being 48 mm tall or just under 2 inches.

Amazingly, the printing went off without a hitch.  I printed it with supports and a raft as it would need the support under the raised fuselage and the raft helps keep it on the print bed.  Both the supports and the raft came off without a problem.

Unfortunately, I don’t have a good picture of the unpainted model at the moment.  I had taken some but they are all blurry and you can’t see any of the details.  I’ll post actual pictures when I do the next post on painting this model.

Until then feel free to comment below.


Writing Doldrums

dol·drums
/ˈdōldrəmz,ˈdäldrəmz/
noun
plural noun: doldrums
a state or period of inactivity, stagnation, or depression.

This has been me and writing recently.  Okay, not the depression part, just the inactivity and stagnation.

The truth is that it’s really a time management issue.  I actually have lots of great ideas I want to write about, I just don’t seem to find the time to actually do the writing (hence this short, and later than usual, post today).  However, this should be changing.

Happy Camping ArcheryLast semester was pretty grueling but it’s now over and my next class doesn’t start until the second week in June.  And that class should be much easier with less writing as it is a web development class.  In the mean time, I have my mornings free so the time was I was doing class work can be devoted to writing.  Plus, during the first and last weeks of June, I’m chaperoning two youth campouts for my church.  The young women (my wife is one of the advisors for that group) are going on a 4 day camp at the beginning of the month, and the scouts (2 of my boys are working on their eagles) are going for a 3 day camp at the end of the month.  For the most part, I just need to be there, I’m not involved in conducting or running any activities soI’m planning on using that time to relax and get a bunch of writing done.

So look for more of my 3D printing articles as well as more of my “Designing Out Loud” series.  I’ve still got quite a number of models to describe (and I need to paint them as well) and have several thoughts stewing around in my head for my game design.  I just got a jump start in that area from Shane Winter who just sent me his home brew version of a revamped Star Frontiers rule set that he’s working on (which reminds me I need to send him my comments).

The other thing I’ll be working on is the sequel to my first book, Discovery.  This has been stewing around in my brain for a while and I need to get it out and on paper.  I might talk a little bit about some of the content here and there or I may not.  We’ll see what happens.

In any case, I’m looking forward to a summer of writing and more substantial blog posts starting with next week’s entry.


Hard sci-fi, realism, & consistency

I’ve been thinking a lot recently about what I like in my RPGs.  For those of you who have been reading my posts, it probably looks like I prefer science fiction to fantasy.  And it’s probably true, I definitely lean that direction and given my background (BS Physics, MS & PhD Astronomy, work as a software developer) it’s probably not surprising.  Now I love a good fantasy book, movie, or game just like the next guy.  In fact, the best game I ever played in was a fantasy game (although with some sci-fi overtones/backstory, but the game itself was wizards, warriors, priests, and rogues).  It’s just that science fiction is closer to my heart and is where I’m spending my limited free time right now.  So I’m going to be talking about science fiction in this post.

Hard vs Soft

When I first started thinking about the topic of “what I like” the hard vs. soft dichotomy was the first thing that came to mind.   When people talk about science fiction games, the topic of hard verses soft sci-fi often comes up and they like to classify the games as such.  I get the feeling that these definitions (or at least their interpretations) are very subjective as I have often seen different people describe the exact same system as both soft and hard sci-fi.  So I guess I’d better begin with what I mean

Hard science fiction

To me hard science fiction is more science than fiction.  It stays close to what we know about the laws of physics.  It doesn’t seem too far removed from our current day technology.  Sure there are things like faster than light (FTL) travel, laser guns, lots of spaceships, and possibly aliens, but mostly things are as we know it.

Soft science fiction

If I think of hard science fiction as more science than fiction, then I guess soft is more fiction than science.  Things like artificial gravity, “the force”, jumping halfway across a galaxy without batting an eye, and other such “magical” technologies.

And I guess that if that was the division, I’m probably in the hard sci-fi camp.  However, as I was thinking about it, I realized that wasn’t really what defines it for me.  Which brought me to thinking about

Realism

There is a sliding scale about how “realistic” a game or setting is.  There are personal tastes all along the spectrum.  For me this comes in two flavors.

The first type of realism kind of goes back to the hard sci-fi idea in that it asks, how realistic, or close to modern technology (or a reasonable extrapolation thereof) is the game/setting.  The closer it is, the more realistic.  And I definitely lean toward games that are more “realistic” in this sense.

The other kind of realism might be labeled simulationism for simulationist or something along those lines and refers to how realistically the rules simulate reality or represent how things would “really” work if you were to experience them in person.  This covers things like how long things take to accomplish, diversity/number of skills and how they apply, how deadly weapons are, encumbrance, etc.  At some level this is the crunchiness of the system but it’s possible for crunchy systems to be unrealistic (In which case, they’re just complicated as far as I’m concerned).  I’m definitely in favor of this type of realism as well.  And I’ll have to admit, I’ve never actually met a game that I feel was too crunchy.  But that may just be because of my math and science background and the calculations and such that typically accompany a crunchy system don’t bother me.

But as I reflected on this more I realized that really wasn’t what I was exactly trying to put my finger on either.  Which brought me to my final point:

Internal consistency

In the end, I think this is what I’m really looking for.  Does the game/setting make sense?  If you have a technology, have all the implications been explored?  If there are things you would expect to be possible because of a technology but you can’t do it, is there a good reason why?  If there are limitations, are they reasonable or just arbitrarily imposed because the designer didn’t want that to happen?

When it comes down to it I’m just a logically minded person and I think what I really look for is logical consistency.   For me that internal consistency and “making sense” trumps everything else.  I think my preferences for “hard” sci-fi and realism flow into that as the more things are on that side of the spectrum, the more likely they are to be consistent.

And that probably also why I like to tinker with my games and am starting to write my own.  I love Star Frontiers but anyone who’s spent any time in that game knows there are a few logic holes and things that just don’t make sense and weren’t completely thought out (not to mention orthogonal descriptions of some things in different places).  I think what I’m really trying to do is fix those issues.

What about you?  What do you look for in your games?  What do you like in your favorite games that attracts you to them?  Sound off in the comments below.