Jumbli

If you’re thinking about developing your first VR game, these notes may prove to be useful. I've run a Kickstarter and Greenlight campaign, entered VR competitions, launched free demos and Early Access campaigns and finally released my full game on Steam and Oculus Home.

Let me share with you what I've learned so far and the many ways I've made it difficult to turn a profit.

From the solo-developer of Dimensional on Oculus Home & Steam

I'm Brett Jackson, 45 years old and have worked in software development since I was 18. I started working in VR as a result of the Oculus Kickstarter filling me with enthusiasm for VR. I had no previous experience in game development.

It's been nearly 2 years since I started game development and working full-time in VR. Now I've released Dimensional I can finally slow down a little and take some time to think (and talk) about what I've been through and learned along the way. Dimensional was supposed to be a small game that would help me raise funds to extend the amount of time I could spend on VR projects. It ended up taking nearly 18 months to complete and felt like a roller-coaster ride.

There's so much I could tell you. I've tried to condense and order the information to make it a little easier to digest. I'll start with the most important decision you need to make.

Be very clear about this - it will affect everything you do. Personally, I was driven by my excitement for VR and the possibilities it brings. I accepted from the start that I wouldn't make a profit but hoped that income from the final release would help to fund a future development. While sales have been disappointing, I have no regrets. I've learned so much and achieved an ambition by releasing a finished game that I'm proud of.

If you're driven by your passion too, make sure you have the means to finish your project. If you put everything you have into a game, it will be soul destroying to stop before you complete it.

Unreal and Unity are fantastic products and make it possible for new developers to easily create prototypes. As your project progresses you’ll realise how complex and powerful these tools really are and how much you still need to grasp.

I used the following tools to deliver my game: Unreal Engine, Blender, FMOD, Audacity, Quixel, Lightworks, Gimp, Inkscape, Acapella-box, Libre Office. All of these products have a learning curve.

The following infographic highlights the areas I needed to cover as a solo-developer.

As you can see from the previous infographic, you need to master many new skills. Maybe you're lucky enough to be artistic, a strong coder and have a good ear for audio. Even if you are, the workload may melt your brain. Involve other people with strengths in different areas if possible. My strengths are in VR concepts and coding. I would have benefited from getting help with graphics and audio but ultimately couldn't afford to buy-in more resources.

If you are working alone keep in mind:
Sick days, holidays and other commitments stop the project in its tracksWhen you hit a problem, there's only you to solve it

You have to squeeze all these new skills into your brain and it feels like there's always more to learn. While you're doing this you're constantly thinking about your game, coming up with new puzzles, rearranging the narrative, redesigning bits you're not happy with. Now add in the time pressure. You're desperate to complete this project, but you can only afford to spend so long on it. Then come the bugs that keep you awake at night. Obviously, it's fun and rewarding too :)

Before you start your intended project, build and release early tech demos to experiment with different ideas and to get feedback. Be careful not to give away any unique ideas, unless you're OK with other developers running with it. My early tech demos included:

Breath Tech Demo - use a microphone to project your breath into VR to increase immersion and use it to interact with objects. I made the source code public and was pleased to see it used by other developers.

eve-Books - used tiny head movements to track which line of a story was being read and changed the scenery and audio around the player to fully immerse them in the narrative.

Playpit locomotion system - the first version of my system to allow room-scale type experiences in small playing areas and force the player to physically move through obstacles.

Don't start a project that feels overly ambitious. I initially began with the intention of creating a complex game relating to lucid dreaming. After progressing for a couple of months, I realised that I wouldn't be able to complete my ambitious goals within the 12 months worth of funding I had allocated.

I then came up with the idea for Dimensional, a simpler idea I could complete within 6 months - it took nearly 18 months.

I developed complex prototypes to demonstrate the main technical features of the game in a matter of weeks. It felt like the hard work was behind me and now it was a matter of adding polish and building more levels. This is a major misconception.

Expect your early concepts to change a lot as you progress

Polishing a game takes a long time

