Please note that I don't update this web site anymore. You can visit my new personal blog at


Tuesday, January 11, 2005

In response to my lack of progress with Trichromix, I did some serious thinking as to why things aren't going as I want them to. One of the conclusions I reached is that I don't like my current toolset very much.

Auxilliary languages

At this point, I write all my code in C++. That is, for example, why I ended up using Spirit for parsing my GUI Definition Language. However, I think it can be very beneficial to use different languages for some tasks. It might be much easier (and quicker) to write a data file parser in a functional language than it is to use C++ and Spirit for that task. Stefan Holdermans, a good friend of mine, has already generously offered to give me a crash course in functional programming in Haskell in general and writing my own parsers in Haskell in particular. There may be other programming problems best solved by yet another language.

Of course, this brings up the problem of interoperability between these languages and C++. I see this as a start-up problem, though. Once I figure out how to mix, for example, Haskell with C++, I don't have to think about that stuff the next time I need Haskell. Languages that are designed or often used for scripting, like Lua, Python, Tcl, have good interoperability support to start with.

Then there is the possibility to design my own language. In that case I would end up with a system much like the Torque engine. The Torque engine itself is completely programmed in C++, but almost all game development is done using Torque's own scripting language. This might work for my Flatland engine as well. Of course, there are some serious downsides to developing my own language. I found a nice blog entry on rolling your own language by Alastair Patrick. In the long run, I like the idea of a custom language very much, but for now I'll have to do without.

Main language

No matter how much task-specific language I intend to use, I'll always have a main language, like C++ is to me now. That language will be what binds the entire game together, the language from which the executable is built.

When I started working on Trichromix, I saw C++ as the only realistic candidate for my main language. Although I like C# better, I think the requirement of the .NET Framework will lose me way too much potential customers. Java is slightly better in this respect, but it still requires a virtual machine. The fact that I don't particularly like the Java language, might have also played a part in my considerations.

Right now, I think the D language is a serious alternative to C++. It compiles to native code, it's cross-platform compatible and it provides much of the same features that make C# and Java easier to use than C++, even though it lacks reflection. It's already possible to use SDL with D, so porting my Flatland engine shouldn't be too much trouble.

The main advantage that C++ has over D, is its support base. There are lots of useful libraries out there for C++ that I can take immediate advantage of. D doesn't work with C++ code, although it provides an interface for talking to libraries written in C. This means that you don't have to wrap these libraries, you can call them directly. Since a lot of libraries are written in C and not C++, C++'s edge over D might not be as sharp as it looks. I'll have to investigate.

Custom tools

Since I'm just starting out with game development, I haven't written any custom tools yet. I already found it worthwile to create my own GUI Definition Language, but it would be even better to have a custom GUI editor. There are more tools like this that I like to develop. Obviously, this takes time, but I think it would be wise to plan the development of these tools as seriously as I plan the development of my games.

Development environment

My current IDE of choice is Visual Studio.NET 2003. It works well with C++ and is simply great for writing C# programs and ASP.NET web sites. However, adding support for a new language is hardly trivial. It's certainly possible, since Visual Studio is highly extendible, but it takes a lot of effort. Since I expect to be using more languages in the future, some of which will be custom languages for data definitions and configuration files, this is a major downside. Visual Studio is also rather expensive and my license runs out in a couple of months.

I've been trying out different text editors, but so far none of them is to my liking. Almost all of them lack good support for managing projects. I guess I'm not the only one who has considered writing his own text editor. I'd rather not, however, I have better things to do.

I installed Zeus yesterday and it looks promising, since it's more like an IDE than just a text editor. It even has out-of-the-box support for D, including class browsing! Unfortunately, it doesn't allow me to use variable-width fonts for my code, which I have grown to love. Most text editors don't, however, and I guess I can learn to live without it. I'm going to give Zeus a serious try for the next couple of days. Hopefully, I can do all my coding in it, including everything I use Visual Studio for right now, in which case I'll more than happily spend US $35 on it. Or more, since the web site states that this is a limited-time only special discount price, although it doesn't state the usual price nor when this offer will end.

Back to blog index


Dustin Sacks says:

I find your blog to be an interesting read. However, from my outside perspective it seems as if you are spending too much time building up a superb infrastructure, with your engine, your GUI description language, etc. If you want to make games then you'll probably accomplish more of that if you forget about writing portible architectures and just get down and dirty writing a one-off game. Anyway, just my 2 cents. Good luck.

Thursday, January 13, 2005 2:15 PM

Joost Ronkes Agerbeek says:

You are absolutely right of course. It's not the first time I ran into this problem. I tried to be very pragmatic about Trichromix from the start, but old habits die hard. Thanks for the reminder. I still believe it would be wise to plan the development of my toolset, though. That might also help prevent focusing on it when I shouldn't. Anyway, I'm glad you are enjoying my blog. Just subscribed to yours. ;-)

Thursday, January 13, 2005 3:30 PM

Boris Yankov says:

I was just going to write you are concentrating too much on the underlaying part but I saw this is alreay suggested :) There are three aspects of making a profit with a game. 1. The engine + the programming. 2. The game design. 3. The marketing. Believe me they all are equally important. If you are concentrating too much on p.1 you are going to fail. I have seen very well made games that are simply not enjoyable!!! And after you are finished with the game the actually selling has just begun!!! And it is hard. Just do the minimum you can to finish the game. You will have time to improve it for v2 or your next game. One more good advice. Join the Association of Shareware Professionals. I did less than a couple of months ago and (warning: a cliche ahead) this was my best investment of $100 ever made.

Thursday, January 13, 2005 7:45 PM

Boris Yankov says:

Oops. I see you are a member of ASP already :) Nevermind. The advice remains to all who are reading this :)

Thursday, January 13, 2005 7:46 PM

Tell me what you think

Since I'm not updating this site anymore, I disabled comments. You can visit me at my new site: