Category: RPGs

Roleplaying games

[Mothership] THOUSAND EMPTY LIGHT – a full playthrough

Hello again, I made a thing! I have been interested in the Mothership scifi rpg for a while, and I chanced upon a solo scenario for it by Alfred Valley called Thousand Empty Light. This was a revelation to me in a couple of ways – first, although I played roleplaying games for a good couple of decades of my life, I was completely unaware of the concept of playing them solo (beyond a ‘choose your own adventure’ book anyway). Second because it is just so well put together. It’s presented as a company document instructing a “Lamplighter” (that’s you) who has to enter an underwater facility beneath an alien ocean and turn the power back on there – and since this is designed with Mothership in mind of course there’s something horrible down there. On top of that though there are codes to crack, secrets to find, and all sorts of hidden goodies to track down. You can check it out (and buy a copy) from Alfred Valley’s itch.io page and I heartily recommend that you do (I would also recommend the accompanying soundtrack “Sleeping in a Drowning Stone”, which is also available from there and served as excellent background music while I was writing).

The general idea with solo RPGs is that you’re given a framework of a setting to work in, and you explore it by asking questions that have a yes/no answer (e.g. “can I see any tools here” or “does the creature look hostile” etc). Then you roll dice and consult an “Oracle” which is a table that has “no”, “no but…”, “yes but” and “yes…” answers along with some prompts to help you describe the scene – e.g. if you asked “can I see any tools here” and rolled a “yes but” then you may see some but they’re in a locked cabinet that you’d need to break into. And then you fill out what happens to move the story forward and move on to the next situation, and repeat as required. In this specific scenario you’d use the Mothership rpg system to resolve things like skill checks, saves, and combat as well.

Now, I’ll be the first to say I probably didn’t do everything “right” here but then maybe there isn’t really a “right” way beyond just having fun with it, and I certainly did enjoy the experience. First I tried gathering some binary keys from Alfred’s site and the internet in order to tackle some of the binary codebreaking, and one of the prompts there gave me an idea. Then I started playing through and writing it up the thoughts of the lamplighter as a “journal” from the perspective of the character (I ended up writing over 11,000 words, which is the most I’ve written for anything in a very long time so I think I can safely say that I did get into it!). I started off just using the Oracle and taking whatever it said literally so things begin a little strangely, but as I went along I started using it less for the descriptive prompts and more for the yes/no answers, and then by the last couple of sections I had formed a good idea about where everything was going so I pretty much freeformed the rest of it (about halfway through I managed to decode/find all the secrets in the book too so that caused the story to evolve a little differently that I initially intended too). I’m pretty sure one could just use the Oracle as prompts for creative writing in general too. I should also add that this isn’t the only way to play solo RPGs – Mothership is actually intended to be a multiplayer RPG but there are plenty of dedicated solo RPGs out there now (I’ve bought a few of them but haven’t had a chance to look at them yet, but hopefully I’ll write something about those here later).

I think I’ve come up with something good here anyway – so without further ado, here is my playthrough of Thousand Empty Light! Let me know what you think! πŸ™‚


THOUSAND EMPTY LIGHT – a full playthrough

arrival on UPB 154

UPB 154 was a grey, bleak, forbidding world coming in on the shuttle, and it’s a gray, bleak, forbidding world now I’m on the β€œground” too. I say that in quotes because there is no actual ground here, just a creaking metal platform hammered by the winds and rain and spray of this godforsaken planet. Barring a few barren rocks poking above the surface, the entire planet is covered by a corrosively salty ocean and an unbroken layer of thick grey clouds above that. The wind gusts and howls, the waves crash on the caisson, and the rains lash me mercilessly as I stand on the platform watching the shuttle depart. I hate this place already.

Continue reading

[Battletech] Advanced Rules: Realistic Mech Movement

In my last post I showed how most Battlemechs couldn’t actually walk as fast as described in the game – if you missed that then you can read it at How fast can a Battlemech walk?. In this post I will present some optional Advanced Rules to implement the more realistic mech movement described there.

This is what I’m setting out to achieve here:

– Mechs now walk, run, and sprint at realistic speeds.
– Where possible, movement rates should be as consistent as possible with their current stats. That said, the fastest mechs must be slower here because it’s now impossible for them to be as fast as they were – this means they will have smaller engines and more space for equipment.
– It must be possible to design mechs so that their engine ratings (and gyros) are comparable with published designs.
– MASC, Superchargers and TSM will have a similar effect on speed as in the existing rules.
Continue reading

[Battletech] How fast can a Battlemech walk?

A good demonstration of how a Locust doesn’t walk! πŸ™‚

Or: “Can a Locust Battlemech really walk 240m in only 10 seconds?”

