Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

KickStarter Monomyth - A first person action RPG/dungeon crawler - now in Beta

Nyast

Cipher
Joined
Jan 12, 2014
Messages
609
From my (admitedly limited) time working with people who were self-employed, I remember they were able to file some personal expense as business expanses, so they'd avoid to pay taxes on it (well, they wouldn't pay income taxes on the money they would have used for those expenses); I remember examples like paying car maintenance, personal office space renovation, meals, suits for those working in finance, computer equipment... But then of course it was in France, so different fiscal regime and I guess your accountant would have told you about this

I presume that he/his accountant is already doing that. Here in Belgium I can deduct half of my energy (gaz/electricity/water) (half: because I'm working from home. If I had a separate office it'd be 100%), internet, all hardware/pc costs (even video games or paper magazines), office tools, software expenses, social cotisations and most importantly sub-contracting work. That works both for deducting tax income and VAT too (you get back 21% of those). All in all it's not too bad, but yeah, if you're working on software, you're basically creating value from little so you're heavily hit by the VAT.
 

KeighnMcDeath

RPG Codex Boomer
Joined
Nov 23, 2016
Messages
12,859
I dunno... this dude is creeping me out.
fVVp7aa.jpg
 

Gargaune

Magister
Joined
Mar 12, 2020
Messages
3,136
You still can. The dev has a slacker backer page all set up. Let's see that money put where your mouth is! If I can do it so can you!
Huh, I missed that, thought it ended already.

RatTower - dude, I don't wanna pester, but could you give us some guidance on that GOG question? I'm sorting out my PayPal at this time and I'd be happy to pitch in, but I'd like to avoid the situation where I back early, get a Steam key on release and then a month later, bam, Monomyth hits GOG. I'd just like to know whether backers would get a choice of store assuming you'll be releasing on GOG (and it does seem like Monomyth would be right up their alley).

P.S. How does it work through that Kickstarter Encore thing? On release, do we get our key at the e-mail associated with the PayPal account? Or is there some other registration involved?

P.P.S. Get an SSL certificate for that webpage, man.
 

Infinitron

I post news
Staff Member
Joined
Jan 28, 2011
Messages
97,228
Codex Year of the Donut Serpent in the Staglands Dead State Divinity: Original Sin Project: Eternity Torment: Tides of Numenera Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 A Beautifully Desolate Campaign Pillars of Eternity 2: Deadfire Pathfinder: Kingmaker Pathfinder: Wrath I'm very into cock and ball torture I helped put crap in Monomyth
https://www.kickstarter.com/projects/836367155/monomyth/posts/3331745

State of the Game: Current Progress | Creation of Level Sections


Hi, dungeon-crawling fans!


It's been a few weeks so it is time for another update! A lot of things have happened and the project is on a good way! So without any further ado, let's get started...


Current Progress

As you may remember, I am currently in the middle of the content creation phase or, more precisely, in the middle of the world-building process. This process has a few stages. It starts with the creation of the level designs "on paper" (or in planning software, as you will see later in this update). It then continues with a blockout phase, where the basic building blocks of the designs are put into place. The finished blockouts are then re-iterated on and eventually replaced with actual game assets (i.e., 3D models of the level geometry, mostly split up into modular parts). After that follows the so-called "detail pass", where detail assets (furniture, rubble, wall decorations, vegetation, etc.) are placed in the level. The whole process is then concluded with a lighting pass, audio assets, visual optimizations, and level logic.

Monomyth is currently in the re-iteration stage (here and there I am already adding details, but mostly I am trying to stick to one task). All areas in the game - from the beginning to the end - have been blocked out. This was an important step because it narrows down the actual scope of the project and keeps it manageable. The levels of Monomyth are no longer just "on paper" designs that could be changed at the drop of a hat. Instead, I am now dealing with a finite set of concrete work tasks, which is infinitely better if your goal is to get things done.

601a0f8e66f20bc8cee9f54901e93b62_original.png

Blockouts from various areas in the game. Some areas are more detailed than others to get a rough feeling for the intended look.

After reviewing my schedule I decided to take a little break from level design and do some game system refactoring (that is, a reworking of the code to make it more maintain- and extendable). That means for the next two weeks I will be doing some coding which I would have otherwise done in January. Level design is a comparatively straightforward challenge from now on and I am trying to prepone any tasks which may cause unpredictable problems. Coding has a tendency to cause such problems, even though I already figured out most of the refactoring on paper, so, fingers crossed!

