Just two days ago Epic announced that you can use their powerful Unreal Engine 4 with no upfront costs. And a 5% revenue fee is only collected when your gross is over $3.000,- per quarter. This used to be $100.000 per developer seat just a couple of years ago. One day later, Unity announced that they basically give away their engine for free with their personal edition. Only when your revenue/funding exceeds $100.
English
In the last months I have been working on a video game. In the early development days I made some choices regarding the technologies to use. Here I want to talk specifically about my choice to go with low-level languages and low-level components, rather than a high-level game-engine such as Unity. A polished design The market for video games is huge, but pretty saturated. So, how does one stand out among the crowd?
I have been experimenting with the D programming language over the past couple of weeks. D is a native language and was conceived by Walter Bright. Although the language itself has been in development for many years already, it seems that it has been getting more traction over the last couple of years. The name D hints already at it’s reason d’etre: to be a better C++. Because of endless backwards compatibility and decades of evolution the C++ language has grown.
We as programmers like to think otherwise, but we are by no means perfect. We do make mistakes all the time. One of the most important traits of a good programmer is to recognize this and, more importantly, to act upon it. If one takes on a development endeavor there is one obvious path that also happens to be the most error-prone. It is this path: you have an idea, you code, you startup your app, click through it once and you’re finished.
At the vari-arch workshop at the European Conference on Software Architecture (ECSA 2010), I presented my work on Active Components. Active Components are the building blocks in a software product line infrastructure that I have designed. In it’s design I have chosen flexibility over rigidity (i.e. a strong compositional way of specifying your software product, rather than driven by a central architecture). This gives better means to widen the scope of a software product line, something that was specifically the case at the ISV where I did my research.
