Revival Release Design Document
The goal of this design document is to lay down the development goals for a possible new release addressing various pressing matters that I think have been overlooked for years. --Clonkonaut (talk) 23:05, 2 August 2019 (UTC)
Introduction
Currently, OpenClonk development is in a standstill. However, there is no shortage of possible development tasks. Personally, I feel that there are parts of the game that serve as a constant bother to all players but have not been properly addressed throughout the development history. These amount to some quirky behaviour of your clonk, weird looking situations and outright annoying gameplay. The little problems are well known to all of us and we have learned our ways around them. But, everyone who is not willing to go that extra mile will be put off for good. My goal with this document is to propose possible solutions for certain problems or to spark interest in exploring possible solutions to problems that I have no deeper insight into. The latter meaning that this document will not provide conclusive answers on everything.
What seems to be the problem?
Over the years, OC has got more features and expanded on its gameplay. This is not bad. Right from the start, we have always sought to alleviate the gritty bits of playing the game. But we always left a few things to be desired by saying that we will look into these at a later stage. As the game grew more complicated, these problems became more and more convoluted and harder to solve. Where changing a basic system now means having to work on many more little things and a seemingly simple task becomes a behemoth of annoying bits. This leads to something I have by now seen in other open source games. A fatigue to work on the pressing matters in favour of more fun, new and flashy features. Each new release brings a potpourri of new things to the table while the core problems stay the same and will annoy the players away all the same. Even worse, the game looks a bit different each release in a feeble attempt to somehow work around the problems through a path of low resistance to get to developing the fun features again. To my understanding this leades only to frustration. You want to enjoy a new set of cool things but still struggle with button-mashing your way through the landscape. The only way to lift this curse, as I see it, is to properly address the core problems and really grind into the hard work of trying to fix them. To make your time of playing the game worthwhile.
Exactly that is what I am trying to achieve with laying out this document. Pointing out the problems I see and put them up for discussion. Suggesting possibilities to smooth them out in a way that makes the overall game simply feel 'good', so you are eager to explore it more. All this will probably be a good chunk of work and not necessarily the fun kind of making new toys. The outcome will most likely - and I understand the irony of it - change the appearance of the game again - hopefully for the better and into something that will not need changing as much.
Structure
The document is structured in three parts, each describing a different overarching problem with the current game: the clonk's movement (core gameplay), the amount of and the way players are provided with information (UX) and obstacles for third party development (modability). Each part is split up into several sections that describe one problem in detail. Some of these are interconnected between the three parts because the problem does not always suffer from one particular flaw but more than one. Therefore the sections link to one another. Be sure to keep that in mind when trying to tackle a single problem. Each section describing a problem features the following subsections: The Problem, Open Points, Solutions, Cross Reference. The subsections respectively contain the following:
- The Problem: an introduction to a specific problem in the game. Describing it in as much detail as I can to make it clear what unwanted behaviour we find in the game and how it makes for a bad playing experience.
- Open Points: certain key aspects of the problem that I think are worthy of a discussion or more diverse input than just my own. Alternatively, in cases where I do not have a ready suggestion for a solution at hand, these are just my thoughts on how to approach the problem and connected thinking process to come up with a solution. Also vague ideas with no fully-fledged concept of how to achieve the desired effect.
- Solutions: more tangible suggestions of solutions to the problem. Plural, because a single problem must not always be addressed in a single way but multiple ways are imaginable. Since all of the ideas in this documents are so far coming from me and me alone, all these solutions are absolutely open for debate. I do not claim to have all the answers.
- Cross Reference: links to other sections (problems) that are somehow connected to this one and why.
Core gameplay: Movement
The clonk's movement has been described as unprecise, sluggish and 'not feeling good'. This stands in conflict with what historically had always been the clonk's description in the game: Witty and nimble if skillfully controlled. Problems with moving the clonk are problems with the very core of the game. If simply moving around becomes cumbersome, the rest of the game suffers greatly. Clonk has never been a game that could be described as having the best controls despite of what some community members always claimed. Still, the predecessors managed to achieve a certain sleek gameplay that left players with situations in which possible movement paths could be preplanned. We should try to give the movement in OpenClonk a similar smooth feel.
Shape Maps: Traversing the landscape
The Problem
In a typical game you will move left and right a lot. Doing so, you will most likely run across the surfaces the level designer prepared. Along the way, you will probably hit a few speed bumps:
The surface is supposed to be a flat stretch of rock. But as you can see, the clonk needs to scale through it frequently. This is of course the shape map of rock not producing a relatively smooth surface. The movement across this is therefore frequently interrupted. Interrupting walking in OpenClonk will also mess with things you are currently doing (more so than in previous Clonk games): you cannot place a construction site, while aiming with a weapon you are stopped in your path, other actions are disrupted. The shape maps, when created, were mostly eyeballed with having the texture in mind. We never got around to critically assessing their impact on gameplay. Some of the shapes produced this way are a nuisance in the game. Sucking up objects tumbling into small cracks and of course, forcing frequent scaling. Whether or not a shape map produces an acceptable surface is heavily dependent on the y-coordinate of the material line:
Open Points
Some materials could just be meant to be rough and not easily traversable. Some materials maybe just look bad if we don't pay heed to the texture. When thinking about changing material shapes, we can separate all the materials into ones that we think are surface-level materials and are suitable for designing a scenario floor to walk on as opposed to underground materials that usually are not used for that. Some materials could therefore stay rough.
Still, some shapes that are being produced by shape maps might look ridiculous enough to change them.
Solutions
Edit the shape maps of surface-materials to provide you with a smooth surface that does not need scaling. Scaling should only be necessary when the surface heigth changes a pixel or two. The gritty part of this job will be to go through all the scenarios in OC to check whether certain scenarios relied on certain shapes of a material, to prevent players from accessing parts of the landscape. Or if certain passages become impassable. Or, or, or. Rather than to rework the shape map to fit a scenario or to not change a shape at all, the scenario should be matched to the new shape.
Cross Reference
Corner Climbing: Bad animations, bad movement: see there.
Corner Climbing: Bad animations, bad movement
The Problem
Scaling around the various corners in the landscape often leads to weird behaviour and animations of the clonk. The various contact points of the vertices lead to a constant switching of Walking, Jumping, Scaling and/or Hangling. To the eyes of a player, this looks like an unfinished or buggy behaviour. Seldom do you encounter fast and uncontrolled animation switching in other games. The fast switches will also sometimes prevent you from properly controlling your clonk. Instead of going into the direction you really want to go, you need to button mash all the directions first in order to find what way your clonk can still move. Afterwards, you'll probably have to find a different way up the corner. This battling with the landscape slowly becomes its own, unintended metagame and is often no fun. You, as a player, really just want to climb up that wall. But to do so, you must know remember a certain combination of button presses, specific to that individual part of the landscape.
Open Points
This problem needs more creative thinking as there are no obvious solutions at hand. Other games can often more directly communicate to the player which parts are climbable and which are not due to having a static landscape. With our very dynamic approach, a bit of trial and error will always be part of the game. Yet, we can strive to weed out heavy frustration when doing so. A possible way to make climbing smoother, is giving a climbing (scaling) clonk more leeway when it comes to what kind of wall shapes a clonk can climb up. The engine would need to be more forgiving and helping. Don't drop clonks down too fast. Don't switch to a different movement style (walking, hangling) too fast. The fast cycling through different animations (or rule sets for movement which then trigger a change in animation) are most likely caused by conflicted rules in the movement code of these rule set. A walking clonk will behave in a certain way and switch to scaling when certain triggers fire (contact on vertices configured in a specific way). A scaling clonk will suddenly adhere to different rules, will try to stick to the landscape in a different way and then judge whether it should start walking or falling and sometimes immediately do so. When a certain position, with certain contact points will lead to a cycle of animations, the clonk is probably better off with just picking one that will most likely fix the problem the player is having. This might require the engine to evaluate the clonk's movement in a different way, maybe there is more information needed than just contact on vertices, maybe the engine needs to think ahead what will happen next if it changes the movement rule set. The engine might have to keep the clonk fixed in certain positions even if a specific rule set (walking/scaling/hangling) would say that, for example, the clonk should rather fall down right now. The goal here is to provide a more fluent movement for the player. If executed this way, it will also mean that a clonk will most likely be able to climb up walls that before where impassable. All existing scenarios would have to be checked.
And just to be clear: the intention here is to fix more than just the animation glitching. In the end, the player will have more freedom when it comes to moving around the landscape as the clonk can climb up walls that it could not before.
Solutions
Nothing so far.
Cross Reference
Shape Maps: Traversing the landscape: Shape Maps maybe contribute to a lot of impassable walls in the game.
Landscape Manipulation
Manipulating the landscape to your advantage is a major point in a game of Clonk. Therefore, you should be handed the tools to do this in a satisfying way. I feel that right now, we do not have these tools for the players. While destroying the landscape is easy, restructuring it is tedious to a point that you often don't bother. This again makes you worry to not destroy the landscape at all to not have to deal with it afterwards.
How can I get my material back (Bucket and Loam)?
The Problem
Once you dug and blasted your way through the landscape, you are left with holes. Maybe you wanted to construct your base in that area and are now struggling to find a smooth surface to build on. You built a long tunnel, going down into the earth. Everyone can probably relate when I say that you will have a memorised set of movement commands and jumping spots when it comes to working your way back up. You know where to stand for a certain jump and it only works from that exact spot. If the next person were to foolishly dig away that vital edge of earth, the path is destroyed and you don't really know how to get it back.
Open Points
We once had this problem before. The lack of reshaping tools lead to the creation of the bucket. It was meant as a quick way to fill up some earth. But you always have to struggle with the weird fluid dynamic of flowing material pixels in Clonk (same problem with concrete). Without a proper basin to work in, the bucket will not bring you a good result as all the earth will flow down to whereever you do not want to have it. Creating a basin is met with the same problem: how do I get simple material shapes to work with? Creative thinking is needed to come up with new tools (or maybe we do not need new one but improve upon the old ones). Wall kits are a step in the right direction. Those at least give the player a clear indication of what will happen and where. We need more of those instead of 'throw the thing and hope it will do what you want' items. Loam is equally surprising and unsatisfying to use. When using it, you never really know what will happen and when it does, it will happen very quickly. The way it controls is as follows: you start pressing the mouse button, hoping you are pointing in the right direction but as soon as the first few pixels appear, you realise you were wrong and will do some hasty corrections. The result is a wiggly line.
Solutions
Loam: Loam will have to be less surprising and quick in its use. While the first idea of having full artistic freedom in 'painting' earth with it was appealing, I do not think it is worth the downsides. The result is almost everytime the said wiggly line unless you were very specific in your direction. Maybe loam should be reverted to a more simpler state. Loam could first of all preview the result. Simply being able to see what you will do is a tremendous help after all. Because of this, loam would have to go back to creating stright lines or a predefined set of shapes. This does mean less freedom for the player. But maybe freedom in this was never necessary as it leads to not being able what you really want. The shape preview could also try and attach itself to the landscape in a helpful way. Most of the times you want to extent from existing material anyway. Alternatively, maybe you select a start and end point for the earth line. The starting point could be sticky (search for possible anchor points in surrounding material) and then you get a draw straight line from that point to an end.
Bucket The bucket currently is so unpredictable and useless that it mostly is not bothered with at all. Similar to loam, the bucket should provide you with a clear preview of what will happen. Similar to loam, the bucket's functionality should probably be extended (also when it comes to the range it works in). Maybe the bucket attaches blobs of material onto existing material (with a preview) - in theory this functionality is already in the bucket but very unpredictable. Maybe the bucket works like a filler tool and will create a gradually growing blob of material.
Cross Reference
-
Digging: The weird tunnel
The Problem
Digging offers a similar freedom than using loam. It faces similar problems: while digging a straight, long tunnel is achievable, fine-tuned manipulation of the landscape is tedious if not impossible. It involves mastering the weird upwards digging movement to smooth out the various unwanted corners you built up over time in your tunnel.
The shovel acts fast and merciless. You might appreciate this when going big but it's often annoying when trying get that one spot you want to build on or carry your lorry across right.
Open Points
Giving the player more freedom in digging when compared to previous Clonk games certainly made digging more fun. We could simply decide that this fun outweighs the annoyances. I believe that, while at first it is fun to just dig around like you want, once this effect wears off, you are more likely to get disgruntled that you just cannot really achieve what you want to.
Secondly, I would fully abstain from changing the shovel into a tool that needs some kind of 'status switching' (like a fast, unprecise state and a precision state). The shovel is the most frequently used tool in the game and should always work smoothly and fast. Having to spend extra thought into 'oh wait, what was my dig setting again?' will be equally annoying over time. If we cannot come up with a way of solving both tasks (being able to excavate big areas relatively fast and being able to fine-tune little edges), we should probably dismiss the problem altogether.
Solutions
One possibility is to have the shovel no longer take out a circle around the clonk but rather chunks of materials in the direction of the cursor. This would result in a similar behaviour than other 2D destructible landscape games, e.g. Terraria. The chunks could either determined freely or refer to a fixed landscape grid. Either way, the shovel can easily display a preview overlay on the material constantly or as soon as the mouse button is pressed. This would make the shovel similar to the pickaxe. It should still be faster since digging through earth is an important task in the game.
Another way is to restrict the shovel again to certain angles around the clonk. When holding the mouse button, the direction would snap to the nearest allowed angle of digging. Building straight tunnel would be easy this way.
Cross Reference
-
Player Communication (UX)
OC features a lot of different ways how communication with the player takes place (getting inputs, giving information back). Sometimes, the same basic function (e.g. menus) will have two or more different solutions. Unifying these and, more importantly, reevaluating whether communication is done in a sensible and good way, can help providing a more solid gaming experience.
My clonk is talking to me (status messages)
The Problem
Objects (often items) in the game sometimes want to communicate a certain message about a certain clonk to the player. The implementation always varies. There also is no clear decision when a certain item will tell you something and when not. Some things simply stay silent and you have to figure them out for yourself.
Open Points
Clonk -> Player communication should probably be unified. Either the way a clonk shows a message becomes more standardised or we abandon the 'show message above clonk' way at all and create a dedicated HUD interface for displaying messages. This can easily show more messages than what is displayed right now and experienced players could be offered a way to turn off tutorial or basic messages.
Solutions
-
Cross Reference
-
The Problem
This problem is most easily described in pictures:
The UI throughout the game simply looks different everywhere. Nothing seems to be connected and made to work together. Menus frequently work differently and you have to figure this out time and time again.
Open Points
This task should better not bog down into endless discussion of personal taste. We should rather focus on function than form. The menus should work, look alike and therefore work similar. Especially reworking something like the F menu requires touching the engine. This menu clearly is a relic and looks like one. It is also weird that there is a difference between the Esc menu (just exiting the game) and the F menu which looks like an options menu.
Solutions
Go through the many menus that we have and rework them. Do not exclude engine menus like the scenario selection from this process. The developer might see a difference between the ingame scripted menu and the engine ones, a player does not.
Cross Reference
-
Settings all over the place
-
Menus & Keys
The Problem
Script GUIs cannot be controlled via keyboard controls just with the mouse. I don't think this needs further explanation. This part of the game is actually unfinished.
Without keyboard controls, it is impossible to play the game with a gamepad, it is impossible to play splitscreen. I don't think this is really acceptable.
Open Points
One of the reasons this was never really finished is that script GUIs are very variable and open in scripting. This makes it hard to come up with a good way of controlling them without a mouse. I would say if there is no better solution to be found, just make the script GUIs less flexible and more restrictive. At least, then we would have controls.
Solutions
Implement a way of controlling the menus with directions keys and a button to confirm a selection.
Cross Reference
-
Clonk Controls
-