Construder is so cool we wanted everyone to know about it, so we made a quick interview with Robin, who is not only a great programmer but also a very nice guy. Check it out!
Can you share a bit about who you are and what's your background?
I'm a 27 year old Informatics student from Karlsruhe, Germany. I work part time as a (Perl) programmer and programming is my main hobby aside from other things like photography and music.
I started programming around 1999 and wrote lots of network related applications since then. Many also found their way to CPAN as Perl modules, such as AnyEvent::IRC, AnyEvent::XMPP and AnyEvent::HTTPD.
Tell us a bit about Construder. What's it about?
Construder is a 3D game that takes place in a completely modifiable world that is built from small cubes. The core of the game is construction of buildings and items from those cubes. The goal is to push up your score points as far as possible.
In order to score you need to build blocks, construct items and finish assignments. For each score milestone you will get a trophy.
The game currently is focused on single player experience, but the architecture has been made to support multiplayer gameplay. As a matter of fact, it's perfectly possible for multiple players to play in the same world at once. (One of the unfinished things is, that you can't see the other players at the moment, only their actions can be observed :-)
How about the technology involved?
I use the CPAN modules SDL and OpenGL for all the graphics stuff in the client (there is some C OpenGL code, to render the volumes, but most of the engine is written in Perl using the OpenGL module). The primary purpose of SDL is to give me keyboard and mouse input, loading images and providing an OpenGL context.
But there are also other modules at work here:
- Object::Event my own most favorite module for event based programming
- AnyEvent for networking and timer releated stuff
- EV as a reliable event loop
- Compress::LZF for storing and transmitting the map data
- JSON as a generic format for storing data (player files, resource files)
I started with a basic engine prototype on the 19th April 2011. So it took me 3 months of steady development and research to get the game to the current state.
Much research was necessary, as I originally only had basic experience with OpenGL and 3D engines in general. Especially collision detection and finding graphics were noteworthy researches.
On top of that I also looked through many books and articles of game design, which helped me a lot with designing the actual game.
You mentioned MineCraft as an inspiration for Construder. How are they similar? And how are they different?
Minecraft inspired the aspect of a completely modifiable world that is built from small cubes. In this regard Construder is very similar to Minecraft or it's predecessor Infiniminer.
But Minecraft is, or at least it will/wants to be, a survival game, where you have to fend off monsters that come at night or from the darkness.
With Construder I wanted to put focus on the constructive aspect and build a game around that. Construder of course still has survival aspects, as you have to take care not to starve. But thats more a question of resource management and not survival.
Apart from that the generation and design of the world differs completely from Minecraft's medieval theme. Construder has a much is more futuristic world with very artificial structures in it.
How did you get started in game development? Is this your first game?
Construder is the first game I designed and implemented completely by myself.
But around 2005 me and a friend (Marc Lehmann) started to play Crossfire (a 2D (M)MORPG) together. Not long and we started to improve Crossfire and eventually we forked it off into a new project, called "Deliantra". Our main focus was to fix the stability and balancing problems that accumulated in Crossfire over the decades (it's a really old game).
What are you proudest of about Construder?
I'm most proud that it is a playable game, which is finished to a certain degree. Next I'm proud that I was able to compile a texture set that does not completely look like the so called "programmer art".
However, I'm not that proud of the code in Construder. When developing a game on your own with limited time you need to make sacrifices and compromises. Those usually don't lead to the most elegant or best code. As a result of that there are many things that can be improved in Construder.
Why did you choose Perl?
As I write 80-90% of my software projects in Perl the choice was quite natural. Minecraft also showed that a 3D engine does not need to be written in C/C++. So I also thought it was time for a 3D game in Perl.
What do you think are the biggest advantages for people considering Perl for game development?
The biggest advantages of Perl are the data structures like hashes, arrays and string that are tied closely into the core of the language.
This allows for rapid development of new ideas and algorithms, which is essential for any game project. You just need to try out many approaches to find the right one for your project.
The scripting character of Perl really starts to pay off once you get to implement the game logic and balance and user interface. Everything stays in a flexible shape and you can change it at will without having to rearrange the whole code archtitecture.
On top of that modules like Coro and AnyEvent which come with utilities like Coro::Debug or AnyEvent::Debug allow runtime debugging in the running game. You can peek into all your data structures and execute code at will at runtime, and this really pays off for bugs that are hard to reproduce.
How about disadvantages? Where does Perl (and underlying CPAN modules) need to improve for gamedev?
It would be great if Perl had a JIT, then probably even less parts of Construder would have to be in C/XS. But this doesn't mean that Perl is slow. It's definitively fast enough for 80-90% of the engine, but handling volume data in Perl is neither fun nor fast.
The CPAN modules, like SDL or OpenGL are quite useful and don't really need much improvement with regard to Construder. Maybe there could be a more useful 3D engine module for Perl, which makes it easier and faster to handle 3D data.
But the Construder engine is quite customized anyways, so a module, except maybe a special voxel world module, wouldn't have helped much anyway.
What's next?
Next issues that need to be resolved is the distribution. It would be great if distribution maintainers could package it for Debian and/or Ubuntu for example. It would also be great if volunteers could make a binary for Windows.
I probably wont have so much time to devote to Construder anymore, as I need to concentrate on finishing my diploma. However, as author I will try to maintain the project, and apply patches and bug fixes.
