Hey Folks! Most of today's work was on toggle switches for the ship.
All of the previous GUI work I've been doing was partially to get the general GUI system running, and to make it support signal conduits, the ship editor, selection brackets, and AI. The first test UI was a non-interactive meter that the user could wire to various items on the ship.
The toggle is going to be the next improvement to the GUI: a widget that the player can interact with during the simulation mode, and have it affect things on the ship. Here's what I'm thinking for the first iteration:
Like with the battery meter, there will be a front panel the user can interact with (the top half of the screenshot), as well as an internal panel for adjusting the inputs and settings for the controls (bottom half). Most of the time, the player will have their AI walk to the controls, and they'll flip toggles, read meters, and do other UI things. During ship building, and possibly during ship repairs, the player will access the internal panel to rewire things and change labels, etc.
In this case, there is support for up to 4 connected items, with each switch controlling some aspect of the connected item. The current plan is for each of these toggles to trigger an interaction on the connected item, since interactions can apply or remove conditions, initiate a mode switch, and do other things which cover most of our needs. And probably, the user will click each screw as they did with the meter UI, and be presented with a list of potential connections.
However, now that I say it "out loud," I think there's a missing piece. Namely, each toggle will probably need to fire separate interactions when "ON" vs "OFF." E.g. the HVAC input will probably need a "Mode Switch: On" interaction when toggled on, and a "Mode Switch: Off" interaction when toggled off. So that probably means we have four "screws" to control what we're connected to, with two interactions to choose for each "screw." (The "ON" interaction and the "OFF.") That'll mean some rearranging of UI.
I was considering how to test this on the ship, and almost started working on something more complex (like an airlock cycling UI), but I think getting this simple case might be a better stepping stone. There's already a lot to tackle in just this simple case.
Should be fun once it's up and running, though. I could conceivably hook this up to remote airlocks, air pumps, and even lights! Okay, maybe "fun" is too strong a word :)
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.
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:
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.
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!
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!
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).
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!
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:
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!
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...
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!
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:
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:
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!
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.
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 :)
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:
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 :)
Hey Folks! I tried to put my head down today and focus on gamedev, and got a fair amount of work done.
I had a thought last night about a different way to wire-up the ship items using an in-game UI. Rather than clicking on an item and filling-in a bunch of text fields when building the ship, it might be more intuitive and fun to do it graphically. Plus, I can probably simplify things for the user in the process.
The new idea is to let the user "open" the control panel to see wiring inside, and then choose colored wires that correspond to items on the ship. The colors available will depend on how that panel is linked in the ship via colored conduits. Here's a preview of what it might look like:
In the above image, the control panel is the meter on the left. Clicking any of the screws will replace that UI and expose the "innards." In this case, two wiring terminal screws with some labels. The labels here might say "Meter 01 Input" and "Meter 02 Input." There's really only one meter here, but I wanted the second screw to show how more would look.
Clicking on the gold screw will show available wire colors to choose from. The user can then choose which wire connects to the meter input, and voila! The control panel is hooked-up to the ship item.
How does the user know which color to choose? Easy. They determine that by laying colored conduit between the control panel and items on the ship:
Just like laying power conduits (the gray-blue quartet of pipes), the user can place anywhere from 0-4 different colored conduits on the ship. Depending on where these are, they may connect items to control panels. So if the control panel was at the top of the screen above, it would have green and yellow conduits coming into it. And if the player wanted the meter to be based on signals from the battery, they would choose the yellow conduit. (Green doesn't connect to anything, it just ends at the junction box.)
Of course, this isn't a perfect system.
For one thing, I'll still need a text box or something to edit the label on the meter (so it doesn't just say "Title.") Also, what if the control panel is on the same item it needs to get the signal from? (Any color works?) What if I need two signals from the same item? (Does it matter? Maybe one conduit is good enough for all signals from a single item.) And are four colors really enough to wire an entire ship?
But I kinda like this approach. It looks fun, and a heck of a lot more engaging than filling in a form for each UI.
Plus, this seems like it might open up the possibility of fixing equipment in-game. Perhaps I could let players reroute controls to different items in a pinch? Or figure out why a panel is dead after a hit? I could add patch cables to run along the floor and jury-rig connections when underway. I might even be able to let the player slot replacement parts into items/panels this way.
As I said, seems like it could be fun. I'm waiting for the gotcha to appear :)
Hey Folks! Hope everyone had a good weekend. Pretty quiet here, all things considered. Finally a break from trips, appointments, gatherings, and other interruptions. A few weeks of no obligations ahead, yay! Except for chores, errands, baby stuff, and the usual, that is :)
I was only able to do a little gamedev today, but I actually have some visible results to show. As mentioned Friday, I was hoping to get some UI fields on screen for when a user chooses an item and then a GUI for that item to be edited. After some mucking around, I came up with this brutally ugly UI:
Right now, I've loaded my ship, clicked the battery I've placed on that ship (see bottom of image), and the sidebar with "ItmBattery01" was loaded to tell me a bit about it. That sidebar includes a "GUIMeter" button to tell me that there is one UI I can edit for this item.
Clicking that button loads the "Meter" on the top left, and the text fields on the right. The top left UI is the way this meter looks when playing the game. The text fields are the things that can be edited here in the ship constructor mode. I can change the title of the UI panel, the condition it tracks (e.g. battery charge, temperature), the min and max of the meter, and the ID of the item to be tracked.
Right now, they're all default values. I have to do some finagling to make these editable and to save that data out somewhere so it persists across game modes/sessions. I'll also need to make certain fields easier to edit. E.g. ID should let me choose parts by clicking on-screen (or at least from a list), and conditions should be a dropdown.
Not bad for a couple hours of work, though!
The rest of the day was spent on NEO Scavenger mobile, and some admin stuff. Tiago submitted his latest build today, and I was able to get much further in it on my iPad! Still bugs here and there, but they're getting more and more minor. We're optimistic this is the final week or two of dev, and then it's just admin stuff (storefront, account settings, behind-the-scenes stuff).
So in retrospect, today was actually pretty productive! Hopefully, an auspicious sign for the week ahead :)
Hey Folks! Another largely business-admin day today, but I did manage to get back to gamedev later on in the afternoon.
The morning was mostly spent working on record-keeping for my new company. I had a pile of official documents (certificates of formation, business licenses, etc.) and a binder that needed assembling, and my receipts were starting to pile-up. So I took a few hours to finally get that in order so I could start using it. I also setup new profit and loss spreadsheets, since the new company reports in a different currency (USD) than the old one (CAD), and has some updated licensees.
Fun, right? I know!
Anyway, with that out of the way, I took some time to chat with Josh a bit more about composing this new game's OST. We're both getting pretty excited, and just hammering out some contractual choices before we move forward.
In terms of actual game dev, I'm working on "GUI Property Maps" (GPM). A GPM is basically a set of data that tells a GUI what to display. Things like label names, value ranges, and which items and conditions on those items to use as a source for data.
Originally, I just had this all defined per-interaction. Logical enough for the time. However, if I want the user to be able to choose which control panels correspond to which items on the ship, I need an in-game way to edit this. And that means the ShipEdit mode needs some more UI.
I decided to make a new stand-alone data type called GUIPropMap for this purpose. That way, different objects in the game can all refer to the same set of properties for a UI. Placed ship items can have a list GPMs that make sense for that particular item instance. When a player selects that item in ShipEdit mode, they see a list of buttons: one for each possible GUI.
Clicking one of those buttons will load that GUI, and they can proceed to specify the editable parts of that GUI as they see fit.
I'm most of the way through this process now. I think the pieces are pretty much in place, and I'm just smoothing out some compiler errors. Then, we'll test it, likely debug it, and hopefully be able to edit some GUIs in-game on Monday! Have a good weekend, all!
Hey Folks! Just a short update today as a chunk was spent at the dentist, and since I was in that part of town, the office supply store for some corporate binder stuff.
Most of the morning was spent doing some site update and maintenance tasks, and then following--up on emails. So not much to report there.
However, I did get a bit more work done on the in-game item UIs. Nothing new to show yet, but I'm starting to work out how the user can edit the in-game item UI properties. Hopefully, more on that tomorrow!
Hey Folks! I forgot to mention yesterday that we have a new mod: layarion!
You've probably seen him around the modding forums, as well as the website suggestions forum. He's been a pretty active member helping folks where he can, as well as making his own mods, and has a particular passion for improving documentation and usability on the site.
Hey Folks! I tried something new today: using toggle.com to track my gamedev time vs. business and non-work tasks. As of this news post, I'm at 7h30 of work, with about 3h30 of that spent on gamedev, 1h40 on business admin tasks, and 2h20 on non-work (eating, showering, child-wrangling, making coffee, in roughly that order). I'll likely have another 30 minutes of admin by the time this post is done.
3h30 may sound pretty pathetic, but that's actually a good day in my world. Most days I'm lucky to open any gamedev apps at all, let alone spend appreciable time in them. 2h10 (including this post) might actually be a record low in terms of business admin tasks lately. And the 2h20 non-work is a bit high today, largely due to the toddler deciding not to sleep for a few hours at 2am. We'll see how it progresses tomorrow, but whatever the case, I think this is not only useful info, it also helped me stay on-task. I was sort of reluctant to change the timer's task away from work, so I probably did more as a result.
So what did I actually do today?
I'm working towards a way to edit an item's in-game GUI. The simple battery meter I setup is functional, but largely hard-coded and makes a lot of assumptions. If I'm going to have more complex UIs for things (like viewing all batteries on a ship at once, or you know, actually flying a spaceship), these UIs are going to need more complex customization. And since the user is going to be placing control stations, they're going to need some way to edit those stations' connected items and other properties.
My thinking, then, is that during the placement of ship parts (a.k.a. ship edit mode), users should be able to click a part on the ship and see some editable data for it. In the above image, the selected battery shows an edit panel with the name, image, and ID of the battery. And below that, a button for "GUIMeter."
I plan to make any item that has UIs show a button for each on this panel. When that UI's button is clicked, the UI will appear on the screen, and the player can start clicking sections of it to edit it. E.g. click the bar graph and choose the battery it links to, click the title and change the name, etc. Some stuff won't be editable or will use assumed values (e.g. nav console will assume the current ship as the target ship to be steered).
Also, in the crew sim mode, I decided on something like this for showing the UI:
Once an AI raises an in-game UI, it'll look kinda like this. The left bluish panel is most of the screen with UI elements and widgets on it. The right gray portion is a special section for navigating the panel. Usually, it'll just have the "X" button to close the panel. The other arrows are to switch panels to adjacent screens, for really big/complex UIs.
With this new panel nav UI, I changed a few things so now the AI interacts with something, that raises this GUI, and then the AI sits there waiting for the UI to close. For now, it'll wait an hour regardless, but I'll update that later to be more context-sensitive.
Overall, these are some boring-looking, but important upgrades. We can now enter and exit in-game UIs when an AI interacts with an item. And, we have the beginnings of a tool to let the player configure those placed UI consoles on the ship. We may not be far from AIs monitoring the status of remote objects, overriding airlock lockdowns, or even affecting the status of the overall ship!
Hey Folks! I actually snuck a little bit of gamedev in today. Hooray! I basically had to tell myself that before lunch, no other stuff would interrupt. Just pure dev.
As a result, I've made some progress on the in-game UIs for interacting with items. As mentioned two weeks ago, I started with a simple battery charge UI to get the system working:
The tricky part turns out to be layout. I'm trying to figure out the best way to get a self-contained UI such as this combo of colored bar and labels to position and scale appropriately in-game. Since the game resolution changes wildly across devices, I want to get as much mileage out of each UI as possible. I don't have that figured out yet, but a Unity video tutorial has helped me make progress.
The code side, on the other hand, is super simple. I made a few changes to things today, and the system is starting to make sense.
First of all, I changed the UI to appear at the beginning of an interaction. This way, I can define an opening interaction where the AI gets situated with a UI, then a follow-up interaction of longer duration for when the AI is "using" it (i.e. waiting for the player to click buttons and exit). Once the AI successfully raises the UI, the whole screen will be filled with the UI they're using. Here, the player will view readouts, click buttons, and generally affect changes to the ship. And when they're done, they click something to lower the UI and return to the game.
During this time, the game may or may not pause. Probably not, as navigation and other time-sensitive use cases will require time passage to get UI feedback about changes and let the player decide how to react. And since time is passing in the background, the AI will likely need to interrupt this if in danger or other priority comes up. I'll figure that out later.
Another thing about this UI-raised mode is that I'll probably need some sort of crew-selection UI on screen while using a UI. This way, players can coordinate actions across the crew as they use multiple UIs. (E.g. combat)
In fact, combat reminds me that time controls will probably also need to be available to players so they can pause/unpause to coordinate more complex things. Also, so they don't stress out trying to do complex UI things with a timer running :) One of my mandates as a company is to design games that respect the user's time, and don't pressure them. So making this enjoyable is key!
Anyway, I have a few layout things to sort out before continuing. And then, I want to see if I can get the UI to close when the AI walks away, and figure out how to let the AI interrupt if need be. Here's hoping more dev tomorrow!
Hey Folks! Hope everyone had a good weekend. Ours started out crazy as we planned a birthday gathering, but mercifully quieted down on Sunday so we could get our lives back together :)
Today, I had a few more business-y things to catch up on. First up was the website.
After Friday's mockup review, I created a mockup of my own to send to the designers, and we hashed-out ideas and feedback this morning. They're going to take that input and run with it, and explore two of the stronger ideas we've discussed so far. Looking forward to seeing what's next!
Second, Tiago was able to get the iOS build running a bit more smoothly. It took a lot of memory and performance optimization, but he was able to squeeze just enough performance out of it to get it running on iPad 3rd gen. iPad 2 may be beyond reach due to limited ram, but 3 and up may be sufficient to hit a wide target audience. He'll be focusing on the final stretch of mobile features this week, such as touchscreen/zoom, demo vs. full version, and other differences from PC.
Finally, I got an email from Josh Culler last week, and finally had a chance to reply. NEO Scavenger fans will know Josh from his brilliant music in the game, and he's interested in talking about work on the space prototype. So I spent some time composing my thoughts on how I see music in this new game working/sounding, and I'm looking forward to the rest of this discussion!
With those things done, I may (may) be able to get back to actual dev tomorrow. Gasp! I know! I really need to get something done to quell the unease I'm feeling after so many days of no progress. But that's running a business for you.
Hey Folks! Another non-dev day today. Although, not a business admin day either, which is always nice. "What else is there," you ask? Why, fancifying the website!
The Jibe sent over their first mockups of the new homepage this morning, based on our discussions so far. We had already agreed upon a general wireframe for the page, so this was mostly mocking up colors, fonts, and design elements to make it look more finished.
I think we have a start, but it wasn't without some concerns. I had about a page of notes to send back, though many of them were related to the same points. Namely spacing and fonts. And we have a follow-up call Monday to discuss where to go from here.
However, I also wanted to tinker with some of the design elements I talked about in my feedback to them. And in the process, I came up with a few things that I may ask them to try out.
It's been a long time since I've done any web design, or even critique of it. And Rochelle and I went back and forth over type treatment, paragraph justification, and layout. There may be no easy answers here, and whatever the end result, it may not please anyone.