Level design and difficulty balancing is hard to get right

I was also driven to continually experiment and put the player in different situations on every level. You can't afford to do that so much if your goal is profit-focused.

Simple stylised graphics are the recommended approach for small indie teams. You can concentrate on making it look great with effects and lighting and give it a unique style while keeping it simple.

I didn't go for the stylised approach because I was interested in making scenes feel more real and immersive. Personally, I wanted to see dirt and scratches and allow the player to know what objects were made of and get a feeling of their weight. This creates an overhead because players take notice of their environment more when the game isn't stylised. I crafted the narrative to explain the deserted chambers, but still found myself going back and adding more content (such as the worker droids) to make them feel less sparse. This is another example where designing for profit can differ from following your passion.

Screenshots and videos sell games. Keep this in mind while developing your game. Create content that you know will look great when presented online. You need to be in VR to appreciate Dimensional, that's not ideal.

You can purchase sound effects or in some cases you may want to record your own. Audacity is a free tool that can be used to record and alter sounds.

Positional HRTF audio is a must in VR projects to allow players to hear exactly where audio is coming from. This can be implemented in Unreal Engine using third-party plugins. I use the Oculus Audio SDK and FMOD.

The game should never be silent, so you will need background / ambient sounds. In VR you should try to create assets that produce noise and then you have somewhere to position your sounds.

If your narrative requires voice work you'll need to write scripts, audition voice talent and arrange for recording of the audio. This all takes more time and effort than you may realise. I use acapela-box.com to convert text-to-speech. This was a good fit for the AI in Dimensional.

The small number of headsets sold are spread around the world. To maximise sales try to reduce the need for a player to understand complex written instructions or voice-overs. Providing subtitles for voice-overs, even if only in English, can help more people understand local dialects.

Dimensional required quite a few instructions and included voice work in my local Yorkshire accent. A bigger budget game could have invested in better graphical or video demonstrations rather than written instructions and could have included multiple language support. The easiest approach is to keep your game simple so that it requires less instruction and also keep your narrative to a minimum.

You'll notice the large number of wave-shooter style games or puzzle games that have a low number of environments. They take something fun and make the most of reusing a mechanism as much as possible. That's the recommended approach for small indie developers. I'm sure you've played great games that do exactly that.

I tried to do far too much with Dimensional, which again is because I was following my passion and creating my dream game. Dimensional takes place over a number of chambers. While many 3d models are reused, each level brings new elements to the gameplay, new types of puzzles and new assets. Every level was hard work and took weeks of development and testing. If you're considering a level based game, think carefully about the length of the game you're aiming to create and the number of levels you need. Try to reuse assets wherever you can.

As your skills improve you'll no doubt revisit assets that you created early on and decide you can do better. I remodelled the level selection assets three times before I was happy with them. Doors, walls, checkpoints, teleport beacons and indicators all received multiple redesigns. There will probably be some puzzles or game mechanics that just don't feel right once they're finished. It's hard to throw something away after you've invested time creating it, but if it niggles you, it will annoy players. Sometimes it's quicker to scrap something and try again rather than repeatedly trying to make it fit.

If you're pushed for time, it seems obvious to limit the amount of effort you spend developing content that the majority of players won't see. However, it's easy to get drawn into creating something because it's fun to develop. In my second level there's a hidden area where a swarm of tiny maintenance bots fly towards you. If you stick around you'll see two of them busily at work covering up the secret messages left by someone. I spent too long on this area. In further hidden areas I tried to limit myself to revealing more of the narrative through simple messages rather than adding development effort.

I added some Easter-eggs in Dimensional. I'm confident no-one will find one of them because you need to be laying down. It wasn't sensible, but it made me smile - not a great use of my time though.

In Dimensional I unlock the next level even if you fail to complete the current one. I want people to experience everything I created for them, so the idea of stopping their progress if they get stuck on one puzzle was unacceptable to me. It's a sad thought that people often don't finish games and see everything you've worked so hard on.