Once the code refactoring is done I will continue with the detail pass of the level design. This brings us to the main part of this update...


Level Design

In the last update, we spoke about level layouts and how to structure a semi-open game environment. We discussed, how levels in various classic games were essentially a set of largely independent sections, interwoven with a separate "connector" section. Today we will take a closer look at the sections themselves and talk a little bit about their creation.

A section is essentially just a collection of rooms containing encounters. Such encounters may be enemies, friendly NPCs, puzzles, etc. The first question is, how to approach a section's design. Just as with the level layouts, there are essentially two ways to go about this process:

a) Top-down: You start with a rough overview of the entire section and you continue to go into detail for every single room as a part of the whole. This approach puts an emphasis on coherent interconnections between a section's individual rooms. However, these rooms may require restructuring once the full design becomes more concrete.

b) Bottom-up: You start with a collection of readily designed rooms and compile them into a section. This approach puts an emphasis on gameplay-driven design. However, the rooms may become incoherent with each other and the connections between them may feel unintuitive.

A room, respectively a section can be anything by the way. It does not need to be a "closed" space. Practically, it can be any area with a finite set of entrances that connect it with other areas of the game. Talented level designers can create a collection of such areas and connect them in a way that seems like an entirely open world.

A very good example of this is the map of Gothic 2, which is presented as an open world environment, but strictly guides the player through various bottlenecks (i.e., entrances) from one area to the other. Fans of Gothic 2 may be very familiar with the northwestern area of the map, which is enclosed by the sea, the city, the ancient forest, the bridge, and a valley of aggressive monsters. Unless players get very "creative" (e.g., by climbing onto walls and roofs where they technically shouldn't be), exiting into another area of the game without going through one of the bottlenecks can be very difficult.

5233d1f17351b337c271c6186e8cc49f_original.png

The main map of Gothic 2 with highlighted entrances to the section north of the game's main city. Readers of the last update can probably already spot the different sections of the game.

Coming back to Monomyth, I am mostly using a top-down design approach. This means, I first draw a rough overview of a section and I start re-iterating on the design. At this point, I am also annotating most of the rooms with a location name or a first idea of an encounter.

There are numerous ways to draw section overviews. Some people prefer working on paper, while others use dedicated software. For Monomyth I normally use Dungeon Painter Studio (DPS), a tool that was originally developed for Pen & Paper DMs. It allows its user to draw tile-based maps, much like on graph paper.

7a9e306feee8c54ff5ead7bcbc1bd508_original.png

An exemplary map design made in DPS

Having all the map designs in a digital form has a big advantage. Once I am satisfied with the design I export the map as an image file and I import it in the Unreal Engine 4 (UE4). With the right scaling, the image file can be applied as a texture on a simple plane, which then serves as an exact floor plan for the blockout stage.

4660b5c9a4f28ae8d2e02879fd1bb55f_original.png

The map design from DPS, applied as a texture in UE4

During the blockout stage I align the floor plan with UE4's top view grid and I use blueprint actors to build the environment according to the design. These blueprint actors represent various building blocks of the level, such as different kinds of walls, floors, doors, and so on.

199eb1846e6f5d3044f848ea998c7c06_original.png

Some building blocks of the environment.

8bf40626403d7b9271de15078131de38_original.png

The floor plan is exactly aligned with UE4's grid and scaled in a way so its tiles match the building blocks.

Every actor I place is of a certain class. This has the advantage that once the modular meshes for the respective area are done, it is not necessary to replace the entire blockout. Instead, I simply adjust the blueprint classes, which then automatically updates every actor. Take for example the following meshes:

738781d1d6c887e3b261dd094bc4569b_original.png

A set of modular 3D meshes

I simply plug these meshes into the blueprint actor classes and remove the original gray building blocks in them. All instances of the adjusted classes are automatically updated and the blockout will be significantly closer to the desired end result. At this point, it is also a good idea to think about encounters.

d5e783ed227fb339783071241f5463a7_original.png

Top view of the built level section using adjusted blueprint actors

0e55e0136d665d362b5dc1e661fbcde8_original.png

Perspective view of the built level section using adjusted blueprint actors

Once the basic geometry is there and I am satisfied with the look of it all I usually continue by adding detail meshes and lighting. This is called a detail pass, respectively a lighting pass. In these stages, I also visually optimize the scene by adding particle effects, fog, etc.

ef53c251c2e6b187e84810bebf8a50e5_original.png

The realized level design after the lighting pass.

At this point the only thing that is still missing from the level section is level logic. Level logic describes any level-specific functionality within the game environment. This may be something that affects the level design (e.g., a collapsing hallway or a suddenly flooded room), in which case it is recommendable to already consider level logic during the blockout stage. Sometimes, however, level logic can be something as simple as an automatic door:

f6761958f58fcbe18e1cfee189b4095c_original.gif

All done! Level logic can add dynamic elements to the level.

And that's it! During the entire process, it is of course recommendable to test the section again and again. Especially with regards to scaling, encounter pacing, item distribution, and so on.

It should be noted, that this approach is slightly different from the industry standard and requires special consideration in terms of verticality. Usually one would use so-called geometry brushes, which are simple 3D shapes that are combined into whatever you wish to block out. UE4 does provide such geometry brushes, but unfortunately, this feature has been slightly neglected by the engine developers, meaning it is not very performant, and comparatively impractical to work with. So impractical in fact that there are plugins by the UE4 community to make up for the engine's native feature.

Either way, the process I am employing works very well for enclosed spaces and dungeon crawling environments. Next time we will take a look at rooms and encounter design. Until then!


Best wishes,

Michael
 

RatTower

Arcane
Developer
Joined
Apr 24, 2017
Messages
468
I actually got the same feedback about the head bobbing from a guy working at epic :D
Lately, I have spent most of my time with level design though, so I haven't touched that code in a while.
Tomorrow I will start with the code refactoring. I should be able to cover that there.

Huh, I missed that, thought it ended already.

RatTower - dude, I don't wanna pester, but could you give us some guidance on that GOG question? I'm sorting out my PayPal at this time and I'd be happy to pitch in, but I'd like to avoid the situation where I back early, get a Steam key on release and then a month later, bam, Monomyth hits GOG. I'd just like to know whether backers would get a choice of store assuming you'll be releasing on GOG (and it does seem like Monomyth would be right up their alley).

I can't say for sure yet. I am planning a GoG release and I hope it will be accepted there but in the end, it depends on them. If Monomyth gets greenlit on GoG in time, backers will at least get to make a choice about their preferred key.
In case it can't be timed properly, I am also thinking about giving out the GoG key to any backer that requests it afterwards.

P.S. How does it work through that Kickstarter Encore thing? On release, do we get our key at the e-mail associated with the PayPal account? Or is there some other registration involved?

There is no registration involved. It's all handled through Paypal and the mail address associated with your account there.

P.P.S. Get an SSL certificate for that webpage, man.

On my ToDo list :salute:
 

Gargaune

Magister
Joined
Mar 12, 2020
Messages
3,136
I can't say for sure yet. I am planning a GoG release and I hope it will be accepted there but in the end, it depends on them. If Monomyth gets greenlit on GoG in time, backers will at least get to make a choice about their preferred key.
In case it can't be timed properly, I am also thinking about giving out the GoG key to any backer that requests it afterwards.
Thanks, chief! That all works for me, I'm on board.
 

Infinitron

I post news
Staff Member
Joined
Jan 28, 2011
Messages
97,228
Codex Year of the Donut Serpent in the Staglands Dead State Divinity: Original Sin Project: Eternity Torment: Tides of Numenera Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 A Beautifully Desolate Campaign Pillars of Eternity 2: Deadfire Pathfinder: Kingmaker Pathfinder: Wrath I'm very into cock and ball torture I helped put crap in Monomyth
https://www.kickstarter.com/projects/836367155/monomyth/posts/3396213

State of the Game: Current Progress | Refactoring & Game Design



Hi, dungeon-crawling Fans!


The year is coming to an end, but the work on Monomyth continues - a good opportunity for another update! This month we will focus more on the technical side of things, so, let's get started...


Current Progress

You may remember, in the last update, I mentioned that I'd do some coding for the first two weeks of December. I wanted to improve some of the game's systems and make it easier to include additional immersive features (work I would have otherwise done during January).

After the first two weeks, I saw that with a little bit more time I could turn the refactoring into a major code rework, which would immensely simplify future development and potentially save me a lot of time in debugging. So, I decided to take the chance and I dedicated another two weeks to coding.

Alongside the removal of several conceptual problems with the AI, two major results came out of this process:

  • Improved Character State Machines
  • Improved Inventory System
These improvements allowed me to introduce a series of features, most of which were either requested during the Kickstarter demo or part of the "Expanded Immersive Simulation" stretch goal. In this update, we will deal with the inner workings of the improvements as well as their effects on the game design. It will be a bit more technical this time but don't worry, we will talk more about level design (and - as promised - dungeon rooms) in next month's update!

Refactoring & Game Design

To recap a bit, refactoring means the rework and improvement of code and code architecture. Much of the Kickstarter demo's code has been written quite some time ago, and while it is maintainable, cleaning it up here and there is always a good idea. Failing to do so may not ruin a project (even though, there certainly are projects that have become victims of their own spaghetti code), but with increasing complexity, the time spent on fixing bugs and introducing new features increases drastically. Lately, people started referring to this additional work as so-called "technical debt" or rather the "interests" of technical debt - a term originally coined by Ward Cunningham in 1992. It's a common problem in many engineering fields and game programming is no exception. A cleaned-up architecture helps to keep the code maintain- and extendable, mostly by preventing side effects of both major and minor code changes. I refactored a few systems this month. The most significant ones were the character state machine, as well as the inventory system. So let us take a look at these.


As for the character state machine, we must first clarify: "What even is a state machine?". A state machine (or FSM, standing for "finite state machine"), is actually a very simple concept. It's a depiction of possible states a certain object (e.g., a person, a machine, a piece of software, etc.) can be in. It further depicts how the state of an object can change (i.e., what triggers the transition between states). To give you an example:

Imagine yourself. You can either be "awake" or "asleep". To be awake you have to "wake up". To be asleep you have to "fall asleep". This can be depicted in a simple state machine (I won't bother you with default states for the moment):

6000ecb1938db9a96c584a81cb8e2895_original.png

Being awake (normally) allows you certain activities. For example, you could play video games! Usually, that shouldn't affect your awake state, so the activity could be expressed as a self-transition (alternatively "playing" could be a sub-state of "awake", but I won't bother you with that either - for more information, look up "Hierarchical State Machines"):

4956704cf862a3de35322dbc9b2a0380_original.png

You can probably already see how this concept can help organize the activities of a character within a video game. It is also very easy to add further complexity to these constructs while keeping the programming effort relatively low. That is if you follow a proper design pattern and know how to implement it in the engine you are using.

There are numerous ways to use FSMs in a game's code, from NPC behavior to the lock of a simple door. Among other things, Monomyth uses FSMs to document a character's current state and restrict possible inputs for both the player and the AI:

96ec7135e8af35753910c901eea9a2ae_original.gif

Originally, Monomyth used an old-fashioned enum-based state machine for its player controller class. Characters mostly used ad-hoc structures to restrict their inputs (e.g., gates, checks, etc). This worked for the most part, but using a well-defined design pattern instead helps avoid a vast variety of potential bugs and unexpected runtime behavior (especially with regards to AI).


Now let's come to something that had a more immediate effect on the game design. The refactoring of the inventory system opened up a few possibilities in terms of newly implemented features. But first, what exactly was wrong with the original implementation you saw in the Kickstarter demo?

The original implementation of the inventory system used a static approach towards object handling. That essentially means that items were not really passed between the game world and the player inventory. Instead, what was passed was an identifier, from which items were constructed in the inventory once the player picked up their representation in the game world. There are various reasons to implement inventories like that, but in the case of Monomyth it was mostly premature optimization, as well as vaguely defined requirements, both of which are big no-nos in any software project. From the player's perspective, it would mean that items had - for the lack of a better description - no "object permanence". Custom properties, that would change on an item throughout the game, could not be carried over from the world to the player inventory. This restricted various planned features. Among others, blacksmithing, which is directly connected to weapon improvements and item durability. But let's go through these things in detail...


Blacksmithing

Blacksmithing was one of the features planned for the "Expanded Immersive Simulation" stretch goal, and while we slipped slightly under that goal in the final funding, I still intend to implement a good bit of its feature catalog. The feature itself is always a difficult topic in games, because a) you don't want it to be a time sink and b) you don't want it to feel like just another menu slapped on the GUI. In Monomyth the players should really swing the hammer, and when they do that they should do it for a useful purpose (no "creating 100 iron daggers to push a number in the character menu"). Blacksmithing will focus on repairing items, improving items, and creating special equipment. The earlier two require the aforementioned custom properties introduced during the refactoring, while the latter is more of a special questline for the right ingredients. Improving items can take many forms, from creating a classic "Longsword +1" to instilling a holy essence in a lance. Repairing items on the other hand is a more straightforward process, that only really makes sense when there is item durability.

