I keep a running devlog in my project folder. It reads like a terse transcript of everything I did that day. Usually, it's a few lines long, highlighting the features I've added, or the bugs I've fixed. The changelogs you see with each new build are usually lightly-edited versions of that devlog, minus notes to self that aren't meant for the public (e.g. installed software X, emailed contractor Y, etc.).
Today's devlog was 28 lines long. And I didn't really get much "done." I did learn quite a bit, though.
Basically, today's work amounted to digging into code for textfields in multiple UI libraries, as well as the generic OpenFL textfield. And with slight variations, what I'm discovering is that each has issues with multi-line input text. Since much of the data in my games is multi-line (e.g. descriptions of in-game things like items, creatures, interactions, etc.), this is a problem.
HaxeUI has some nice UI stuff, but I had to hack the code to force it to use OpenFL "next," which has some improvements to TextField (such as exposing the selected index on non-Flash targets). It has almost everything working, but as soon as I try to highligh across multiple lines, I get a crash.
StableXUI was my next try, and like HaxeUI, has some handy widgets. It was also way easier to implement. Unfortunately, the multi-line support seems missing here, too. I can sort of hack it to accept multi-line input, but the highlighting of text across lines is wonky. (Doesn't crash, though.)
Finally, the vanilla OpenFL TextField seems to be the most stable, but also requires some hacking to accept line breaks. The good news is that highlighting seems to work across lines. So I may look into extending this to see if it works tomorrow.
While I got little more done today than yesterday, I did learn a lot about haxelibs. I figured out how haxelib dependencies worked, how to force which versions of libs to use, switching from "legacy" to "next," and even how to modify libs to work differently. That last bit is one of the major benefits of an open-source platform: I can just get in there and muck around if I need something that the off-the-shelf thing doesn't have.
The down side, of course, is spotty features and instability.
Anyway, I at least made some progress today in terms of understanding what's going on. And most importantly, I have some hope restored and some direction for tomorrow's work. Still no "silver bullet," but I have some footholds to stop my sliding downhill into despair :)
Hey folks! Hope everyone's doing okay. Feeling a bit defeated here, mainly due to programming woes.
I spent a bit more time trying to get flixel-ui's FlxUIInputText to work as a multi-line text field, but no dice. There seems to be some hard-coded behaviors in that class which assume a single line. Some hackery allowed me to input newline characters, but that still didn't solve the caret position and field height issues. Not wanting to waste too much time patching an unfinished system, I moved on to my next trick.
I had already started writing code the other day which dynamically replaced all FlxUIInputText fields with vanilla OpenFL TextFields. The nice thing about this is that those vanilla TextFields are a bit more robust. Multi-line input and line-wrapping work better, as does mouse selection and highlighting.
The trouble with that, however, is that they use a different display hierarchy than Flixel. So if I want to do any sort of scrolling/zooming of UI elements (and I do), it means manipulating both the Flixel camera and OpenFL rendering stack in tandem. And since each treat their stuff differently, this is tricky.
Worse, Flixel's camera.zoom seems to do weird stuff which makes it almost impossible to zoom out. The camera moves on-screen with each zoom, the bounds no longer fit, and even if I compensate for those, I get crashes below 1/8th zoom (which appear to be due to an invalid bitmap, probably either too big or too small to allocate memory for).
So, I put the Flixel/OpenFL mixed UI on the shelf, and started to take a look at a pure OpenFL UI. This is what I was using on NEO Scavenger's encounter editor, which mostly worked well for my needs. It was fast, zoomed/scaled predictably, and offered a lot of leeway in drawing.
However, I quickly remembered one of my frustrations with that setup: few out-of-the-box UI widgets to work with. Basically, a simple button and text field. If I wanted checkboxes, scrollbars, radio buttons, or anything else, I'd have to roll my own. (And probably hit many of the same problems I was trying to avoid by skipping the Flixel UI mentioned above.)
Finally, I took a stab at searching for OpenFL UI systems. And I found one! HaxeUI seems to be a very robust UI system including pretty much any UI one could want. It uses a variety of layout methods (XML or hard-coded), and could be skinned however I wanted. And since it used OpenFL, I still got the predictable scaling and scrolling I needed.
However, I forgot one other issue that I had with OpenFL in the NEO Scavenger encounter editor: text fields in native targets. Native C++ targets like Windows EXEs and the neko target had only partial text field support, ignoring crucial keyboard events like ctrl-A, ctrl-C, ctrl-V, etc. Basically, I could type, but not edit. Highlighting a bunch of text and hitting the shortcut to "copy" would just erase everything and replace it with the "c" character.
I don't think OpenFL has a fix for this yet. I saw a few whispers of a fix, but even when using the latest 3.3.6 lib, it seems broken.
I dunno. Like I said, I'm feeling a bit defeated. It's like I'm just hitting dead-end after dead-end here. Admittedly, this is just for making a tool to edit data. It's not actual game features I'm stumped with. And maybe I need to lay off the editor idea.
But on the other hand, my data is getting downright hoary. I need some better way to visualize what's going on if this game is going to get any more complex (spoiler: it is).
Unity's still out there, of course. But I have misgivings on that front, too. It's a lot of re-leaning I need to do, if I switched to that tech. It's a lot of dollars I need to lay down for each platform I want to target. A lot of the stuff is hidden behind their WYSIWYG editor, which irks me. And I don't like that they could vanish tomorrow and leave me with an expensive tool (and time investment) that's no longer supported.
Like I said. I dunno. Feels like a lot of dead-ends in here. I'd like to just be coding away making cools stuff, but it feels like I'm wrestling technology wherever I turn.
I should probably talk to some other devs. I'm in my own bubble here, and maybe self-defeating. There are lots of helpful people out there, and I know many of them.
Hey Folks! Hope everyone had a good weekend. We left the house with the baby this weekend, and made actual human contact! It was seriously good to interact with human adults for a while. They made us dinner, and it was awesome.
I also had some time to think about the whole HaxeFlixel/Unity crisis. One thing which occurred to me is that I was somewhat quick to jump to a wholly new technology simply because HaxeFlixel's multi-line input text wasn't working. A field I may not even need in the actual game, just the editor. And one which may get fixed over time by the community.
True, there are other frustrations I've run into, but I came to the realization that I would be discarding a huge amount of familiarity by switching to Unity. And in gamedev, familiarity with a platform is an oft-undervalued thing. "The Devil you know" and all that.
Also, one or two tricks came to mind which might allow me to work around the issue. All told, it gave me a bit more confidence to go back and see if I had exhausted all possibilities. 'Cause the last thing I need is to start from scratch at the first sign of trouble. (Which is a dangerously easy thing to do in gamedev.)
Cracking open the HaxeFlixel code again, I tried a few more things to get FlxUIInputText to work. In the end, I still wasn't able to wrest control of the text field's size, and the caret wouldn't ever move to subsequent lines in the field, even though I could type a paragraph of wrapped text.
Taking a leaf from my NEO Scavenger editing days, I tried replacing the FlxUIInputText with a standard OpenFL TextField. I had some trouble with that last week, which prompted me to abandon ship. However, a bit more finagling got it to work okay. It was able to line-wrap, move the caret from line-to-line, and even supported things like ctrl-A, ctrl-Z, and other common editing shortcuts.
The main trouble with TextField is that it uses a different display hierarchy than the flixel-ui. So they have to be moved independently, which means two sets of scrolling and zoom. The scrolling turned out to be simple once I took advantage of hierarchies and parallax. But the zoom is still causing issues.
The important thing is that these issues are purely math ones, and not shortcomings in the API. Figuring out the right scaling and position offsets is a solvable problem. More on that tomorrow.
That's about all for today. I'm happy to say I have renewed at least some of my faith in HaxeFlixel. I haven't written-off Unity just yet. It's a powerful tool, to be sure, but it didn't take long to realize I'd be starting near the bottom of another mountain if I abandoned my current trail. So for now, Unity remains installed. I'll probably tinker with it just because it seems interesting. But only in my "spare" time :)
Hey folks! After yesterday's work getting familiar with the flixel-ui and firetongue libraries, it was finally time to start trying them out.
I started by adding a name, description, target interaction point, and checkbox field to each interaction edit UI. Adding the fields wasn't too hard, once I figured out some text formatting stuff. And I was even able to add localized strings for English/German (well, fake German) using firetongue. And for good measure, I even chose a public domain font that supports lots of language glyphs. (Hello Latin, Greek, and Cyrillic!)
AND, flixel-ui even allows me to expose all this to modders, in case they want to change UI, localized translations, or even use their own ttf fonts. Pretty cool!
Now the bad news. Multi-line text inputs seem to be borked, at least in the build I'm using. They seem to display on one line only, and the caret (cursor) won't leave that line. Worse, editing breaks down once the cursor is positioned beyond the displayed text. Basically, this makes text editing impossible for anything except short phrases.
That's a bummer. And as a "Hail Mary," I decided to see if I could bypass Flixel's UI to use the standard TextField provided in OpenFL. It worked, sort of, but had its own set of problems.
So I had a bit of a crisis of faith. (In fact, this'll be my second one, but the first I've mentioned.) Maybe Flixel just isn't ready for prime time yet. Which is a shame. I really want it to be.
I think if I were happy with limited UI stuff, this may not be a problem. Flixel can do quite a bit of standard "game-y" stuff. But for more advanced things like this, I seem to keep hitting walls. My head can only smash so many before I get sore :)
So I decided to put Flixel aside for a little bit, and fire up Unity. I've never used it, so I'm going in blind. I already have a slight bias against it because it's a closed-source system. Having used a closed-source platform before (Flash), and having had the rug pulled out from under me with no recourse (Adobe abandoning Linux, and later, Flash itself), I'm loathe to put my future in another company's hands.
Plus, I'm already familiar with the OpenFL/HaxeFlixel tools and workflow. I can make stuff happen quickly and easily, when the libraries are working.
On the other hand, I need the libraries to be working. I need to be able to move forward with a feature without waiting for someone to fix code. I'd like to be able to use breakpoints in my code without relying on Flash targets. All of these things seem far enough into the future for FLixel that I seriously considered Unity today.
This, of course, all depends on whether Unity is as stable, feature-complete, and easy to use as folks say. And the only way to figure that out is to try it. Fortunately, they have a free personal edition for folks to test, so I fired that up, and I'm going to see how their 2D roguelike tutorial feels.
It may end up having it's own issues. I'm already running into situations where the editor does something unintuitive that restores something I've deleted, or deletes something I've created. And the UI gives me flashbacks to Torque3D. Not a good start. But in most cases, it "just works," and there are enough folks out there plugging away at it that help isn't ever far.
Who knows? Maybe it'll work out. I'll have to pay an arm and a leg to upgrade to Pro, but if it lets me focus more on making games than working-around/fixing the tools to make games, I'll pay the price.
More to come on that. For now, though, I need a beer. Have a good weekend, all!
Since the data editor is going to have a lot of text input and other UI elements, I decided to try flixel-ui again. It's the de facto way to do UI stuff in flixel, so I might as well see if I can get it to work.
A while back, when I last tried it, I ran into all sorts of library version conflicts, and gave up. This time, with some confidence borrowed from Lars, I tried again. I hit a compile error almost immediately, but decided to insert some shim code to hack my way around it until the libraries were more stable. It turned out to be a pretty simple null-pointer fix.
Once that was up and running, it was time to see if I could get text inputs added to my data editor for each interaction in the game. This turned out to be a bit trickier than expected, but only partially because I'm dumb.
You see, by default, text input fields are invisible. So I spent quite a bit of time pulling my hair out, trying to figure out why text input fields were missing, but all other UI elements showed up. An hour or so of tracing and stepping through code led me to the inevitable: it was working and my wrong assumptions are what sunk me.
With that figured out, I was back on the road to editor-making. As of now, I have a purple box on the screen for each interaction, labeled with the name. I want to see if I can get an editable widget for each of the data fields, and then do the same for each condition and condition trigger. Then, I can start linking them with arrows and arranging them on-screen so it's easier for me to keep track of how they link and interact.
Then, I think I can get back to this food-container problem I'm trying to sort out. Namely, I'll better understand how to hook food up the way I need to for it to be a consumable, contained item, using the interaction/condition system.
I finished working on the item placement UI helper today, and here's a shot of how it looks:
As mentioned yesterday, this helper UI is basically a red or blue square for each grid cell the item requires underneath. All items have a 1-cell padding around all sides to let me specify that one side must be a wall or open floor, as in the case of this bed. (So AI can approach it from one side, and bed attaches to wall on the other.)
Blue squares means this grid cell fits okay. Red means there's a conflict. In this situation, the bed mostly fits in the open floor, but there are two red cells at the top where it wants a wall, one on the left where the bed's foot intersects a wall, and one on the bottom left where it requires open floor.
I also placed a bed across the room, oriented 180 degrees so it attaches to the other wall. This allowed me to take a snapshot of it's interaction point, the little green dot to its left.
Interaction points are where an AI must stand when doing an interaction with the item. This interaction point is the default, but I setup the code to allow multiple points per item. This way, we can have the "use" interaction point be in one place, while things like "clean" can be elsewhere, since not all interactions are performed from the same place.
You can also see a small smush of white and yellow pixels further to the left of that bed. That's a placeholder food packet item, which I plan to use for item inventories. I want to setup the item system to allow for "free" items (which can drop on the floor, be picked up, carried around, and stored inside other items) and "fixed" items (which are things like furniture, lights, etc.).
I already have a "fixed" fridge item that dispenses food when an AI interacts with it. Now I want to make the fridge give a food item to the AI when it's requested, and the AI can later eat it. This'll require rewiring the interaction data for food, eating, and the conditions associated with them.
However, the test data is already becoming cumbersome to edit. As any modder can tell you, hundreds of XML elements can become unwieldy. And tracing from one XML to another and back again gets tedious.
Therefore, I'm going to see if I can setup some sort of in-game editor for these data types. This editor will show a UI per data item that can be edited, as well as arrows pointing to other data it references. This visual arrangement should make it easier to understand how all the data works and interacts, sort of like my Encounter Editor from NEO Scavenger.
And this time, I'll see if I can include the editor as part of the game. NEO Scavenger's editor required a database be setup on the local machine for editing data, and most users couldn't use that. But with separate data files from the start, this shouldn't be a problem.
Today's progress was impacted by a trip to town for some errands. Unfortunately, a shipment was late, meaning I had to sit around for a while and wait. So, I decided to use the time to work out some problems on good old fashioned paper. Namely, I wanted to see how I could represent complex equipment in the game. Here's the result
This is a crude representation of a nuclear reactor using simplified block elements on a grid (specifically, the cross-section of a tokamak's toroidal reaction chamber). Individual component squares are described in the key at the left, and their failure states are listed below.
I was trying to figure out how I could simultaneously let the player see and tweak complex equipment designs without needing to know nuclear and high-energy physics to do it. In this case, grid squares represent individual components of the reactor such as sensors, radiation shields, gas pumps, and magnets. Each piece serves a purpose, and if it fails, can cause issues ranging from fusion shutdown to containment breach.
The player may not understand how exactly this works, but they'd understand that the cooling superconductors, for example, are better if they cool more or use less energy, or even withstand more radiation before failing. So a player could theoretically see loot on another ship such as "Li-shielded superconducting coils" and look back at their existing "Unshielded superconducting coils" and think, "maybe these new ones would last longer?"
Similarly, if their reactor had a blown Deuterium pump, maybe they could turn up a replacement in a junkyard and install it, allowing them to power-up again. Or even keep a few spares on hand in the ship's cargo hold for emergencies.
The point of this is threefold.
First, it gives players a chance to tinker with ship designs in a more meaningful way. Instead of swapping "fusion reactor mk1" out and replacing it with "fusion reactor mk2," they can fine-tune the performance of their ship to their own tastes. Games like EVE Online allow ship mods, but they're limited to a few hardpoints and off-the-shelf systems. Gearheads like to get in there and mess with the guts.
Second, this makes failure more interesting. "How did your last character die?" "Well, the Lithium tank blew when we were en route to Jupiter, unloading gas all over the engine room. We were able to contain it by locking the room down, but the pressure drop caused radiation to start escaping the reactor. We either had to shut down the reactor and hope for a rescue, or limp with an unshielded reactor and hope we survived the rads..."
Third, I like this kind of stuff. Realism in sci-fi is more interesting to me than hand-wavium, and I love it when I'm playing a game that treats the subject matter with respect. And bonus if I can inspire players to learn more about these things (or even subtly trick them into learning)!
This may be pie-in-the-sky, but this seems a bit more workable than my original idea. (Which was basically to simulate all the science down to the atom. Yeah, I know. I have a problem :)
In other news, once I got home and back to my computer, I jumped back on the item placement problem. There was still a niggling problem of accurately showing where the current item would drop into the ship as the cursor moved around while at a non-zero rotation. This was just a matter of adjusting the item's offset for the rotation.
Then, just as I was about to start working on items-within-items (i.e. containers), I realized I should probably add some UI helpers to make my life easier. Namely, I need to see the current item's grid fitting rules and how that fits the ship underneath. Since containers will be leaning on grid-fitting a lot, it makes sense to tackle this first.
So I started work on a sprite overlay that shows me per-grid-cell fit feedback. This way, I can visually tell which tile is blocking the item I'm trying to fit, instead of tracing through code and checking each cell.
That's probably where I'll pick-up tomorrow. Have a good night, all!
Hey Folks! Hope everyone had a good weekend. Most of our weekend was, you guessed it, baby-related! Boy, they sure do eat up time. I did, however, get about 45 minutes to try out the Factorio demo. And, upon reaching the end, I threw some money their way. A very compelling demo! And since I kind of want interoperating systems on my spaceships, I thought it'd be interesting to see how other games handle them.
Last week's post about lighting and line of sight (LoS) prompted a fruitful discussion about the pros and cons of omniscient vs. single-avatar LoS for a crew-based game. We discussed merits of such games as FTL, Rimworld, and Prison Architect, and some of the gotchas to be watched for.
It's definitely given me some food for thought. One of the immediate changes it prompted was the ability for the LoS system to keep track of tiles that are undiscovered versus those that were previously discovered but are now out of sight. This way, a player could see the entire map of a ship they were familiar with at all times, but their LoS would restrict seeing things like creatures, fires, and other "live" data about a room. This is similar in principle to the NEO Scavenger hex map, where visited tiles are dimmed and one must be within LoS to see what's in it, while undiscovered hexes are black.
Ultimately, this is something that will require playtesting to nail down. It might not be fun to have limited view, and it might require LoS for all crew, or even omniscient view. But until I have more gameplay, I'll leave it with this NEO Scavenger-like map.
Putting LoS aside, I turned back to the items system. Specifically, item rotations. After looking into it a bit more, I was relieved to discover that the item data was easy to rotate. I was initially worried the item's grid-fitting data would require looking up a lot of special case fitting data, but it seems I can just rotate the item's grid fitting data without looking anything up. (Basically, imagine rotating a Lego so the brick's top dots are in the right place.)
It didn't take too long to get this working, though it exposed a bug in my array rotation code. Also, it looks like I need to do some translation offsets for the cursor when it is in item mode. The actual item grid-fitting position and cursor position become unaligned at certain rotations. Shouldn't be hard to fix, just a matter of finding the right offset calculations.
Once that's done, I should be able to place furniture against any wall. And then I can test interactivity (i.e. where AI must stand to interact with a rotated item). And beyond that, I think I'm due for some item/container code, so I can start testing items with limited supplies/charges (e.g. food cabinets, water faucets, etc.).
Hey Folks! As predicted, yesterday was a bit of a wash for productivity. Most of the day was chewed up by the baby's doctor appointment and a vet run. Fortunately, GOG.com's sale finale was worth writing about!
Even so, I did manage to get a small but important fix in for the lighting model. It corrected the star-pattern that was appearing in light calcs, which were due to the edges along each octant getting double light calcs in some cases.
And today, after some testing, tweaking, and feature-making, check it out!
What we see above is a combination of a few things.
First, the line of sight code is enabled here, so we can only see things that "Mal" can see from his current position. Namely, the current room, a bit into the blue room on the left, and a dark area of the room below (a bit hard to see, but there are totally dark tiles revealed down there).
Additionally, the fixed lighting model creates those nice blobs of color we see on the floor and walls. Light fades out from the center until it's gone, and where lights overlap, a blended color appears. It also uses the same line of sight checks that Mal does, to cast shadows. I ended up turning off symmetry in the visibility and shadow-casting code, as it looks better. I'll have to see how that affects AI later.
Finally, there are some snazzy glow effects on the map. I've seen some pixel-art games out there with some really fantastic lighting, and I wanted to see if I could replicate it. In the end, it turned out to be pretty simple to do. Each light has a "glow" image specifically tailored to it, and attached to it.
The light fixture itself is a dull cray rectangle (the lamp housing), and is hardly visible with the lights on. But the real magic comes from a wide bloom or glow effect, which is just a special image drawn with a soft brush and hard, bright center. The fixture is on the same layer as all ship items, like furniture, but the glow is on it's own layer atop that. This way, the fixtures can get the same tinting the rest of the ship gets, but a light's glow is not darkened by any shadows.
When you put it all together, I think it creates a really visually interesting space. It feels futuristic, and particularly with the glow, a bit cinematic, too. (Basically, it's a faked lens flare.) Colors can be used to set moods (cold and clinical, warm and inviting), and shadows can cast doubts.
There's way more that could be done, such as directional lights (flashlights?) or animated lights (sparks?). But for now, this should be robust enough to see if it's worth doing more. From here, I may swing back to item interactions and inventories, to flesh-out the crew sim aspect some more. I may also need to side-step into tool-making to help me manage the growing data files in this prototype.
And I'm also probably due for some NEO Scavenger work, if not a new build. Lots to do! For now, though, it's the weekend. Have a good one, all!
Hey Folks! I managed to get another day of mostly coding done, which always feels good.
First up was item placement. Yesterday's issue I noticed with the items ignoring placement rules turned out to be a minor one. For some reason, the check I added to make sure items couldn't be placed illegally was just being called in the wrong place. I'm not sure if I moved it when working on another thing, or if I was testing it some weird way. But after some moving around of code, that was working normally again.
Then, I wanted to see if I could expand yesterday's line-of-sight (LoS) code to also work for lighting. The good news, it does! It didn't take too much work to figure out how to use the LoS code to calculate where a light shines vs. casts a shadow. And it even supports color and color blending (e.g. with other, overlapping lights)!
The bad news: the way the light intensity diminishes over distance looks a bit weird. I'm still trying to figure out what exactly is happening, but it appears that the light goes really far in each of the diagonal and cardinal directions. So I get these sort of star-shaped patterns in lighting blobs.
At first, I thought the LoS code was somehow doubling up on those tiles. It uses something called "octants," which basically divides a full 360 arc into 8 equal arcs, and perhaps where those octants meet, tiles were getting light added twice. So I cleverly halved light intensity along each of those directions.
That worked at first (with a red light), until I started using other light colors. The star pattern seems to come and go depending on color, which means this may be a perceptual color blending issue. It also may be a falloff issue, since I was trying to do realistic attenuation based on inverse square law.
So as of now, I have a really cool lighting system with some distance-fading bugs, on top of a really cool LoS system. I might get some really neat ship interiors if I can get this working, so more on this tomorrow.
Which reminds me, I may not get much done tomorrow. We have a doctor's appointment for the baby, as well as a vet's appointment for the cat, so it could be a wash as far as productivity. I'll do my best, though, and maybe catch up in the evening or weekend. Or say "hell with it" and call it a day off :)
It was more realistic than a simple room-based system.
It was more efficient than my initial brute-force raycasting system.
It revealed walls along the edges of sight lines, unlike either of the above.
It was relatively simple to code.
It was guaranteed to have "symmetry," which is something I didn't consider when writing the first two systems. (E.g. if creature A can see creature B, then the reverse is always true)
What we see above is "Simon" walking through a room with a pillar, a fridge, and a bed with someone in it. He can see most of the room except behind the pillar, and a bit of the next room through the bulkhead. The yellow icons below each crew member are a debug icon I use to see their biggest concerns. The sleeping dude is worried about their level of achievement, while Simon is having trust issues.
After getting it running, it was actually a bit mesmerizing to watch. I could switch points of view by clicking other crew, and I set it up such that other crew and furniture disappear if they're standing on invisible tiles.
I think a system like this would offer many opportunities for gameplay features. Ship designs could take advantage of lines of sight to make observation deliberately easy or hard (smuggling? sneaking?). Firefights could use this system for better hit checks. Even systems that involve electromagnetic radiation (e.g. gamma and cosmic rays) could piggyback on this to see if a creature is exposed to a source. Or just plain lighting effects, for that matter. Handy!
Where to go from here will depend. I'd like to dig into the item system a bit more, and maybe model things like containers so the fridge can have limited food. I'd also need to model items that aren't fixed to the floor, such as a sandwich. Somehow the code to check if an item could fit in a space is being skipped, so I'll need to look into that. And items don't yet have any way of rotating to fit alternate layouts.
And that's just items! Still a lot left to explore, and we'll have to see tomorrow what's next. For now, have a good night!
Hey Folks! Hope everyone had a good weekend. This was our final weekend of having my folks visit to help take care of the baby. We said our goodbyes this afternoon, and we are officially unsupervised parents now :)
Even though Friday's post was about the discount, I did get some work done that day. It was limited, though. After my successes the day before with localized UI, I managed to screw up my Haxe libraries. This meant my prototype wouldn't compile, or sometimes, would compile but would immediately crash when run. I spent most of my day trying different combos of Haxe libs, and even some manual code patches to smooth things over, but wasn't able to do much.
So, I backed-out the UI and localization for now, and reverted to my working prototype code. I'll try again in a bit, perhaps paying closer attention to the library dependencies.
The work I managed to do, however, involved line of sight. I've been trying to figure out how line of sight might work in the space prototype. One of my early iterations was a brute force line of sight calc, which was a true raycast to each tile on the map. This was cool in that it allowed me to see down hallways, but also was expensive to calculate, and had some edge case issues (e.g. cannot see walls in the same room if at too shallow a viewing angle).
Investigating this further, I focused on a so-called "flood fill" algorithm to figure out the bounds of the player's current room. This works similar to how paint programs fill an area with a color (hence the name), and is fairly efficient. The downside, though, is that it's only a rough approximation. Line of sight is "all or nothing" for the current room, and one cannot see down halls.
Line of sight might seem a bit overkill for a grid-based ship sim, but I think it also might allow for some interesting gameplay. One need only look at NEO Scavenger's line of sight on the hex map to see how limited visibility can produce interesting situations. And in the cramped quarters of a ship, maybe even more so. E.g. "Is someone lurking behind that corner? What are those noises I hear from the next room?"
I'm also trying to figure out this game's eventual point of view. Should the line of sight be limited to a single crewmember (i.e. the player) or to all crewmembers? (e.g. FTL-style)
My first instinct is to limit it to a player-centric viewpoint. I kind of want to make the game focus on ship stations and controls instead of an omniscient viewpoint. E.g. the player can see things in their current room, or things on the control panel they're using.
But if the player wants to see the activity in the galley, they need to either walk there or install CCTV in their ship. I think this approach lends itself to the most suspense and drama, as the player is left to wonder what happens behind closed doors.
One alternative is to make all crew's sight visible to the player, like FTL (or X-COM). This still allows for some suspense, but changes the feel of the game from occupying a person to experiencing all the crew's lives first-hand. Not necessarily bad, as Firefly shows us, but a different experience.
And a final option is complete omniscience, like Rimworld. I'd kind of like to avoid this, as it exposes a lot of what might make for good mystery or drama. It's a bit more fun to watch in a "fishbowl" sort of way, but dampens the suspense a bit.
What I eventually choose, however, is going to depend on how it feels. And for that, have to test and iterate :)
For a limited time, you can get NEO Scavenger for half of it's normal list price. And while you're there, check out the many other games featured with up to 80% discounts!
Or, if you're feeling adventurous, try giving the piñata a whack! Every Indie Piñata costs $3 (or your local equivalent) and includes a random indie game that GOG.com thinks you should play. The Piñata can include games anywhere from ~$9.99 to ~$44.99.
Note that NEO Scavenger is not inside the Indie Piñata, so if you want NEO Scavenger specifically, you'll have to purchase it directly. However, there are reports of some very cool games coming out of the Indie Piñata, and the selection changes regularly!
I finally had more time to dedicate to development today, and decided to tackle two things.
NEO Scavenger Changelog
First, I finished up a draft of the changelog I mentioned yesterday. As of today, if you visit any NEO Scavenger page, the navigation menu will include a Changelog button. This changelog lists most of the game's change history in reverse-chronological order, with build IDs, dates, and expandable lists of changes.
I had to stop at September 2012 because it would've taken a lot of manual transcribing to do earlier builds. I do mention how to find those, however. And there is also a link to Game Dev Gone Rogue for those interested in ancient history.
Prototyping UI and Localization
The rest of the day, I decided to check out some of the UI and localization stuff available in HaxeFlixel. Lars created a handy demo which shows off this built-in UI system combined with the Firetongue localization library.
What exactly does this mean? Basically, it's a way to define the game's UI using XML files and images instead of hard-coding them. And the Firetongue addition means it can be localized into different languages using data files. After seeing how many people wanted translations of NEO Scavenger, I definitely wanted to explore this option for future games.
The good news is, this seems to be working without too much trouble! I have my latest prototype using this new UI/localization system on the main menu, and I can dynamically switch between languages. It took some doing to get all the plumbing in place (lots of xml, csv, png, and ttf files), but it should be easier to modify and maintain than NEO Scavenger was, since all the text content and layout is separated from the code into text files.
I have yet to use this in a production environment, so I may still encounter issues with large-scale use-cases. But for now, this seems like a promising way to make future games ready to accept translations!
Also, one of the other things I want to explore soon in my prototype is adding various UI elements for ship features. So this is a bit of a foundation step in preparing for that.
It's about quitting time here, though, and baby's starting to cry. So have a good night!
So today was a bit of a bust. I got very little done due to a server update I applied.
I have a server (NAS) running in my apartment which I use for storing the version-controlled files for all my projects. Last month, I updated the server's OS for a security update. Unbeknownst to me, this update wiped out my version control installation on the server, causing my development machine to complain of network connection errors when I tried to update my code this morning.
After hours of debugging, I eventually figured out what happened. And after more hours of helpless trial end error, I finally found a solution in a dusty corner of the web.
It turns out the OS's new way of handling my version control was not running because of an old setting from the original. Removing that setting and rebooting the NAS got things working again. I wouldn't have found this single line of config if it weren't for a forum deep on the web.
The good news is that it seems to be up and running again, and I can update my files normally. But it pretty much killed any progress today.
The one thing I did manage to do in the remainder of my day was to finish a collapsible, html changelog for NEO Scavenger dating back to September 2012. Some folks have been asking for it, and I think I'll publish it on the game's download page for those interested. As said yesterday, it's a bit redundant this late in the game for NS1, but I hope to make it a thing for all future games. Saves folks the trouble of searching for "New Beta Build" for info.
Also as said yesterday, I should make better use of the title screen in future games for broadcasting relevant info.
For now, though, time to sign-off and mind the baby. Have a good night, all!
I'm back! It's been a long (and often sleepless) month, but we're finally getting the hang of parenting enough for me to start working again. The baby is healthy and has three stat bars: food, poop, and sleep. They run down about once per 2.5-3 hours each.
The first order of business was to quickly run through the forums and catch-up here and there. I definitely couldn't cover them all, but I tried to get up-to-date on the tech support at least. And while I was doing so, I fixed a few minor bugs in NEO Scavenger's St. James Parkade and creature death code.
I also caught-up with the contractor who's helping me with NEO Scavenger mobile. Not playable yet, but I was able to get character creation screens displaying on Android, and could manipulate skills on the PC (Haxe Neko) version of the mobile engine. Steve says he should be on track for a more playable engine next month, so fingers crossed!
Finally, I decided to look into a changelog for NEO Scavenger I can post on the website. It's been requested a number of times, and I never got around to it. Since I haven't yet ramped-up on prototype work after paternity leave, I figured the website could use some love.
It's admittedly a bit redundant now that the game is almost a year old, but it'll be good to have something setup for this to use with future projects, too.
Speaking of meta-game data, I recently started playing both Rimworld and Duskers, and I was impressed by the messaging both devs had on their games. Rimworld had some really nice links on the title screen for things like the dev log, wiki, setting info, and other relevant data for players and modders. Duskers had a handy development meter on its title screen, as well as links on the menu.
And, of course, they're both really cool games :) (Rimworld in particular is a bit like what I have in mind for the new crew-management prototype, so I had a lot of fun scratching that itch in between diaper changes.)
Anyway, things are spooling-up here, and hopefully I'll be back to full speed soon!