Think about your price from the start of the project. Are you creating a short experience and charging a small amount or is there going to be hours of quality gameplay that justify a higher price.

I thought that if I made a long, highly varied game and charged a small amount then more people would buy it. I wanted the game to be played by as many people as possible and I hoped the low price would increase sales and average out OK. In fact I think the low price works against me. People see a 4.99 USD price tag and assume the quality or scope must be very limited so they don't buy it. People often comment on it being great value for money, but that hasn't driven sales.

VR is a rapidly evolving industry. I spent a lot of time upgrading the project to newer versions of software that supported the latest VR features and SDKs. Things have calmed down now but be aware of this extra overhead. You'll probably want to keep as up-to-date as you can. V2 hardware will bring new challenges and upgrades.

Working with the latest hardware and software increases your chance of finding bugs and issues. I use Blueprints for the bulk of my game, but have had to dig into the code multiple times to work around issues or missing functionality.

Keep your eye out for VR competitions and read the rules carefully. I entered and won the VRTGO VR competition in 2015 with a very early prototype of Dimensional. Rather than a monetary prize, I won a £1,000 PC, the opportunity to have a stand at the VRTGO event and mentoring from nDreams and Sony. If it wasn't for the competition I probably wouldn't have had the confidence to continue. Having experienced developers tell me I had a good idea gave me a much needed confidence boost. The advice provided during the mentoring was invaluable as was nDream's assistance with creating my Kickstarter campaign. Watching people play my prototype at the VTRGO event was also a real eye-opener. The experience gained through these competitions can be more valuable than financing for a new developer.

I successfully ran a small Kickstarter for Dimensional. Rather than just raising funds I wanted to test if there was any interest in my concepts.

Kickstarter is a fantastic platform. It advises and guides you throughout your campaign and makes the process as easy as it can. Kickstarter staff tagged my campaign as a "project we love" which was another boost and helped to generate additional traffic. Here are a few considerations when running a Kickstarter:

Preparing videos, demos, screenshots and the campaign text takes a lot of time

You need to spend time promoting your campaign and answering questions

You're committing to spend ongoing time posting future updates

Try to design rewards that give you things you need, such as assets or art

Don't have rewards that will take a long time to implement or deliver (e.g. T-shirts)

Make sure you have multiple rewards levels between £1 - £25

Ideally you should demonstrate progress with your project during the campaign

By asking for too small an amount, some people thought I was less credible

Don't over-promise - keep your stretch goals small and simple to deliver

Your Kickstarter can help raise awareness of your project and build a following

Currently VR projects are not having to go through Greenlight, but don’t expect this to last forever. I ran my Greenlight campaign alongside my Kickstarter to help promote one another. Like Kickstarter, you need to spend time running the Greenlight campaign and promoting it. My development progress slowed greatly during the lead up and duration of the Kickstarter and Greenlight campaigns.

Most VR games launch without a demo, so you are by no means obligated. Personally, I feel that VR is so new and there are so many ways to make people feel ill, that it's only fair to let them sample the game.

If someone has 10 pounds to spend, they may play your free demo and then buy another game for 10 pounds so that they got to experience 2 games for their budget. People may incorrectly think they have experienced most of what your game has to offer in the demo and therefore not buy the full version.

If you do release a demo, you'll need to update it as you refine the game mechanics and add more polish. That means spending time building, releasing and testing the demo multiple times.

My early demos were stable but visuals and audio were very rough. First impressions stick and videos may end up on YouTube. People may never check out later builds of your game due to their initial impressions.

Try to make your early demos a good representation of the final quality you're aiming for. I put far too much gameplay in my early demos to let people see all the features I wanted to demonstrate. Short and polished is much better than long and rough. I left my UI design till very late in the Early Access, thinking that people are much more interested in gameplay mechanics and UI didn’t really matter. It does matter. Everything matters. UI, audio, atmosphere, fun - get all these things right from the start to make the best impression.