f83b69ce80b22dfde310e41e33d705a6_original.gif


Item Durability

I can already hear some people groan, but don't worry! Item durability is a logical conclusion of previously introduced features (not only blacksmithing) and I will try to handle it in the most balanced way possible. I remember having a discussion on the topic a few years ago and people generally felt lukewarm about it. I expressed my concern that there was very little to prevent players from destroying all doors in the game, other than the fact that it may attract hostile NPCs (which is essentially just a problem for stealth-focused characters). In the demo, this was balanced out by using indestructible metal doors in numerous places. It was a more or less subtle solution to the problem, but what it really did was nullify a feature of the game. With item durability, on the other hand, there is an explicit trade-off attached to destroying doors. Now the question is, how to balance this feature properly.

In a lot of games, item durability comes in one of three flavors: Neglectable, annoying, or stressful. Neglectable item durability is the one that you never really notice. You go through the entire game finding lots of new equipment so item durability never really takes effect. The feature is more of a formality than part of the actual design. Annoying item durability is the exact opposite. All your weapons break all the time and you have to go and repair them constantly. Here, the feature is more or less a time sink. Stressful item durability essentially works like the annoying kind, except all broken weapons vanish from your inventory forever. In many games, this approach disturbs clean item progression and the sense of finding a real treasure because everything is essentially fleeting.

