Hello, everyone - time for another update! A new build is on its way, look for it soon. (Changelog)

New Approach - Focus Updates

FRONTIERS is a big game - I've cut a lot of features since the Kickstarter, but it's still really big. And until we can grow the team some more most features can only be worked on one-at-a-time, so I get a lot of messages asking 'Hey, are you working on this or that or the other thing?'

Those questions gave me an idea. I can't work in parallel so why not embrace linearity? Starting today I'll announce which feature I intend to focus on. I'll still work on major bugs & performance along the way of course, but overall that feature will get most of my attention until it's finished. And you can help me finish it faster by focusing on it along with me.

The next time you launch FRONTIERS you'll see a little popup window that tells you which feature I'm working on. You'll also be given a cheat code - eg, if I'm working on the bow & arrow, the code will give you a bow & some arrows. Some of you will play normally, some of you will use the code, but either way I'll get a whole lot more reports on that one feature than I might otherwise - and you'll know at a glance what I'm working on at the moment.

We'll see how it goes!

Oculus Support / Controller Update

I'm nearly ready to throw the switch on Oculus support - finishing up proper controller support is the next-to-last step.

In the latest build I've finally added direction-based controller interface navigation - but be warned! It's far from perfect. In fact it might not be perfect for a while, because this has turned out to be trickier than I expected. (Big surprise.) It's a simple question: 'what button should I navigate to if I hit up/down/left/right?' The answer is obvious if you eyeball it, but that obvious answer is frickin difficult to recreate with code. It's kind of a fascinating problem.

Anything grid-based is easy, of course. Here's a test of the inventory screen with colored button weights visible (green is best and red is worst):

But once you start getting into weirder layouts, things don't always behave as you expect.

My earlier methods might select a button across the screen because its axis-alignment was perfect. Later methods might select a button that was totally mis-aligned because it was so close. My current method is better, but I've yet to find one that's juuuuust right.

I'm thinking some interfaces will use special cases (like a pre-determined 'tab order'), and I'll continue to improve the generic sort method to use a smarter combo of distance and orientation. If anyone cares to poke at the code, this is where navigation is done. (WidgetSearch.CompareTo is the sort function.)

Fast Travel - Almost Done

Video if you haven't seen it. It's been improved slightly since this was recorded.

Critters - Finally!

Critters are implemented. Bugs, butterflies, frogs and other simple/tiny creatures now appear randomly all around you. (If you weren't a Kickstarter backer you probably weren't expecting this, but butterflies and bugs have been a promised feature since forever.) Butterflies aren't seeking out goodies yet, but they will soon.

I love these little guys. The lightbugs are my favorite, they sound like wind chimes.

Performance - Another Black Eye

Performance remains an issue, but it's a battle I'm winning 1/10th of a millisecond at a time.

I'm also pleased to say that the folks at the Eden Star project have generously offered to help by poking around in the project & looking for ways to optimize things. (Eden Star is Unreal-based but their team is familiar with Unity as well.) Their expertise is most welcome and I hope it will help to improve everybody's framerates. I'm sending them the project soon - cross your fingers!

But there's one performance issue I can't fix: UNITY.

Even now I'm hestiant to throw their name around. It always sounds like an excuse. 'It's not me, it's the engine!' As if that matters - even if there IS a problem with the engine I'm still on the hook because I'm the one that picked it. And generally speaking I don't like to dogpile on anyone. I know how hard development is. Unity's to-do list would probably make me pass blood. Their overall competence can't be denied. Unity - within its niche - is a solid engine. Have I qualified this enough yet?

I hope so, because lately this has gotten kind of personal.

There's one bug in particular that's really killing performance. You might remember a long, sometimes close-to-hostile (on my part) conversation with a Unity dev in the comments of a previous update. Well, at the end of that conversation I felt hopeful. I'd convinced them to re-activate this previously-closed bug report, and they had convinced me to submit an additional bug report with assurances that I'd see some kind of response within two weeks (despite the original report being on the books for 6 months). I felt really good at the end of that conversation. And for what it's worth, I still believe that the dev I was speaking to was 100% sincere in their desire to help.

Well, it's been a month... and nothing. No response. Not even on the original bug report. There have been more complaints by developers, though! Let's take a peek (none of these people are me, for the record):

JAN 30, 2015 13:21
Noticed this went from 'Fixed' back to 'Active'. Any update on whether we will see a fix before 5.0. Bug is still appearing in 4.6.2.
Also, is anyone else noticing their RenderTexture Switches going up when this bug occurs?

FEB 01, 2015 19:51
It is totally killing our game performance. Should be fixed ASAP otherwise engine is being broken for any Open World production.

FEB 02, 2015 14:09
Currently using 5.0.0.b18 and still experiencing this issue. This is a total performance killer on our open world game.

FEB 13, 2015 05:43
Seems like this is still an issue... Really? 4ms for this on my terrain, this is completely unacceptable.