We have been trying to update our software iteratively. Early on, we decided that we’d work hard to focus on our riskiest assumptions and try to deliver functionality as quickly as possible to test those. With desktop software, this is a little more complicated than web-based tech, so early on, we built an update mechanism that allows us to auto-update our software any time someone launches it, and even while it’s running.
Our technology is really complex, but as mentioned, every iteration should aim to prove/disprove a hypothesis. We want to walk before we run and have each improvement provide value to our customers. We’ve come a long way in the last six months with our product, and we wanted to share why we made some of our choices.
Our vision is that we’re entering a new era of computing where software eats local processing, and we access our computers rather than own them. This will free consumers from the constant hardware upgrade cycle, get hardware out of the way, and just let everyone enjoy the software and content they want without worrying about compatibility. To do this, we’ve built a low latency, 60 FPS HD video streamer. Gamers can now access their gaming PC from anywhere on lots of different devices or set up a cloud gaming PC without buying an expensive gaming PC.
Step 1 — Can We Build This?
First, we had to prove that we could build the streamer. We focused 100% of our energy on our streaming software and making it as low latency as possible. There were tons of bugs and some seriously opaque errors (sorry), but this early version from September proved there was demand, and we could build it. At this stage, we didn’t spend any time on a user interface. Early on, our software was a terminal application…
Step 2 — Make The Software Easier To Interact With
We knew that most people, even fellow developers, didn’t want to interact with this terminal application. So we built a simple website that gave users a few settings and control via the web.
This was a first step and allowed gamers to use the application with a little less friction and fear. We asked a friend and designer, Ed Moss, to spend a couple days making this website better, and he came up with this:
This helped, and gave us some breathing room to jump back into the core application.
Step 3 — Refocus On The Core Software
We tried to solve some of the usability issues, but there were a ton of improvements required on the core technology to really bring the latency down further. We introduced our own networking protocol, brought down the latency on the Mac and Windows clients, built friend streaming, and debuted a pet project that shows the power of low latency streaming — a Raspberry Pi client. Jamie joined team and took the lead on core usability features. We know that these things matter, but having a stable foundation to build upon was really important. This iteration brought improved interactions with controllers and fixes for edge case bugs with the mouse and keyboard inputs.
Step 4 — Get Rid Of The Terminal
That terminal application got us pretty far, but it was time to retire it (on the client first). We increased the number of users significantly, so we needed to add a little more functionality to the client to help people log in and connect to their servers.
At this point, Parsec gamers still had to use a configuration file (config.txt) to manage their settings. It was annoying, but early users were willing to dive in and tinker with their settings — thank you. We will always keep this functionality because we believe in the power of controlling your own gaming environment.
Step 5 — Combine The Client And Server And Introduce New User Interface
Having to download two different pieces of software adds confusion. Skype and other client-server software typically have consolidated their two applications. A lot of the work that was done in January and February prepared us to combine the Parsec Client and Parsec Server into a unified Parsec Application.
Adding a settings page was also a big win with this release because it gives users who are less technical more control over their sessions. Of course, there’s still an advanced settings section, but with the current settings, gamers on Parsec are able to manage a lot more.
Step 6 And Beyond — A Better UI, More Clients, More Functionality
We’ve learned a lot from our users over the past 6 months. Thank you so much for putting up with the early versions of the product and for your patience! Our next project is to reduce the number of connection errors with some magic to help us traverse nasty NATs. Following that, we’re going to add more functionality around connections, switch from wxWidgets to atom.electron.io (goodbye 90s, hello 2017), and add compatibility with other operating systems. There’s a lot to do, but we’re equally excited to keep learning and building with our customers!