In my previous post on C++ embedded scripting I talked about ChaiScript and described how to implement some tricky cases when embedding this language into your C++ application. Although the language is really interesting, there are some flaws in it that I find serious, like, for example, not very rich syntax or long compilation times.

Having said that, I decided to search again in attempt to find a good Lua binding library. After some research I found one - LuaInft (C++11), which I want to talk about today. A good documentation (at least it has one!) plus the fact that its author positions the library as a modern remake of LuaBridge (another good, but abandoned library), attracted my attention immediately.


Go to recipes

Currently there are several options for embedding scripting into your C++ application. Among the most well-known, from my experience, are Lua, AngelScript and the recent addition - ChaiScript. I’ve been evaluating these languages for some time recently and my main impressions are:


Part 1

Whoa, that did happen! Not So Flat has finally been released and is available for free on

The only game before Not So Flat that also had a devblog about it was ultimately abandonded and never made it to the release. I was afraid that Not So Flat would suffer the same fate, but things turned out (almost) very well.

This second part of the devblog is aimed at explaining the character movement implementation. This includes two major topics: the actual movement (running and jumping) and the calculation of the space available for movement.


Not So Flat devblog

22 Mar 2015

Part 2

Not So Flat is the name of the new game that I’m currently working on. When I first started the development (late December 2014), it’s been already more than half a year since my previous game Cubic Roll came out. At that time I was struggling to come up with a unique gameplay idea that I’ve never seen before, but which could still be quite feasible to implement within an acceptable time bounds.

In search of inspiration I was looking through my old prototypes and found one that was dated back to the beginning of 2013. The idea was quite interesting but at the time the demo was made I had lost my inspiration because I wasn’t able to implement the concept in a way that I could be satisfied with (that was technically a bit challenging). Looking at that demo again I’ve decided to give it another try and see what happens this time. I had no ideas better than the one already implemented, so the decision to continue the project was easy to make.


CLion is a new C/C++ IDE from JetBrains, the creators of ReSharper, IntelliJ IDEA and many other great products for software developers. CLion is claimed to support a full-featured refactoring workflow for C++, similar to how it is already implemented in other JetBrains products. At this moment the IDE is available in early access mode, which means that we can download and use it freely, keeping in mind that the product is not stable yet, so bugs are possible.

I decided to move one of my projects from XCode to CLion. The refactoring capabilities of XCode for C++ are far from being good (in fact, there is no refactoring support for C++), and after using ReSharper for my C# projects, I simply don’t understand how to work without “Rename”, “Find usages”, “Generate missing members”, smart highlighting and a plenty of other super-useful features.

CLion uses CMake to describe and manage its projects (at least yet). If you’re not very familiar with CMake (like me), creating and building anything more complex than the default Hello world will be sort of a nightmare. In this post I’ll share my experience in building a static library and a project that uses this library in CLion, hoping that this will save a lot of googling time for anyone having the similar task.


Picking and dragging objects around is something that you can see quite often in various games with the first-person camera view. This features adds a lot to the level of interactivity with the game environment, so developers build their game mechanics around this feature for a good reason.

So, how to implement this inside Unity? I’ve seen some implementations ranging from the very simple to the more advanced ones. In this post I’ll try to explain what I don’t like about some of them and propose my own solution with an interesting hack behind it.


When Epic Games introduced their new type of license for the Unreal Engine 4 (the so-called EaaS, i.e. “engine as a service”), it was only a matter of time for me to start testing and using the engine. To be honest, I had certain difficulties understanding some basic concepts of various things that make up the engine editor. Most importantly, the blueprints. It is indeed a very powerful system, and judging by various tutorials that float around the Internet (including the official ones), this system can do almost anything that you previously needed to write code for.


A few testimonials first. FAR Manager was the kind of software which I used a lot on a daily basis. Really, it’s fast, has a rich feature set and looks cool (console-styled interface is quite competitive with those native Windows GUI’s that other managers have). When it comes to reading large files like logs, FAR manager is beyond comparison.

However, one thing that sucks and always did in FAR is the quick search – the search that is activated when you press Alt key and start typing. The concept itself is very useful and allows you to navigate files at the speed of light, but in FAR the whole idea is ruined by the way it’s implemented: FAR seeks the input string only at the beginning of each file name. Let’s imagine that we have a program that consists of an .exe file and many libraries. All file names have the same prefix. For example, they follow some awkward notation <CompanyName>.<ProgramName>.<extension>, which, you know, is quite a real case in business software. As you might expect, there’s no way to quickly navigate the exe file in this directory – you literally have to print the entire file name to select it, because most of the files differ only by extension.


Most of the time when you use external libraries to create window for your app (for example, graphics engines like OGRE), the app doesn’t actually need to have WinMain entry point. Moreover, if you’re going to port the app to other platforms, you’ll have to adapt the entry point to be main instead of WinMain. I think having the same main entry point on all platforms could be quite convenient.

On the other hand, only console apps normally have main entry point on Windows. They also auto-create console window, which isn’t what we want in a GUI application. The following steps will help us to solve the problem (assuming that we use Visual Studio):

  • Open project properties
  • Change “Linker -> System -> SubSystem” option to WINDOWS
  • Change “Linker -> Advanced -> Entry Point” option to mainCRTStartup

The System option set to WINDOWS makes application run with no console window. The Entry Point option allows us to specify what entry point the compiler should expect to find in our code (main in this case).

Recently I had a twitter conversation with Jonathan Blow, the creator of Braid and leader of the team behind the upcoming game The Witness. I was wondering why developers decided to use custom engine in their project, considering many good engines already available out there.

Jonathan spoke of the following reasons:

  • You have full control of your code
  • You have no restrictions
  • You can achieve any level of quality you wish (clearly because of 1. and 2.)
  • You owe no money to anyone whose commercial engine you might have been using

These are good points, however they shouldn’t be considered as a 100% guide for you to go and roll your own engine. Do that only if you really need to, if other engines don’t provide you with the necessary tools. Sadly, there were no technical details discussed about what was actually impossible to achieve with existing engines when developing The Witness. Hopefully we’ll hear about it from developers in the future.

Below is the conversation: