Hey Folks! Today was a continuation of yesterday's flight management UI work with some tax spelunking thrown in for good measure.
The tax situation has improved slightly, as I did some more reading, and I think I can sell the Android version in the US, Canada, the EU, Brazil, Australia, South Korea, and Norway while only having to handle sales tax for Washington, US customers. Possibly Japan, too. That may not be too bad. But it leaves a vast swath of the world in question. (E.g. Russia, China, India, Mexico, and about 100 other countries)
Still looking into my options here.
Back to more exciting stuff, behold the first draft of the orbit renderer!
I finally bit the bullet and just bought Vectrosity for my line renderer. Figuring out a homemade solution was taking too long, and for $29.99, the problem was solved instantly and for less than the cost of me noodling endlessly.
Well, nearly. Getting lines on the screen was instant. It took about an hour to figure out how to get those lines to stay bounded within a UI area, and to give them the style I want.
And speaking of style, how about that glow! I took a few cues from current flight navigation systems, which have this neat look to them. Limited color, simple vectors, and piercingly bright lines. I had to play with textures a bit, and it uses a slightly altered standard Unity shader for the additive blending. But I think it looks pretty lively, and I like that it resembles actual aviation controls.
The screen glare may be on the chopping block. Part of me likes it, but it also seems to compete with the lines (and I think the aircraft versions are glare-free anyway). Still, not a bad haul for the day! I can't wait to start plotting celestial objects on there :)
Finally, I wanted to give everyone a heads-up that I might be out of the office more in the coming 2-3 weeks. My parents are coming to town to visit, and I'll likely spend some time with them. I'll probably still be working part days most of the time, but if I'm slow to reply to something, this is why! And as always, email is the best way to reach me if something comes up that requires my attention.
Hey Folks! So my foray into flight management continued today, but I hit a bit of a downer early on.
Basically, I discovered that selling apps and in-app purchases on Google Play means I'm going to have to figure out sales tax for any region I sell to. This means calculating, collecting, and remitting sales tax for my home state in the US, and if I understand correctly, every other country (and in some cases, each province within a country). The one saving grace is that Google handles VAT for EU purchases, so at least I don't have to handle that mess. But still, Japan, Korea, Australia, Canada...the list of tax regions in the dev console has got to be in the dozens. Maybe over 100? And they're all different, all can change rates and laws at any time, and all require regular reporting.
This just went from "another one-time setup headache" to "another recurring headache." And to make matters worse, Google still charges the 30% transaction fee for...what exactly? Apple charges 30%, but they handle taxation. Heck, FastSpring does it for 10%. And just about every other store I've worked with does taxation for devs, too.
And for good reason! Devs don't want to deal with this. Devs probably won't even get it right if they try. The number of conflicting reports out there on what people are doing is absurd. Ugh. Seriously considering ditching Android after this. But maybe I'll sleep on that a few nights while I weigh the pros and cons.
In better news, I've managed to get started on the flight manager UI:
Before spending too much time on layouts for the main ship controls, I figured I'd at least try to get the orbital position plotter up and running. It'll be useful for debugging flight, and be a good basis for other line-rendering tasks.
The trick right now, however, is figuring out how to render lines in Unity's 2D mode. The magenta lines you see above are the "LineRenderer" component, which is the built-in method for rendering lines in Unity. They look fine in 3D, but they disappear to nothing in 2D mode. Probably due to the camera's orthographic settings.
Some other methods appear to be hand-crafting my own quads in code to make line segments, which is reportedly fast, but is likely a huge headache to manage. A third method is a direct OpenGL call to draw pixels, but I'm not sure I want to go that low-end. Probably super fast, but also super basic.
There's an asset in the Unity store called Vectrosity which seems like it might do the trick. Basically a custom line-rendering utility for any style or shape. So I may check that out.
And, of course, I could also delve into shaders. Maybe I just throw a quad up where the display UI should be, and use a shader to draw pixels right on it? That opens up a lot of options, and might even be the fastest. But I need to explore it a bit more to know for sure.
Anyway, busy day today! Unfortunately, busy in some boring ways. Hopefully less of that tomorrow!
Hey Folks! Finally decided to get back to the space prototype today. With Tiago working on the UI zoom feature, the web team working on the first functioning site draft, and a game title that is still (fingers crossed!) viable, I figured I'd turn my attention to the neglected prototype.
First order of business was to figure out where I left off. Some devlog digging reminded me that I figured out how to connect functional UIs to interactive objects, so we're starting to get player control over ship systems through control panels the AI uses. Also, after adding that feature, I broke AIs' ability to open doors without player intervention.
As a quick warm-up, I decided to tackle that AI regression bug, and a little while later, AI was opening doors again. (And a related null pointer bug squashed as a bonus.)
Then, I decided to take a step back and assess things. My main questions was, "how can I get this prototype from it's current state to something enjoyable in the shortest number of steps?" It's not a game yet, so why is that? And what things can I add to at least make a minimum viable game loop?
After a bit of brainstorming, I think there are two areas I could tackle: navigation and ship design.
Navigation means making the ship go places. Right now, the ship is just a hunk of tiles with crew running around on it. It doesn't go anywhere. It uses no fuel. It is not subjected to space hazards like temperature or radiation or micrometeoroids. It doesn't visit a planet or asteroid, nor dock with a station. If I could get some UI in place to make the ship go places, I could start tying-in other things like making sure the ship has enough supplies for long trips, ample shielding against radiation and ballistics, and other voyage needs. Players could at least start enjoying prepping for a journey, plotting a course, and seeing if they survive the trip.
Ship design means making enough ship systems such that their interplay is interesting to balance. Like in NEO Scavenger, if there are enough related systems with inputs and outputs, it can be fun to design and optimize the collection of systems to work efficiently. In NEO Scavenger, this meant keeping Philip warm, fed, rested, hydrated, and meeting his other physiological needs. Often, satisfying one need meant detracting from others, so it became a game of choosing the right combination and order of operations to keep him alive given the constraints of what was available.
Similarly, each ship system is going to have certain input and output needs, and their performance is going to affect the health and happiness of the crew. Optimizing the available systems to some viable configuration and watching it go can be a game in itself.
Ultimately, both of these "games" are part of the bigger game I have in mind. So if I can tackle one or both of these ASAP, maybe people can start to play it?
For now, I've decided on the former: navigation. I have an old orbital navigation prototype I whipped up in Haxe, and I think I can port it to Unity and start working from there. It should at least allow me to see orbital positions of things and control the position of the ship among them. I'll probably rig this up to a ship control panel, just like the HVAC switches from before. And then, the player can assign an AI to use the panel, and the player starts using buttons and knobs to fly around the system. Maybe they can resupply power, atmo, food, water, and other things at each dock? And maybe this can dovetail into the second game loop above?
I think we may have a winner! After a list of progressively shorter game titles, I reached a point where I thought, "okay, this is getting so short that it no longer tells anything about the game." Plus, the logo looked nicer, and more akin to NEO Scavenger's, if I made it longer again.
So after some more word-searching and tweaking, I think I've finally arrived at a safe title. No competitors so far. Some room for interpretive meaning. Logo looks good. Words in the title hint at some relevant game things. It's not perfect, but I'll be here all year if that's my goal. So I'm going to give it another night or two to check for staying power (and any IP conflicts).
In the meantime, I started tinkering with some title screen treatments for the game. It's not strictly necessary at this early stage. But it'd be nice to know how I'm going to present the game to the world, from a marketing point of view. Are there any thematic colors? Textures? Imagery? I may not arrive at answers to these questions before I reveal the title, but it doesn't hurt to explore these questions for a bit before I do.
On the mobile front, Tiago and I discussed micro-UI problems a bit more, and we decided to try out pinch and spread as a gesture to access some of the more crowded UI items in NEO Scavenger. The holy grail of this exercise is to be able to pick a tiny object like a glass shard or lighter out of a cluster of tiny objects using one's finger as an input tool, move it to the desired container, and fit it into a slot.
So far, this has proven to be tricky, even on 10" screens. The precision just isn't there with a fingertip. And this pretty much makes or breaks the game experience. So we have to get it right!
Anyway, this is our current focus. And with any luck, this experiment, or the zoom lens, or perhaps a combo of the two, will get us there.
Hey folks! Hope everyone had a good weekend. Mine was actually a nice, relaxing one. And for some inexplicable reason, I had a burning urge to make a first-person shooter all weekend. Still like the idea, which means it goes into the old idea folder for another time when I'm unshackled by responsibilities :)
First order of business today was to check out Tiago's latest work on mobile. It was a productive week for him! And I had my first taste of the pop-up "zoom lens" feature for making UI easier on smaller screens. So far, it has potential, but there was one major issue with it that prevented me from making full use of it. And getting it here has been tricky to say the least. So I've posed some questions to him about whether we should push on in this direction, or maybe try pinch-zoom or an offset cursor before investing more time in the lens.
And as with the past couple of days, I continued working on names and logos for the new space prototype. The latest one has survived three days without me finding a conflict, so that's good. But it's an extremely ambiguous title, and so short a title that it doesn't have the same nice look as previous, beefier logos. However, the ambiguity of the title is also really neat, with some cool things to be read into it, so it might make it worthwhile.
Anyway, not there yet. I still want to vet a few more options before committing. More tomorrow!
Looks like that name I was crowing about yesterday is also already another game. This one not-yet-released, but legit enough to warrant a course correction. I mean, it's great to be discovering this all now rather than after I've launched. Saves me the trouble of rebranding and confusing fans. But still. Sheesh! I can't seem to win on this one.
Back to the drawing board.
In better news, I actually got a bit more mobile bug fixing done today. I managed to solve a bug that prevented ingredients from being removed when reverse-crafting, added a way for touchscreen users to toggle stack/single item mode (via context menu for now). I also made a few tweaks so that this was still compatible with the desktop version (since this will likely be NS2's engine).
It felt good to be solving a few things. I definitely needed some victories to raise the spirits.
That game title, though. Man! Let's see if fresh ideas come to me over the weekend. Have a good one, all!
Well, it looks like I messed up. The name I had been running with is actually already used by another recent game. Which is a pity, as I was really starting to like the logo.
On the plus side, however, the part I liked most about the logo can remain, and the part that needs to change is really easy to change. So I set about vetting some alternate titles today, and I'm narrowing the field. In fact, I may have an alternate that works even better. Score one for constraints producing better work, I guess?
I also did a bit more mobile debugging today. I think the new demo data file I worked on solved one of the skill-select problems we were encountering in the demo. However, as I went to test some other demo limitations, I noticed the demo region of the map wasn't working as intended. "Cool!" I thought. "Maybe I can fix that!"
Turns out, maybe I can't. At least, not yet. I got tangled in the mouse vs. touch input code, and I may need to defer to Tiago's skill in this area. Or at least approach it with fresh eyes. It was good to get in there, though, if for no other reason than to learn a bit about the new mobile code.
Also, I've been running into motivational walls off and on this week. I think it's been a while since I've had a visible, measurable success that I could share, and that always cuts my momentum. Hopefully, tomorrow is more inspiring (and productive) for me!
Hey Folks! Still working on demo and logo today, and while the latter is certainly something to look at, I don't want to release it before I'm certain :)
The demo took the bulk of my day, as I finished upgrading all the encounters, triggers, creatures, and other bits from the old demo build to the new full version's engine. Quite a bit of data had changed, either from bug fixes or from new features (e.g. point-costs for skills), so it was a lot of file-diffs and judgement. I think the data is done now, though, and we can resume work on the code aspects!
And for the logo, I'm still trying to figure out a treatment for the "A NEO Scavenger Story" subtitle that works with the new game's logo. If you can imagine, the new logo is a lot like the NEO Scavenger one, except upside-down. Some treatments make it look too tacked-on, like it doesn't belong. On the other hand, integrating it too much results in it being too busy-looking, and hurt legibility. I've only just tried a few variants at this stage, though, so we'll have to see.
Hey Folks! Not much to show today, as it was more behind-the-scenes type stuff. Though some of it was still fun.
First up was a conference call with the web development firm. We went over the latest mockups, and I think we're pretty settled on the new design. The next step is for them to make an actual web layout based on our mockups. And I'm pretty excited about how it's turning out. We're gonna really class-up the joint :)
I also sent word to Josh that his first track is "approved." It sounds good, and I can't wait to sneak it in somewhere for y'all to hear!
Lastly, I've resumed converting the old NEO Scavenger demo XML to work with the new mobile engine. So far, I've covered treasures, recipes, maps, and I'm partly through items. This is a long list, though, and will take a while longer.
Once done, however, we should have a working mobile demo build. The plan at this point is for the demo to be free for all to download and play on iOS and Android, with an in-app purchase to unlock the full version. Hopefully, the free demo works as well on mobile as it did on PC enticing players to go for the full version. Most folks seem to agree the upgrade was worth it!
Hey Folks! Hope everyone enjoyed their weekend. We had a dinner guest Saturday, and that meant wine and steamed mussels. A nice treat! And a bit of a rough next morning :)
Also, a lot of content has piled-up over the weekend, as I had new website mockups, a new track from Josh, and a new mobile NS build all waiting for me this morning. Lot's of catching-up to do!
I tackled the website first, since that was first to arrive, and needed the most feedback. I think it may be near the final design iteration now, and I'm liking how it turned out. It's a bit of a leap away from the original concept I pitched, but as we tossed ideas back and forth, I think we've arrived at this new theme in an organic and sensible way. It makes a lot more thematic sense, too.
Next up is the new track from Josh. He shotgunned a handful of test tracks at me a while back to see which was closest to my desired direction, and this is a revision of the one I liked best. I've only been able to listen to it once, but it's sounding good. Very evocative :)
And finally, I have that mobile build to test. Been a while since I fired-up the iPad or Android, so it'll be good to get reacquainted with where it's at.
Hey Folks! Split the day 50/50 on mobile and space prototype today.
The mobile work was fixing buttons in the new engine. There was the seemingly minor issue of some buttons remaining highlighted after being clicked when they shouldn't be. I figured this'd be another simple one to snipe while Tiago handles bigger fish.
Turns out, I made a special button class to do...something back in NEO Scavenger, and now, it has problems. It seemed like a simple fix at first, and the more I dug, the more issues I found. In the end, the fix actually was pretty simple, but the number of times I had used the button in GUIs meant that I had to check each case and adapt it to the fix. Basically, the bug that was there was being used as a feature in many cases, and I had to adjust the code in those places to use the fixed button correctly.
Later, I turned my attention back to naming NEO Scavenger's space prototype. I think yesterday's name is still holding up well after a night of sleep, so that's a good sign. I've tweaked minor details in the name for a bit to arrive at something with less chance of IP confusion, and then started tinkering with logo ideas.
After a few hours of work, I'm starting to find a logo I like. It borrows a lot from NEO Scavenger, which I'm hoping will help name recognition. I'll still need to work "...a NEO Scavenger Story" or similar into the logo/title somewhere, to seal the deal.
That's all for this week. Have a good weekend, all, and see you Monday!
Hey Folks! Mostly focused on more title brainstorming today, continuing yesterday's efforts.
I've got a growing list of ideas, including several submitted by readers. And despite several valiant attempts at bending the "NEO Scavenger" nomenclature into spaceworthiness, I think I'm leaning towards the title/subtitle combo format. It directly links whatever I choose to the original game and setting, and offers me a ton of freedom. It also pretty well shields me from any trademark issues, since the subtitle clarifies the context of the title as not being any other IP.
And fortunately for me, there appears to at least be a consensus that the "...a NEO Scavenger Story" subtitle is preferable :)
I briefly looked into a few other IPs that do many stories, such as AD&D, Forgotton Realms, Dark Sun, etc. Though they appear not to link the setting to the title other than in placement on product covers. I.e. they don't say "The Crystal Shard: A Forgotton Realms Book." If anything, they tend to lean on trilogy names, etc.
After today's brainstorming, I think I've got at least one candidate I'm going to move to the next step. Going to give it overnight to percolate, though.
Hey Folks! Spent most of the day tackling some more mobile bugs today. I actually managed to fix two more!
The first was a bug with item mirroring. Items such as shoes were not appearing mirrored when they should be, both while uninstalled and installed on a socket. This turned out to be related to the way the new engine loads images. It uses sprite atlases instead of individual images, for performance reasons, and this meant some differences to how sprites get flipped horizontally. I was able to consolidate the mirroring code, and all seems well now.
The second issue was causing water to not go into bottles when released. As it turned out, bottles were being flagged as non-rigid, again due to the atlases. In this case, because atlases rotate some images to pack them tighter, the full/empty images for the bottle were at different orientations, and the game thought that meant it changed size when full. A bit of extra handling code in here fixed that, and I could store water again!
Both are pretty minor bugs, but I'm still coming at the list from the easy side while Tiago tackles the hard stuff :)
In other news, I took a bit of time today to start brainstorming name ideas for the space prototype. I've had a few in mind already, but haven't found one I'm crazy about yet. Some of the criteria I'm trying to fulfill:
Does it sound interesting enough to warrant a further look?
Is the name likely to be confused with or infringe upon another product? E.g. other games, shows, movies, toys, studios, etc.
Would Googling the name result in this game, or something else?
Are the URL and Trademark taken?
Does the name communicate that this is related to NEO Scavenger?
Does it communicate that this is a parallel story?
Does the name imply spaceships?
Building and customization?
Solar System travel? (As opposed to interstellar travel.)
Is it easy to say/hear in a loud environment? (Seriously, imagine telling someone the name at a concert. Does one have to spell it out letter by letter?)
Can it be made into a good logo? (What if "NEO Scavenger" words have to be part of the logo?)
Obviously, this is a tall order to fill, and some criteria may be mutually exclusive. Even NEO Scavenger fails some of these. But it's important to consider these things, and at least try to get as many as possible.
The big ones, though, are the first 4.
One trick I'm considering is the combo name, a la Star Wars and other franchises. Namely, "Blah Blah: A NEO Scavenger Story" or "NEO Scavenger: Blah Blah." This knocks out a lot of the confusion and IP law issues almost immediately. But it's a mouthful, hard to logo, and may have other issues.
So that's on my mind. I'm getting tired of calling it "NEO Scavenger: Space Prototype." YouTube videos ask for a game title to tag it with. People are trying to tell friends and have no name to use, etc. It's coming high time I nail this down :)
Good news, everyone! Joshua Culler is officially signed on as composer for the space prototype!
NEO Scavenger players will recognize his work as composer on the 2014 game, and he's also been busy working on the Underrail OST. His signature style has lent an eerie, gritty atmosphere to NEO Scavenger, and I'm glad to have him contributing to this new venture.
It's still early, and we're tossing ideas around, but his sample work so far for the new game sounds good. Can't wait for you all to hear it!
In other news, I fixed my first NEO Scavenger Mobile bug! With Tiago focusing on some of the more high profile bugs, I've decided to try and snipe some of the simpler ones. It not only frees him up to do the heavy lifting, but also gives me a chance to familiarize myself with the new engine code. Fortunately, most of the code looks similar to the old code, as Haxe and AS3 have similar syntax. But there are some differences in the plumbing, such as data loading, image and sound handling, etc.
The list of bugs is currently slightly increasing as we find and fix at about the same rate. However, we should soon be transitioning into pure polish and user experience enhancements soon. And once that's done, I have to figure out how to coordinate the mobile launch and PR, the new website, a possible new desktop NEO Scavenger patch, and maybe even an official space prototype naming and announcement.
Some of you rightly pointed out last week that the video leaves a lot to be desired in terms of context. So today, I've recorded a longer video where I explain a bit more about what's going on. So without further ado, context!
Hey Folks! Finally got the minor toggle issues squared away this morning. Not perfect, but it's working well enough to move on. And I was thinking a next step to try is wiring these toggle switches to something more significant, like air pumps.
As you might remember, I created an airpump and air tank, as well as some gas simulation code for ships:
Pumping air works, but it's really hard to tell from the player's perspective. Is that room pressurized? Or a vacuum? Without the debug overlay, there's no way to tell.
So one thing I'm going to add is a visual indicator lamp that players can place in rooms:
There are three such indicators in the above image. From top to bottom: unpowered, unpressurized, and pressurized.
It's a pretty simple indicator for now. It only cares that the room has some minimum (i.e. safe) pressure. I have yet to finish the code for these, but I'm hoping that with enough of these around the ship, players can tell at a glance if they're in trouble or not. It's a bit more immersive than a colored room overlay, too.
And it also gives me a chance to test the power/signal conduit stuff in another example. I can hopefully hook up some pumps and air tanks around the ship, and use switches to turn them on and see rooms turn green.
In the future, I may need more specific indicators (e.g. O2 levels, toxin detection, etc.), and probably additional indicators for things like fire, general alarm, etc. But for now, this is another good building block!
Hey Folks! I finally got the toggle UI functional! After several days of writing code I'm not sure I understand anymore, I was able to setup this really basic example:
In the above pic, the right side shows the ship layout, and the left side shows the Toggle UI.
The ship is little more than the bare minimum to test remote opening and closing of airlocks. It has one "fore" airlock (top), and one "aft." The Toggle controls are barely visible as some dots on the wall behind Bedford. Yellow conduit runs from the controls to the aft airlock, and red to the fore.
On the left, the control panel is on the top, and its inner wiring on the bottom. The various toggles have labels and are currently set to "OFF" (closed). Inside, there are a pair of input screws for each toggle. And each screw takes a pair of data: the remote object to control, and the interaction to perform on it. So the first two screws are the on and off for the airlock connected by yellow, and the next two are the same for the red. The last four inputs are not hooked-up.
Also, in this screen the user can change the labels over each switch. Just click the text and type.
Once the wiring and naming is finished, the user clicks "Done" and the panel returns to the switches and labels view. And all of this is overlaid on the screen, covering the ship while active. There's a separate button to close the UI and return to managing the crew.
The exciting part, though, is that I could flip those two toggles, close the UI panel, and watch as remote airlocks opened one by one. Sort of a happy coincidence they did so sequentially, as the toggle has its own interaction queue to go through while opening them. I may have to change it to be instant so the player can change the ship without having to close the UI and wait for changes to happen, then reopen the UI to continue making changes.
Anyway, it was a cool feeling seeing this work after all this coding. It's really getting messy in there, and I'll probably need to spruce it up a bit to at least make it more maintainable/extensible. But for now, I can hook up switches to remote things!
Hey Folks! Hope everyone had a good weekend. As most of you probably guessed, I was OOO yesterday due to the national holiday. I'm back today, though, and cracking away at this toggle UI.
I'm getting close, but still running into issues. As of today, I can now wire-up my toggle switches to do one thing when "on" and another when "off." It'll show the user what items are connected via conduit and which support interactions, and the user can simply press the button for the desired interaction on each toggle's inputs.
So far, so good, but I'm running into an unforeseen issue: null references.
Whenever an item undergoes a "mode switch," such as an airlock changing from "closed" to "open" mode, this basically deletes the old object and adds a new one in its place. And because of this, there are some tricky issues with item references. Things like the toggle switch are going to need to be able to update their connections to the new mode's item after the old one is deleted.
And, surprisingly, this has revealed a bug in the bracket selection code. I'm still tracking it down, but it appears to happen if the AI walks through a door while another door is selected, and then I try to select another door. I think the mode switch on the door the AI uses is causing a bracket target switch when it shouldn't, leaving it pointing at the deleted door.
I'll have to look into that some more tomorrow. That's all for today, though!
Hey Folks! I've almost got this toggle panel running in-game. I added the requisite data in the game files for it, cobbled together a tile sprite for the ship, fixed up some bugs in the code, and we're just about there.
Currently, there's an issue with setting up the input screws, and this appears to be due to a piece of data I missed. I have to specify the condition trigger (i.e. filter) to use for determining whether a remote item is a valid connection. So this will probably have to be some sort of filter that triggers on "IsToggleModeItem" or a similar condition.
And once that's done, I'll have to setup an actual mode for an item to toggle into when the switch is flipped. This means both creating an item in this new mode, and the interactions to switch it to and from that mode.
Then, I should be able to wire this item up via conduits, connect them to the screws inside the panel, and flip the toggles to see the item change modes on the ship. Airlocks will probably be the easiest, as they already have the modes and interactions done. I just need to setup the filter to find them and/or setup properties on them to pass the filter.
Should be fun remote-opening airlocks around the ship :)
Some of you are also probably asking about how the heck a player is supposed to make heads or tails of this system. It's a good question, and one I'll have to figure out. So far, I'm thinking most of this hard work will already be done by me as I create items of different types and the logic to connect them. The user will just have to choose from existing stuff in a point and click way.
E.g. the user won't have to create airlocks, interactions, filters, etc. They'll just choose the control panel from the building palette, put it into the ship, and start connecting conduits to it.
Modders, on the other hand, will have to know the system a bit more intimately. But even then, I'm hoping that having basic examples of each type of thing already in the data will make it easy for them to copy+paste and edit their copy, instead of having to do stuff from scratch.
In theory, of course. Everything is always in theory with me :)