Why yet another SDK or engine? Having helped bring several other engines to market and seeing the same problems over and over again, Blurrr’s spirit is a reboot back to fundamentals to try to stab at the heart of the problem instead of yet another layer.
There are multiple things to talk about, but ultimately, it is about understanding and control: the idea that you have the full ability to do what you need to customize, standout, and fulfill your vision.
Understanding & Control
A common theme is that most engines have become too big, too closed, too blackbox, or too over-engineered to understand how they work. And when you need to make them do something they weren’t explicitly designed for, you hit a wall. And there is a self-defeating attitude that it is too hard to write something from scratch or change how something works, so you end up with layers of plugins and workarounds to achieve your goal, which in turn creates performance problems and difficult to maintain code.
We are now in a period that is beginning to push back against the fallacy that writing from scratch is a bad thing. And more importantly, there is a re-emergence in the idea that understanding how computers actually work and how the code architectures we build on top of them matters for both performance and the ability to deliver a superior product.
I personally am a huge fan of Handmade Hero and recommend it to everybody. Some people might misinterpret that as you shouldn’t use libraries and you should write everything yourself, but the real point is that you should be able to reason and understand how things works. You can then make intelligent decisions about whether you can use something else that has been written or if you will be fighting the framework at every step.
So Blurrr starts with SDL, the respected, time-tested, open source cross-platform abstraction layer. From there, Blurrr’s additional libraries try to stay modular instead of monolithic. You can add modules you want and remove the ones you don’t want. And the majority of the libraries provided by Blurrr are open source. With specialized, decoupled modules, you have a chance of both understanding and taking control in meeting the needs of your project.
And Blurrr’s application architecture and library system itself is simply what the underlying platform asks. This means you can always add a native library or your own library. You also control the main application loop of your own program. It is not read-only and untouchable.
Multiple Language Support
Languages are tools, not a religion. It should be about picking the best tool for the job.
In my prior engine/SDK jobs, the problem was they often promoted a certain language and it wasn’t always the best tool for every job, but religion demanded it be used. This created a lot of problems like complexity, slow performance, and complicated build systems. It also created an artificial barrier to native platform features.
Blurrr doesn’t want to dictate religion. You are professionals. You now can choose the best tool(s) for the job.
Blurrr approach to this is meant to be straightforward. C is the foundation of all operating systems, core platform libraries, and the one language that every other language knows how to communicate with. C is also really important to video games because you can deliver high performance. So the approach is start with a C core and build out language bindings.
Lightweight & Modular
Many engines have gotten really heavy. You get tons of features you never use which impacts download size, launch speed, and possibly other things you don’t know about because the architectures are so complex and monolithic.
Blurrr is focused on staying lightweight and modular.
Cross-Platform
Cross-platform is a bigger thing than it used to be. Still, there are a surprising number of SDKs that don’t do some of the significant or interesting platforms. There also seems to be an artificial mental divide between desktop and mobile despite the latter have become quite powerful and the fact that a lot of 2D games don’t need the premium horsepower.
Blurrr wants to bring down the mental divide between desktop and mobile. And Blurrr was treated SteamOS/Linux as a first class citizen from day one of its inception.
Raspberry Pi 2 turned out to be a nice benefit of having both good mobile support and Linux support. But it’s most interesting aspect is how it allows for innovation through custom hardware construction.
Native
The term native gets used in many different contexts. But Blurrr actually tries be native in all of them.
Native code - Blurrr’s foundation is written in C and the native platform APIs. Blurrr apps are native apps.
Native performance - Because the underlying code is C/native, you also get native performance in these layers.
Access to Native features - Since Blurrr apps are native apps, it is always possible to tap into native platform features like any other feature.
Native User Experience - Blurrr tries to pay attention to native user experience too. It takes into account the things like how Mac apps should be self-contained .app bundles without installers, or dealing with the iOS launch screen, or how to get your app into SteamOS Big Picture mode for testing or 3rd parties.
Native Development Tools - Blurrr recognizes that companies like Apple, Microsoft, and Google invest tens of millions of dollars per year on improving their developer tools. You should be able to take advantage of them. And since a Blurrr app is a native app, Blurrr lets you access to them.
Cross-platform Build Systems
Build systems are sometimes harder than your actual code base. And maintaining a cross-platform build system can be tough since there is no agreement between any of the platforms on how something works. Typically, after two platforms, the burden of keeping multiple platforms becomes hard.
Blurrr has multiple goals with its build system.
- Fast
- Access to native tools/IDEs
- Easy to maintain for multiple platforms
So Blurrr uses CMake which is a meta-build system. You provide a centralized build description, and it will generate native Visual Studio projects, Xcode projects, or Makefiles. It has efficient dependency analysis and leverages native tools when it can so it is among the fastest build systems.
Blurrr has done most of the CMake for you, so you just need to plug in new code or resource files in the right place.
Stand-alone, Self-Contained SDK
Blurrr provides a download-and-go experience. Assuming your platform’s compiler is already installed, the idea is you can just download the Blurrr SDK and start using it, without any installers.
This has several powerful advantages.
- Developers in your organization can recreate a development environment trivially instead of wasting hours to get all the dependencies installed.
- This allows you to have multiple versions of Blurrr on your computer. This can be useful for freezing against an old version for existing projects, but testing the latest for new code.
- And it allows for easily reproducible builds.
Everything is local to your machine which means no server components. This means you can work offline, or on an airplane, or anywhere without an internet connection.
Deference to knowledge before
In my prior work on other engines, there was always an perverse incentive and sometimes arrogance to reinvent and “own” the APIs. This means if you were actually using an existing library, you had to change the APIs for the mere sake of owning them. This doesn’t benefit the user, but helps create lock-in.
Sometimes there is a desire to “improve” the library. But I say there is more often than not an arrogance here because far too often they feel they know how to improve things, only after using the library for at best a few days. This fails to take in the consideration of the original author of the library who is probably a domain expert and thought much longer and harder about the problem,
So Blurrr’s approach to libraries is a counter-reaction to this trend. Blurrr wants to be useful, not merely create lock-in. Blurrr provides and promotes many open source libraries and demonstrates how to use them together in harmony as is.
Blurrr is not opposed to creating new wrapper libraries to improve things and there are things already in the queue, but not for the mere sake of owning something. They must be useful in their own right.
Blurrr SDK currently ships (subject to change)
SDL - foundation for basic graphics, low-level audio, input
SDL_image - loads more image formats
SDL_ttf - loads fonts
ALmixer - Higher level audio library API on top of OpenAL
OpenAL - Spatial audio library
Chipmunk2D - physics
SDL_gpu - An alternative renderer for SDL that allows the use of GL shaders
SDL_net - socket library
libcurl - http library
CJSON - JSON library
pigpio - Raspberry Pi GPIO library
Lua additionally contains:
LPeg
LuaSocket
GPIOLua - For Raspberry Pi