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.

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 to tools to this in a satisfying way.