This list seems to suggest that the situation is rather binary. Every outcome except the last one on the list produces miserable to catastrophic failure, with absolutely no usable results.
Social Combat Flow
dcfedor
onSeptember 10, 2019
Hey Folks! More work on the social combat UI today. This time, getting it to respond to user input and start closing the loop.
As you can see in today's screenshot, it's now listing all available interactions in the lower left, and selecting one updates the preview area. Right now, I've got it setup like a radio button. Choosing one deselects all others, so we only click one at a time.
In NEO Scavenger, it was setup such that you could add zero or more items before confirming. And sometimes, choosing more than one input changed the outcome.
However, I'm not sure if that was the best approach. There was a lot of opportunity for wasted effort on the user's part, as they were left to try all the combos and see if anything happened. I think a number of players appreciated a few of the cases where it rewarded them, but probably not enough to warrant having it work that way. (I originally wanted the game to respond uniquely to whatever the player chose, but that rapidly became too complex to manage.)
Here, I think we can basically list all possible avenues, and just let the player choose the one they want. If a choice can be amplified by a skill or item, let's just make that a new choice.
Once a choice is confirmed, the game unpauses, with this UI still active, and we see the message log update, the avatars animate and show thought bubbles, until one of two things happen:
1 - The interaction ends with no further options, at which point the UI closes and game resumes.
2 - The player has a new choice of actions, and the game pauses while player thinks.
This mostly works now as-is. But there are still things I want to add.
First, I want the target's portrait to only show conditions we know about. And to gradually reveal those through interactions. Like an interrogation scene. And similar to NEO Scavenger, I want this to be focused a lot on getting your counterpart's defenses down before attacking, so to speak. If you need a favor from them, don't ask if they're in a bad mood. Improve their mood first.
There might also be some way to integrate a context or subject into the mix here. Like if we're giving them an item, we'd need a way to choose the action "give item" and then the item we want to give.
Or disciplining crew for their actions, we'd ideally be able to choose "discipline" as an action, and a menu would appear to let us choose "insubordination" or "stealing" or something. To make the NPC's AI aware of the consequences of that action. (This sort of ties into an ongoing task on our schedule for making AI's remember incidents and events.)
The content for these interactions is also going to require some updating and tweaking, in light of this new UI. Some of them only work well if non-interactive, and we just read the results. They need refinement to support player interactivity as they progress. Things like user-friendly title text, or a wider range of options.
Finally, there may be a more general need to spawn additional UI while in this mode. Something like a hiring UI, or trade UI. How that UI interacts with the social combat one is to be determined, but we may need to temporarily go to the new UI and come back here when done.
And last, but not least, what happens when social combat evolves into physical combat? What if we throw a punch? Or pull a gun? Not a small problem to solve!
Lighting Upgrades, Interactive Career History, Job System, and New Art!
Hey Folks!
I'm waaay past due for another video, so here's what we've been up to!
So what's new?
We've got a new lighting renderer, choose-your-own-adventure character generation, AI job management system, and as always, new art!
New Lighting, CYOA Chargen, Crew Jobs, and New Art
In this video, we try out the new AI job management system, haul some loot, demo some walls. We also take a tour of Chris's latest work on the improved lighting system. The career generation process shows a new interactive feature. And last, but not least, Charlie's latest concept art!
If this sounds interesting to you, please wishlist Ostranauts on Steam here. Wishlisting it will give me an idea how much interest there is in this game, and how much time I can spend on it.
And if you know anyone else who might dig this type of game, let them know! Spreading awareness is something everyone can do to help me continue to make games like this.
Thanks for your time, and stay tuned for more spacelife news!
Saturday
Functioning Doors, and Crate Room
Hey Folks! Some pieces coming together nicely since yesterday. We have a new crate room for testing locks, and locked doors are now working!
Today's screenshot shows Michael's CrateRoom ship, which we're using to test these latest salvage actions. It consists of a central room with a crowbar on the floor, and doors leading to other rooms for testing.
The left door is powered and unlocked, so can be opened by normal means. And Michael was able to hook-up the data such that we can use the crowbar to pry open the locked crate! No way to access its contents yet, which might be our next big hurdle: inventory management.
Also, Michael couldn't resist a little bit of environmental storytelling, and added a "carelessly tossed trenchers packet" in a back hallway
The other doors cover each of the other possible closed door states: unlocked and off, locked and off, and locked and on. We'll need to figure out how to enable players to bypass these doors with tools next.
For my part, I mainly added the logic to make the doors work like the rest of ship equipment. Now they require power to switch on, and will switch off if disconnected. Also, crew will not be able to open any locked or powered-down door.
And I also fixed a bunch of stuff I stumbled upon along the way. Optimized ship editing lag, fixed dropped items falling into locked containers or the person dropping them, and hiding the inventory list when nobody is selected.
From here, things might get a bit harder to build. We have to figure out unlocking UIs for the various situations (different objects and their different lock types), how to handle linking keys/codes to specific locks, how to represent abstract items like access codes and software, and more and more likely, how to manage inventory.
If only there were a game with a decent inventory management system we could emulate...
Saturnian Moons, Load/Save Fixes, and Inventory
Hey Folks! Slower day today (visually, anyway). I did a bunch more behind-the-scenes work on some systems, plus more admin, planning, and discussion.
The behind-the-scenes stuff has a tiny bit of visual impact, which I show above: Saturn's moons!
I was getting ready to test some inventory UI things, and tried to create a save game in my test room. But loading the save crashed.
When I started poking around, it turned out to be NaN errors in the save file. Specifically with moon stations. Because the moons in the game had no rotational period specified, they were producing divide-by-zero errors when placing stations on them.
So I fixed the divide-by-zero error with a reasonable default (synchronous rotation, which most moons do). Then, I added real-world data for each moon that was missing it. Plus, since I was in there, I added the main Saturn moons. The SVIR station you see there is New Virginia, on Titan. It was previously the only moon defined for Saturn.
There was also a bug in loading saves made in the ship editor, since none of the characters had social info. So I added null checking there. And I added spawn coordinates to the test room so the player would appear near the crowbar, instead of inside a locked, empty room
The rest of the day was more managerial. But one of the bigger discussions to come from it involved what to do about inventory. I'm still a bit nervous about trying to rebuild NEO Scavenger's physical inventory UI here, simply due to its complexity.
On the other hand, it opens up a huge range of new things we can do once we have it. Not the least of which is to let us loot the crate we've locked and provided a crowbar for. It nicely bridges the gap from NS, too, making Ostranauts feel a bit more familiar.
Finally, we have a lot of the necessary pieces for the UI already running for item placement on ships, stacking, containers, and slots. We just haven't tied it all together in a UI yet.
So Michael is going to take a crack at it over the next day or so, to see if there are any gotchas. I truly hope it "just works," and we can sprinkle some nice art into it, then blow away fans with something they may not have expected. Working hard not to get too excited
Locked Crate UI
Hey Folks! Decided to tackle the UI for unlocking a crate with a PIN code today. Plus, Michael's off and running on his crate inventory grid. And Bjørn is starting to look at footstep audio based on tile material!
I spent a fair amount of time thinking about the lock UI, and scaring myself from working on it, before I decided to just dive in. Currently, I want the game to support a few different lock types, for use on different items. Some things require little security (a locker), while others should be near-unbreakable (access codes to a ship helm).
As a result, I've arbitrarily decided on these lock types:
For now, we just need a PIN lock, but I wanted to think ahead a bit. Both for gameplay and world-building reasons.
- Mechanical combination lock
- Mechanical key/tumbler lock
- Electronic PIN lock
- "Q" Locks, which are a form of QKD encryption
- RFID locks, or chip readers
Anyway, I setup a UI the object can spawn if the user chooses to unlock it, and then the fun begins! Normally, in this case, we type the 4-digit PIN into the keypad, then choose to lock or unlock, as needed. The indicator will change if it worked, or reset the digital readout if not. (I realize showing the PIN numbers is insecure in real life, but I don't yet have a * character in my 7-segment UI widget.)
And so far, this works at a basic level. I can lock or unlock any PIN lock UI in the game with "1234"
However, I still need to hook this up to in-game objects. And then I have to figure out how to make each lock generate a unique PIN. And then, how to sprinkle clues around the ship, if needed.
Meanwhile, Michael has a good start running on his crate inventory grid. You can walk up to any object, spawn a UI that shows the correct number of objects in a grid, and you can drag them around. They snap to grid, prevent overlapping, and you can move the whole grid around and resize the window for it. Pretty good! (And already a bit of an advancement over NEO Scavenger's static grids.) He's going to work on getting appropriate item sprites next.
Bjørn has started looking into footfall sound, and is figuring out how to get floor tile info to generate appropriate audio for each step.
Chris is back from his other job's tasks, and ready to resume salvage loop user stories.
And in a surprise email, Josh has mentioned he's interested in revamping the title screen music! I'm more than a little excited to see how that evolves. I always enjoy new track stuff from him.
So I guess this was a pretty busy day! A lot of stuff mid-completion, so I can't really show it off yet. But definitely an interesting step forward in gameplay on the near horizon!
That's all for this week. Have a good weekend, all. And see you Monday!
Murder In the Drama Room!
dcfedor
onOctober 30, 2019
Hey Folks! As mentioned yesterday, we'll be looking into crew drama and management next. Basically, doing a hack job prototype to get some ideas up and running, and to hopefully figure out the best way of making this feature a viable game mechanic.
Our first test is a simple drama scene:
Mal, Zoey, and Jayne are in a ship that's rapidly losing atmo. There are two EVA suits inside, but just outside the airlock is a spare EVA. Unfortunately, opening the airlock means the ship will depressurize even more rapidly, and likely kill whoever isn't in a suit. What will Mal (the player) do?
And our first piece of the test is to get an AI to do something if the player does a thing. In this case, we chose Jayne clocking Mal on the head if he goes for the EVA suit without negotiating first. (In fact, Jayne will clock Mal when he picks up the suit regardless, but that's a problem for another day!)
And today's screenshot is the result: the DramaRoom!
In this scene, Mal has...well, you can read the message log for yourself
So far, so good! (Unless you're Mal.) Next steps will be to layer more and more sophistication onto this, so there are more actions to choose from, and more AI responses.
And if we're lucky, this will start to precipitate a system we can turn into emergent gameplay. The thinking right now is that this dramatic moment represents a sort of choice nexus, and that we can load the game with a bunch of these nexuses, and start to have AI behaving rationally, and perhaps even with goals.
I should note that this overlaps a bit with the plot and AI needs code I've written before. But it is perhaps another approach, and importantly, one which might reveal better ways to make this fun.
More to come!
Social Loop, Preview Text
Hey Folks! Still plugging away at social UI changes. A lot of today focused on getting the social UI to tell us more useful info, and cleaning-up the social actions to be more logical. Also, Chris has merged his camera tweaks into mainline, so we have smoother camera action!
For now, the social UI will reveal all stats on the participants, so we can see what we're doing. As you can see with Benjamin, above, that can get a bit overwhelming. But we can at least see if our actions have any affect on him.
I also changed the way characters are initialized, so their starting conditions are more logically consistent. E.g. they won't end up starving yet stuffed, or prefer Viceroy cigarettes if they don't smoke.
I temporarily removed a bunch of non-social interactions, like trade, hiring, and debug skill reveals, since they were just noise in our testing. I also removed some old social interactions that either seemed anachronistic (trying to defy someone before they do anything) or impossible (offering to buy a drink, despite there being no drinks or bars in game).
On the other hand, I added a few more old social interactions that were originally meant as replies. Things like insulting, encouraging, and threatening are all perfectly-fine ways to initiate contact. And we should start fleshing these out so they are first-class things we can do on the regular.
And one of the bigger changes today was making social UI loop back on itself. Previously, it would close once the current exchange ended. Often after a single reply. This caused problems with not seeing stat results of an action, as well as feeling really jarring and disjointed. There was no conversational flow.
Now, once the exchange ends, we are left with a new round of actions to choose from. I think once we start making this list dynamically based on stats, consumable actions, and increase the rarity on some, it'll be a lot more engaging. And I added a crucial "Leave" action to get out
One last thing I've added was to make the preview text dynamically-generated, so we wouldn't have to manually update a huge list of interactions any time we changed the stats on them. It's a little crude-looking, but at the same time, reveals a lot in the stats that I might not have noticed before!
We're making progress. We still have a few steps to go before this feels like a game loop, but it's already made some leaps forward!
CYOA Career History, and Bashing for Fun and Profit
Hey Folks! Hope everyone had a good weekend. I was actually at work yesterday, but basically on voice chat with devs most of the day. Hence no news post. (And not much visible stuff to show anyway.)
Today, however, we have a bit more to talk about.
In our current sprint, we're trying to make the crew management aspects as compelling as the salvage loop. And after a bit of work towards that goal, we realized we'd end up with a social loop that was maybe fun, but kind of irrelevant to the rest of the game. Like it existed on some island detached from the rest.
We needed to care about our crew, and their relationships to us (as captain). And in order for that to happen, we also have to care about our captain.
So we're going to revise the character creation process a bit to make it more role-playing-like. We're still in the career kiosk, choosing the career path of our history. But instead of seeing a wall of skills to choose from, absent of any context, we're going to try focusing more on events that happen to you during, and the skills, traits, and other rewards that resulted from them.
Today's screenshot shows a template we quickly setup to test this out. Bernardo is beginning their shipbreaker career, and instead of choosing skills in a sterile menu, we see this "Event Intro" with some possible outcomes. Let's say it's an accident on the job or something, and Bernardo is choosing from several, (ideally three or more), equally interesting outcomes.
Maybe he risks himself to save someone, and gets a "brave" trait and "athletic." Or maybe he thinks quickly, letting him have a fire extinguisher to propel himself to safety. And is rewarded with "genius" or "skill: zero g."
Whatever the case, we start to build this story, and our character choices have context. And hopefully, we care more about our character as a result.
We're also going to start making salvage actions require more skills and abilities, to make this less than 100% focused on tools and loot. If you can only do a few things due to skill, hiring crew becomes more compelling. And what's more, we could make things take more realistic amounts of time.
Instead of cutting down a wall in 5 seconds, maybe it takes 15 minutes. That's serious time if your O2 tanks are running out, or you want to get through a whole ship before nighttime. Having crew to help boosts the rate at which you can get stuff done.
And if we're doing that, we need the actions to be able to resume if interrupted. We spent a bunch of time looking into that today, and as it turns out, we might already have some code to do this. The way we currently handle destructable objects actually works pretty well in terms of tracking damage done (progress made) before triggering a destroy action (or convert to a new version). So we could have some arbitrary "install progress" stat that ticks up over time, have that remain on the object if the NPC walks away, and when the player returns, they resume ticking up that stat without lost time.
Finally, we'll need a way to hire and fire crew. Fortunately, we already had the former. The latter was trivial to add. And probably the only thing left here is to add the ability for disgruntled crew to say "I quit!" Which is an important part of the social loop: we want our crew satisfied so they don't mutiny!
There's a lot going on here, and potentially some big wins if we can get this all running as planned!
Short update today, as the screenshot mostly speaks for itself. An example of the career event stuff I mentioned yesterday is nearly done!
Hey Folks! I was able to get a full day of development in today, and managed to finish my skill-gating task!
There were a few more code issues that needed fixing. Mostly naming and reference typos. Then began the long slog of updating all of the data to match the new system requirements.
Mostly, this meant adding a non-skilled option to each of the install/uninstall actions, defining their rates of progress, which ones should appear as menu options, plus some triggers to control when they are valid. I made some heavy use of regular expressions, let me tell you
Once that was done, I could uninstall all the usual stuff again! It currently takes about 1.25 minutes to do, unless you have a relevant skill for the action, in which case it only takes 18ish seconds.
Moving forward, we should probably bump-up these durations to be more realistic. Also, we might want to eventually rethink which skills are required for what. There are a few skills in the game that seem like they'll be unused, and others used a lot. So it might make sense to cull the useless ones, and split the useful ones.
In any case, today's screenshot shows Jenna working away at a floor tile (on the right). And on the left, the inventory UI.\
Michael put a bunch of work into this UI to let the player move items around, and even equip them. We can see items on the ground (lower right grid), items we're carrying (top right), and items we wear (left paper doll). Currently, no items have equipped graphics, so we can't see any equipped items. But clicking on the paper doll will unequip the item there, and dragging an item to it equips it in that slot.
Chris has also been working on some updates to this UI, making it a bit more like the NEO Scavenger one. E.g. moving items directly from one grid to another, without having to pick them up first. Making them auto-place in cases where user input doesn't align right. Etc.
Michael's still working on life events, when not chatting with me about oxygen poisoning
And lastly, Bjørn seems to have surreptitiously snuck some new sounds into the assets folders! I saw them while merging my latest changes, and there are some cool machine drones in there. I'm hoping we get to hear some of that in action next week!
That's all for now. Hope everyone has a good weekend, and I'll see you all Monday!
dcfedor
on12/11/2019 - 10:18
@Maximus79, I think players will still try to get to Earth, but Earth orbit is a literal death trap. So I'm not expecting many attempts to succeed.
And what if they do succeed? I'm not sure what happens then. I mean, does it become a game of NEO Scavenger? Or just a specialized port, similar to the rest of the System's ports?
Plus, climbing the gravity well is a lot harder than falling into it, and I doubt anyone would be lucky enough to traverse it twice. So are players basically stuck down there if they succeed?
It's a lot of questions. And I don't have good answers yet.
What I can say, though, is that Ostranauts is pretty much concurrent with NEO Scavenger. So while Philip is down there scrounging, our captain is up here eking out a living. And since nobody can survive orbit, it's a moot point.
What's more, I could imagine some more enterprising (and desperate) types to dip their toes into upper orbit, to snag some old Earth tech before they're shredded apart.
I think we'll still see some lore mining around Earth. Just not landing on it.
@Rovlad, that's true. But it's safe to follow-up with a more traditional gameplay trailer closer to launch. (Notably, when I finally get this damned game loop solid
In this teaser, we're mainly highlighting the setting, tone, and types of stories this world might generate. For some, this is the hook that will hopefully draw them in to learn more!
Working On PAX Demo
dcfedor
onFebruary 4, 2020
Hey Folks! I'm overdue to post another update, and we've been up to a lot since the last one. So I figured I'd catch you all up.
The big thrust right now is to get a playable demo ready for PAX East, which is in about 3 weeks. It took a bit of trial and error to decide on what the demo would be, but I think last week mostly got us on track. So now it's all about execution.
Roughly summarized, we want the demo to leave players feeling like the game will let them:
And to do that, we're going to have a demo that lets you customize your captain, define a backstory that gives you your first (broken) ship, patch-up that ship to limp to port, try to hire some crew, then set a course to somewhere in the System.
- find a bucket of bolts
- fix it up
- fill it with their space friends
- and fly around making adventures
The captain customization is a lot of the stuff we already had, but spruced-up and refined for public consumption. We trimmed out all the debug stuff, so the player can just focus on their appearance, name, career events (and loot!), plus optional personality traits. Then, they launch!
Once launched, they're on their starter ship, which needs some TLC to get working again. Basically, a brief tour of the physical salvage type stuff you can do, until the ship can fly. Once fixed, that will likely trigger a fast-forward/teleport to the next scene, so PAX players don't have to wait too long.
In the next scene, we'll have some crew the player can recruit. And each potential candidate will require some social (and maybe physical?) tactics to hire. Use your social moves to figure out who you want to hire, then more moves to convince them and deal with their baggage.
Finally, you're ready to start your adventure, and we're hoping this is where we can give folks a bit of hands-on time with the nav station. We'll likely book-end right around here with a summary screen, so the next PAX person can hop on and start the process all over.
It's a lot of visual polish, user-experience (UX) work, design tweaking, and content generation work to be done. But for the first time in a while, I feel pretty confident it'll work out. Late winter was really starting to get to me, and I wasn't sure of the correct way forward. But this exercise has brought a bunch of systems into focus, and now it feels like we just have to build the thing. It's a nice change of pace!
Anyway, we're still working away over here. And we can't wait for fans to get their hands on it at PAX to tell us what they think!
Back from PAX East 2020!
dcfedor
onMarch 4, 2020
Hey Folks! At long last, PAX East 2020 is over, and I've returned home. (Somehow, plague-free, even.) And now that I'm back, it's time to take stock of the situation, and plan for the road to release!
First of all, how did PAX go?
I'm happy to report it went well! The image in today's post was the menu visitors saw as they hopped into the demo. The demo could actually be played in one long sequence from creating a captain to piloting the ship, but players could dive-in wherever they wanted.
As promised, a video is coming shortly. Still getting back on my feet after a week away from the office. But I hope to have something soon. Modern Wolf also wanted to boost the video a bit, so we're going to coordinate.
- Create a Captain: The repeated career kiosk cycle is unclear, so we need UX work there. But otherwise, really solid experience. People spent a lot of time choosing career events for their captains.
- Salvage a Derelict: Mouse UX needs work, and some bugs can break a playthrough (e.g. silent nulls). But the overall experience is good, and people mostly figured out how to get around and find stuff.
- Reactor: A lot of people just dove right into this, and treated it like a puzzle. And the payoff was great when most of them got it up and running.
- Social: When it works, it really works. And that happened more often than not. Overall, tendency over time is every AI gets grumpy, so balancing needed. A bit of repeating was unnatural, but usually folks saw the magic.
- Nav Station: This needs UX work, and bug fixes. But it was clearly marked as experimental, so people could see where it was going, and were excited. The sim fans could really get into the details, too.
All in all, a very successful PAX! Seeing other devs and professionals there was also a nice bonus, too. And my fellow MW wolves (devs) were a blast to hang out with. So I'm looking forward to seeing them all again!
