Since the last post, I’ve been working on a lot of framework stuff. All of it is directly in support of the content for the next release, but until now, it hadn’t all come together in a way that would make it easy to demonstrate. Now, though, there’s a good vertical slice to talk about; a new piece of content that uses many of the new pieces – the comm relay.

We’ve talked about events and information gathering in the previous blog post, and that’s where comm relays come in. You need to be in a star system with one to receive news reports and other kinds of intel. Here’s what one looks like in-game:

 

If you’re saying to yourself, “hey, this looks familiar”, you’re right. It’s the same graphic that was used for comm relays in battle. I say “was” because those, along with the rest of the objectives, now have new graphics that are more consistent with something that might get deployed from a ship, which the battle objectives conceptually are.

Interactions
Now, let’s see what happens when you approach one.

(Kindly ignore the illustration being a vaccum habitat, for now.)

Installing a comm sniffer on a relay is a great way to get more info about local events, but it’s not without risks.

A progress bar! Shiny, and a new interaction mechanic to boot. The same type of interaction could easily be used to, say, survey a planet or search a derelict for valuable technology. The wait can be interrupted by moving away, interacting with the comm relay again and choosing to abort the installation, or being attacked.

Speaking of being attacked:

Whew, dodged a bullet there. Trying the same stunt again would produce a different reaction – unless you’re lucky enough to be intercepted by a different Hegemony force, one that’s not aware you’ve been caught doing this before.

Mechanics
Now, let’s take a quick look at the various systems that all interact to make comm relays work.

• Event reporting – to have actual news being sent across the Sector using relays
• Intel gathering – extra insight into events that can be gained by tampering with the relays
• “Wait for task to complete” mechanic
• Custom dialog for entities – the entire player interaction with the relay is implemented in a general way, meaning other types of similar interactions will be easier to add
• Conversations with NPCs, NPC/entity memory

The comm relay implementation was a test use case for most of these systems. The goal was to turn adding these kinds of interactions from a “coding” task into a “content creation” task.

For example, the conversation with a patrol commander interrupting your hacking attempt could be driven by a bunch of code, with conditional statements governing when a particular line gets said. Instead, it’s data in a spreadsheet, including the logic that drives the conversation. (For that matter, the entire interaction with the comm relay is implemented this way.)

The difference may be subtle (“all code is data” vs “all data is code” – as far as I’m concerned, both perspectives are valid), but it’s an approach that makes it a lot easier to go back and make changes, or to add new content incrementally. Why is that?

If what you’re doing is fundamentally code, the flexibility is both a blessing and a curse. You can do anything! Which probably means you did something very clever a long time ago (and probably felt all smart about it at the time), but if you need to go back and change that code, you’ll have to figure out all that clever stuff – while feeling considerably less smart.

On the other hand, if what you’re doing is data-driven, the restrictions on its structure make it easier to go back re-immerse yourself in what you were doing, never mind making it easier if you’re not the one that put it together in the first place. Basically, there are less ways for prior work to blindside you.

So, this is something that was important to work out, and I’m looking forward to adding more features using these same pieces.

Comment thread here.

 

Tags: comm relay, comm sniffer, conversation, events, intel