Principles of Reconstruction

Author: Flosha
Created: 21.09.2019
Updated: 03.12.2022

Status: Work in progress

What we want to do is to realise the original vision of Gothic as PHOENIX without compromises (and to go beyond this vision by developing it further).

And in order to do so, our primariy directive is to take into account everything (regarding the pre-release material of Gothic and its Sequel). Everything that was included, as well as everything that was not included, but announced, planned and promised, everything that couldn’t be realised or was discarded for whatever reason. We are taking into account every iteration of the story, every idea for a quest, every concept art and every sketch.
But by taking all of this into account, we have to decide what to do with it. We have to differentiate different cases in order to clarify how to deal with a specific idea or content on a case by case basis. For this purpose we have “Criteria of Reconstruction” as described below (translated from German to English and slightly updated at 27.03.2024).

Criteria of Reconstruction

We differentiate nine different cases of content to clarify.

Content, which…

Before we clarify these cases, we should made ourselves aware, that the development of Gothic is a continnuum, in which lots of content was constantly transferred unchanged from an older version into a newer one; other content was deleted and new content was added. Our “reconstruction” will therefore necessarily be a mixture of different versions, as is the release version too - and content of our own. We are just going for a different “mix”. Since it is unavoidable that we combine content from at least two versions, we have to make sure, that the contents of these versions harmonise. One of our criteria be therefore Harmony.

This is relevant for instance in regard to assets, when a specific asset does only exist in a very old version. Older assets should only replace assets from newer versions or be combined with them, if they seamlessly integrate (or can be seamlessly integrated with some effort). Since in every version there are assets from older versions, which do not seamlessly integrate, there are disharmonious aspects in the release version too. The criterium should therefore be extended: Assets can be replaced by older assets or combined with them, when they are adapted to the desired style and quality.

1. Case: In an older version X there is some content that is lacking in Version Y

Examples: An NPC which later was not there anymore; an attribute that later was not used anymore. In this case the content from the older version was not replaced by different content, just deleted without substitution. This can happen either without a particular reasoning (that we would know) or (more rarely) with a reasoning (that we actually know). Such content is restored according to the criterium above - if it harmonises with the younger content or can be brought into harmony with it (by different means). If content was deleted without any obvious reason (or if the reason was just time and money), restoring it does not require reasoning either (just time - and since we do it non-commercial - no money). If there was a reason to which we disagree (based on our analysis of the design principles and artstyle we have to follow), we will give reasons for why we decide otherwise.

2. Case: In version Y there is some content that was not yet there in Version X

We will not delete content from a younger version, only because it was not there yet in an older version. But we will also not shy away from deleting something, when it does not add to the game. The decision depends from several factors: Does the content fit to the story? Does it add to the plausibility? Does it fit to the games inherent aesthetics and gameplay principles as analysed by us? Is something lacking without it? This is rarely the case, but there are for example a few Caves at the surface, which will be removed. Caves which did not yet exist in older versions, where the areas in question look more believable without a cave entry and where we think, that these few additional caves at the surface are primarily a plaster for the condition, that the majority of the underworld was deleted (not to mention that most of the time these caves were not even used in the younger version either, are mere copies of existing caves and have no believable reason to be there or any environmental storytelling to support them). In such cases less is more. In other cases some content we remove for some reason, may appear again in the second Act in refined form and in a more believable context.

3. Case: In an older version is some content different than in the final version

When for example an NPC looks different in the final version, but had a consistent look in diverse older versions for a long time in course of the development and was only changed a few months before release, we decide for the older version. When for instance a part of the gameworld was presented to us consistently in images and across several old versions, sometimes consistently over years in form of promotional material, in a way from which the final version differs a lot, then we go for the older version. Because in such a case it is the old presentation that constitutes the myth of the game, that was promised to us and promoted, by which we were inspired during development and which is the reason this project exists. And when we prefer some older content over the newer content in such a case, then we do not necessarily do so because we deem the old content to be “better” per se, but simply because it may fit better to the vision, that is characteristic for “the” Alpha, for the game we expected to play. In some cases such content is not in conflict with each other and can be combined or can coexist, e.g. by not replacing a younger armour design with an older one, but by making it a variation of the same, which we appreciate even more so, due to the fact that such variety was a conscious design element in earlier versions and was later given up (e.g. for technical limitations at the time such as limited memory).

4. Case: In version X some content was different than in Version Y, where it was different again than in Version Z

There can be an eternal dispute about whether some content should look like in version X, Y or Z. But the same principles as above apply. It is the same problem, just in a much more complex way. Think of three different designs of a location. This can only be solved on a case by case basis and with the utmost focus on a harmonious solution. For instance, some aspects of these location designs may be possible to combine and to thereby enrich the design, in other cases it may be better to preserve the original idea of a particular design, which would suffer by trying to combine it with something else (which also may not be possible at all) and let it therefore appear somewhere else and in a different context. Example: The different designs of the Old Camp, where the designs by Ralf can be combined to some degree with the ingame design in a harmonious way, while the older Orpheus design of the Old Camp is so different that it is impossible to combine it with these, without loosing fundamental characteristics of both. But according to our major principle of taking “everything into account”, we do not discard this design; exactly because it is different enough, we let it appear in a different location (outside of the colony) in a different context (in form of an abandoned factory in our second act).

5. Case: Some Content was planned but (consciously) discarded

In cases in which content was discarded, we always ask for the (potential) reasons first. In many cases we do not know the reasons, but we speculate about possible reasons for the decision of the devs at the time and about possible use cases of the content in question. Based on the original design principles which we adhere to, in many cases we find good reasons to decide otherwise. An example in this regard would be the inventory limitation. In other cases we support the decision of the original devs and change nothing about it, e.g. in regard to the “thumbs up” or “thumbs down” system in dialogues that was originally conceived instead of actual dialogue options for the player.

6. Case: Some content was planned but couldn’t be realised for technical reasons or due to a lack of time

For instance diverse Story Events or Missions. In difference to the old Piranha Bytes we do not have time pressure (other than our wish to complete the project in our lifetime). And we also do have much less technical limitations than they had at the time. Therefore, in such cases we try to realise on principle what they couldn’t (unless we can’t either, as may or may not be the case with the Multiplayer Coop). A similar, but rare case it is, when under the pressure of time, some already existing content was placed instead of the actually planned content, so that the actually planned content didn’t have to be created anymore. In such cases we create the lacking content that was actually planned.

7. Case: Content is broken

There are bugs due to mistakes in scripts, grammatical mistakes, wrong uv-mapping and so forth. We aim to correct them.

8. Case: Content is unbelievable or illogical

In some cases there are rough logical discrepancies in dialogues (e.g. “13. Mage”). A different example: A former stable, that is now used as a blacksmith’s shop in the castle, has a chimney, but the smith stands directly in the opposite corner of the room at a forge. And on concept art the forge is shown in a believable way directly integrated into the chimney. Then of course we model this forge accordingly and change the position of the smith.

9. Case: Content is “lacking” and added by ourselves

This may be the case with or without a concrete model or guidance by documentation and is primarily relevant in regard to the Story or for example regarding new parts of the game world. It is obvious that we can not reconstruct the old story (and even less so the Story of the Sequel in form of our second Act) without filling its gaps from our own writing, since this content was never created by the former devs themselves. We orient ourselves at all the existing material and information, but complement the rest at our own discretion.

/vision/reconstruction.md