I Made an iOS App! And OOO Rest of Week

Good news, everyone! I was finally able to compile the iOS on my own laptop today!

If you've been following these posts over the past 12 months, you've probably seen me gripe about not being able to compile NEO Scavenger Mobile for iOS. PC is easy. Android is easy. (And doable on a PC!)

But iOS? NOooooo. You need an Apple running a certain version of OSX and XCode and provisioning/certificate gobbledygook. And even then, XCode doesn't really work with Haxe out of the box, so some finagling is required.

And even then, you need the right versions of the right Haxe libraries to do it.

Well, thanks to Tiago's patience, and lots of trial and error on my end, we finally did it! Had to reinstall a special Haxe version 3.4.2 (git build development @ ada466c from nightly builds), re-download all the libs, make sure hxcpp was set to v 3.4.64, then run the magic terminal command to rebuild the XCode project before opening it and...voila! I could finally compile for iOS.

Easy peasy! (Not.)

Basically, this means I can now submit builds on my own to iTunes, which will be handy since Tiago is in the process of starting his next project. He's graciously making himself available to smooth the transition, and provide post-launch support. But eventually, I'm going to need to put on the grown-up pants and learn how to maintain NEO Scavenger Mobile myself, right?

In other news, I'll be OOO tomorrow and Friday. Still around, and should be checking email periodically. But no news, and I might be slow to respond. Should be back to normal Monday, though!

Have a good one, all!

Mobile Fixes, Bugs, More Fixes

Hey Folks! Today was mostly a mobile day, as Tiago submitted his latest test build. It included his fixes for loading URLs and swiping.

So far, the fixes seem good! I was able to load websites in the browser (even PDF manual link worked), and the link to rate the game opened directly in the app store instead of a browser. The only thing left there is to setup the rating request to happen at a good time, and only one time.

The swiping was easier to use, too. I made a few adjustments so that it worked on the quick recipes, but otherwise, so far so good. I also decided to change the prev/next buttons and swiping on quick recipes and available ingredients to wrap around from last to first and vice versa. (Rather than requiring the user to page all the way back to the beginning when reaching the end.)

In the process of testing, I noticed two new bugs.

First, the message log disappeared when the main menu was raised and closed again. Turns out this was a missing line in the restore code for the inventory pages. No sweat.

The second issue is a bit worse: no recipes in the demo. It looks like we're not loading them at all. In theory, a simple fix. But this might require special handling to ensure the demo-approved recipes load, instead of full-version recipes.

More on that tomorrow!

World-Building, and Mobile Fixes

Hey Folks! Hope everyone had a good weekend. I enjoyed a nice Father's Day weekend with the family, visiting the ocean, looking at old cars, eating yummy foods, and shopping at a retro video game store. Oh, and we bought a ladder. 'Cause that's what dads do, right?

Tiago sent me some updates today on his progress, and it sounds like he's got URL actions sorted out! As a refresher, this fixes the way the app opens URLs such that it uses the native browser instead of a browser-within-the-app. The benefits of this are two-fold:

1 - Opening links to the app store (reviews, rating) opens the store directly.
2 - Opening forums and other log-in sites takes advantage of any browser-based login solutions the user already has.

That should be a good step towards improving the app's interaction with web-based stuff.

And the remaining UI/UX stuff, such as swiping, panning, and zoom fixes, is nearly there!

In other news, I did a lot of world-building today for the space prototype. Trying to get the information organized and come up with reasonable explanations for things in the System. I've been working with a contract writer on some in-game brands and the lay of the land, and it's been super productive. More on that soon!

Basic Course Plotting Done

Hey Folks! I had another solid prototyping day today, and was able to keep plugging at the flight computer.

Today's work included a fix to the ship projections overshooting or backtracking due to precision errors in the code. I also added code to make the planet projections match the same time steps as the ship course, plus one extra to represent the planet's final position when the ship arrives. (Ideally, at the same place.)

