Posted on

Oculus Rift & Facebook

I’ve been following Oculus Rift with quite a bit of excitement since they first appeared on the scene.  I’ve always been excited by VR, and purchased my first pair of VR goggles (with head tracking) back in 1996.  I have since owned several different pairs of VR headsets, and in all honesty, they haven’t improved much since my first pair in 1996.  That is, until the Oculus Rift.  When I first tried them, I was blown away by how much better they looked than previous glasses.  Instead of getting a viewpoint that looked like I was looking at the world through binoculars (which doesn’t provide a very immersive experience), the Oculus Rift offers not quite full periphal vision, but a much wider view than what I had seen before.  This is what makes all the difference in immersion.  There is one thing problem that I’ve always experienced with VR headsets, and the Oculus Rift is no exception.  Your normal video game experience doesn’t translate well to VR, with the exception of games where you drive vehicles.  The reason is that when you’re wearing the headseat, you’re required to look around, but if you’re standing up or trying to rotate very quickly, it is difficult to maintain your balance, you have a tendency to bump into your surroundings, and you get tied up in the cables leaving your headset.  This isn’t a huge problem if you’re playing a racing game, or a flying game, or walking around in a giant mech, because you can be seated, but in these cases the virtual reality experience you are getting is one very close to the experience you are having in real life.  So although it can be a very good experience, there isn’t a wide variety of experiences you can offer.

I read an article a few months ago by a writer who tried the Oculus Rift, and he had similar feelings about virtual reality that I have.  He went on to describe the most interesting experience he had with the Oculus headset was not an active simulation, but a concert video filmed at one of Beck’s shows.  The show had been filmed on stage, and with a number of different cameras, which they had then hooked up to an interactive experience.  You were able to stand on stage, with Beck, and watch him and his band play their show, and he said that it was that experience that really sold him on VR.  For the first time, he felt truly immersed in the world he was in, but instead of it being an active experience, it was one much more passive than he was used to.

So there’s been a ton of consternation on the internet about how Mark Zuckerburg and Facebook are going to completely destroy Oculus Rift and the experience that they were aiming for.  Now I’m not a huge fan of Facebook, and I like the hardcore gaming experience as much as the next person, but I always wondered how Oculus was going to overcome the same problems I had experienced with VR in the past.  Although it provided a superior experience, it wasn’t addressing what I felt was the biggest impediment to widespread adoption of VR.  The more I think about it though, this may be the best thing to happen to VR yet.  I think the most compelling experience it is going to offer is a way to interact with other people, say sitting around a table having a discussion, or watching a concert together, but doing it virtually.  This is what Facebook is bringing to the table in the deal (besides an enormous sum of money).  If Facebook hadn’t bought them, my prediction that they would have underwhelmed considerably when they launched and would have disappeared, because I have yet to see the killer app that is going to sell these things like crazy.  But interaction with other people?  With your friends?  Experiencing things together, virtually, not like a video call on Skype, but as an immersive experience where you’re removed from your surroundings and brought together in an environment that you can completely control?  That’s compelling.  I think it’s great (despite my feelings about Facebook), and I think because of the purchase, Oculus is going to be a market success.  And because of that success, we (the hard core gamers) will get better and better VR experiences (as well as world’s coolest chatrooms).  We’ll get cheap VR headsets that will no longer be high priced specialty products for the geeks out there.

Posted on

Unity & Assets

Unity is a great engine for multi-platform development, but as with all engines, it certainly has its weak spots.  In an attempt for simplicity, the folks at Unity seem to have erred on the side of less control when it comes to how objects are initialized.  This lack of control may be acceptable for smaller demo projects or hobbyists, but for those of us working on larger scale development, the initialization itself quickly becomes a roadblock and/or a source of a large number of bugs and problems.  I’ll attempt to go through some of the challenges we ran into very early on.

The Unity object life cycle is rather simple, it only gets 2 calls at object creation time.  The first, is the Awake call.  This call happens when an object an object is instantiated, and happens only once during its lifetime.  The second call is Start, which also only happens once after instantiation.  Unity guarantees that the Awake will be called on *all* objects in a particular frame before the Start gets called on all the objects.  The general idea is that you set up all your cross object references in the Awake, and then do all the initialization of actual data in the Start (at which point, in theory, Awake will have been called on every object already).  At first glance, although limiting, isn’t a complete disaster.  As your project increases in complexity there are a number of issues that become impossible to resolve rather quickly.  First, the order in which objects get their Awake and Start calls happen is random.  It’s not completely random, it is semi-predictable when you start working, but as you update platforms or Unity versions, you’ll see the ordering change.  It’s just enough to fool you into bad habits.  This means that for any cross reference between two objects, they both need to have special case code in their Awake to handle the possibility that the other object has not yet been created.  For example, let’s say object A has a reference to object B, and object B has a reference to object A.  Now when A is initialized, it has to look to see if object B exists yet, and if it does, it would set the reference to object B.  If it’s not created yet, it would do nothing.  Object B, when it’s initialized does the same check, looks to see if it can find Object A, and if does, it sets the reference to object A.  The problem comes in that whichever object is initialized first will not get a reference to the other object, only the second one will.  This can be solved by having Object A check if B exists, and if so, set the reference to B, and then reach into Object B and set the reference back to itself (so that B will have it as well).  Immediately, this breaks the loose coupling that you’re supposed to have in OO programming, with each object needing to know about the internals of the other.  This is a rather small example, but as a project grows, you can imagine how the scale of the code grows.

