Last week I was in Berlin attending the XRCC glamhathon (a very glam hackathon) as a mentor and the mentor team included some very talented XR professionals. One of them was Daniel Sproll, the CEO of Realities.io, the game studio behind Puzzling Places, One of the most successful indie VR games out there. (Buy it if you don’t have it in your library yet!) I’d never met him in real life before, but I had a great time with him, talking about VR, eating, and playing games like table tennis or foosball (I still have nightmares thinking about his goalie’s powerful shots).
But I’m not here to write how much I loved him (although I did) but to tell you about him.Some very practical advice he gave to me and the other event participants on managing VR projectsI was able to hear four important lessons in particular that Indie teams need to remember this when developing a game if they don’t want to disappear.
1. If you can’t complete the prototype in 2-3 weeks, you won’t be able to complete the game in 1 year.
When Daniel told us about this “practical law” that we at Realities.io have, our reaction was basically this:
This “law” (which was formulated by Shah of Realities.io) is very interesting because it is true as a general rule: This was true for Puzzling Places and also for Beat Saber. I distinctly remember reading that the Beat Saber prototype was developed in a couple of weeks and then the team spent about a year before releasing the actual game.
The fact is that developing a prototype and shipping a real product is a completely different thing. Prototypes are hard-coded, simple, and buggy. Products need to be highly polished and refined, have a good user experience and onboarding procedure. Building a product takes a lot of effort. And you have to launch a really good product if you want to be successful: Beat Saber became a hit because it was ultra-polished, from the perfect timing of the cuts to the beat of the songs to all the graphical effects happening around you, not to mention how cool it was to have lightsabers in your hands. The game was great to look at, and it looked even cooler in mixed reality videos made with LIV. That was the start of its success. I don’t think the game would have been the same if they had just shipped two sticks in your hand that you could hit some grey Unity cubes with. If you want to release a successful game, it needs to be a highly polished one. This takes a lot of time, much more than it takes to build a prototype.
This general rule is important becauseIt allows you to frame the size of the work your team needs to commit to doing in order to deliver your next game. If you’re an indie team, you’re probably short on money, so you can’t commit to a game that needs 5 years of development – you can do that if you’re Rockstar Games, not if you’re a small team in Italy. So if you’re making a prototype and that prototype is just taking you too long, It means that the game’s development is taking so long that you probably won’t be able to sustain it. If the prototype takes 2-3 weeks, it will probably take around a year to make the fully polished game, which can be sustainable, so you should plan your resources (time, money, people) accordingly to deliver it. I doubt a small team can commit to a project for more than a year without recouping the money, so don’t work on projects that you can’t create in less than 3 weeks.
2. Promise little and deliver little
The Shah also formulated this other law, which seems like a manifesto for lazy people: “Promise little and deliver little.” This statement mocks The usual one, which is “Promise little and deliver a lot”, Which means you shouldn’t be too bold with your promises, but you should always deliver more than expected.
Although I still love the usual statement, because I like to always offer more than people expect, I understand the power of this one too. Although it may seem silly at first glance, It’s actually a powerful statement about not trying to do too much. Overdelivering means putting pressure on your team and probably not meeting deadlines.
I’ve been in XR startups for 10 years and I’ve seen that Every time, each project requires much more than expected, And in the end, you are forced to cut features before the delivery date. Everyone is always very stressed about delivery because there is always too much to do in too little time. It would probably make a lot more sense to be realistic about timing and Don’t try to over-deliver on features that aren’t going to be offered anyway. On the contrary, it is most likely that Even some of the features planned for “normal delivery” have to be removed due to lack of time, So perhaps it makes more sense to plan even to meet the intended goals.
Of course, This should not be a suggestion to be lazy: It is always good to be ambitious and try to push the limits. But at the same time, It is important to be very realistic about time.
3. Define the scope of your work well
Daniel was the mentor of the gaming track. He went around the tables with the teams participating in the hackathon and one of his most valuable pieces of advice was about defining the scope of the work very well.
Most teams participating in hackathons start with ambitious ideas, such as using multiplayer mode or developing very complicated technical features. This will only put a lot of pressure on the team, causing all members to get very little sleep, only to deliver in the end a very bad application that will never win. It is much better Evaluate exactly how to deliver an interesting app, being realistic about the time available and focusing on the few important things you can build.
One of the projects that won the hackathon was simply about assembling cubes to create objects. The Meta mentor who presented the award said the idea was simple and unoriginal, but The implementation was one of the best I had ever attempted, so the team deserved to win. On the contrary, some teams tried to do crazy things like mixed reality multiplayer with space tethers and didn’t win.
I know, it’s a hackathon and it’s meant for fun, so it’s okay to build weird stuff (I would do it myself), but it’s an example of what usually happens with products.You need to have a clear focus on what key features you want to develop and define your scope of work accordingly.
This point is a mix of the two previous ones: Since you need to deliver a polished product, you need to be very careful about what features you add. because you need to deliver them well. I remember in the past I was trying to create feature-rich apps, but then I realized that every single thing I added required Not only more time for development, but also for polishing, debugging and testing before delivery and also for updates after delivery. Every feature you add is a huge drain on your overall project time. And believe me, if you deliver 20 very basic features, you will get a lot of negative feedback from your users. It’s much better to ship just 5 features, but deliver them really well, so your users get excited about them and ask you to continue..
Defining your scope of work, when your resources are limited, is the way to goDon’t try to do too much, focus on what’s important.
4. Only commit to products that “click”
Daniel told us that Puzzling Places was prototyped in a couple of weeks and people on the team loved it when they tried it out. They then left the prototype there for some time without developing it further. They then played it back again so they could evaluate it more calmly.When they played it again, they loved it again. They knew it could have been a great game, it just clicked in their heads, so they decided to commit to developing it. The game became a widespread success.
There are two important lessons in this story. The first is that When you create something great, you know it. The moment you test the prototype, you feel like it’s fun, you feel like you’ve created something that a lot of people will like. You can commit to it, knowing that it will most likely be a success.Of course, you can’t be sure: entrepreneurship is always a gamble. But you should bet only on the horses that are most likely to win, not on the weak ones. When you test your own prototype, if you feel that it’s amazing, and the other people who test it also tell you that it’s amazing, then it’s worth betting on. We all know that “click” feeling we get in our brain when we attempt something great. I felt it myself when I tried Puzzling Places – I found it amazing and relaxing. When you feel that click, you know it’s time to place a bet.
Virtual reality is still a niche, and despite all the numbers about the millions the studio is making that Meta likes to share, the reality is that Most development studios are hungry because the market is too small.You can’t afford to ship an “okay” game. If you release a game that is “fairly fun” you will probably only get “fairly” sales and not recoup the investment you made in developing your game. (the famous year of development). This puts the survival of your entire company at risk: as an independent team, you cannot afford to invest your resources in a title that fails: you risk running out of money. So you have to try to launch a great game.A game that feels special from the moment you try its prototype. Here’s how you can build a sustainable business for your game studio.
The second lesson of the story is much more subtle and deals with Not evaluating your prototype when you are emotionally committed to it. When you make something, that thing is your baby, so you are emotionally attached to it: of course, you will like it as soon as you try it. And you will probably get angry when someone criticizes it. But that is not a healthy way to evaluate a business: You have to think with your brain, not your heart. And that’s why the Realities.io team waited a while after the prototype was created to evaluate it again. After a few weeks, you’re no longer committed to your app, so you go back to playing with what you made with fresh eyes and You can be more rational in evaluating whether it is good or not. And if it clicks again, it means that what you did is probably really cool and you can build a business out of it.
I hope these life lessons can be useful for independent teams. I want to thank Daniel Sproll for sharing his wisdom with all of us and I invite you all to share any other VR management lessons you may have in the comments section below or on my social media channels.
(Header image from Mapbox on Unsplash)
