Explore! Build! Die!



we finished our little trial almost two weeks ago. Time for a little recap. :)

Although we didn’t meet our goals in time, as we underestimated the effort it took to implement core engine features like pathfinding or a fast map generator, it was an important lesson what is involved in programming a “modern” game. We both have development experience of over a decade now but it is still surprising for me how work-intensive “simple” things can be.

Thus said using Python as our main language made it quite easy to develop at a fast pace without losing much time at bug fixing. Optimizing only where it was needed with Cython keeped the source code legible. I hope though that PyPy support will grow in the future, so Python gets faster out of the box.

Besides that we are quite content with our results and plan to expand on it when time permits. Also we will put the source code up online soon(tm).

In our opinion software (and therefore also computer games) should be as open and free as possible because it makes sure you have the opportunity to understand and even improve on what your computer runs.

Day 7: Digging

Today’s the last day (due to another break yesterday) and I’ll start this day by presenting digging, the capability to take blocks out of the world. It’s still sort of buggy but works in principle. (Maybe I have the time to make some video later on, don’t know.)

Anyway, there are a couple of loose ends that we have to knit together to get a decent result in the end. For instance, there is a working implementation of a pathfinding algorithm (A star) that allows our units to move around the world avoiding obstacles.

So, let’s see where we get until tonight.

Some Pictures of the GUI

Here are some screenshots of the user interface. It’s somewhat interactive in the sense that one can open up a menu but does not serve a particular purpose at the moment. The white slots in the unit menu (bottom left corner) are meant to display an icon of a selected unit and the items in its inventory; the red slot is a health bar.

By the way, we are using libRocket with Panda3D to code the interface in a really useful dialect of HTML called RML.

Day 6: Moving Units

It’s been a couple of days and we’ve been developing a lot of algorithms and now, it’s finally time to move on to gameplay. The most interesting thing at the moment is, that units can be moved around (on a straight line for now, proper pathfinding is in the making. We have no real models, so what you can see in the screenshot below is just a dummy earth model we ripped of from another project.

However, the infrastructure that’s been built by now, will enable us to do all the fun things to show off. Stay tuned for the updates, as I really think they will be much more frequent now.

There are only two days left on our schedule but we’ll get to some sort of prototype in the end.

PS: in case you’re wondering, why today is day 6: we both had unrelated things to do on Thursday, so that one does not count. :P

Day 3: The Map Generator

Here we are again and it’s been… demanding. Developing an entire game engine proved to be much more effort than we had expected. However, there’s progress and I’m writing this article to tell you about it.

The map generator is working! Well, more or less. There is at least a working draft at the moment. On Monday it only generated some chunks, no dynamics at all. Now it dynamically generates chunks as needed. It was necessary do optimize a couple of the internal mechanisms to do so.

The chunks (1 chunk=10x10x10 blocks) are stored as simple numpy arrays of 16-bit unsigned integers (giving us 216 possible different chunk types, which should, in principle, be enough). Then there is a geometry generator, which processes one chunk per frame. They are queued as soon as they are required but can’t be loaded all at once.

Both the procedural chunk generator (intuitively called Globus) and the geometry generator had to be ported to cython, since they were way too slow in vanilla python.

Anyway, the engine works very well now. For now, there is only a piece of grass on two layers of dirt and rock. The height map is generated by interpolating random noise. But now, that the generation algorithm works dynamically, it should be quite easy to implement more complex terrain. I’m thinking about mountains and woodlands here.

Ah, and finally: the screenshots!

This is an earlier version without grass:

And here is grass:

Day 1: Hello World!

Hello, World! Today we (a small team consisting of… well, just the two of us) took up the challenge to develop a video game in 7 days. We had planned this for quite a while, to see if we can make a cool game.

Also we want do document our efforts in this blog and write a bit about our journey to world domination.

Now, this is our plan: the game is about building a civilisation in a blocky world combining elements from both real-time strategy and blocky/voxel-based worlds. There are probably quite a few similar games out there but we hope to make our own unique contribution to the genre(s).

The name of the game is qubarchy, a stylized, sorta ancient greek portmanteau meaning the “reign of the cubes”.

There are lots of ideas swirling around at the moment, we’ll tell you about it over the course of the next days. (Our personal deadline is next Monday o.O)

Today we wrote a simple world generator and started to implement the game logic. We zombiefied a game engine we had previously developed, so that gave us a bit of a head start, although getting all the software dependencies to run (again) cost some time too.

We use Python 2 as the programming language. Panda3D provides the graphics and sound engine and we use modern development principles like test driven design (when there is time for it cough) and continuous integration (when the server is up).

So, that’s it for tonight. Stay tuned for the very first screenshots! (Coming tomorrow, we promise ;) )