After we already have a progress report on what the settlement development has reached so far, I wanted to give you all a quick overview about what is planned. Because a picture says more than 1000 words, I tried to make a little something showing the production-lines-to-be.
This is heavy work in progress though!
Click! ->
After a relative silence since the 2.1 release, progress on developing settlement content has increased on the recent openclonk meeting. The first multiplayer settlement rounds have been played successfully. The landscape of Gold Rush, known in CR as the classical Gold Mine, looks like this after completing the goal:
A network round of Gold Rush
The gold, located at the bottom, has been mined with dynamite and transported with a lorry. It can be sold at the flag, or processed at the foundry into gold bars which are more valuable. The foundry can also produce metal, which is very useful in Iron Peak, a scenario with lots of iron ore. The foundry at work in Iron Peak:
The foundry at work in Iron Peak
On this screenshot we also see the tool workshop, where items can be produced, and the sawmill:
The biggest changes are however not content related, but on content and production menus. Although the recently implemented drag&drop menus are not finished and may not even be the final implementation, they are a big improvement over the old menus. They are the reason that settlement may go into the direction of fun rather than frustration. The content menu is shown in the next screenshot:
With the content menu (open with E) the player can exchange contents between all containers behind the clonk, either by clicking the item or by dragging the item. Since the development snapshots are currently broken, this can only be tested if one is able to use our repository. But do feel free to share your opinion here or in the forum and stay tuned for more!
It has been more than six months since the last stable of OpenClonk has been released. However, loads of new features, changes and fixes have been implemented ever since.
Now we want to finally release the next stable. Currently we are blasting our way through the last known crashes, bugs and desyncs and will start the playtesting soon.
The new release will contain very little new game content but balancing changes, loads of fixes, new graphics, tons of refactoring (which is only interesting for developers though ;-)) and many new features such as the high resolution shader, antialising, UTF8-support, a new HUD design that scales with the display resolution or more natural blast shapes.
I wonder whether it was by intention but it made my day. 🙂 Commit b6bec718c930:
C4Group::FindNextEntry only writes in the result buffer finding a file (#618)
Before “Initialize some uninitialized variables”, SCopy would do nothing because the StdStrBug still contained the parameter, but with that patch, it wrote the empty string into the result buffer.
Till now, explosions have always been perfectly round circles. I changed this to somewhat more rough and natural looking shapes, still circular but with a lot of random in it. The bigger the explosions, the spikier the shape. Shapes that have been dug free are more smooth, more circle-shaped.
You might have noticed that OpenClonk’s model rendering code is able to provide nicely detailed graphics even when you zoom in. The landscape however looks like this when zoomed:
Click me for full resolution!
This is because the landscape of Clonk is stored like a raster graphic – if one zooms in, it becomes blurry or pixelated.
If you look around in our forum from time to time, you might have noticed that PeterW has been playing around with a pixel shader to implement a scaling algorithm, namely the hq3x. The result of his work looks like this:
Click me for full resolution!
Notice that his shader not only scales the display of the landscape very nicely but also implements a simple lightning model similar to the lightning in Clonk Rage.
PeterW implemented the feature in the engine already. So to test this, just grab a recent development snapshot and enable the option “High resolution landscape” in the options. Should you encounter rendering problems, post it in the forum (with a screenshot)
By the way, the shader code can be found in Graphics.ocg/LandscapeShader.c, so each scenario can theoretically define it’s own shaders for awesome effects.
Since this scenrio did not make it into the current update, I decided to modify the current version of this scenario so its playable with the current release version.
Claim control over this sky island, which floats up high in the sky. Numerous weapons, spells and environment objects will help you to fight your enemies. Kill an enemy as the king, or kill the current king to score a point. You get healed by 30% of the damage you do, while you are the king.
A King-of-the-Hill-round in great heights. Who scores 10 points first, wins.
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.
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.