Hey Folks! Hope everyone enjoyed their weekend. We had a nice family road trip up the Washington coast Saturday (Chuckanut Drive), and a toddler birthday party Sunday. It's starting to feel like we actually live here!
I spent most of today carving out a new data type for the game: loot. As mentioned last week, this data type works a lot like NEO Scavenger's loot system. A single loot entry can list one or more items (a.k.a. Condition Owners, or COs) with the chances of each and amounts, as well as other "loot" definitions. So an example fridge could spawn with not only 5-10 food packets in it, but also a "random condiment tube." This allows us to have highly diverse loot as well as standardized loot that gets used in multiple places. (Like NEO Scavenger's "random junk item" treasure.)
I've got the data type setup in code, and the parser is up and running. And I've even plugged in some sample data to the fridge item. However, it's still spawning empty, so I need to check out what's going on. It could be anything from missing data in the loot tables to bad debug UI accuracy. Shouldn't take long to pin down, though.
Once that's working, I should have AIs running around the ship, raiding the fridge for food until it's empty. And this might be the basis of AI inventory systems, or maybe even shipboard item simulation (e.g. a fuel store depleting over time).
Hey Folks! Nothing too fancy to show off today. Most of the work was invisible groundwork for what's next in the prototype: containers and loot.
As mentioned earlier, I've been working on getting all items and crew in the prototype to be a bit better organized. I've now got everything refactored, and my item/crew objects have their visuals in one data file, while their game rule definitions are in another. This allows me to define things like starting conditions and AI preferences in the entity. I'm calling them "Condition Owners" or COs for short.
And now that COs can contain things, and add/remove COs from each other, I'm getting started on the concept of loot. A CO for a fridge, for example, might have starting loot of 5-10 food packets, while a CO for a pirate might have a longer list of items. And I want my AIs to be able to run around the ship taking items to be consumed or equipped.
My first inclination is to copy the treasure table format from NEO Scavenger, since I know it works. E.g. "ItemA=0.6x5-10" will mean there is a 60% chance of 5-10 ItemA objects inside. The main difference in this new game is no more AA:BB.CC naming formats. That numbering format caused all kinds of issues in NEO Scavenger, especially with modding. Using simple strings will make things easier on everyone.
So that's where I'll be picking up on Monday morning.
In other news, I've also begun working with a studio on revamping the Blue Bottle Games website! It's long overdue for an overhaul, and the security/outage incident earlier this year bumped up that priority. Things have been running fairly smoothly in the new software, but if anything happens, I still have to drop everything to fix it. This studio is going to help me redesign and reorganize, and it'll be good to have a company I can turn to in a case like that, and just say "please fix it" while I get back to game dev.
It's pricey, unfortunately, but I think the investment will be worth it because it's done right, it's secure, I can free up my time, and hopefully, it'll be a cooler website and easier to use!
Anyway, lots of stuff flying around these days! Space prototyping, mobile development, website upgrades, and NEO Scavenger patching...you'd almost think I were a real studio :)
NEO Scavenger is now officially updated to v1.14! Since the test builds have been relatively stable, I've just finished updating the default builds to 1.14 on all sites. The "test" links are no longer necessary, and have been removed for now.
Added optional autosave feature to save game at the beginning of each new turn.
Added ability to choose whether encounter map labels appear on minimap by adding =0 or =1 at end of data. If missing, assumes minimap label added.
Changed crowded map labels near DMC gates to be invisible on minimap, so only gates visible.
Fixed a bug that allowed communal barrel fires to be destroyed in extinguished fire recipe.
Fixed a bug in loading screen that prevented log from being added to clipboard if error in XML file.
Fixed a bug that misreported 0.0 charges on charged encounter items.
Fixed several null pointer bugs when loading save file that included content missing from currently-installed mods.
Fixed a null pointer bug if game tried to load recipe scrap for missing recipe.
The big change here is the new autosave feature. It'll try to save the game at the beginning of each turn so your progress is not lost in the event of a power outage, crash, or other event. It is enabled by default, and can be disabled on the options screen. Note that permadeath is still active, and your save will be deleted if your character dies.
Also, some modding enhancements made their way into this build. The loading screen logs should now be fixed in the event of bad XML format. And minimap labels can now be controlled by modders. An =0 means no label, while =1 means a label is added to the map. Default assumes a label is added.
Finally, the number of charges in an encounter item are now correctly reported, among some other null pointer fixes.
As always, if there are any issues with the new build, let me know on the forums!
Good news, everyone! NEO Scavenger Mobile has a new dev!
As some of you know, I've had NEO Scavenger Mobile cooking on the back burner for a while now. Steve was porting the old NEO Scavenger Flash engine to Haxe so it could run on iOS, Android, and many more in the future. However, due to scheduling conflicts, Steve had to step down, and I've been looking for a replacement.
Fast forward a few weeks, and I'm happy to announce that the torch has been passed to Tiago Ling Alexandre! Tiago has quite a bit of experience both in developing Haxe apps as well as launching things on the AppStore and GooglePlay. I'm happy to have his expertise on board as he scavenges what he can from the ruins of AS3 code to craft a powerful tool for the future! Or at least, something to help me not starve and/or freeze to death :)
In other news, I slapped together a few normal maps for food packets and the fridge item, and fixed a few bugs to make them work in ship layouts. AI can now consume food packets left on the floor, as well as check fridges for food. (Currently, none found all the time.)
I also started work on a change to the way data is stored so that I can start defining things like typical crew and item stats. Currently, I have "item" data, which is a kind of mix between appearance and game stats. I'd like to change this such that "item" becomes purely visual stuff (images, shadows, grid placement), and a new data type will contain stats, available interactions, etc. This way, I can have a variety of unique entities in the game have different stats while sharing the same appearance.
It's slow-going, though. There's a bit of deep refactoring going on where I hacked stuff together to work. But hopefully, this is the next step towards having things like preset crew and item types (e.g. tough guy, mechanic, pilot, and malfunctioning fridge, fancy fridge, etc.)
Continuing work on AI today, I managed to fix a bug that caused AIs to interact with other AIs that were currently busy doing something. For example, an AI trying to get some sleep might try doing so on the same bed another AI is currently using. Funny, yes. But not really the target behavior.
Once that was fixed, it was time to sit back and get a big picture of the AI system. So I built a new ship layout for testing, and added two crew members per bed (since right now, each AI starts with a high chance of sleepiness). Here's the result:
First things first. It's buggy. AIs are having conversations in rooms where other crew are trying to sleep. Some AIs are magically talking through walls and across the ship at other AIs. Some AIs are escaping mid-conversation and leaving the other AI waiting...
That said, AIs are having conversations! And sleeping! And navigating to each other (most of the time)! Overall, I think there's something workable here. And the icons are doing their job so far. I'm seeing them pop up around busy AIs and I have a rough idea of what's going down. Talking, inquiring, affirming or denying, sometimes yelling.
In this case, Rodriguez is being friendly to Brickell, Mann is doing some prone activity (likely push-ups) in his room, and the rest of the crew are trying to get some shuteye. Not bad!
I think it'll be a toss-up between fixing some of those aforementioned issues and maybe fixing up a fridge and food items for alternate metabolic actions besides sleeping. This may be getting into one of those fleeting "fun zones" of game development :)
Hey Folks! Hope everyone had a good weekend. Ours was still chock full of bureaucracy, but we did manage to squeeze some fun in here and there. Plus, pizza!
Today, I tried to keep the forward momentum on last week's crew speech bubble UI elements. So I took some advice and skipped reinventing the wheel, instead using the existing NEO Scavenger encounter items to show AI interactions. Here's a preview:
Using the NEO Scavenger icons gives me a chance to move forward with UI positioning tests without having to draw a bunch of new art. And for the most part, the old icons cover all the social situations I have so far. Assuming you guys are seeing the same thing I am. My interpretation of this scene is that Brickell is glaring at Edison about something, while Rodriguez chews out Jones. When I click on Brickell a few moments later, this is the message log I see:
Looks like things were going okay until we caught them, when Edison hurt Brickell's feelings, so Brickell showed her disapproval. This may not be a completely logical interaction, but hey, these AIs are like 5 seconds old each. Plus, they have a total interaction vocabulary of maybe 7 items plus sleeping. They need some development :)
Focusing on the UI, though, this might be a workable solution. I'll probably try to add some generic animations for broad classes of interaction (e.g. talking, shouting, prone, violence, etc.), and see if the icons enhance the animations or if they get in each other's way. I may also consider color-coding the icons so blue is neutral, and red is shouting, or something similar, so a sudden outburst will catch the player's attention.
Going to need a lot of testing and tweaking, I'm sure. But not a bad start!
Hey Folks! I was looking into AI interaction icons again today. I started working on some icon speech bubbles, and they were working out alright until I ran into some of the more action-y/gesture-y interactions:
How do you show "throws hands up" with a word balloon?
Certain non-verbal/non-thought interactions just didn't seem to be covered by the above. And when I reached out to folks for ideas, Matthew Glidden reminded me that I kinda already did this:
@dcfedor you had lots of Action poses in neoscavenger for sure
Like, I literally made a whole library of verbal/non-verbal action icons:
Whoops. I guess I'm the typical "reinvents the wheel" dev.
Armed with a newfound trove of icons, I think I'll get to work on porting some of these over. There should be more than enough to work from to cover the interactions I have so far. And hopefully, when one of these appears over an AI's head, the icon is a nice, instantly-recognizable summary of the interaction.
The question is, in a room full of a half-dozen people (i.e. the crew), can the eyes follow this without working too hard? We shall see!
Hey Folks! More good news: I continued to do game development today! It's crazy that this is something to get excited about, but it's been so long since I've had time to focus on my job instead of things like banking, insurance, and other general running-around. It's almost like things are getting back to normal!
Focus was still on AI today, as I fixed-up some of the rough features added yesterday. There was an infinite loop when the game tried to clear the message log if a user clicked a different AI at the wrong time, so that was first order of business. I also added some code to allow AI to update the message log in real-time, so they could pump messages to it and the user could read them as-it-happens. (Previously, the log would only show messages from before the AI was highlighted until the user highlighted the AI again.)
More interestingly, I added code to include both parties in a conversation to the message log. Now, when one AI talks to another, the message log recaps both at the same time:
Now it's starting to look like a real conversation or other interaction! There are still a lot of repeats, as AI only has a limited vocab right now. Basically, one interaction type to choose from for each personal need. I'm hoping that adding a few other options per need will flesh things out a bit, not to mention add more of a range of responses.
With this all in place, I'm starting to reach a point where I need to "play" the game to see if it's working. This will mean the aforementioned additional data for the AI to work with, but also one more thing: word bubbles.
Being able to see the details of the clicked AI's conversation as it happens is great, but I can't keep up with a crew of 7 all doing this at once. Players will similarly not want to have to constantly click around on AIs to make sure they're not getting in trouble. (Or indeed, even to be entertained by their antics.)
As a first stab at solving this, I'm going to try adding word bubbles above an AI when it's interacting with another AI. This way, the player can see which AIs are engaged in activities at any point in time. And I may even make "themed" word bubbles, so the player can see not only the presence of an interaction, but the nature of it. E.g. talking, shouting, thinking, etc. Or perhaps I can even have icons for specific needs like achievement, security, and intimacy.
All of this should hopefully make it more of a thing to watch, and take out a lot of the microclicking. Users can focus on what interests them, or issues that need attention.
More on that later, though. For now, time to make some dinner. See you tomorrow!
Hey Folks! Today was a much more productive day, as I was able to spend most of it working on code. And so, I focused on making the AI and its feedback UI better.
The first thing I did was to shore-up the dialogue UI a bit more for better debug output. I added some activity timer info to it so I could see the countdown as an AI was acting on something. And after a bit of watching and stepping through code, it turned out there were a handful of bugs in there that made the AI behave a bit strangely.
First of all, there was a bug that caused an AI to clear it's own queue if it walked to a target, instead of doing the next action in the queue. Normally, the AI would tell the target to stop it's current action (waiting, since it was an action's target) when it arrived. But in the case of walking, the actor and target are the same AI, so it told itself to stop doing the next action.
Once that was fixed, AI behaved a bit more predictably, and the next bug came more easily. I was able to fix an issue that caused the animator to get stuck walking/using when it should revert to idle. Now, the AI would play a walking animation as it approached the target, then switch to "use" animation when it got there, and finally, "idle" when it finished.
After the above, I decided to also start working on migrating the message log data from the scene into each AI. This way, the messages would be recorded on each AI in case the user (or in my case, developer) wanted to check the history. The scene version would only show messages if the AI said them while selected, resulting in data being missed by the user.
And to go hand-in-hand with this, I also changed the message log UI to appear as soon as an AI was clicked, and to fill it with the AI's message log. Now, the user can click around to see what each AI has been up to recently.
It still needs some work, both in terms of bug fixes and refinement. But this is a big step forward in peeking "behind the curtain" on these AIs, and being able to test them in a more macroscopic way. I.e. "are they behaving like crew should?"
I think that last series of bugs had me in a rut, and it feels liberating to be past those now. Hopefully, this is a sign of more progress to come!
Hey Folks! Sorry for yet another late news post. It was another one of those days of running errands to get family established here. Today we opened no less than 5 accounts! And the scary thing is we still have a few left to go. Health insurance is the next big one, and we are not looking forward to picking apart that knot of confusion.
The work I did manage to finish was one part debugging UI, and one part art discussion.
The debugging UI is a way for me to monitor an AI's stats in realtime, to compare them to the AI's behavior. I want to make sure AIs are seeking out ways to fulfill their needs in logical ways. And hopefully, that will lead to some interesting AI interactions and strategy.
Right now, I've got the UI showing the AI's current list of priorities (conditions it needs to address), as well as the interactions in its queue. Each interaction also lists the target AI or item, so I can see where the AI plans to perform the interaction. Finally, I can also see the AI's current animation state, which is a value that controls which animation should be played next.
Upon my first few tests, it was information overload. But I think I can probably focus on individual data while checking the AI movements and look for discrepancies. One thing I'm already noticing is that a queue can go from 2 items to 0 items in a flash, even though each one should take some time to complete. I'll have to look into that next, maybe.
On the art side, I've been chatting a bit more with the artist about graphics styles. The other day, he sent me this tantalizing animation:
What you're looking at is his sample art applied to some walls and floor, as well as his modified crew rig. The crew rig is a lot like the one we've seen before, just with some "X" shaped cross-sections to give the illusion of thickness at different angles. And the walls are just 2-sided sprites with a top sprite.
Now, let me be clear. This 2.5D style is something I like a lot. Many of my favorite games are some variation of this isometric-like pixel art.
However, the thing that worries me is that this may seriously inflate the complexity of each art asset. Those walls now require 3 sprites per segment, instead of top-down's single sprite. And for something like a chair, it might require up to 5 sprites.
What's more, a chair-shaped object wouldn't nicely fit a cube mesh, since the chair is more L-shaped. Seeing the chair at any angle that showed any two adjacent sides (e.g. front and left, or rear and left) would look wrong if they were just sprites painted on a cube. The edges wouldn't line up. Here's a simpler example:
Basically, there are no sprites (a.k.a. textures) that could be applied to the sides of this cube to make it look correct from all angles. We'd need a 3D mesh to approximate this shape so it would look correct from a non-orthogonal direction. And if we're using 3D models, well, then we need separate meshes and potentially complex texture maps. Starting to get more expensive to make, and out of reach for non-professional modders.
I could me missing something, of course. Maybe there's an example of this already out there. And the goal is certainly worth attaining. But I don't want to start down this path only to discover it's too expensive to build (and too hard for modders to use).
It's a dilemma. And maybe I'll let this stew on the back burner for a few days...