Atmo Pump 1 is Go. Atmo Pump 2 Is Go...

Hey Folks! I think I've finally got the GUI system behaving as it should. I had to make a few more changes so each item could list more than one copy of a GUI type at a time, as well as some code to make sure each GUI's settings were being saved and restored correctly. That goes for both changing scenes in-game, as well as saving out to a file and loading again between sessions.

Coupled with a minor fix to the unique ID system to avoid creeping IDs between scenes, and I was finally able to edit, save, load, and use GUIs!

Unsure what to do next, I decided to fire up the ship editor and start tinkering with it. And after a little bit, one thing was clear: it is really easy to misjudge how big a ship needs to be.


"We're going to need a bigger boat."

The ship above was just a shot in the dark outline that I then tried to fill with rooms and equipment. Not a lot of room once you start filling-in walls and equipment! As I started to visualize where the HVAC and conduits could go, I decided the next thing to work on might be an interactive control panel:


16 switche- Okay, only 7.

This might be a good stepping stone for working my way towards full ship controls. With toggle switch UIs, I could wire-up things remotely and have AIs control them from one room. And assuming that works, I can try something a bit more complex.

A Little Bit of Everything Day

Hey Folks! Hope everyone had a good weekend. I got off to a late start today, but still managed to get a little bit of everything done today.

Most of the stuff was administrative. Chatting with Josh about the soundtrack contract (space game), a conference call with the website developers (website), and catching-up with Tiago (mobile).

However, once that was done, I decided to jam in what prototyping I could in the remaining time. And in fact, I tackled more than expected!

More specifically, I made a few changes to the way shipboard items store their GUI settings. Last week, I was trying to store a list of settings on the ship, and have each item point to one of those settings bits by name. That mapping was turning out to be pretty complicated, though, and making sure the data pointers survived saving/loading might have been problematic if the item IDs had to change from one session to the next.

So now, the settings to use for each GUI an item supports is stored per-item. I've basically cut out the middle man, avoiding the issues of links getting broken between sessions.

I think I did, anyway. I still have to test whether json coughs on the nested data structure. But if this works, it should simplify data (and code) a fair bit!

Mobile Data Loading and Space Prototype GUI Work

Hey Folks! Bit of a mixed day today. Mobile-related work in the morning, and space prototype in the afternoon.

The mobile stuff was pretty light today. I chatted a bit with Tiago about how we should load and override data in the new engine. And apologized for subjecting him to the Troy-like legacy code on top of legacy code he has to sift through. Over the course of its history, NEO Scavenger has alternately loaded data from databases directly, remote PHP files, embedded XML files, external XML files, external XML files across multiple folders, and finally, multiple external files within multiple folders.

Needless to say, the data loading code is like archaeology.

The space stuff I did today was focused on the GUI system. I got the system limping last week, and the next step is to get it loading, storing, and saving data set by the user. That, and to have reasonable default/template data in cases where the user hasn't set anything yet.

The majority of the work today was refactoring who stores what data and how to set and access it. The way it was setup before took me too long to figure out, so I tried to simplify it a bit. I think I have that done now, and I'm trying to get it to store user choices next, so they can be loaded in subsequent scenes/game sessions.

Hope everyone has a good weekend, and see you Monday!

Mobile Demo Prep

Another mobile day today, as I continue getting demo data ready for the new engine.

I'm working my way backwards through the game data to compare current data to the old demo data. The reason from starting at the end is because treasuretables are a big part of the difference, with the demo having fewer items to choose from. Recipes have to be trimmed down to the bare minimum, and the map needs the special hexes removed.

I'll have to go through items, creatures, and probably some chargeprofiles and other types, too. However, if all goes well, it may mean a better version of the demo than the one we've been using for years. E.g. more bug fixes, stability, performance, and some of the benefits of non-Flash (like keybinding and fullscreen).

Not the most glamorous work, but necessary!

Contracts and Mobile Progress

Hey Folks! Busy day today, though more managerial in nature.

My first task was to draft a work contract for Josh to do the soundtrack. He's basically ready to go, we've hashed out rough terms, and we're in the process of finding a contract that works. Assuming all looks well to him, we should be able to commence soon!

And although it only took a line or two to mention that, it took hours to put together. And not exactly fun work :)

Once that was done, I turned my full attention to NEO Scavenger mobile, where Tiago is plugging away at bugs and UI. We now have a rough zoom lens to help with precision touch input (e.g. 10x10 items, small buttons), and are working on ways to make the user experience (UX) better.

We're also continuing work on the demo vs. full version. There may be an easier way to do this than the tedious XML editing I was doing the other day, so that's on pause.

Things definitely seem to be speeding up on the mobile front, and I'm feeling more and more confident in it each day!

Mobile Achievements, Leaderboards, and Demo

