This weekend, we fired out a big new update. It solves many of the problems that were reported in the bugtracker and otherwise includes minor improvements and balancing. Below is the list of changes.

Windows users will have to download and reinstall the new version from the download page. Linux users can use the built-in update function.

Engine
! fixed random sky color (#317)
* default control rate is now 3 in network games
! fixed fused dynamite hits clonks
+ artwork for OC installer
* script: FindConstructionSite return 0 when the search fails
! clonk doesn’t continue burning after death (#222)
* update XPM icon from CZ to OC
* changed default IRC channel for clonk client to #openclonk
! fixed possible crash in C4GUI::Container::ClearChildren()
* runtime join off by default because it does not work currently
! opaque submeshes are rendered before non-opaque ones
– removed FIGHT procedure and all related stuff
! win64: Fix crash when a C4String gets allocated at >4GB

Game mechanics
! cannon can’t shoot when turning around (#512)
! rope of grappler is not disconnected too early anymore
* continue to aim with musket after musket has been reloaded (#508)
* press on [Q] now opens the backpack menu even if another menu was open before (#515)
! fixed nullpointer exception on death of clonk that is in no crew
! javelin exits clonk on throw in right height now
! clonk can’t jump out of solid rock
! fixed typo and some “code never reached” warnings from C4DT
– removed the display of (A) and (B) hands in the HUD
+ new texture for the target balloon in the tutorials
! fixed zooming with gamepad (#536)
! fixed error causing variable declaration

Game content & Balancing
+ added missing German string in tutorial 3
* King of the Hill: only king gets a big malus for suicide (#520)
+ King of the Hill: goal now announces new king on the death of old king
+ King of the Hill: open weapon menu on game start now
+ Parkours: give a more informative goal short description (#547)
! Boomshire: various fixes
* Hideout: various map improvements and balancing adjustments, kill logs, adjustments to the magic gems
+ kill logs added to all melees
* CTF – flag: now attached to flag base, grabbed automatically and has a visual trail
* Frozen Fortress: frost bolt now only damages clonks
* sword damage lowered by 1 per hit
* changed mushroom mass to 6
* loam bridge length increased by one third
+ replaced lava texture with one that looks more liquid
+ added shield walking animation
! fix sword texture for Molten Monarch
* changed walking cycle of clonk to look less “chicken-legged”

Even though we don’t have a real magic system in OC, there is already a lot of magic stuff. Mostly bound to scrolls, those magic items are one-time-usable. In the following, I will show up all the magic scrolls we’ve got, along with some useful hints how to use them best.

Fireball Scroll

The fireball is a medium to fast moving projectile, which explodes on enemy clonk contact, when it hits a solid wall, or after a certain time has passed. Characteristic for this spell is his flight curve – its not a straight line, but a sine-like wave, which makes the aiming a bit more challenging. Once it hits a target, it splits into three smaller explosions which are spread around the impact point in a small radius. Thus, the clonk takes high damage and is flinged around a bit. The smaller the distance to the target, the easier is it to hit with it – in close combat you just jump over the enemy and smash the fireball right into his face. On a medium distance, its still not that hard to evade, but combined with another fireball which is aimed a bit higher, you can almost not dodge it. Over a long distance, you need a bit of luck, since the enemy can see it coming from all over the map. Thus, its mostly better to get closer to the enemy for a better hit chance.

The Fireball is available in Overcast and Thunderous Skies (hopefully coming with the next patch).

Teleport Scroll

This spell is a defensive spell, and it can save you life if you use it fast enough. On use, it teleports you to a random place on the map, most likely next to a chest or to a safe place. Thus, especially in Overcast its very good to carry always one with you. Be it because you don’t find useful stuff in a chest and want to get to another quick, or because you fall down and would have no chance to survive. You can activate it out of tumbling, so its even more useful. When you’re not that fast with the backpack, it’s good to carry it always in one hand when moving in the lower area in Overcast, in case you fall down. For the fast-clickers, be sure to remember where exactly you put that scroll into your backpack – you have almost no time to react once you fall down.

This scroll is only available in Overcast.

Wind Scroll

The Wind Spell is an all-rounder: you can use it to defend, to move and to attack. After the delay of a half second, the area in the direction you clicked at will push any movable object in this direction.It is strong enough to push clonks in the air for the duration of the spell, which is 5 seconds. Arrows are mostly too fast to be fully reflected, but the spell is strong enough to change their flight curve, depending on the angle of the incoming arrow. With this strength, you can also make enemies fall down over the edge, or give thrown objects or shot arrows an extra boost. All in all, this spell is always useful – in almost every situation.

The Wind Spell is available in Overcast, Frozen Fortress and Thunderous Skies (hopefully coming with the next patch).

Frostbolt Scroll

Like the Fireball, this spell release a fast moving projectile in the direction you click. But in difference to the fireball, this spell moves a lot faster and has a less strong sine-movement. Therefore, it is also very useful at long distances. The explosion is also different – instead of having a small and compact explosion, the Frostbolt splits in a lot of smaller explosions spread over a big area. This makes him pretty nice against more enemies standing together. But be warned! Because of the big radius, you can also hit your team members which are fighting against your targets very easily. You also need to know that the explosion does not deal any damage to buildings, such as the defense gate from Frozen Fortress. When you want to steal the flag, its always useful to have one of these – you can stop your chasers pretty easy with it.

This Scroll is only available in Frozen Fortress.

Hardening Scroll

Change snow to ice! This seems not very useful in the most cases, but in Frozen Fortress, its a huge advantage, because you can not dig thought ice there. On use, it releases a small moving projectile, which begins to convert snow into ice over time on impact. The radius is rather small, so make sure you use it on the right place – the best for defending is directly under your main gate, if there is snow lying around.

This spell is only available in Frozen Fortress.

Thunder Scroll

On use, after a one second delay, a lightning strike will appear from above, which hits everything near it, damaging it and flinging it in the air. Even if this spell is rather hard to hit, it is very strong. You can use it perfectly to fling enemies off edges, or just in the air, which gives you a time bonus, in which you can continue attacking. Once you casted it, make sure that close enemies stay close – hit them with a sword or shoot at them. It will also hit balloons flying above you, which can, if you do it right, deal a very high amount of damage to the enemy. You also don’t need always to be directly close to you enemy, you can also be under or over him, since the lightning will strike from above. Thus, you can defend this spell by simply hiding under solid material. For stealing kills, this spell is, when used right, very good.

The Thunder Scroll is only available in Thunderous Skies (hopefully coming with the next patch).

These are all Scrolls that are currently in the game, but I guess it won’t stay like this very long. Creating spells is just too much fun for me, so I will probably continue making more spells. I hope these tips and infos help you using them, and discovering new strategies.

There are now automatically created linux builds available on the downloads page. Also, the nightly builds include a linux binary now.

By the way, it’s not big news that OpenClonk runs on Linux, it always ran under Linux. But now, we have automatically created builds available. 🙂

The first milestone of OpenClonk, the open source successor of the Clonk series, has been released!

Download here

Scroll down for some videos and screenshots!

This first release is a beta release. So please help us getting rid of any glitches and bugs by reporting them in the bugtracker.
If you want to give some feedback (please do!) or have great ideas in which direction we should advance the project in the future, please visit our forum.

This milestone focuses on some fast paced melees, races and a few experimental scenarios to choose from. All scenarios are meant to be played multiplayer through the internet (for hosts: ports 11111-11114 are used). It features completely new controls, a new HUD and many weapons and tools to choose from (see a more thorough description here). Also included are four tutorials that guide new players and veteran clonkers through the new controls.

From the main page:
OpenClonk is a free multiplayer action game where you control clonks, small but witty and nimble humanoid beings. The game is mainly about mining, settling and fast-paced melees. OpenClonk is also not just a game but also a versatile 2D game engine that offers countless possibilites to make your own mods.

Here are two OpenClonk gameplay videos.
The first one is a new scenario I made. The goal of this map is to capture the enemy flag and bring it into your own base. It is a snowy map, which contains most of the weapons, useful stuff and three scroll-bound spells.
The second one is a video by Ringwaul, which shows some of the scenarios and objects we have.

Thanks to Spell, who helped me a lot with the making and editing the videos.

Players:

Team Snowbreakers (right): MimmoO & Spell
Team Icecrackers (left): Phoenix & Maikel

Earlier I wrote something about the new features introduced in Clonk by the OpenClonk project. However, what about the actual game content? What about playable scenarios?

Except for the tutorial rounds (which are worth a separate blog post) all scenarios in our first milestone OpenClonk – Back to the Rocks are meant for the multiplayer game – cooperative, in teams or everyone for himself. Here is a full list of the scenarios which will be included in the back to the rocks release:

Shiver Peak
– Classic race to the top of a snowy mountain, using loam bridges and explosives. Can be played alone, in teams or everyone for himself.

The Guardians of Windmills
– A cooperative Shoot’em up where you must defend your sky island against approaching waves of evil rockets.

Kamikaze Cowboys
– Crazy race where you ride on makeshift rockets to reach the goal. Can also be played alone.

Cool Cavern

– Cool race where you have to reach the top of a chasm using grapples, rope ladders and more. Can be played alone, in teams or everyone for himself.

Bristle Ridge
– A fast-paced race along several narrow ridges.

The Cauldron
– A small arena-like melee for 2+ players

Rock Bottom
– An even smaller arena on the bottom of a dry well.

Overcast
– A small arena up high in the clouds which contains various spells.

Mountain Melee
– A large arena map.

King of the Pyramid
– King of the Hill scenario in which all players except the king fight against the king and the other way round.

Boomshire
– A cooperative race for two players.

Hideout
– A capture the flag scenario for two teams.

Clonk has supported parallax objects and backgrounds for a while. Parallax scrolling is a method to create a faux 3d effect with only 2d methods by making objects move slower or faster when the imaginary camera moves across the landscape. This approach generally works well, but the effect this had when the zoom level changed was unfortunate. Instead of simply making parallax objects and backgrounds look the same way as the other objects when zoomed, Clonk-Karl and I figured out how they would behave if they really were before or behind the landscape. The first question we had to answer what different zoom levels represented in that virtual world: Does the distance between camera and landscape change, or do the camera optics, like a zoom lens? We eventually came to the conclusion that we needed both: the zoom lens to ensure that every player sees about the same picture independent of the pixel count of their monitor, and the distance change to represent zoom. While real-world zoom uses a zoom lens, real world unmodified humans do not, so changing the virtual distance should feel more natural.

Figuring out how the objects should display on a diagram was straightforward after that. Put a point for the camera, one line for the landscape and screen (the landscape always is on the same plane as the screen, because the screen is what keeps the sky islands from falling down), and one line for the object, and then draw lines from the edges of the object to the camera. The object should be displayed were those lines cross the screen. But we needed several iterations translating that to the formulas used in the engine because we hadn’t fully internalized what the given values meant. The position of the object is not where the object is in the virtual world, but where it is displayed on the landscape when the camera is at position 0/0, and the zoom factor is 1. And the camera is at position 0/0 when the upper left corner of the screen is there. It’s as if only the lower right quarter of the camera’s view is displayed. The reason is that the parallax math works out rather nice this way: When translating from landscape to screen coordinates, the position of the upper left corner of the screen is simply multiplied by the parallax factor and subtracted from the object’s position. But our first diagrams had the camera positions in the middle of the screen, which was confusing because it introduces the screen size into the formulas, which we knew is not there in the engine code.

We finally arrived at what we believed were the correct formulas and put them into the engine. The result was for the most part satisfactory, especially the sky behaved nicely. But objects moved around on the screen when changing the zoom factor while moving as expected when just moving around. I finally discovered why when constructing this diagram a few days later:

The diagram shows a view from the side on the camera, landscape and one object. Because the formulas for X and Y are independent and identical, only one dimension is shown.

The black distances are given, the red distances are the ones we want to calculate. The green ones are intermediate results. The dashed lines are the lines of sight between camera and object.

At the top left of the diagram is the camera that defines the internal object positions: The position of an object is where this camera would see the object in the landscape. A bit to the right is a camera at position 0/0, but with a different zoom factor (called “Zoom”). Our first version mixed this camera up with the first one. This doesn’t matter for objects at position 0/0, which explains why the sky worked correctly: We only tested in a scenario where the sky doesn’t move with the wind.

Down from the second camera is the third one, the one for which the calculations are to be done. It has a distance of “TargetX” from the origin, and a zoom factor of “Zoom” like the second camera.

At the right there’s the object to be displayed. This one is behind the landscape, but fortunately the formulas work just as well for an object before the landscape. It’s distance on the Z axis from the first camera is “1/Par”, where “Par” is the parallax factor. Consequently, the distance to the landscape is “1/Par-1”, because the first camera has a distance of “1” from the landscape. The position in the virtual world on the X axis is “VX”.

Once I had this diagram, calculating the result is a simple application of the Intercept_theorem.Those interested in the result can take a look at the C4Object::GetDrawPosition() function in the engine.

Until recently the sources of the developer mode documentation have been in German. This was due to traditional reasons since the documentation is based on the Clonk Rage one which was only available in German for some time and which was later translated into English. However this made it quite hard for international folks to contribute since a German version had to be available before it could be translated into other languages (see bug #287). So after some initial work by Maikel I sat down this weekend with the goal in mind to turn around the situation: The main documentation sources should be in English which can then be translated into German (or other languages). The way the translation process works is that a tool called xml2po scans all XML files in docs/sdk/ which make up the documentation and creates so-called po files which contain all strings that need to be translated and their translation into a certain language. The po files are edited by human translators and, once finished, are eventually used to generate translated documentation XML.

The following steps were required (plus/minus some detail work):

1. Finish the English translation: When I started there were like 200 untranslated German strings in the documentation which I needed to translate. gtranslator is a nice tool to do the translation, except for the fact that it does not show where the string to translate originates from (i.e. from which XML file and line) — I had to look that up in the plain po file when I needed the information.
2. Write a script which reads the po file of the English translation, replaces the German content of all XML files with the English version and creates a po file which contains the translation from English into German. This started off as a quite nice and clear python program but then I added handling for an increasing number of special cases until it resulted in code I am certainly not proud of anymore… but well, it did it’s job in the end. Another thing I learned while doing this: It’s a good idea try to avoid mixing python strings and unicode objects; instead always use either one or the other — otherwise you get strange UnicodeDecodeError exceptions and whatnot all over the place… that’s why I normally prefer strongly typed programming languages.
3. Get rid of duplicate entries in the newly created de.po. There were quite a few cases where two different German strings translated to the same in English, especially in tables which list (English) identifiers that should remain untranslated since they refer to the name of a setting in a configuration file. I decided to mark them with a different tag in the XML (<literal_col> instead of <col>) which causes them not to show up in the translation.

Some of the strings to be translated contain XML fragments, for example for inserting placeholders or highlighting portions of the text. Quite a few of this XML was broken in the English translation. I wonder why this did not show up previously when building the documentation.

Now if you want to translate the documentation to German or even another language all you need to do is to edit docs/de.po with your favorite translation tool (which might be a simple text editor, the format of the file is pretty self-explanative). On Linux you can then easily regenerate the .po file (by scanning the XML files for new strings) and create the translated version by running make in docs/ (for Windows that’s a bit more complicated, but you can have a look at README.cygwin.txt which has instructions). This also converts the XML into HTML suitable for display by any web browser (for example Firefox cannot handle the XMLs directly for some reason). If you want to create a translation to a new language from scratch and need a po file to start with (or want it to be integrated into the make process without knowing how to do so) feel free to approach a developer in the forums or the chat. A word of warning though: Translating all the docs is a huge effort since it includes more than 4,000 strings. However it’s also perfectly fine to only translate parts of it as a start. Untranslated strings will remain in English.

Despite this work there is still quite some documentation tasks to be carried out. Newton gave a nice overview in the forums. Just now you don’t have an excuse anymore not to do it, my English speaking friends :). Additionally some of the code examples still contain German string literals or comments. Eventually they should be turned into English as well though I think most of the examples are understable already since they are accompanied by an explanative description. If you edit the documentation XMLs you can directly review your changes with Internet Explorer (not Firefox though).

Around the start of July, Clonk-Karl and I were able to meet in person in the country I call home: Canada. Since I am currently the only developer living on the western half of the planet, it was a fortunate event that we were able to meet at all. But as luck would have it, his destination wasn’t too far off from my hometown.

During the visit, we played a few rounds of OpenClonk (and found a few dozen bugs), a few rounds of Clonk Rage (of which were melees, on average I lost miserably :] ), and even had a trek up one of our famous British Columbian mountains with another friend, Andrew (numbers is always better against wild animals). This was one smashing adventure… before we even got to the mountain I almost stepped on a snake. After hiking up a fairly steep trail, we were spotted by a black bear that had the civility to run away, which we found would be a good idea as well.

Andrew on the left, Clonk-Karl on the right, and my quirky self in the middle

And possibly the most talked about part of the meeting: Doppelkeks. Well, at least by us Canadians. These little cakes taste damn good. And they don’t sell them in Canada.

:'(

Our Nightly Builds have recently gotten quite some overhaul. We now support builds for multiple architectures and with multiple compilers. In addition to 32 bit Windows builds we added 64 bit Windows builds built with both MinGW and MSVC (courtesy of Isilkor). Build status is now not only green (build worked) or red (build failed) but can also be some color in between indicating the number of warnings the build generated. Maybe this can motivate developers to get the build on their platform as green as possible? 🙂

It required some puzzling to set up the cross-compilation environment for 64-bit MinGW: Debian’s gcc-mingw32 package comes with a 64-bit C compiler, but does not include a C++ compiler (Debian bug). So I tried to compile the MinGW compiler myself I was not able to get working though. Instead I did what the reporter of the bug mentioned above suggested: I apt-get source‘d the gcc-mingw32 package, enabled C++ support in debian/rules and rebuilt the package, which worked nicely. Most OpenClonk dependencies offer 64bit binaries, others are available via the GNOME project. Only fmod and d3dx9 were problematic since they did not provide a 64 bit import library. However I was able to create corresponding import libraries from the DLLs with MinGW’s gendef and dlltool tools. I still wonder a bit why import libraries are needed at all if all information is available in the DLL anyway – I was thinking import libraries carry information that is not in the DLL and that’s why they are required for linking.

Loose plans for the future are to provide builds for other platforms such as Linux (maybe even as .rpms and/or .debs) and to provide the Windows development snapshots as an installer.