The success of your project shouldn't rely on getting funding. I invested time trying to get funding so that I could buy-in design and audio skills. I approached all the major players and applied for the Unreal Engine developer grant too. I wasn't successful. At the time, the lack of responses to emails was frustrating and demoralising. I felt I had something different and worthy of investment, but I wasn't being realistic. Why would they invest in a solo-developer with no proven track-record who was pushing rough prototypes that lacked polish.

On the other hand, do make yourself known. I did benefit from receiving free hardware for HTC Vive, Oculus Rift and Touch and OSVR HDK2. That’s a big saving for a solo-developer.

Dimensional has loads of USPs: unique locomotion and methods of supporting room-scale and small spaces, handling boundary violations, dominant forward direction, use of mic and more. I started off trying to think of the limitations faced by VR and then found ways to work around them and make the game as immersive as possible. It takes an A4 page to fully explain my technical USPs and why they're important - that’s not good. Your USP will ideally be something that can be demonstrated without explanation in a very short video. Fun, interesting USPs beat technical achievements.

Performance is critical in VR so make sure you're developing and testing using the worst case scenario, i.e. the lowest specification recommended by the HMD manufacturers.

Start off with simple scenes that perform well and then gradually add detail. This is much easier than creating your ideal level and then trying to make it perform adequately.

Dynamic lighting can drag your performance down. Use it sparingly and avoid overlapping dynamic lights. As usual, I like to make things difficult so use dynamic lighting throughout the game. I like to use physics-enabled objects with dynamic shadows to make the world feel more believable. You'll notice I turn lights on and off as you enter a leave areas to minimise the overhead of having multiple dynamic lights. Sometimes the dynamic light follows you instead, so I can just use one light source.

When you play your game, the controls feel natural, the solutions to puzzles obvious and nothing is confusing or obscure. To get a true measure, you need to involve new people who have never played the game before.

I first realised how important this was when giving demos at VRTGO. Just watching people play is immensely useful. Seeing where they look, what they notice, how they respond to cues and how they think a puzzle should be solved. You need this kind of input on every level you build. People who haven't played before are much more likely to discover bugs too because they will do things you didn't plan for.

If you release an Early Access version, regularly search for videos of your game that have been uploaded to YouTube. Most videos I watched resulted in levels or game mechanics being tweaked. Shane4Games played all my levels and uncovered numerous issues that I was then able to fix in the full release.

Here are some of the bugs that caused me the most stress.

When I first released the Early Access on Steam, some players reported they couldn't shoot my droid using the HTC Vive controllers. At first I thought the issue was just with one player and maybe their controllers were faulty. Then a second report confirmed the issue. It turned out some Vive controllers didn't reset the trigger value to 0 when fully released. That was very hard to diagnose without having the problem hardware in front of me. Don't assume all hardware will act exactly the same, especially with new hardware.

Watching a video on YouTube, Shane4Games couldn't teleport to a platform on the first level. He tried for 5 minutes and suddenly it worked. That's pretty disastrous. I tried to reproduce the problem for ages but couldn't make it go wrong. Then I noticed, Shane is taller than me. I climbed on a chair and played the level again and sure enough I hit the problem. An obscure issue relating to the players height caused the issue. VR games can have VR specific bugs.

I had an early issue where positional sounds would just stop working. I thought I had this bug squashed. A few weeks before the final release I watched a video and saw the problem had still been occurring. Again this would have been a major bug to release with. It turned out that to reproduce the problem you needed to play a single session for a lengthy time. My testing mainly involved lots of short sessions as I constantly made little changes - so I had missed it. The issue was related to audio resources not being released. Once I could reproduce it, I could fix it. Make sure you test your game for long sessions just like your customers will.

Note that many people will not report bugs, they will just stop playing.

If you see a bug occur once, it will happen again. A bug is never just a "one-off" freak occurrence.

An Early Access campaign is just like a full launch. In fact, I sold far more games during the Early Access launch than the full launch. Fewer titles means that people are more likely to buy in at the Early Access stage.