Hey Folks! Continuing this week's focus on mobile dev, I've started looking into some interesting new developments in the world of NEO Scavenger: achievements and leaderboards!

Both Google Play (Android) and Game Center (iOS) have achievement and leaderboard support, and one of the questions Tiago asked me in the port was whether I wanted to try adding them. We decided to leave it as an optional feature towards the end of the project, depending on time. And as we're reaching the bug-fixing and polish phase, I think this may be worth the extra cost to, ahem, achieve.

So what does this mean? Well, I spent several hours looking over old forum posts and online discussions of NEO Scavenger achievements/leaderboards, and did some brainstorming of my own, and I think I've arrived at a set that makes sense for the game.

In particular, I heard the comments about keeping the achievements challenging, meaningful, and spoiler-free, and I'm going to do my best to, ahem, achieve that.

So for example, there won't be "Craft 10x spears," or "Defeat 100x dogmen" style achievements. But there will be a few in the vein of "Build first fire" and "Survive first night."

I'll also try to cover several of the significant plot points, such as "Discover meaning of NEO" and "Expose the Bishop at Saginaw." There will also be a few serious challenges, both of skill and rarity, such as "Survive a week with all frailties" or "Nurse self back to health from near-death."

And I'll try to make the spoiler-type ones hidden, so people don't accidentally ruin surprises.

Leaderboards will probably be more run-of-the-mill stuff, but I'll still be trying to make them meaningful categories. E.g. longest survival time, most km traveled, shortest time to reach ending, etc.

Now, I know more than a few of you are asking, "what does this mean for the PC version? Will it have achievements/leaderboards?" And for that, time will tell. The mobile edition is a good starting point for a new PC version using HaxeFlixel. And if Tiago and I can get everything working again (e.g. mods), we'll definitely take a look. SteamWorks should be compatible with HaxeFlixel, so there's hope.

But hope is not a promise ;)

And for that matter, no promise on the mobile achievements, either. I think they'll be straightforward to code, but there's the question of balancing, cheating, and other considerations. We'll just have to see.

In other news, we're also trying to shore-up the demo so it can be used on mobile as a sales tool. And if all goes well, the demo will be the same app as the full version.

You know that part in the demo where you reach the invisible boundary and it says "You've reached the edge of the demo"? Normally, that would link to the website to buy the game on PC. On mobile, we're going to try an in-app purchase (IAP) to unlock the full version.

Having the demo at all is good because users can see if it works on their hardware, and if they enjoy it. And having it be the same app means avoiding two sets of app approvals on each store, avoiding split codebases, and having shared ratings/user stats.

Unfortunately, the demo hasn't been updated in a while. In particular, the XML content. For several hours today, this was my screen:


Line 4271 of 127983...

There's roughly 6MB of text data to review for any changes, so this is going to take a while. But it had to be done at some point, and although an engine change isn't as exciting as a new game or new content, it's a solid stepping-stone. And as we saw earlier in the post, it allows us to, ahem, achieve some interesting new things!

Changing Gears to Mobile for a Bit

Hey Folks! Hope everyone had a good weekend. Outside of family stuff, chores, and melting in the inferno that was Saturday's weather, I racked up a fair amount of hours in Enter the Gungeon. I think my brain needed a break from slower strategy and role-playing, and it was a nice (and surprisingly deep) experience!

Back at the office, I decided to tackle the tasks accumulating in the mobile project. Tiago's been hammering away at performance, bugs, and lately, store integration, and we're really getting close to the end here. In fact...


Doot de doo...

Feels a bit surreal to see it like that. I mean, it was surreal seeing the app icon on Android and iOS so many months ago, but this is the next level of surreal. Though, this is still just beta, so only Tiago and I can see this page.

One thing you'll immediately notice is that it is "Rated M for mature 17+." I had to fill out a questionnaire to add it to Google's store, and it figures out comparable age ratings across various regions (E.g. ESRB, PEGI, etc.). I expected to have some maturity rating, but I was surprised at how high the age recommendation was when I finished.

The questionnaire focused on such things as violence against humans, violence against animals, the realism of the setting, the reaction of targets of violence, suggestive themes, and drug/substance use. Needless to say, NEO Scavenger touches on a lot of these (though not quite like other games, being largely a text-based game).

Again, it's all coming together. Somewhat quickly, too. And it's got me thinking about how to launch, when, will there be tie-ins with the new site, PC patches, etc. A lot of swirling things coming to a head!

Control Panel Signal Selector

Hey Folks! More progress today on the control panel configuration UI. It's actually at the point now where certain settings result in a functional control panel! And work is shifting to fixing edge cases and bugs.

Here's a snapshot:


Choosing which input the control panel is wired to.