Ultima Underworld on the other hand had a relatively balanced approach towards item durability. While most weapons could be entirely destroyed, you could pick up weapons from enemies. This balanced item durability and gave the early game a bit of a survival element.

I do not intend to implement full item destruction in Monomyth, however, I would like to scale item durability with ongoing item progression. This means earlier in the game item durability will be more important, while later it will take a backseat. This way, Monomyth might develop a survival aspect in its early game, similar to its inspiration. And of course, that means another thing...


Picking up weapons from dead NPCs

During the Kickstarter demo multiple players wanted to pick up weapons dropped by enemies. Not being able to do so was considered immersion breaking, illogical, etc. The same was true for the "loot orbs" (the floating blue orbs that would appear on an NPC's corpse). With the introduction of the new character state machine, the new inventory system, as well as item durability, these problems could be addressed. Players can now directly loot items from a character's body. Given that the character is in the right state (dead) the new code directly accesses that character's individual inventory. The same approach could be used for a pickpocketing feature (which was originally included in the "Advanced Playstyles" stretch goal), but given the schedule, unfortunately, I can't make any promises concerning that right now. Weapons dropped by NPCs are now regular (damaged) items the players can pick up. Item durability is supposed to balance this new feature as well. Talking about picking up stuff from the ground: I implemented one last feature after the inventory system refactoring...


Inventory Tetris

Maybe one of the most popular inventory management features from the late 90s/early 2000s. Since the existing inventory system from the Kickstarter demo was just a specialization (with all items occupying only one space in the inventory) it seemed natural to prepare this approach while I was already working on the inventory code. What happened in the background was a switch from a simple item array, to a vector map of items and the addition of dimensions to item data. From there on the implementation was relatively straight forward and most of the work went into the functionality of the GUI (which now features drag and drop interaction).

1979da29c42f31873018f31b1eb5d95d_original.gif

I am also reworking the visual design of the inventory.

Testing will show how much of an impact this feature has on the game design. My guess is, that the deciding factor of inventory space management will still be item scarcity, whereas item dimensions should add a further possibility to balance the issue.


In conclusion, I believe that the refactoring was definitely worth it. Newly introduced features, as well as implemented feature requests, look promising so far. I still have to adapt a few systems to the new codebase (persistence, item combinations, etc). I hope these follow-up tasks won't interrupt the planned schedule too much. All in all, I'm confident that the lion's share of the necessary work is done and smaller features will fall into place nicely due to the improved architecture. During January I will mostly create narrative assets and do more level, respectively character design. I'll probably throw in a day of programming here and there and update you about the progress. Until then!


Best wishes and a happy new year!

Michael
 

Gargaune

Magister
Joined
Mar 12, 2020
Messages
3,136
Can we just take a moment to recognise how cool it is that these updates aren't just progress reports, but also educating the masses on software and game design concepts? Many of us here probably know about FSMs and the like, but non-engineers get a rare glimpse into the development process and it's an excellent marketing exercise because it reassures backers that their eurobucks are being well spent by someone with a thorough and methodical approach to production.

Also...
Inventory Tetris
:happytrollboy:

God bless you, RatTower, happy new year indeed!

P.S. If you're reworking the inventory UI at this time, please don't forget about the resolution scaling bug, at 1680x1050 the description panel was cutting off halfway on the left edge of the screen.
 

Infinitron

I post news
Staff Member
Joined
Jan 28, 2011
Messages
97,228
Codex Year of the Donut Serpent in the Staglands Dead State Divinity: Original Sin Project: Eternity Torment: Tides of Numenera Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 A Beautifully Desolate Campaign Pillars of Eternity 2: Deadfire Pathfinder: Kingmaker Pathfinder: Wrath I'm very into cock and ball torture I helped put crap in Monomyth
https://www.kickstarter.com/projects/836367155/monomyth/posts/3371568

State of the Game: Current Progress | Rooms and Encounters


Hi, dungeon-crawling fans!

We are one month into the new year and it's time for yet another update on the project! January was a month filled with brushing up earlier work, tidying up workflows, and generally bringing things into a more presentable state. But let's go into detail a bit...


Current Progress

After a major refactoring in December I mainly focused on four tasks during January:

~ Asset Migration: This was mostly follow-up work of the refactoring. I ported some assets to the new code base and adjusted a few things. This is ongoing work.

~ Writing: Currently, most of the writing revolves around creating narrative assets. That means, writing dialogue trees, quests, or item descriptions.

~ Detail Pass: I started with the detail pass of the first area in the game. In this phase, the blocked-out level concepts are made into presentable environments, filled with details. Some of these environments will receive further polishing in the lighting pass.

44fcd85abefb305392d1b7dee76d1391_original.png
76ccbe79d5fbf9f59e50326519db2872_original.png
6e6cedcaae545d74bfede28184e33117_original.png
cfff74d721b10ae57fd7409430e646b8_original.png

~ Character Design: I also did some character design, modeling, and texturing. The most important part here was to get the workflow right, especially with regard to animation and character modularity. Animation is (still) a tricky topic when it comes to the Blender/UE4 pipeline (even though it has improved drastically over the last few years). Generally speaking, it is recommendable to use the standard UE4 mannequin (respectively its skeleton and extensions thereof) as much as possible - simply due to the fact that it saves you a lot of work when it comes to humanoid characters.

Importing the UE4 mannequin in Blender has been the cause of many headaches for developers. That's why for animation I mostly use Mr Mannequin Tools - a Blender Plugin that makes this procedure as simple as it gets. Another dimension of the problem, however, is binding custom characters to the standard UE4 skeleton. That is unfortunately a more complex problem, which can be (kinda) solved by playing around with empty vertex groups and surrogate skeletons. Luckily, in humanoid character creation, it is possible to model a character as a group of "empty" clothing meshes. These are then bound to a readily rigged UE4 character via data transfer. Or, to put it into simple words: You can just get a readily rigged and animated standard humanoid UE4 character (which has all the correct vertex groups and bone weights), you "dress that character up" with your clothing meshes and then you just copy the skeleton bindings from the underlying humanoid character via Blender's data transfer modifier. This approach requires some cleanup, but it's definitely faster than doing it all manually.

5be0fcdbdb771fce258822235c6ad894_original.gif

Speaking of clothing meshes: A proper modularization of such meshes into compatible parts provides you with a powerful workflow to quickly create a large variety of different characters. Those of you that backed the project at the "Lysandrian Minister" level or higher, will be provided with a catalog of such character parts to build your very own character. To give you a little idea of what this may look like consider the following image:

4a43bca2e73c83edc42a5fc455a1b67b_original.png

Backers pick individual parts and will be provided with their final selection. For example, the following character consists of the parts A1, A2, A3, B4, and a color variation of A5:

98278c30748c71d0c7fc3cd052c31ad5_original.png

I will have to see how far I can take individual wishes with regard to coloring into account. I may provide backers with fitting color schemes from which they can choose.


Level Design

As promised, this time we will conclude our documentation of Monomyth's level design principles with a short discussion on room design. To recap: In previous updates, we talked about the layout of a level as well as the design of its individual sections. We mentioned that a section is a collection of rooms containing encounters. I should mention that "room" is a very loose term here and the same principle could be applied to any sort of (largely independent) level subsection, indoor or outdoor.


Generally speaking, rooms contain challenges, or "encounters", for the player. The design of these encounters is usually feature-driven, meaning the player has to understand the challenge and apply some sort of game mechanic in order to overcome it. The encounters themselves often have an impact on the visual design or the structure of the environment in which they are located. A good example of this is Dark Messiah's conveniently placed spikes into which you can kick your enemies, whenever you have had enough of them. And here the dilemma of room design starts.

8314a6f438f7027319f0c2a061b51aa7_original.jpg

The adventures of Sir Kickalot (Dark Messiah of Might & Magic, Arkane Studios, 2006)

Basically, you want a room to be coherent. The structure must be recognizable and logical. At the same time, there must be some sort of game mechanic involved in a room's planning to make exploration more than just a nice little stroll. The problem is, that integrating such mechanics may be detrimental to structural coherence. The prime example of this is the iconic narrow pathway with pendulum axes.

291427e041fb54d528099d54347e170a_original.jpg

Sen's Funhouse (Dark Souls, From Software, 2011, via darksouls.wikia.com)

Besides a few exceptions, there is no real reason to put something like this anywhere, however, it can be an engaging challenge. So in a way, there is a basic dilemma between what makes sense and what is fun. Often, it is a good idea to resolve the issue via the "Rule of Cool": Anything that is engaging is preferable to whatever is logical. Of course, in an environment that needs to be plausible and immersive, this can easily be overdone. Luckily, most dungeon crawlers are set in the mythical lands of fantasy adventure and plausibility is only a reasonable "in-lore" explanation away. However, the issue is a bit more delicate for immersive dungeon crawlers. Immersive and emergent gameplay strongly relies on the logical conclusions the players can draw from their "real-world" knowledge. This normally isn't a big deal, but it serves as a warning to not take things too far. In room and encounter design, any fantastical element, be it floating platforms, levitation elevators, illusory walls, non-euclidean hallways, and so on, must be properly introduced so they become a part of the players' realm of reason. Only then a meaningful interaction with such elements can happen.

Of course, none of these are novel considerations. Others have thought of these problems before and wrote several books on rooms and encounters, most notably, D&D's Book of Challenges as well as the Book of Lairs. But really, any dungeon-crawling module, from short adventures to mega-dungeons, can provide detailed insights into the art of room and encounter design.

a55d7828755dee71bc2ffeb094ecb5b7_original.png

While reading these books and looking at their numerous interpretations in computer RPGs we intuitively understand some prevalent categories of encounters. The following is a limited overview of such categories, some of which tend to be mixed together. Each one would probably warrant its own little essay.

~ Combat Encounters: The lion's share of most RPGs' encounters is combat. There are whole modules dedicated only to detailed combat situations. These are usually part of group-oriented RPGs focused on tactics. Different character classes bring different abilities to combat and provide players with different possibilities to overcome their enemies. Ideally, all combatants have strengths and weaknesses that add up to a zero-sum. Of course, the more complex the characters' underlying statistics are, the more complex it is to design a well-balanced combat encounter. Action-oriented RPGs usually put less focus on these intricate details. However, there are a few that make use of enemy weaknesses, bringing a strategic element into play. The classic example is skeletons being weak to bludgeoning damage. Certain status effects such as poison, blindness, or petrification are normally less popular in action-oriented games, however, used in moderation, they can add an interesting aspect to combat.

~ Treasures: There are numerous theories on how to create an engaging reward loop. From the field of professional gamification to countless free-to-play titles, thousands of developers have put a lot of thought into this topic. In some cases, developers rely strongly on constant dopamine hits, leading to rather questionable (and more importantly, often unsustainable) results. In classic RPGs, especially in those that are focused on room-by-room exploration, it seems more fitting to distribute rewards by a more irregular pattern. In Psychology, this is referred to as a variable-ratio schedule, where behavior is reinforced through an irregular number of rewards. Imagine, for example, there are rooms in a dungeon that are visited in a certain order. Let's say on average you would like to reward exploration every four to six rooms. So there is an average expectation for rewards (roughly every five rooms), but there is also an element of uncertainty (+/- one room). That uncertainty is essentially what keeps the engagement going because it introduces an element of tension and relief. Without the uncertainty, exploration would become just another grind. Of course, this is just a very primitive example, and there is also the aspect of balancing the value of individual rewards. The more precious rewards, for instance, could be preceded by riskier encounters.

~ Traps: Speaking of risky situations, treasure can also be an effective bait when it comes to traps. Traps had a bad reputation in game design for a while. I can only assume this goes back to certain notorious dungeons of D&D and how various DMs threw their players to the wolves, giving them nothing to avoid danger. Group-oriented RPGs rely strongly on rogues and their skills to spot traps. However, when a dungeon crawler only features a single character, it is recommendable to at least provide alternative ways to detect traps in time. As a rule of thumb: Every trap needs a (subtle) clue and must be avoidable. Every poisoned well should at least have a greenish glimmer or an oily film, every pressure plate should at least stand out a bit, etc. Some traps are quite obvious. These could be seen as generic obstacles (e.g., pendulum axes). Traps should be deadly but fair. Their main purpose is to keep players on their toes.

2d93453fefbfaf5037efe65f79e4627d_original.png

"Go ahead and take a sip! What's the worst that could happen?" (In Search of the Unknown, TSR, 1980)

~ Secrets: Some people tend to develop a sixth sense for the exact location of secrets within a room. This is not as fantastical as it sounds at first, but rather the result of a learning experience that picks up on minor clues within the environment. Sometimes secrets are spotted through the absence of a different meaningful encounter within a room. Sometimes it is oddities with the architecture, like an alcove in a weird place or a wall where a room should be. Sometimes it is the fact that a certain area is visible but apparently inaccessible. Secrets can be communicated to players in very subtle ways and not everyone will pick up on these. At times not even the level designers realize how much they really give away, while attentive players will see through their secretive shenanigans immediately. If secrets always follow the same principles people will open one hidden door after the other, and the surprising element is lost. It is, therefore, a good idea to come up with different types of secrets and equally distribute them throughout the dungeon.

~ Puzzles: Puzzles come in all shapes and sizes. A detailed discussion of the topic in a short paragraph is pretty much impossible so I will limit myself to my personal preferences. I still consider Riven (aka Myst II) as the gold standard of puzzle games, mainly for two reasons: 1) All puzzles in it are completely logical (i.e., you get all necessary clues and there are no random elements to them) and 2) you cannot brute force them, because they all involve combinations of variables with potentially millions of possibilities. While these two aspects have their advantages within the adventure genre, they can create a problem within immersive dungeon crawling. If the core principle of your game design is to let players figure out their own creative solutions for a challenge, a classic puzzle, which must narrow down everything to one solution, may be out of place. It has to be conceded though that both Arx Fatalis and Ultima Underworld featured such puzzles, some of which could be skipped, however.

