All Articles

Technology Choices

When starting out on a new software project, after figuring out the initial idea, the issue of choosing the right technology stack to build is the next thing to tackle.

Sometimes, it’s really not that important, like just recently when I created this new blog. I just set some requirements:

  • Easily self-hostable, I don’t want to depend on backend services
  • A ready-made theme that looks alright
  • Static site generation, point nginx at the directory and go
  • Ability to write posts in markdown

Started googling, and quickly found gatsbyjs. Easy to install via NPM, picked one of the ready made themes, it just worked. It also has the advantage of using React, which seems like a good up-and-coming technology to have some exposure to. Deployment is trivial.

Done!

Now, a blog is not really business critical and can, as mentioned, be trivially replaced. The last few months my head has been bursting with ideas to realize as VR applications, and now that I have time to finally build something, I need to choose my stack.

For example, ever since the Oculus kickstarter, I’ve wanted to do something with VR. And now that I’m independent again, I have to pick tech to work with. So I started surveying platforms. The choices seem to be:

  • Unity. By far the most popular, not too expensive, but has limitations.
  • Unreal. Very powerful, can write game code in C++, very expensive when successful.
  • Build-my-own. Unlimited power, but need to build everything from scratch in C++.

Here the choice is trickier, and other considerations come into play.

Since I am currently a single developer with no team, I need to maximize my own advantages. I can’t create games or applications that require a ton of art, but I can do advanced rendering or world-building technology that’s tricky or impossible to replicate within the confines of fixed engines like Unity. I am a very strong C++ programmer, so the C# of Unity is not much of an advantage.

Unreal is (or at least can be) C++ based, but it’s a massive system to learn. I recently heard someone say that when you start with an engine, you start with years of technical debt! Of course, you also start with a lot of working systems.

Unity is also quite powerful and has the huge advantage that lots of people are learning it now, so future collaborations will be much easier. The flip side of that also means that lots of people will be creating the kinds of games that are easy to create in Unity, such as simple physics puzzlers.

Another issue is that I’ve been away for graphics for a while, so I’m just now catching up on things like PBR rendering, GGX distributions, metalness workflows and so on. Making good progress there though!

So call me crazy but I decided to indeed build my own. Forces me to learn the new stuff in detail, and gives me tons of freedom, but is a lot of work of course. I already have something running, complete with a simple asset pipeline built in CMake.

Let’s see how this pans out, stay tuned!

Comments are appreciated :) Just e-mail me at hrydgard@gmail.com .

Published 9 Dec 2016