Your Early Access should include a high quality product that represents your final product in terms of polish, performance and stability. My Early Access started with too much content and not enough polish.

Preparing releases and testing them to make sure you haven't broken something takes a long time. Releasing too frequently wastes your precious development time.

Positive and negative reviews and general comments provide valuable feedback. Think very carefully about criticisms, they are usually valid and can help you to improve your game.

Check your community pages regularly and answer people quickly. The community you're building can help with identifying bugs, balancing issues and general testing. Most gamers are friendly and helpful and want to help make your game better. They are a valuable asset, make sure you respect and appreciate them.

People are happy to help you. Not everyone you give free keys to will provide feedback and that’s OK. You can't expect someone who's never played your game to commit to playing it all the way through for free if they don't love it. I expected about a 50% feedback rate, so gave away double the number of keys.

Beta test the full release weeks before you plan to release it. Give the testers plenty of time to complete your game. You need time to fix bugs, but the testers will also come up with great new ideas for your game that you may have wished you had time to include. My beta testing was far too rushed.

You're job isn't just to develop a game - you need to sell it too. Try to build interest throughout your project with appropriate high-quality videos, articles, press-releases and social media postings. You will probably want your own website or at least a presense on something like indieDB / VRDB.

If you are launching a Kickstarter or Greenlight campaign, you would ideally have a following before your launch.

Preparing for your launch should include writing and distributing press-releases, demo videos, sending keys to You Tube players, planning social media posts. Do all this before you launch, not after.

Places to promote your project could include Reddit, YouTube, specialist VR websites (UploadVR, VRFocus, RoadToVR and more), Facebook groups.

I stupidly launched my Early Access campaign on Steam during the summer sale.

I launched the full game on the lead up to Christmas as lots of other developers were pushing their releases out. I was especially disappointed with the Steam release. Within under 24 hours the game was pushed off the first page by newer releases. The Early Access had already resulted in sales to many of the people interested in the game so the number of new sales remained low. This resulted in fewer new sales and therefore less promotion / traffic to the store page. Very quickly my visibility on Steam and potential for meaningful sales volumes was vastly reduced.

Make a plan from the start and build in plenty of flexibility. It's better to wait a few weeks rather than release at the wrong time.

If your feelings are easily hurt, game development may not be for you. You're going to be putting everything you have into the project, doing your very best. When people don't connect with your project it can feel disappointing. Negative reviews can be hard to take. Remember that negative feedback is important to help you improve your project.

Don't let down-votes on Reddit get you down. When I excitedly posted an announcement about finally going live with Dimensional it received a downvote within the first 10 seconds. Don't worry, most people are supportive, helpful and friendly and the votes soon balance out. You'll notice that most posts have some down-votes.

Don't try to please everyone. Have a target market in mind and aim for that type of player. I tried to do a little of everything so probably ended up frustrating players in some levels where they encountered styles of gameplay they weren't expecting.

On the positive side, hearing from players who really understand what you're trying to achieve and that enjoy your game is very satisfying.

It's your game and you love it, so you'll think it's the best game on the planet. For your game to be financially successful in such a small market you need people to get excited about it.

A good test is to post videos and information on social sites such as Reddit, YouTube and Facebook. Don't take a dozen positive comments as a sign of future success. I would say having up-votes of over 100 would be a better indication and videos, with thousands of views, that are being "liked" and shared.

If videos of your game don't get a massive response it doesn't mean you have to scrap the project, but you may want to limit the amount of time you invest. Maybe cut back on the number of levels or complexity if interest is not as high as you had hoped. You can always extend the project after Early Access or even after the full release if demand turns out to be high.

I built the game that I'd envisioned without compromise and I'm more than happy with the end product. I've not really got any regrets. However, I felt like I was rushing every day for 18 months and that detracted from the enjoyment of the project. I hope this article educates other new developers and steers them in a direction that is less stressful.

I'm often around the VR subreddits if you want to ask me anything /u/Jumbli.

Thanks for reading.

Connect with me for more news and insights