This problem, although leading to ugly code, is solvable, but assuming you’re willing to put up with it, there’s a second issue that you’ll quickly run into.  Objects that are loaded via scene vs instantation vs pre-fab all have different latencies after which their Awake/Start is called.  So in the case of having your objects created at runtime, or loaded through different methods, now your cross references break again.  This means that you can’t even guarantee that the awake will be called before the start in 2 objects that are loaded via a scene vs an asset bundle.

This issue stretches beyond the initialization.  On each frame, every object gets an Update call.  When they are destroyed, they’ll get an OnDestroy.  The order of the OnDestroy calls can be somewhat haphazard, and isn’t guaranteed to happen on the same frame.  So take our previous example, and expand it to include any reference in one object to the other in its Update.  And go one beyond that to include any function that can be called from any other object that has an Update.

So the solution?  The only viable solution that we were able to come up that still satisfied the other requirements of our project, was to not use the Awake or Start callbacks.  In our case, we set up our own analogous initialization system, where the order of initialization was strictly controlled.  We were vigilant to not fall into old habits and use the Awake/Start calls, and once we stopped using them our lives became a lot easier.  I’ll post a bit more about our solution in a later post.

Posted on

The future of game development

Most of the work I have done in the recent past has been on mobile development, with a specific focus in the free-to-play arena.   Going back further my background is primarily in premium console products, with a couple brief stints/false starts in mobile.  I moved out of console into mobile for a number of reasons.  I liked the shorter development cycles, the ability to make changes rapidly and get feedback on the product from users (instead of reviews), and the hands-on aspect of the development work.  On console side, I also had some concerns, one of which is how the console/premium space is going to evolve to support the ever increasing costs as the scope of the games we work on increases.

One of the avenues in which this has started to manifest itself is in the adoption of third party engines.  In past console titles, the performance hits of adopting a general purpose engine was relatively high (proportionally speaking), and so there was a lot of pushback from developers in using an outside engine.  The last couple generations of consoles have changed things in a fundamental way, where the performance hit of using a general purpose engine has been eclipsed by the costs of developing a custom one.  The transition from in-house to out-of-house engine development has been much faster than many anticipated.  The transition started with Havok and other physics engines at first, but has included rendering engines as well as full game engines more recently.  There has always been a percentage that didn’t develop their engines internally, but that percentage has increased significantly in recent years.  If you look at console games that are out there now, a large proportion of them are using engines that aren’t internally developed, and it isn’t obvious from looking at them which ones do.

These things aren’t enough to support the large development costs that modern games entail, so we’ve also seen many studios and publishers moving to incremental updates and add-ons to their game to try and amortize their costs.  On the mobile side, things have moved away from premium products to a free-to-play model.  Developers in the free-to-play model have learned many lessons that will be useful in the upcoming era of live service on consoles.  These things need to be examined carefully, and I’m certainly not proposing that there aren’t large differences in F2P mobile vs console.  For starters, things like session length, player demographics, etc. are VASTLY different.  But be careful not to throw out the baby with the bathwater, there are nonetheless important lessons that can be taken from F2P.  For starters, developers to put a lot more thought into live service, and how to keep users engaged for longer periods of time with their game.

As we move forward, there’s clearly going to be a move towards a live service model on the premium titles as well.  It’s a great way for publishers to keep their users engaged, and provide additional value to players after they have played through the content.  This manifests itself not just with primarily online games (such as first person shooters) but in the live service events provided by games such as Forza 3 and Assassin’s Creed: Black Flag. It is inevitable on the console side that it will start adopting many of the techniques that have been commonplace in the free-to-play realm when it comes to live service, so that additional revenue from titles beyond what is included in the original shipped title can be earned.  This is won’t be the sort of cheap monetization tricks you see that give F2P a bad name (such as payment gates), but more along the lines of localized leaderboards, synchronous and asynchronous multiplayer play, ways to link up with your friends that increase social activity and competitiveness.  It’s going to make games on console much bigger as far as a gameplay experience without all the additional costs  of entirely new content or a new engine.  It will allow for much faster iteration and ability to stay engaged with our players.  We’ll be able to make better games with this sort of engagement and iteration process, but it will require developers to start incorporating these techniques into their design during the initial development process, and not just tacked on afterwards.

Posted on

Introduction

Hello, and welcome to Lunatic Labs.  This is a site I’m putting up to write up my thoughts on the mobile and video game industry.  I may veer off topic from time to time, but my posts will tend to be around things I’ve been thinking about, and so will often lean towards the game industry.   I think a lot about different trends in the industry, and when NDAs permit may take about some of the problems I’ve been working to solve, and sometimes just a shout-out to particular tools or projects I find useful.  Just to give you a little background on me, I’ve been in games for 20 years this year, both on the side of publishing as well as development.  I tend towards smaller companies, but there are certainly advantages to the resources larger companies can deploy towards development, so not exclusively so.  Most of my work has been in the console space, but I moved over to mobile development about 2-3 years ago.  I’ve been dabbling in mobile for quite a while, doing early work for JAMDAT and MachineWorks, both a bit early (2000 and 2004), but I finally feel like the market is starting to mature and so I’ve made the switch.  I love console games, both playing and developing games for them, but my focus is primarily on mobile at the moment.