20
\$\begingroup\$

On occasion, I've had reason to describe obviously fictional technical processes in-character. I'd like to be able to describe on these occasions without sounding like I'm saying utter gibberish. But it's not straightforward to do, particularly if I have to make stuff up on the spot.

How do I do it?

\$\endgroup\$
1

3 Answers 3

21
\$\begingroup\$

Before you even get to the point where you need to start talking technical, it's worth taking some time to head off that sort of necessity in the first place. Often this won't be possible, it's worth trying to focus the scene around character interactions rather than the technology being used. That should head off many of the dangers of sounding off when making up technological phrases and words.

But if you do find yourself in a situation where it's necessary, here's the core of what you should do.

  1. Avoid having to actually describe abstract processes in-character. If you're in such a situation, gloss over as much of what your character is doing as possible. You can do that fairly easily by limiting things to actions that are easy to understand, or honestly even just saying "yay! we did it!" Consider the following two examples:

    Michelle: "Give me a moment, I'm going to set up the field generator."
    Lars: "Sweet, you need any help?"

    possible lines:
    Michelle: "Nah, I'm just gonna rejigger a couple things and we're good."
    Michelle: "Yeah, can you flip that switch over there?"

    Compare with:

    Michelle: "Give me a moment, I'm going to set up the field generator."
    Lars: "Sweet, you need any help?"
    Michelle: "Yeah, can you realign the beryllium sphere to point west?"
    Lars: "Alright, I did that, but the quantum phase detractors are desynchronizing."
    Michelle: "Oh, shoot, I'm going to reset the power field wave generator, one moment!"

    etc. etc. There's a hidden trap here: the latter scene might seem or feel more interactive, but in reality, neither player really has any understanding of what's going on - they're both going through the motions of "do some stuff, then some stuff happens." If there's a critical point in character, skip to it. Don't dawdle.

  2. Go as far as you can with real (or already-established) terminology. This is going to depend on your level of knowledge, and the level everyone else is playing at, but the further you go using real words that describe real processes, the more realistic (go figure) your end result is going to sound. This requires a bit of thought and work, and can be hard to do on the spot, but it's a good place to start overall. Don't make up something new to describe something that can already plausibly be done.

    Also, if you've already introduced new terminology for a process or method, you're welcome to include it here. If everyone's already agreed on which words mean what, that's fine, and counts as established terminology.

  3. Plan and introduce in advance. If the details of some technology, method, or process are going to become relevant (instead of just accepting that the process exists), it's worth fleshing out in a bit more detail in advance. Why? If you can establish new terms and words, then you can follow the above advice and keep people more engaged in the scene. They'll understand what's going on if they have a better sense of what needs to happen.

  4. Be sparse. Even if you're doing both of the above, don't use too many technical words at once. When too many technical terms and phrases make their way into roleplaying, it starts to sound like a joke.

    "We need to realign the quantum nuclear crystals in the phase detractors of the wave generator to establish warp uplink! Hurry!"

    Instead, consider:

    Michelle: "Hey, can you reset the whatzit over there? Wave generator's giving me problems."

    Notice that "quantum nuclear crystals" and "phase detractor" can be compressed into "whatzit" at no cost, and "establish warp uplink" can be left sort of... implied, probably by context.

  5. Be internally consistent. If you're going to use real words to describe fictional processes, only combine words if they have a good a priori reason to be together. As an example, "the power grid is undergoing hydrostatic overload!" While it makes intuitive sense that a power grid can be overloaded... hydrostatic isn't exactly a great choice of words. Even if we're talking about a hydroelectric plant, hydrostatic is still not the correct choice of words.

    It's true that this requires some baseline familiarity with what words mean, but if you're going to be making up technological stuff, that's not exactly a bad thing. Getting some familiarity with the terms you want to use in advance will allow you to select better ones on the spot.

  6. Be generally minimalist. Real Science (TM) doesn't use very many new words to describe ideas. A new word or phrase is usually added only when there's something very new to describe - otherwise, old words tend to be efficient. Any given problem or process is only liable to use a handful of words, and going beyond just a few technical terms is going to make it seem a little fake.

The tl;dr of the above boils down to this: it doesn't really matter what you pick, given that a) you don't pick too many words, and b) the words you pick are reasonably relevant. What I wrote above is long, but it's long because tech talk in a role-playing game is hard to do well. That's why I really recommend that you avoid it if you can, and if you must, establish in advance as much as possible.

\$\endgroup\$
3
  • 10
    \$\begingroup\$ #5 (Be internally consistent) is also utterly essential if you're running with people who are actually in a technical field. We're very used to not being familiar with what someone in another field is saying, but we'll sniff out inconsistent terminology in a heartbeat. It's just a skill we have! \$\endgroup\$
    – Cort Ammon
    Commented Nov 28, 2016 at 3:29
  • 7
    \$\begingroup\$ I'll just add to this excellent answer that I work in a real-life dev environment, and although people could use technical vocabulary all day long, it's not in human nature to do so unless there's a real reason to be so specific. So we will instead give status reports in a high-level way: "Did you fix the problem with the matrix generator?" "Yeah, we made a few tweaks, it should be stable." It's convenient shorthand for details that aren't actually required except by a few specialists and would take far too long to explain for the purpose of most situations. \$\endgroup\$
    – flith
    Commented Nov 28, 2016 at 7:18
  • \$\begingroup\$ To insist on @flith's remark: you probably use your "portable telephone" or "smartphone" everyday; you likely call it "phone" or "mobile". \$\endgroup\$ Commented Nov 28, 2016 at 9:40
8
\$\begingroup\$

There is no shame in describing some aspects of a scene at a slightly higher level of abstraction than other aspects. This is not a matter of replacing specific jargon (flux capacitors) with generic jargon (whosawhatses).

Rather, I mean one of the following:

  1. Refer to systems by their functions, rather than parts by their names. So don't have your characters trying to fumble their way through the fake intricacies of flux capacitor chrono-magnetometer couplings, just say that the time-drive isn't interfacing well with the temporal navigation system '... and by God, we could end up any-when!" This avoids having to remember fake names for things, and reinforces what the actual plot-related effects are. You can always have a fake object if you need a repair-macguffin for a session or an adventure, but I would be hesitant to make much greater use of jargon.

  2. You just simply don't need to engage in detailed blow-by-blow word for word conversations all of the time. In many instances, you can handwave with, "You and the NPC spend some time talking about the time drive, and what it boils down to is...." I often treat technobabble like haggling scenes-- get it over with as abstractly and quickly as possible.

The places where these may not work is if a game really needs a detailed understanding of some concept in order to proceed, for instance, in order for the players to have agency. But in that hypothetical time travel game, it seems more likely to revolve around the plot-related effects and limitations of time travel (when can you go, how hard is it, how does paradox work) than in the hardware to achieve it.

\$\endgroup\$
0
\$\begingroup\$

This is a situation where pulling up episodes of Star Trek will come in quite handy. Pretty much every episode of Star Trek ever made is full of lines of dialog where engineers or bridge officers are spouting off endless lines of technobabble and make it sound at least somewhat plausible and realistic. Copy down a bunch of these lines into a list and just pick one at random from the list as needed to fulfill the current need.

There are also a number of great sources across the web that highlight some of the better exchanges such as this thread on Reddit and this forum thread on TrekBBS

\$\endgroup\$

You must log in to answer this question.