Are you a hardware manufacturer? Are you looking to developers to create software for your product? Are you wanting us to implement your SDK? You already have plenty of hard work to do for your end consumers, but it doesn’t stop with them. Games hardware doesn’t appeal to end consumers without a good quantity of quality content for the device.
Gettings us Interested
Let me give you the TLDR now – I still get emails occasionally asking us to support some new VR hardware from an unknown company coming to Kickstarter, where they will happily give us early access if we “just pay £XXXX”. I’ve also seen “competitions” where if you show off a game you could “win” hardware. These immediately put me off as they are not a compelling business case for us and shows us that you don’t necessarily respect our time.
Where we are as a business now vs. a few years back means things have changed a bit but my interest comes down to (in priority order);
- Potential profitable business opportunity – now and later
- How much we think you believe in your own product
- How much you respect us and our time
- The potential market – i.e. how many of our players will use the hardware based on my +10 years as a dev, and +30 as a player, of seeing hardware die straight out the gate from even the biggest of companies
- How much I think you’ll be able to support your own and our products on the platform
- Our previous experience working with you or what we’ve heard from other developers
- If it fits into existing projects or future games, and where we are in our current projects dev cycle
- If other developers are also supporting your product
- My checks on your company via companies house, looking at your directors and previous things they have done, checking previous news reports about your business
- How easy will it be to be onboarded as developers
- How different the technology is to learn and adapt to
There’s much you can do to help some of these points!
Access to Hardware
The basics for us not paying for access to hardware, and getting it early before we have to pitch. This at least allows us to sample some of the quality of the kit, test to see what it can do, and push it to its limits. What you say it can do doesn’t mean we trust that evaluation, or the exact details of it. We need to be able to jam with the kit, make our own little test games for it, to see what will work best in terms of gameplay and really show off the hardware. Its in both yours and our interests to make a game that shows off the strengths of your hardware.
I have two good examples of this.
HTC and Valve brought over the original Vive (DK1) kit and hosted a game jam. This was a good year or so before it’s final public release. They allowed us as developers to experiment with the hardware, try out some ideas on it. We made an early prototype of Unseen Diplomacy in a weekend for it. We were not sure on the device before that, but after we were convinced of its potential and had a game concept we could run with and build into a fullier title. That title was eventually released for the launch of the Vive and was the perfect example of really using the room space, with many press realising the potential of the hardware via our game.
On the opposite scale was when the original Oculus Rift said they had expanded their tracking capabilities. We got to test the tracking out – and it wasn’t what we were expecting. They assumed that players were always going to be standing so the controllers couldn’t track well for crawling around on the floor, and the total play volume was smaller than what the Vive could do. This meant for us it’ll be considerable amount of work to port Unseen Diplomacy to Oculus Rift. Without any funding we had to make the business decision not to support it and focus on more profitable ventures instead. Trying out the hardware save us, and Oculus, time and investment that would have potentially been wasted – and stopped a game releasing that would have showed off the limitations rather than the possibilities of the hardware.
Please remember – coming up with concepts isn’t free, and we can’t just drop everything. We need to be able to plan projects often a year or so in advance, and it may take a few months to create a concept that we’re happy with. Make sure to send us hardware as soon as possible so we can plan well in advance what we’re doing.
The Business Opportunity
As a business we’ve got our head down making our own personal IP, making and selling Unity Asset Store tools, and doing some work for hire. You have to pitch to us why we should be spending our time on your hardware. Cool technology and free “exposure” doesn’t pay the bills – in fact my new favourite comeback is “exposure tends to kill humans”.
There’s a lot to weigh up – but if you make it so that the venture of porting to your hardware is immediately profitable, then we’re much more likely to take notice! This of course is optimum for developers as it basically turns the venture into a more client based relationship and we’re much more likely to be able to focus our efforts onto designing for your product.
If there’s potential extra revenue further down the line, then sometimes we may ask for an advance on sales at least to cover our development costs. This way it shows that you believe in your product and are willing to invest in quality content, and that you know you’ll be getting your money back on your products launch. We’ll want to see some figures of course, see your plans for shipping and marketing so that we can plan ahead too. If you can’t afford that small advance for the port – then it shows us you can’t even necessarily afford the final build of the hardware and marketing costs it’s going to require for your product to take off.
Reputation and Respect
It’s rare we just support new hardware for fun. Again, it’s about potential future interests vs. current ones. We still need to be able to pay our staff, but we are also looking for future business relationships.
I’ll be doing my research – asking around other developers what their experiences have been, checking out the state of your company via your tax returns and what your directors have done, researching the people behind the business to see their ability to deliver. Of course, I’ll also remember times we’ve worked together before, or how you’ve interacted with me at expos or events. I’ve caught one company out before by finding old court documents where they haven’t paid the developers they were working with!
I’ll be asking hard technical questions or thinking of odd side cases – be ready for me to interview you rather than you just interviewing me. Allow time for that during our conversation.
Along those lines, generally I’ll be seeing what respect you’ve shown to me and my company. Do you address me and my male partner equally? Have you done your research on me and my company so I don’t have to introduce everything? Have you played the titles we already have out and thought about how design wise, they will work on your platform? Tell me what your favorite elements of our games are – let’s have a talk about them so we can jam some ideas together. So me your invested in me, so that I’m much more likely to be invested in you.
Onboarding
So you’ve sent the hardware to me, signed me up with NDAs and we’ve agreed on a porting rate. I’m still going to insist on trying out the hardware first, and now your SDKs, before actually signing to a project.
If your backend is a mess, your SDK undocumented and your support staff hidden behind a single email – that’s really going to put us off. We don’t want to feel like public beta testers – unless we get the compensation to do so. We’ll be looking at the quality of your work, seeing the efforts you’ve put in, basically testing out to see if you know what you are doing! We can plan projects based on known risks, but if the robustness of the SDK is wibbly and unpredictable – we may not be able to afford to take the extra risk on the time it can take.
We can help as developers – use that to your advantage. We’re much more likely to be wooed if you are clear and honest about the current state of your hardware and software. Show ALL your bugs and upcoming features to developers, and their expected fix date. We need to be able to find bugs, report them if they are new, work around them if they are expected to take a while to fix, and discuss with other developers and your staff on other possible workarounds. The most frustrating case we’ve had recently was one of our staff spending 2 days finding a new bug,creating a repro project, spending a while creating the bug report. After a few weeks they were told that the bug was being closed because a) it was on their internal bug database, b) they wouldn’t make a public one so we couldn’t track it, and c) told it wasn’t serious enough for them to fix regardless of how serious it was for us! This shows us that hardware manufacturer doesn’t care for our time or respect us.
Don’t just create a bug database though – allow for feature requests too. I’ve been doing a lot of research into accessibility and have a lot of tips and user cases I could share. You want a method for developers to be giving those ideas and feedback – otherwise it’s just lost. This shows us that you care about our ideas and knowledge, and respect us enough to listen to us.
Day to Day Programming
Hurrah! We’ve all signed up. Next stage is that you want to ensure you get the best product out of us, to the time scale and budget we’ve agreed. How is that going to work? By giving us developers the tools to create content fast, reliable and efficiently.
Simple one to start – you don’t know what kind of machines developers are developing on! I’ve been put off working on hardware as it was forcing me to upgrade my workstation from Windows 7 to 10 when it was still fresh out the gate (something that could take a developer out for a few days). A developers environment is their castle, they are comfortable with it and work quickest with what they know. They could be Mac users, use AMD over Intel or ATI. Make sure to test your hardware and tools on all platforms and setups and try not needlessly force developers out their working battle station and forcing them to take unnecessary risk.
Another one which may be overlooked are samples. Create demos for developers. These demos we may play before we’ve signed up for a port to test out the functionality of your hardware. But we often resort back to samples throughout the development of a project – we’ll use it to check out best practises, every time we update the SDK we try out the test scenes, make sure everything is working as expected. We use your samples to build our own work. Giving us samples enables us to get going faster and to check to make sure everything is all OK.
If we’re doing a porting project – we may not want to update to the latest version of Unity. Sometimes it’s because it’s not stable, or that a feature we need isn’t supported anymore. You need to be supporting a range of engine versions for an extended period of time – especially the LTSs.
Developers also need to be able to debug. Is your hardware standalone? Do you know how LONG it takes to do a build? And the sheer pain trying to debug something on the kit when you don’t have all your usual debugging tools like being able to see the scene, hierarchy and console? Give developers power tools – PC based simulators so they don’t have to debug on kit all the time. Screenshot, video, stats capture and dump on PC so we can program playback so we can see stats/video/inputs again to try and replicate bug or step through frame by frame what we think may be happening. Be able to debug exactly what the CPU/memory/GPU is doing. Even the ability to video stream out to PC so we can capture on our own desktops to use that for quick gameplay trailers or bug reports. What ever you can do that saves us time and brain power – we can put into making the game for your platform better. This comes down to respecting our time and sanity.
If you push an update to your SDK – try not cause any breaking changes! We don’t want to be updating to the latest SDK and find that the game doesn’t function anymore, silently breaking in your code because a function has changed. On that note do be sure to document all changes to your SDK – past, present and future. A developer may need to roll back, or update an SDK due to come issue so they need to know what version it’s been found and fixed in.
In Summary
- Respect us, listen to us, be passionate about us
- Respect our time and understand that our time is limited and valuable
- Be as frictionless as possible to onboarding developers and give them an enjoyable time developing for your product
- The better you support developers the better the quality they can produce, which is good for everyone
I hope I’ve given you a lot of tips and an insight into the minds of developers. Not all developers are equal of course, they are all at different stages of their careers, businesses, of life – and have different passions.