The answer, perhaps surprisingly, is “no, it can’t” – a Locust (or indeed any battlemech) could run that far in that time… but it is actually physically impossible for it to walk 240m in 10 seconds (at least in gravity similar to Earth’s). To discover why, we must take a rather fascinating scientific journey that sheds some light on something that perhaps many of us take for granted – the mechanics of how we move on two legs! Read on to learn more…
Continue reading

[Battletech] Revisiting the Mech Record Sheets

You hear the distant boom of an Autocannon echoing across the landscape and your mech shudders at the shell impacts against its left torso, blasting off some of the armour plating. It’s not enough to significantly damage your mech, but certainly enough to get your attention as you scan for your attacker and raise your arm-mounted PPC to respond…

And so the player peers at their Mech Record Sheet, and marks off five points of damage on the Left Torso:

five damage marked on the left torso on a normal record sheet
Just your normal everyday record sheet.

But something’s funny here, to me at least. The way I see it, the side marked “Left Torso” is actually shown on the right side of the mech (it’s the player’s left side, but not the mech’s left side)! This has bugged me since I first started playing Battletech back in the 80s, and now I’ve started playing again I was reminded of it once again so I thought I’d dig into this a little further.
Continue reading

[Battletech] Realistic gravity-based Jump Point Distances

I’ve got back into Battletech recently and I’ve been trying to reverse-engineer how the Proximity Limit is calculated (because I like to know how these things work). First, here’s a little background if you’re unaware of how jump works in Battletech. According to the fluff, Jumpships use a “Kearny-Fuchida drive” to travel over interstellar distances almost instantaneously. Traditionally they arrive at the Zenith/Nadir points – above the north and south poles of a star respectively – at the Proximity Limit, which is (supposedly) determined by the gravitational field of the star. These Jumpships usually carry Dropships, which then detach from the Jumpship with their cargo of mechs and head towards their target planet using normal fusion drives. Meanwhile, the Jumpship (which has little more than a few manoeuvering thrusters) generally sits at the arrival point and unfurls a large solar sail about a kilometre in diameter that it uses to recharge its drive in readiness for the next jump, which usually takes around a week (150-200 hrs).

After looking at the latest version of the stellar data table on pg. 100 of Campaign Ops, and I made an interesting observation: the Proximity Limit is not based on gravity. Given all the fluff says that this distance is determined by gravity (e.g. the notes on pg. 122 of Strategic Ops, summarised as “hyperspace fields don’t like gravity”) this is somewhat surprising. It turns out I’m not actually the first to notice this either – a thread on the battletech forums from over a decade ago discusses this too, but no solution to this is presented there. So I wondered – what would it look like if the Proximity Limit was calculated using gravity?

If you just want to skip to the point – here’s the gravity-based Safe Jump Distance table that you can use in your Battletech games instead of the published ones (this is just intended as a variant to use if you want more realistic values):

Table showing recalculated gravity-based Safe Jump Distance values.

If you want to know the technical details behind how I calculated this then read on…
Continue reading

[2300AD] Pushing the Stutterwarp Drive

extended_range

While I was looking at the side branches of the French Arm (I’m still working on it!), I found a group of systems that were 7.769ly from the nearest star on one of the side branches. Which got me to wonder – what happens if a system in the 2300AD setting is slightly over 7.7 ly away – between 7.7 to 7.8ly? Can people still reach it without tugs or multiple drives/tuning? Do they have to “push the drive” even for such a small increment?

Let’s have a look at how “pushing the drive” really works (using the MGT rules). The rules say: “Pushing a stutterwarp drive past its discharge limit: 1–6 hours, Very Difficult, range increased by Effect x10%.” So when do you start “pushing the drive”? I’d guess no later than 6 hours before it gets to 7.7 ly (otherwise you wouldn’t be able to finish before hitting the limit).

Getting into the nitty-gritty of the game engine, I guess theoretically an engineer could spend a lot of time on it (reduce by two timesteps to 10-60 hours – so break out the coffee and stims!) to knock the DM penalty from DM-4 to DM-2. I’d imagine most engineers would have skill level 2-3 (DM +2 or +3), and Int or Edu of at least 9-11 (DM+1) – let’s just say that a competent engineer should be able to get a DM+4 between their skill and characteristic. So if they spend 10-60 hrs on it they’d be rolling 2d6 against difficulty 8 with a net DM of +2, which would give them a 72% chance of success. Though granted, it’s unlikely they’d be able to do the task for 10-60 hours (on their own at least) – at worst I think they’d just do it at Very Difficult with 1-6 hours and have all the DMs cancel out for a 42% chance of success. It seems to me that a competent engineer could reasonably be willing to spend at least 6-24 hours to push the drive to get a 58% chance of success with no possibility of destroying the ship (though there’s still a 42% chance that he’ll destroy the drive, so it’s probably not something that would be tried regularly).

Exceptional Failure only occurs if the Effect is -6 or less (I think that’s what the rules mean – not less than -6, since -6 isn’t on the table otherwise), so they’d only have a 2.8% chance of exploding the ship if they didn’t take more time to do it (Very difficult, no DMs, 8+ required) – otherwise Exceptional Failures can’t happen if there are net positive DMs. Though Average or Marginal Failures still at least disable the drive (I’d imagine the drive would just explode but not necessarily destroy the ship with it, and the the ship would suddenly drop out of stutterwarp).

If the roll succeeds, then there’s a decent chance that the range is increased by 10-30% (the chance is lower for the 40-60% increase, since that would require bigger effect – though spending longer on the roll would make those more likely) – so theoretically a drive has a reasonable chance of being pushed to 10.01 lightyears (maybe up to 12.32 ly if the engineer is very good and very lucky)!

So the question really is whether all this is even necessary to go slightly over 7.700 ly. If it is, then I guess it’s not going to be very likely that anyone would want to be regularly heading out to systems that are even 7.71 – 7.80 lightyears away since there’s a significant chance the drive would be destroyed/rendered inoperative (even though it’s at most about 1-2% further in range). Maybe risk-taking explorers would do it, but it wouldn’t be a regular route. Or maybe a 1-2% range increase is OK, but the drive MUST be checked over/recalibrated/retuned at the destination (after discharging) before it can be reused? I’d be more inclined to go with the latter option – it adds possibilities and doesn’t seem unreasonable.

Extending the drive range

There are at least three options (possibly more) to increase the range of the drive:
Continue reading

[2300AD] The complete 2300AD Near Star List!

Now that my website is settled in its new home, I can finally start a new 2300AD project here. This time I’ll be moving on from the 2300AD Realistic Star Maps and going back to the original Near Star List!

Kafer space
Kafer Space (from the Kafer Sourcebook).

The first thing to do is to make the data available. I’ve transferred the original NSL (oNSL) table from 2300AD into digital form and incorporated the extra data for Kafer Space from the GDW Kafer Sourcebook – and as an added bonus I’ve also thrown in the Backdoor system from Operation Backdoor that allowed the humans to contact the Ylii (Operation Backdoor may or may not be official canon, but I’m throwing it in anyway) :). This represents all the xyz data for the stars that was originally provided by GDW.

The xyz data is presented here as they were in the Near Star Lists – I haven’t rotated or recalculated anything, I’ve just transcribed them (though I have reordered some of the stars in the list to be consecutive to their companions for clarity). The list itself is in a CSV format that can be imported into Astrosynthesis, and the canonical arms are also provided in that format – the Backdoor route is also there. Keep in mind that this is not consistent with the Realistic Near Star Map that I’ve produced on this website (IIRC the coordinates may be flipped on the realistic map too) – but it’s all internally consistent at least.

The oNSL stars are listed with a Catalogue Number (Cat_no) between #230001 and #230749, the Kafer Sourcebook stars are #230750 to #230787, and the Backdoor brown dwarf system is #230788. So if you only want to use the oNSL stars you can ignore or remove the stars from 230750 and up (or just use the 2300AD_original_oNSL.csv in the zipfile below).

While there are some real stars in Kafer space in the oNSL (e.g. Gamma and Lambda Serpentis), the Kafer stars and the Backdoor system listed between #230750-#230788 are entirely fictional. Almost all of these fictional stars are within 7.7 ly of other stars (as shown in the screencap above), which means that there are no “dead ends” in Kafer Space – this is quite unlike the distribution of real stars in the oNSL (I would imagine that this was a design oversight when the new stars were being added – realistically I think the stars should be more spread out, with more being inaccessible).

You can download the CSV data from the link below. As usual, please don’t redistribute these files yourself – just link back to this page if you want to spread the word! The zipfile contains the following:
2300AD_original_Kafer+oNSL.csv (the full oNSL+Kafer Sourcebook xyz, cat_no, name and startype data table),
2300AD_original_oNSL.csv (just the oNSL data),
– The French, American, and Chinese Arms in a csv format that can be imported into Astrosynthesis,
– the original_2300AD_NSL+Kafer.AstroDB file that can be opened in Astrosynthesis.

Next time, we’ll start exploring some of the lesser known side branches of the original 2300AD near star map!

 

Copyright stuff: The 2300 AD game in all forms is owned by Far Future Enterprises. Copyright 1986 – 2016 Far Future Enterprises. 2300 AD is a registered trademark of Far Future Enterprises. Far Future permits web sites and fanzines for this game, provided it contains this notice, that Far Future is notified, and subject to a withdrawal of permission on 90 days notice. The contents of this site are for personal, non-commercial use only. Any use of Far Future Enterprises’s copyrighted material or trademarks anywhere on this web site and its files should not be viewed as a challenge to those copyrights or trademarks. In addition, any program/articles/file on this site cannot be republished or distributed without the consent of the author who contributed it.