~ Friendly Encounters: One of Ultima Underworld's greatest features was its "civilized" areas. To this day, meeting friendly NPCs within dungeons is rather noteworthy, especially when they are part of a larger group. Regarding a dungeon as a living space shines a different light on dungeon layouts, sections, and room designs. Suddenly the necessities of everyday life come into play and the environment may reflect this in one way or another. Naturally, the less expected such friendly encounters are, the more they stand out. A great example of this is World of Warcraft's "Grim Guzzler" - a tavern in the middle of a volcanic dungeon, filled with (otherwise hostile) NPCs that are too drunk to care about your presence (that is, until you start a bar fight). I mention this encounter in particular because it highlights how a small deviation in terms of NPC hostility can create an encounter that may stick in people's minds for decades.

3104fdaf35acf782da9155d67c2a6e74_original.jpg

The Grim Guzzler Tavern (World of Warcraft, Blizzard, ~2005)

All of these categories can be related to multiple game mechanics. Combat encounters may be avoided by sneaking around them, traps can be triggered by throwing objects at a pressure plate, puzzles can be circumvented altogether if you bring the right item, and so on. With all these things in mind, it is significantly easier to elegantly marry structurally coherent environments with engaging mechanics and end up with a feature-driven design that is fun to play.


And this concludes our little foray into level design. Over the course of the next month, I will likely focus on character design and detail passes. I will keep you posted! Until then!


Best wishes,

Michael
 

Curratum

Guest
For what it's worth, I'll always be a fan of the majority of "out of place" or even "ridiculous" things in any room, area or encounter, if they add to the gameplay and pose fun challenges and/or solutions, except for the most wildly outlandish fringe "absurd" cases.

Heaven knows, Dungeon Crawl Classics adventure modules and supplementary materials make very little sense as structured, "sensible" dungeons but they're the most fun you can have with a tabletop game's official materials I've seen in forever.
 
Last edited by a moderator:

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom