Editing! Sort Of

After most of a day spent hooking-up the remaining Interaction fields and handlers, I managed to edit some things! Sort of.

Specifically, I was able to modify the SeekFood interaction chain to accommodate two paths: getting food stat directly vs. getting an item of food which can be used later. It involved editing an existing SeekFoodAllow interaction to only apply to things which are food (renaming it to be SeekFoodAllowDirect), and add a new SeekFoodAllowItem interaction that only applies if the party has a food item.

And to signify either of these conditions, I created HasFood and IsFood conditions, and hooked them up accordingly. Then, I hit "save," and voila!

A bug.

You see, when I hooked-up all those data fields to update game data on-the-fly, I forgot one thing: if you rename an item to match the name of an existing item in the game data, it overwrites that data quietly in the background. So as I was typing "SeekFoodAllowItem" in the name field of my new interaction, I briefly had a moment in the text field where the text read "SeekFood," and that steamrolled my original SeekFood interaction. And as I kept typing, the old interaction was lost forever in its wake as the new one kept updating it's name.

So I think one thing I'll do Monday is to skip updating game data if there's a name conflict, and highlight the field in red to make it clearer. This way, the old data will be preserved, the user warned, and worst-case scenario is that the newly-created data won't get saved due to the conflict.

But yeah! Editing! It actually went pretty smoothly, otherwise. Jumping between editing interactions, creating conditions, and back again to link them, all went pretty quickly. Way faster than hand-editing text files! (And way easier to keep track of.) Hopefully, this means I'll be back to prototyping game data again soon. (Though I suspect Items will need to be brought up-to-speed soon, too, for more crew actions to be possible.)

Oh! And in other news, it appears that HaxeFlixel just got an update that allows for custom shaders per-camera. This is perhaps one of the most-wanted features on my wishlist, as it allows for cool things like normal-mapped sprites (e.g. sprites with light and shadows playing across the surface) and other effects. Some very cool possibilities may have opened-up!

Comments

ra1's picture
ra1

So the crew are going to have their own inventory? How will they determine what goes into it? Player interaction or AI?

If AI, I'm wondering how you will motivate a not-hungry crew member pick up food for later. The "planner" trait? Will the "glutton" trait make them eat it even if they aren't hungry? Lots of ways you can go with this.

dcfedor's picture
dcfedor

That's a good question! And one to which I have no answers. Yet :)

Over the past few weeks, my thinking on crew control has been evolving.

Originally, I was thinking the player would only control one avatar, the captain. They'd only have that avatar's line of sight, and knowledge of that avatar's status, etc. I was banking on this being interesting because you'd have to decide which candidates were trustworthy for your crew.

Lately, I've been leaning towards a model more like Prison Architect, where omniscience extends to all crew. It'd still be limited line of sight to those people, but as some have pointed out, the alternative might be really frustrating.

Also, when it comes to things like equipment repair, the system I'm envisioning might only be doable with human intervention. I'm not sure AI could do it (or at least any AI I could write).

However, I may still experiment with both a bit. And maybe I'll try to keep both working as long as I can until I'm sure one is a clear winner.

In either case, I think my ideal situation would be a NEO-Scavenger-like inventory (limited space, weight, and paper doll with containers, slots). Not sure if I can manage all that UI, though :)

Dan Fedor - Founder, Blue Bottle Games

matsy's picture
matsy

Re: Equipment Repair

Could you not assign crew members to job roles which in turn they would then seek those objects that have an assign, and do the required work for these? Kind of like Gnomoria/Prison Architect style with rooms.

Now I guess your engine design system is where things would get tricky but in my head from your example, you'd obtain engine blue prints which you could then mod and refit to your liking.

But in terms of what the 'Engineer' would do, and following you Firefly lore

Kaylee will seek engineer related objects, like the engine, then one job that she could do is 'maintenance' which then it will go to each part that needs it the most (maybe a bit of random order or something RNG to determine what to check to introduce faults eventually). Then if a fault is spotted it would tell the Captain a part is needed, or try to fix it if we have a spare which would just be searching storage for an equivalent.

Saying all that, I think back when this subject was brought up for NEO Scavenger you talked about system where a part / object like a gun could be broken down into sub parts like trigger, butt, etc to repair items rather a quick 'fix' as it were..

dcfedor's picture
dcfedor

Yeah, the tricky part was more the second part of your point: the complex working machine aspect.

You're right that if there were blueprints, an AI could just swap out expired parts for new ones, or top-up fluids, etc. Basically, following rote instructions.

However, it'd kinda suck if your "Kaylee" couldn't fix a broken thing because the exact spare part was missing. Or to borrow an example from Red Dawn, if radiator fluid ran out, one could bleed the gray water system (i.e. piss) to holdover the coolant system until port. But an AI wouldn't experiment like that, because it wasn't pre-programmed with the idea. It's something a human player might think of, and would be one of the emergent elements that made things interesting.

This is one of the big reasons I'm thinking the player may want more granular control over the crew.

I suppose I could have AI be "magic" in that they can repair things that would otherwise be impossible. Pen and paper RPGs already kinda do this by abstracting skills away to rolling against a skill. E.g. Kaylee has a 33% chance of repairing this broken engine...it worked! How? Who cares?

It'd still be potentially generating equipment from nothing, though, which is a no-no in a survival/hard-sci-fi/scarcity game :)

It'll warrant more thought, to be sure. Like I said, I'd kinda like my options to remain open until I have a chance to at least try them. Sometimes, the "right" answer turns out wrong in practice, and the "wrong" answer was the right way to go all along!

Dan Fedor - Founder, Blue Bottle Games