I also added code to make "snap" work when moving the crosshairs around the system. When enabled, the crosshairs snap to the nearest celestial object and track it until something else becomes closer. I also made it work with the "lock" button so the player can lock-in the destination and pan the map without disrupting the course. Part of this work involved making sure the crosshairs snap to the planet's projected position at arrival, and not the current position.

I fixed-up with ship cursor to match projected thrust directions during the trip (i.e. towards target for first half, away for last half). And in so doing, I discovered and fixed a bug that caused the ship to move at a different time rate than the rest of the system. (I was feeding the ship the total current time instead of delta time since last update).

With all that done, we can pretty handily plot various courses to the planets in the system, or just choose points in empty space. We can dial-up or down the number of projected steps for finer/coarser step sizes (useful if something crosses the ship's path). We can also adjust the map's time passage rate to play, fast-forward, reverse, or pause the system and see where things are and will be.

Overall, it's a pretty powerful tool for plotting courses! But now we get to the dirty details.

For one thing, the planet will be moving (and fast!) at the point where we arrive. So simply rolling up to a full stop will mean it either blows by us, or (more likely) we crash into it. Also, everything so far has assumed the ship begins at rest. So executing the plotted course will cause the ship to arrive with the same relative velocity as when it started, which could be any direction or amount.

So the next step is to compensate for this relative velocity difference. In addition to traversing the distance between here and there, the course also has to change the ship to have the same final velocity as the planet at arrival.

The concept here is pretty simple, actually. Finding the thrust needed to change from starting to ending velocity given a time t is an easy equation. And since we know t based on the plotted course, we can just add the course's thrust to the velocity change thrust and voila: a total maneuver thrust that gets us there!

Unfortunately, this simple addition of thrusts means we end up accelerating faster than we should, depending on the difference in velocities we need. If I want to limit ship thrust to 1g, this might result in 2g, for example, violating my limit.

The real solution involves a bit more vector math and solving a system of equations. I.e. finding a thrust and trip duration that solves both the velocity change and trip distance equations. And my brain fizzled out before I could tackle that this afternoon.

Still, this is a fine problem to have! Instead of building rudimentary systems, this is making more complicated systems work together. So I'm looking forward to it.

Now, however, time to rest. Have a good weekend, all!

Main Menu Music, and Course Plotting

Hey Folks! I had almost a full day of prototyping today! And Josh's latest menu music is in.

The prototyping mainly centered around plotting a course to a destination, using some of the tools I've been building in the plotter so far.

The first task was to get a set of crosshairs on the map that the user could control. And for now, these align to the center of the map and follow the screen around as the user pans. When the user wants to lock-in the current position, they toggle the "LOCK" button, and future panning doesn't affect the crosshairs. I'm also planning to add a "SNAP" toggle which will snap the crosshairs to the nearest celestial object instead of dead-center on the screen.

With this in place, I was able to start work on a course projection algorithm. Knowing the ship's current position, and the desired destination crosshairs, I could calculate the time it takes to reach the destination at 1g acceleration. Then, I could assume 1g acceleration half way to the destination, and 1g deceleration the other half. (For now, we assume a stationary target.)

And with those acceleration parameters, I can start plotting future positions of the ship. The buttons I added yesterday let me control how many projections to plot, so 1 projection step plots a ghost ship halfway to the destination, 2 steps plots 1/3 and 2/3 of the way there, 3 does it in quarters, etc. If the user wants, they can ramp this up to 10-20 to see fine-grained position info.

The plan is to use this stepped projection calculated from the ship course to also plot celestial objects at those time steps. And with that, we can see if the ship is crossing any dangerous objects during the trip. It has a few minor issues at the moment, including some cases where the number of steps is not evenly distributed. I think this'll be an easy fix once I figure out where the problem is. Likely the difference between <= and <, or a sign error.

I'd also like to add a few things to this, now that I've tinkered with it. First of all, I'd like to account for non-zero initial and final velocities, so moving ships can dock safely with moving objects. Also, grav wells will inevitably interfere with the straight-shot path, so I'd like to apply their effects to curve the path. And likely, I'll let the computer figure out a counter thrust to compensate (rather like "trim" in aviation).

Finally, I realized I'd probably want modes in this screen so the user can query certain objects without canceling the flight plan. So some mode buttons to switch between NAV and INF modes (and maybe others) seem to be in order.

It's starting to feel like a flight computer!

In music news, Josh submitted his latest track for the main menu, and it's beautiful. Rather unlike NEO Scavenger's harsh, exotic electro warble, this one is warmer, synthetic, and a bit ambient. Perfect for pairing with a warm ship's console and background animated activity :)

Orbital Plot Interaction

Hey Folks! Short day today as I had to watch our daughter while Rochelle took an exam across town. But I was still able to churn out a few new things on the orbital plotter.

The first thing was to get the same "onion skin" effect on the ship as I added for planets yesterday. The reason for this was to see if it would help predict future positions of the ship vs. a target planet, and allow the user to plot a course that worked.

It sort of does. But it's not enough info nor sophistication for a full flight yet. It's mainly good at showing objects' relative positions over a range of time. And the useful time range varies a lot depending on the speed of the ship and/or planets in question.

So the next thing I added was making the time range adjustable, as well as the rate at which the plotter moves things around the system. And this meant adding my first on-screen buttons!

Up until now, I've been temporarily wiring everything into hotkeys like WASD and arrows. Good for quick testing, but not a long term solution. Eventually, I would need on-screen widgets for the user to interact with.

Adding those turned out to be pretty straightforward. And I even have a mix of buttons and text readouts!

So far, I added controls for increasing/decreasing the number of "onion skins" to see further into the future for objects, or clean them up if I wanted to pare-down to just the present again. And I also started adding some controls/readouts for controlling the speed of time in the System map. Sort of like VCR controls for the map to move things around.

Already I'm starting to think my first approach to navigation is off, as choosing a direction and then plotting a course seems too clunky and fraught with edge cases. I'm now thinking maybe the user adjusts the crosshairs on the map to their desired location, and the nav computer will calculate the most direct route and show it on the map. Then, I can use these VCR controls and onion skin tools I've created to let the user preview the flight. Maybe add waypoints, set maximum delta V to conserve fuel, avoid regions or grav wells, etc.

I'm thinking it'll still require user intervention when the planned flight encounters certain conditions (e.g. mid-transit maneuvers, unexpected objects, deviation from plotted course gets too large, fuel reserves changed, etc.)

However, all this is meaningless until I give it a shot and see how it actually feels!

Last Few Mobile Bugs, and Flight Planning

Hey Folks! A little bit of catch-up this morning before jumping back on the orbital plotter.

Tiago sent me his latest update, and we're basically down to 3 issues, and two procedural tasks for me to do once the launch is initiated. In other words, we're almost good to go!

Of course, we'll still need to test these latest changes. And flipping the launch switch has a series of steps and things to wait for. But this is about as close as we've ever been!

For the orbital plotter, I'm starting work on a way to plan a route to a point in the System. And for that to work, we need to know not only the current situation, but what it will look like when we get there. Trips are measured in days, weeks, or sometimes months, and a lot can change in that time.

So one approach I'm going to use is a "projected positions" plot on the system map. You can see where everything is in blue, and where everything will be in orange. More specifically, where things will be at t, 2t, 3t, and 4t, where "t" is some amount of time in the future.

For example, we can see Mars is at its current blue position, and then adjust the tool to show us the positions for it over the next 4 days at 1-day increments. This way, we can set a heading and thrust amount, and plot our ship's projected position at those times, making adjustments until the final projection of our ship is near the final projection of Mars.

If you've ever done animation or stuff in Flash, this is sort of like working with animation frames on a timeline and "onion skinning."

And, of course, this is totally experimental. I'm just thinking it's a way for users to fairly intuitively plot a path from A to B in an orbiting system with long transit times. And it follows the design goal of flying the ship indirectly through "beep boop" control panel stuff. Lots of flipping switches, turning knobs, punching buttons, etc.

We'll see soon enough if this is usable!

TotalBiscuit, Taxes, and Orbital POR

Hey Folks! Hope everyone enjoyed the weekend. And if you were still waiting to pull the trigger on NEO Scavenger, hopefully you saw the chrono.gg sale yesterday.

As it turns out, TotalBiscuit saw the sale! (If you're a non-subscriber, here's a peek.) As some of you know, TotalBiscuit has partnered with chrono.gg, and sometimes plays the games on offer. And though he's under no obligation to be kind to the games he tries, I think he gave it a fair shake. Not his cup of tea, he admitted, but he enjoyed the immersion and level of detail. Plus, there were some entertaining moments like the above :)

And, as many of you won't be surprised to hear, it had an impact on both sales and awareness! NEO Scavenger got a healthy blip of attention and sales yesterday, which is really good timing with mobile coming out soon. TB was even kind enough to mention the mobile version was coming soon, so hey, that was a pretty snazzy Sunday!

In other news, the IRS sent me a nice letter over the weekend. And by "nice," I mean a "penalty for remitting withheld income tax too late." Turns out that the tax I withhold from my paycheck is to be paid monthly, whereas I was paying it quarterly. So I was assessed an interest penalty. Bummer, but fairly easy to correct, going forward. (Something which I tackled today, for all Q2 paychecks so far.) I suspect I'll have another, smaller penalty in the near future since the first two Q2 remittances are late. But it shouldn't be as much this time. And hopefully $0 from now on.

Fun!

Finally, after catching-up on some emails, I decided to do a bit of prototyping. One thing I've been working on is the orbital plotter UI for when the player pilots their ship. I was able to get the orbits done, and have started work on a ship component.

Today's work included making that ship movable around the system, and having the UI update the closes grav well for reference. The ship flight controls are just a stand-in for now, since I plan on those being more indirect. But this allows me to check that everything is working correctly. I can also start adding orbit-plotting for the ship based on current velocity and nearby grav wells.

Hopefully, this will make it possible to plot a course to a destination, which is the reason I'm doing all of this: it's a rough draft of one major game loop, where crew flies from one end of the system to another for transport, missions, or other purposes. Once that works, I can move it over to the crew sim portion of the prototype, and have AI sit at the console to change course, then walk away for days while the ship executes that course. It'll also give me a better idea of how this UI should work, what inputs it needs, etc.

That is, of course, unless mobile or web projects are ready to go to the next level. I suspect one or both might be soon :)

Today Only: NEO Scavenger Only $3.50 at chrono.gg!

Folks! For the next 23 hours, NEO Scavenger is available at chrono.gg for only $3.50!

IMAGE(http://bluebottlegames.com/img/screenshots/screenshot-2017-06-11.png)

Deal ends at 9am Pacific, June 12th!

False Alarm! Site Relaunch Postponed

I bet you thought the new site was launching today. Fooled you!

And as it turns out, fooled me, too. We were on track to flip the switch today, when the lead dev went into labor early. We sort of thought we had a few days until then, which is why we were aiming to do it yesterday and today. Buuut...nature waits for no website :)

In a way, this works out okay. I was finding and fixing things up until a few minutes ago anyway. Things like NEO Scavenger SWF database issues, SolSolo not loading, and updating some minor things on privacy policy and other content pages. So basically, I would've been fixing stuff after launch anyway, and now I have most of it figured out for the next attempt.

So what does that mean? For now, this site is back to normal for a few days at least. Continue using and posting on it normally. And when the time comes, we'll do another freeze, re-migrate everything, and this time I'll have fixes for all (most) of the known migration issues in my back pocket, ready to go.

For now, have a good weekend, all! See you next week.

Pages