Posted on 02/05/2016 - 17:20
Hey Folks! Progress on the data-editing UI is actually pretty good. I got a bunch of features hooked-up today that have traditionally taken me weeks in other APIs, so I'm feeling hopeful.
Data Editing form showing actual interaction data.
As of now, I've got a form that I can dynamically add to the scene which has editable text fields for each data field. I was able to add an interaction's values to each field, and capture changes to those fields immediately after the user makes them.
The form can be dragged around, the scene can be panned with WASD, and zoomed with the mouse scrollwheel (or +/- keys). If the user clicks in a text field, scene view controls pause while they type.
As an added bonus, the Unity text fields seem to handle just about everything one would need. Ctrl+A selects all, I can (sort of) highlight text with the mouse, cursor navigation via arrows works.
Unfortunately, the "Enter" key seems to lose focus on the field instead of entering a line-break. However, this seems to be more of a default behavior setting than a missing feature. I think they expected most text fields to be single-line, so hitting enter immediately focuses on the next field in the form, so users don't have to click to continue filling-in the form. I'll be looking into how this can be changed next week.
Apart from that, the UI stuff has been pretty easy so far! I think I'll be able to start tackling node-to-node connections to show branching logic, and maybe some other node types (Conditions, Triggers, etc.) soon. And all this is with the aim to make editing my data easy again in this new engine (and therefore, easy for modders in the future).
Also, I've been continuing my thinking about drama UIs, asking around here and there, and I'm getting some good feedback. One thing which came up today in my discussions was a potential example of gameplay. I.e. what do I expect the player to be experiencing during the ship and crew management portion of the game?
Here's a possible example:
Player: Huh, I wonder why Ted is just sitting there at the end of that corridor, not doing anything? <Clicks Ted> Ted: Ted is moping around, dejectedly. Ted: Ted is listening to voice mail over and over. Player: That's not good. What the heck happened? Scrolls around ship to find rest of crew. Sees Tina and Vallerie chatting in the mess hall. <Clicks conversation icon.> Vallerie: Vallerie puts a hand on Tina's shoulder. Tina: Tina vents about Ted's constant advances. Player: Hm. <Clicks Tina's avatar.> Tina: Tina refuses to be around Ted. Tina: Tina is considering terminating her contract with the Flying Dutchman Co. Player: Ah crap. I'm probably going to have to get rid of one of these next port. Or else keep them on opposing shifts from each other. Game: Alert! Pipe freeze in the main coolant system! <Fluid starts flooding the HVAC chamber.> Player: Crap again! Drama's going to have to wait. Time to roll-up my sleeves and jury-rig a fix for the busted cooling system. Hope we have enough coolant left to reach Io...
Up until now, I've sort of been hand-wavy about how drama is going to work aboard the ship. But this is one of the first times I've written it out, and thought about user clicking, decisions, etc. I'm unsure if all of this will be possible yet, but it gives me a slightly more tangible goal to work towards. And I think it's pretty compatible with our recent discussions re: clicking conversational entities.
More on that later, though. The weekend is here, and Steam is having a Lunar New Year Sale (which features a -50% NEO Scavenger, hint hint). So grab some games, a hot drink, and enjoy the weekend!
Posted on 02/04/2016 - 17:21
Hey Folks! The rumination continues on the crew drama UI system. I'm getting lots of useful feedback and suggestions, and I think there are some new directions to try. So that'll be on the plate soon.
Before that, however, I need to make sure the interaction system is actually doing what I designed it to. I've been noticing some glitches here and there, and they're complicating my playtesting.
One of the issues mentioned yesterday was the interaction target points being wrong. I had two errors in my code, causing the items to have use points which were inaccessible. The first issue was an incorrect calculation of the point's position based on item rotation. The second issue a problem with radians vs. degrees. Once these were sorted out, I was able to see more consistent/accurate AI positioning when performing actions.
The second issue I've encountered involves the sleep cycle. I cleared out all the variables from my AI except sleeping stats, and I'm not seeing what I expected. The AI rightly seeks out a bed when drowsy, but never seems to fall asleep.
Looking into the data, I'm finding it hard to reconstruct in my head how it worked. Lots of jumping around json files to map condition to trigger, trigger back to condition, etc. All the numbers and references seem to be correct, but I'm finding debugging to be hard.
And to make matters worse, my old Haxe editor used XML format instead of JSON, and I've since added some new data fields. So I don't have the nice visual editor for the interaction trees and data fields. I've been putting off data editor work so far because it takes me away from gameplay design, but I think it's caught up with me. So I've decided to try and bring the data editing tools back up to speed:
(In Simon and Garfunkel voice) Hello GUI my old friend...
Getting a complex form GUI hooked up is no small task, and I've been kinda dreading it based on past experiences. However, it's not turning out as bad as I expected this time around.
For one thing, Unity has a visual GUI editor which my Haxe tool didn't. Where I spent weeks (months?) struggling with text field line wrapping and input, and other missing UI features, the Unity stuff "just works." And laying it out isn't too hard once one learns how the position and anchor widgets work. I knocked-out the above layout in about 30 minutes, and I can move and scale it with reasonable widget repositioning and resizing. Not bad!
Of course, I still need to hook it up to data. But this is miles beyond my previous experience of using incomplete UI libraries and doing it all in code. WYSIWYG editors have never been my favorite, but this may be one case where it truly makes my life easier.
We shall see, however, once the rubber meets the road. (Or in this case, the data/logic meets the form.) More on that tomorrow!
Posted on 02/03/2016 - 17:24
I made a few more tweaks to the crew simulator this morning, so the labels sit more tightly with their owners, and they stay out of each other's way when more than 2 crew are present. Once these were in place, it was a bit easier to watch the simulation and judge.
And judge...and judge...and judge...
I'm not sure if this will be the right way to go or not yet. It works well-enough at first. I can see the bracket highlight the named crew sprite on the map, and the text below tells me what they're doing. And with one or two crew present, I have enough time to see what each is doing before it updates (mostly).
However, my eyes are flicking back and forth a lot from the portrait/text blurb at the bottom to the bracketed sprite on the map. And as the number of crew increase, things get worse. Eye-flicking gets strenuous, and many messages get lost in the flurry. Kaaven's suggestion to limit the feed to certain comms or other channels might help stem the tide, but I think there will still be situations where it's overwhelming.
I think I'm okay with the player missing the complete text of statements in a crowded room or busy comms channel. That's not really a shortcoming. It's reflective of reality. It's hard to follow multiple conversations, so we block others out to focus on one, and I could maybe do a UI to simulate that, and simply show fragmented versions of text in cases where the player is trying to follow too many at once.
My main concern is the eye-flicking. It's reminiscent of the combat UI in NEO Scavenger: one of the major flaws that gets called-out by reviewers. People like the deep combat, and some even enjoy reading the logs, but having to constantly read, check the UI, go back and read, and repeat is a chore. It's a lot of mental remapping to keep situational awareness.
So I'm going to think on this a bit more before moving forward. There's got to be a better way to take-in the goings-on around the ship without constantly checking back and forth to see which sprite is where and what they're saying/doing.
I still like the portraits, though. They add personality, and I think they'll be worth the added content costs.
Since no ideas were readily coming to me, I decided to double-check the interaction system to see if anything inspired me when I saw crew not only interacting with other crew, but taking breaks to sleep, eat, etc. And I noticed a bug!
It turns out the game wasn't applying all the item data it was loading, so beds and fridges were lacking flags that made them address their respective human needs. It was pretty easy to fix once I figured it out. And it revealed another bug with pathfinding.
Each item has certain interaction points for controlling where crew stands when interacting with the item. E.g. one stands next to the fridge when using it, or on the bed when using it, etc. However, these points were not being scaled down from pixel space to world space coordinates, and pathfinding couldn't reach the super-huge coordinates they were providing. Easy fix: just apply pixels-per-unit coefficient.
However, I still think they're broken when the item is rotated. It seems the points are not getting rotated with them, so I'm getting invalid use points still.
The good news is that this may actually be the source of some weird interaction bugs I've been seeing between crew, as well. I think crew have been interacting at long-range because of the scaling/rotation errors. We shall see tomorrow!
That's all for now. Have a good night, all!
Posted on 02/02/2016 - 17:35
Hey Folks! I managed to get Unity's UI under control enough to move forward with hooking it up to data today, and it's starting to take shape. Here's a sample:
Drama aboard the SS Prototype!
Using yesterday's portrait mock-ups, and Kaaven's suggested UI mock-ups, this is how the prototype's UI currently works:
- A dialogue UI appears at the bottom when any crew begins an interaction that's set to "dialogue=true." (E.g. visible ones like talking, waking-up, but not waiting, continuing to sleep, etc.)
- That UI continues showing the same info until another crew does a visible interaction. (Usually the response.)
- A UI bracket appears around the crew sprite in the ship to help denote who's acting.
- Each crew has a nametag floating near their head that follows them around.
In simple situations like this, I think this is working pretty well. The user has plenty of time to read each interaction as it appears on the UI. And it's guaranteed that the user probably wants to see them all for such a small ship and crew.
Some problems can occur, however, as the situation gets more complex.
- The dialogue UI stays up forever until another interaction.
- The dialogue UI sometimes appears too late or early for an interaction.
- Two or more crew doing interactions at once makes the dialogue UI change too quickly. Only the last interaction to be displayed is there long enough to see.
The first two problems are pretty simple to fix. I can add a timer or something to hide the UI after so many seconds. (I could probably even setup a history/log to open if the user wants to see earlier entries.) And the timing of the UI can be fixed to appear more sensibly once I figure out why it's doing so.
The third problem, simultaneity, is more complicated. With this style of UI, I think the user needs to somehow control which crew they care to see vs. ignore. Since we cannot see both Mann's argument and Edison's push-ups elsewhere on the ship at the same time, we need to single out which one the user currently cares about.
One possibility is for the user to simply click the person(s) they want to monitor, or grab the AI closest to the camera's center. This way, the user is directly focusing on what they want at all times.
Another possibility is to make the user correspond to a single avatar. Then, that avatar's current position controls which interactions they can see. If it's in the same room, it appears. If it's far away, it doesn't. If multiple are in the same room, like a cocktail party, they'll have to move closest to the group they want to monitor.
And a third possibility is that we go with another UI which accommodates multiple interactions on-screen at once. So far, feedback has been that the interaction shouldn't dominate/obscure the screen, which I think I agree with. But it's possible there's a way to do this unobtrusively. So I'll keep my eyes open.
Still, it's nice to see AI doing stuff! I'm not quite transfixed by the unfolding drama yet or anything, but I can start to see how interesting interactions will happen that I can fill-in with my imagination.
Posted on 02/01/2016 - 17:38
Hey Folks! Hope everyone had a good weekend. I think a lot of our catch-up from returning home spilled into the weekend, as it felt like we were still doing a lot of running around. And there's more to come, as we start getting our ducks in a row for the big move. We technically have two months to vacate, but that time's going to go fast between hiring a mover, finding an apartment in a distant city, getting the pets vaccinated/documented, and the other seemingly endless things that need wrapping-up.
I'm also trying to find a good lawyer to consult on the business moving across the border. No definite prospects yet. If you know any good attorneys with game industry experience, let me know!
Right, so what did I do today? Unfortunately, accounting in the morning. With taxes coming up (yet another thing!), I'll need to make sure my income/expenses are neatly organized and receipts ready for the CPA. Lots of slips to gather and upload, too.
But what did I actually do for work? Well, crew portraits!
There will be no smiling on this ship. Are we clear, Akiko?
After last week's post, there was a great discussion in the comments about possible dialogue representations. And Kaaven mocked-up a pretty easy-to-read UI possibility showing portraits.
I decided to run with that general layout, and see if I could put together some modular/procedural portraits so players could recognize and/or customize crew.
The above example shows two different faces using a combination of parts layered on top of each other. They include different head and jaw shapes, eyes, brows, ears, mouth, nose, hair, shoulders, and shirt. And background.
My initial thought was to try and normal-map them like the crew/ship sprites, but I quickly shelved that when I realized how hard it would be to seamlessly overlay these different parts. For now, I think I'll go with the more toon-ish style. It also got me thinking about whether the in-game crew sprites should be a similar toon style, to make them easier to spot, track, and differentiate from each other. (Kaaven rightly pointed out that the current lit crew sprites may be too hard to discern one guy from the next.)
As always, this is placeholder art, but I think it shows one possibility for how we can get variety in the crew, and make dialogue more interesting to watch.
The next step is to see how this looks in-game, and decide if it's a step in the right direction. So far, I've only got the UI mocked-up. Getting Unity to do a UI bar for the portrait and text is turning out to be tricky. It's easy enough to just lay them out manually, but I think there's a way to make them horizontally arrange themselves to fit the space if it changes (e.g. other resolutions). I want to try and get that working if I can, so I don't have to hard-code UI sizes/positions.
That's about all for today. Have a good night, all!
Posted on 01/29/2016 - 17:34
Phew! What a week. After multiple days of driving, flying, crossing time zones, speaking French, and navigating bureaucracy, our cross-country trip is complete. Looks like we may be cleared for moving to the US! Now begins a new laundry list of things that need doing before we can uproot and relocate. Lawyers, accountants, movers, landlords...we're in for some fun now!
Also, to make sure things were not too boring upon my return, the website died. By all accounts, it was a spammer clogging the system via a security hole, and the hosting provider suspended the website until we could root it out. It took a few hours, but I think we've cleaned the offending spam script and patched the hole(s). Still, we'll be keeping an eye on things just to be sure. Sorry about that!
And despite the whirlwind of activity above, I still managed to get some tinkering done on the prototype. The main feature is status text above each crew to help me see what's going on:
Riveting, I tell you. RIVETING.
Long-time readers will recognize this from the old Haxe version of the prototype. This is basically the same AI code running in Unity, with UI text floating above each crew member. I hastily added some code to spawn extra crew with a keypress, and can fill up my ship layout and watch them go.
As usual, it wasn't too hard to port. The main issues were learning how Unity handles UI vs. the way Haxe/Flixel did.
So far, I think the main issues are some visual glitches. I've got the UI text setup to stack vertically if it overlaps, but it breaks if there are more than two crew on the ship. (Which I think is a simple error in my code.)
Also, the timing of the UI text updates is a bit off from when the AI is acting. The last action sometimes lingers over the crew too long, and other times, the text appears and disappears too fast to read. Still other times, the text doesn't update until too late, often after the action has happened.
I need to sort this out for more accurate testing/debugging. It might be that I can't rely on the timing of the action queue being cleared. Or I may need to do some special handling to make sure actions aren't firing before the AI has pathfinded to its goal.
But the good news is that these issues are more shallow and shouldn't be hard to fix conceptually. Just details. A more complicated and challenging task lies beyond that: figuring out how to present these AI interactions to the player so they can watch it for entertainment.
Talking heads on the bottom of the screen, with a dialog scrolling past?
Roguelike general message log with all on-screen participants sorted chronologically?
Text bubbled above each AI?
Let the user focus on individual conversations and hide the rest?
Posted on 01/19/2016 - 17:21
Hey Folks! I managed to get the rest of the AI stuff ported and compiling, and spent most of the day working out the bugs. As of now, it's nearly working as designed:
Two men enter. One man gets food. The other sleeps.
Surprisingly, the biggest issue I'm running into seems to be null pointers from not initializing various things. I think the way Unity calls Start() and Update() is not the way I think they are called. Namely, Update() seems to be called arbitrarily before Start() on my classes, and I'm finding I need to do a lot of hand-holding to make sure each class is initialized before it's operated on. Probably, I just need to roll my own initialization and update code, and call them manually.
We're not quite at the point where AI is interacting with each other, grabbing food, etc. However, the AI is wandering around the ship, and periodically checking against its own priorities for what to do next. The next thing I need to fix is this decision code so there are no null pointers.
It's sort of implied above, but this all takes place in a new game mode called "CrewSim," as opposed to "ShipEdit" where the ship parts are arranged and saved. I managed to get these modes to talk to each other, so one can build a ship, switch to crew sim mode, watch stuff, and switch back to continue editing the ship.
This sort of mode-changing is something I hadn't done before in Unity, and it wasn't too hard. It also forced me to clean up the organization of more code, so it lives in more logical places when it needs to be shared between modes.
Not too shabby! I'll have to sort out that AI decision stuff next, and see where the simulation stands!
Also, I'm afraid I'm going to be out of the office again. Sorry about that. More immigration stuff for Rochelle, inconveniently not local to us. The plus side is we'll at least be seeing my family while there, which doesn't happen often due to their distance from us.
Anyway, I'll be trying to work on the road again, but internet access may be spotty along the way. I should be back to normal on the 29th. (Until immigration's next trick whisks me away, I guess.)
Have a good weekend, all. And see you when I return!
Posted on 01/18/2016 - 17:26
Hey Folks! Hope everyone had a good weekend. Ours was mostly okay, though I got a weird headache last evening which developed into feeling sick. It seemed to dissipate late in the night, though, and I feel much better today (thankfully!).
Today's work is a continuation of what I started last week. Namely, getting the crew, item, condition, interaction, relation, trigger, and condition owner classes moved from Haxe/Flixel over to C#/Unity. Progress is still pretty steady, as the syntax is similar enough. The main speedbumps I'm hitting are when old Haxe code runs afoul of Unity's component model.
Technically, I think almost all the old code can run as-is in Unity (I.e. using interfaces, class inheritance, etc.). However, the "Unity way" of having game objects with components offered some opportunities to refactor old code to be more organized and maintainable.
For example, I used to have an IConditionOwner interface class which Crew, Items, and Relations all implemented. This allowed me to do similar operations on each of those classes such as adding/removing more crew/items, or searching them for compatible items/crew.
However, using the component model, I can make a condition owner (a.k.a. CondOwner) component class, and just add that to both Crew and Item classes. This allows me to keep all the Condition-processing stuff in a single class, instead of having to update copies in each of the Crew, Item, and Relation classes any time I made a change.
It also meant I could do away with the Relation class, and just make it an empty game object with the CondOwner component.
I've also been separating other components out where it seems logical. E.g. the pathfinding code in Crew is now a component, so any object can take advantage of it if needed.
This is a new way of coding for me, so I'm still getting the hang of it. But it seems to be a better fit for a lot of what I was trying to do than my old way of having lots of duplicate code and bloated classes. I guess we'll see if that refactoring results in better code soon enough :)
So far, I think I've got the majority of these classes ported over, and I'm just hammering out the last dents before getting it to compile. I'm totally expecting some crashes the first few times I run this raft of new code, so bug-fixing will be the order of the day after that.
However, once those steps are done, I'm hoping we'll see the return of crew walking around and interacting with each other!
That's all for today. Have a good night, all!
Posted on 01/15/2016 - 17:19
Hey Folks! Since it had been a while, I decided to tackle a few NEO Scavenger issues this morning. And in my remaining time, I began the heavy-lifting that is porting old crew/AI-needs code from HaxeFlixel to Unity.
First of all, Kaaven mentioned that it'd be nice to omit certain map labels from the minimap, as they were getting difficult to see when too close together (as in the DMC area). So I looked into that, and it didn't take long to add a new option for making labels only appear on the main map. Basically, the old format was:
20x164=Gyges Cryo Facility
and the new format is:
20x164=Gyges Cryo Facility=1
That last "=1" is the new bit. The game will interpret "=1" to mean the label appears both on the main map and minimap, "=0" means just the main map, and if that last bit is omitted, it'll assume default old behavior (both maps), for backwards compatibility. I also edited the labels around the DMC so only the Glow/Gates will appear on the minimap, since it was hard to read if any others appeared there.
Also, while I was in there, I noticed a way to fix the issue with charged items showing the wrong charge count in encounters, so I fixed that. Yay bonus fix!
I also tried to track down a few other reported bugs, but had trouble reproducing them in the debugger. So I'll have to try again later once I have more info.
Back on the prototype, I fixed the crew rotation so it now faces the right direction when walking. I also fixed a minor bug in the item placement editor, which forgot to rotate the item's placement grid on the new cursor item if you placed something with a non-zero rotation. And I made a tweak to the item selection code to make sure it selects from top to bottom when deleting, so it doesn't delete a floor from under a bed, for example.
Once that was done, I began work on the long, tedious process of porting old AI code to the new Unity project. Fortunately, a lot of the syntax is similar, so this isn't too hard. But there are enough differences in syntax and architecture to require more thought.
So far, I've got most of the CondOwner class covered (anything which is interactive and can have conditions), and large parts of CondTrigger (condition trigger rules), Condition, and Interaction. Because of Unity's component model, some of these will have to work differently. (E.g. I can't just instantiate an item and add it to a crew's inventory, as it would appear in the game without special handling)
I think it'll be a couple days' worth of work to get any visible progress here. But the upshot is that the progress should come in the form of crew wandering around and interacting with each other.
Oh! And one other thing. On a whim, I decided to try spawning a couple dozen crew and checking the framerate with each one generating heatmap pathfinding info over and over. Good news! No framerate drops! And since the number of crew on a typical ship is likely to be way less than this, I shouldn't have to worry about pathfinding performance. Pathfinding quality, however...
But enough about that. The weekend is here. It's pizza time! Have a good one, all, and see you Monday!
Posted on 01/14/2016 - 17:30
Hey Folks! I think I've got the heatmap pathfinding working, for now.
Introducing a "passable" property to each tile avoids the bug I described yesterday when I tried to make walls cost more to traverse. Instead, if the tile is impassable, the heatmap code just ignores it, so they don't pollute nearby tiles with incorrect path values. As a result, I can get a whole map processed with numbers increasing each grid square away from the destination!
The next step was to see if I can get crew to follow it. And before that can happen, I need to introduce the concept of crew to the code.
I started out by ripping the mesh-creation code from items, since both items and crew are going to use similar code to create display mesh in the engine. This is where Unity's component-based architecture pays off, since I can just create a "SpriteMesh" class that both Items and Crew can share. I just create either an Item or a Crew object, and tack-on a SpriteMesh component, and voila! Each can now have procedurally-generated mesh in the game.
After I extracted that code, I created a simple Crew class that could track current position, destination, and heatmap info. For now, I'm storing the heatmap on the crew for simplicity. I could easily move this over to the ship, though, and just store heatmaps for each goal on the ship as-needed. (Assuming those heatmaps remain valid, that is. If any obstacles can appear and/or move, heatmaps become out of date.)
A little bit of tinkering later, and my Crew object was able to pick a destination at random and move to it! Except it was so fast that it looked like The Flash blipping in and out of every tile on the ship in rapid succession. To fix this, I turned down the movement speed of the Crew, and I could follow more closely. It kind of cuts corners now, but that may not be a bad thing.
The next thing I started was changing the Crew's orientation to match the direction of movement. And I almost have this working now. Except, the rotation is mirrored when traveling in the X+ direction. I'll have to dig into it to see why, but I suspect there's a sign error somewhere, or else an arctan correction that's missing.
In other news, I stumbled across an interesting crew sprite solution today. @Ellian, a talented pixel artist, was tweeting about a set of top-down sprites he did for a cancelled project. They had a clean pixel art style, movable parts/joints, and swappable parts/clothes. And best of all, it required no 3D modeling/rigging/keyframing/rendering!
This is a video of the early prototype in action:
His channel has a few other videos, including one for character creation with swappable parts, and a character select screen where the characters are much larger and easier to see.
It's not perfect, of course. For one thing, the animations look a little like the heroes are wading through water. And there may be a limit to the types of animations those parts can produce (e.g. prone). And rotating sprites in 3D will look a bit weird, since "real" pixel art would have different animation frames per rotation.
Still, though, this offers a ton of customizability in terms of clothing, equipment, and even character builds (male, female, burly, thin). And it's way simpler than trying to model, rig, and animate each of these combos in 3D.
That said, I'm taking a break from experimenting with art styles for now. I feel like I've been noodling on that for so long that I'm ignoring more important things, like gameplay. I can always come back to the character art and change it later. But this warrants a bookmark for further review.
Tomorrow, I may dip into some NEO Scavenger stuff (bugs/modding). And if time permits, I'll probably continue fleshing-out the Crew class to do more of the stuff the old HaxeFlixel prototype did. (AI seeking needs, interacting with each other and items.)
Have a good night, all!