Building a Dynamic Hub

Part two in a weekly(?) devlog.

Map creation continued this week. I spent a lot of time focusing on the hub, the main map where the player character returns between missions to recuperate, upgrade, chat with companions, and advance the plot. Players will visit most maps once, and a couple of maps twice, but will see the hub many times during the game. So, I felt like time spent polishing it would be especially well-spent, and I also wanted to maintain the player's interest in it over the course of the game.

In a previous post-mortem, I'd noted a somewhat failed experiment back with Corona, the third part of Antumbra Saga. I'd put a lot of thought and effort into dynamic updates for your base at Redding Old City Hall, building a fairly complex and integrated system that caused the base to shift over time in response to your player's decisions. I was nonplussed by the lack of a response, and belatedly realized that it was because there was no in-game explanation of how the player's actions were affecting the environment. In Caldecott, I had a much less dynamic map, but much more explicit linkages: for example, if you rescued the dogs from the basement in the Gauntlet, then the dogs would show up in the Halferville slums, and a dwarf child there would explain that these were the same dogs from before and they're here because of what you did. I'd worried that it was over-explaining, but it seems to have done the trick, and I've gotten multiple nice comments from people who appreciated seeing that outcome.

For my new campaign (tentative title: "CalFree in Chains"), there are a variety of ways the hub can shift over time. Some occur as a result of the player's choices, some reflect the player's story, and some are essentially random. A few will be obvious, others less so, and I hope some players will feel a little delight at discovering some of the more hidden ones. There's also a subtle character-development dimension to this. One of my overarching goals for this campaign is to help the player feel like a member of the community and invested in its well-being. Not a murderhobo who runs for profit alone, but someone who has a stake in the outcome. I personally really liked how HBS handled this with the Berlin Flux State in Dragonfall, which felt more like a "home" than Heoi or the Seamstresses Union did.

So, for this post, I'd like to talk about one particular dynamic feature: the player's personal room. You have your own bedroom, where you'll typically appear after loading the scene; this suggests that some time has passed since returning from the mission and you're waking up, ready to start the next day. The basic contours of the bedroom stay the same: the bed, the trideo station, the kitchen, etc. But specific features will vary to reflect your character's build. Are you a gun-toting street samurai? You'll see display cases up on the walls showcasing your arsenal. Are you a mystic mage? Expect to see some arcane paraphernalia like crystal balls. Or maybe you're a rigger? You might find a spare drone or two lurking around.

I'd initially thought of just doing this based on the player's archetype, but once I started scripting the feature, I realized it would be more fun to update the environment based on the player's current skills. That means that, for example, if your player starts out as a rigger they'll see some drones, and if they later branch out into decking then they'll see some additional tech equipment. It also allows me to, in some cases, provide an upgrade path as their skill level increases. For example, shamans will have a shrine in their bedroom; as their skill in conjuring or spirit summoning grows, the shrine will become more impressive.

Enough words, time for pictures! Here's what the bedroom currently looks like in the editor:

Oh! I should have said this back in the previous post, but: standard development disclaimers apply. This is pre-pre-pre-Alpha content, everything is subject to change, features may not be present in the final version, there's a very strong chance none of this will ever be released, etc. etc.

Some technical notes on how to script this system:

There are three possible ways to change the elements in a map. First is "Move Prop", where you can pull an item into the map where the player can see it, or pull it back out to a hidden location. The main downside with this approach is that you can only use it for specific props which have set an interaction, and cannot easily apply it to a group of related props.

Next is "delete prop", which removes one or more prop that you don't need. This does offer a "delete by tag" version, which allows you to quickly and easily eliminate a large group of related props. But it's a one-way street; there is no "create prop" trigger to bring them back.

Finally is "set prop visibility", which can make a prop appear or disappear. This includes a tagged version and is reversible, so it's useful if you want things to appear and disappear in the same scene. Note that, when you make a prop invisible, you essentially remove it from the map; this means, for example, that it can be used to remove barriers and allow players to move through those areas.

In this particular case, I'll be using "delete prop". I just need to update the environment when the map first loads, not make in-scene changes. You'll notice that the above screenshot looks really messy. That's because every possible prop is placed. Once the scene actually runs, I'll figure out which ones should remain visible and which need to be deleted. Here's what one of the triggers to do that looks like.

You may notice that this trigger is set to "On Map Start" (When CONTINUE is pressed) rather than "On Map Setup" (While map is being initialized). That is a little unfortunate: "On Map Start" runs AFTER the player clicks "Continue" on the loading screen, so if I'm doing a lot of work here, it will feel sluggish. However, the player character's stats have not loaded yet during "On Map Start", so I need to run this later. Based on my testing so far, it seems to be acceptably fast (and it doesn't affect the total loading time, just when it occurs). If this does feel pokey in the future, I could work around this by loading the player's stats into global variables, and then checking those variables during map setup.

Here are a couple of in-game screenshots from different characters at different points in their careers.

 

 

The overall room looks very similar in all of them, but observant players will notice a few minor features of their environment changing to reflect their character's advancement.

So, yeah! I'm pretty happy with how this is looking and working so far. It makes absolutely no difference whatsoever to the gameplay dimension of this campaign, but I think it's a nice bit of atmosphere that helps accomplish my narrative goals and makes the player feel recognized for how they're constructing their character.