In the above image, we have "unscrewed" the control panel face, and are choosing which target device this control panel connects to via "wiring." In this case, the control panel (top left black box) has one input, "Input 1." Clicking that gold screw opens the list of options to the right.

For reference, this is the setup we're editing:


Two batteries linked by a conduit. Bottom battery is current selection.

The first input option is just empty. No signal.

The second option, "Self - ItmBattery01" means this input will be wired into the bottom battery (i.e. our self).

The third option is whatever is at the other end of the yellow conduit. In this case, another battery at the top of the layout.

Once we've chosen an option, the gold screw gets an icon next to it illustrating the currently attached choice. In this case, the yellow conduit. But if we chose "Self," it'd be blank, and if we chose nothing, it'd be a red "X."

Once we're done rewiring the control panel, we can click the "Done" button, and the panel's face will appear again. And provided we're connected to a device, the UI will show that device's status! (Note: the input choices will likely be filtered to only include valid options or "empty")

So far, so good! As I said, there's still a lot to be done fixing edge cases and bugs. UI elements need to be cleaned up when exiting. Invalid choices shouldn't crash. And we have yet to see how this works in more complex situations. But it was exciting to actually wire something up and see it work.

Next week, I may take a few days to switch to NEO Scavenger mobile and website stuff, as both of those projects have some milestones coming up. But I'll squeeze in more work on this where I can. Have a good weekend, all!

Signal Conduit Selector UI

Hey Folks! Continuing work on the signal conduit system today. I managed to put a lot of code down, but I still have a bit more to go before it does anything.

The main thing today was getting the control panel to query its tiles for any devices that fit the criteria for input. This includes anything sharing a tile with the panel (e.g. the battery itself in the battery charge panel), as well as any distant device connected by a conduit. This info is then stored on the panel, so the user can choose which input they want to hook up (if any).

Another big part of this was the actual UI for choosing input(s). Making the gold screw and input text for the panel was just one part of it. There needs to be some way to see all possible inputs to that screw, and to choose one from that list.

So I spent some time this morning working out a scrolling button list that shows each conduit type and what's at the other end, and the code to populate that list with valid options. I'm nearly there, and as of now, I'm writing the part that tells this scrolling list what options there are. I believe I have the code to gather these options, and the layouts to show them, and I just need to pull it all together.

No doubt there will be bugs once I run it for the first time. Compiler errors, null pointers, missing options, layout issues...the system is pretty complex and spans several pieces. However, once I get that sorted out, I should be able to do the following:

  • Place something on the ship that needs a control panel for player/AI to access it.
  • Place a control panel somewhere else on the ship.
  • Place one or more colored signal conduits to connect them on the ship.
  • Choose that control panel.
  • Choose the GUI I want to edit from that control panel's possible GUIs.
  • See what the GUI looks like.
  • Click on the screws in that GUI to see the wiring underneath.
  • Click one of the input screws to see what devices are available to this panel.
  • Choose one.
  • Close up the GUI, and see if it worked!

There's probably a lot of streamlining to be done with the above workflow, too. However, I reminded myself this morning that I'm in "game jam mode," and successfully stopped myself from going into the weeds on making the conduit placement more streamlined. Still need to get this stuff all working first. See if it's fun, or even hints at being fun. Then we can start streamlining :)

Signal Conduits

Hey Folks! Work continues today on the in-game item UIs and the signal conduits for them. I've gotten a few steps closer to a working wiring system.

The main attraction today was getting the ship setup to detect signal conduit endpoints. In order for the player to connect a distant UI to a device, they'll have to lay signal conduits on the ship between them. Once those are laid down, the control panel UI is going to need to know which inputs it has available, so the user can choose which they want to use. And while it's easy for the control panel to find nearby conduits, it's another problem to know what's at the other end of each.

Today's work was writing code to "walk" the length of each of these signal conduits, and start storing information about which tile is connected to which other tiles via the various signal conduits. This screenshot should hopefully make it easier to understand:


Two different signal conduits with endpoints labeled.

In the above image, we have two yellow signal conduits. The left one is pretty simple. It just links one tile to another two below it, and gives them both a unique ID (658). The right one is a bit more complex. It also links two distant tiles, the top is four tiles above the bottom, with ID 652. However, since there is a junction box in the middle, the adjoining tiles to that box also have signal outputs 652.

The plan here is to be able to put a control panel at one endpoint, and a thing to control (or query for info) at the other end. That way, the user not only has control over connections between panels and items, but it's a graphical way of setting it up (instead of menus).

It's far from fool-proof, of course. Conduits can be setup incorrectly. T-intersections can be made without junction boxes, but the results are unreliable. And there's still the question of what happens when more than one valid thing is at the other end of a signal conduit (e.g. a branching conduit with more than 2 endpoints).

However, this should hopefully be enough to at least get things up and running. Polish can come later :)