State of the Game: Video Devlog 1.0 | Beta Update 2
Hi, dungeon-crawling fans!
It's time for another update on Monomyth! Just like last month, I would like to present this update in the form of a short video, which you can find here:
For those of you who would rather read, I will attach the transcript plus relevant screengrabs!
Best wishes,
Michael
-------------------------------------
Video Transcript (Video Devlog 1.0)
Hi, dungeon-crawling fans!
A new year has begun and I am still very busy developing the project. I am going through milestone after milestone, slowly pushing toward a game that is ready for you, the backers, and the many followers who have supported Monomyth for over a year now (some of you even longer than that). Thank you again for your patience! I will do my best to get the project into your hands as soon as possible.
But before that, we will have to go through a couple more beta patches first. As this new year begins, a new update for Monomyth’s closed beta is about to be released. Update 2 is being packaged at this very moment. So, I thought, let’s take a look at what’s actually in there, so you can get an understanding of what goes into a patch and why this particular one took so long:
The most time-consuming task for update 2 was the level design. Under the heartlands, you will find the mines and the factory tower.
These areas are relatively expansive and there is a lot of focus on verticality, which made it harder to assess the full scope of the environment. Essentially I started out with the idea of an underground tower adjacent to a series of caves, which later became a mine. My original intention was that the players would make their way down the tower traveling between the tower halls and the mines which are connected by bridges.
You can probably see the inspiration from locations like the mines of Moria or dwarven strongholds from various fantasy settings here.
Of course, the more impressive you want the vertical aspect to be, the higher that tower will turn out to be. But the higher the tower gets, the more caves you need to build to get a well-knit together environment with a well-balanced variety of aesthetics. You don’t just want to be in the tower and you don’t just want to be in the caves. You want to travel through a nicely mixed-up environment to keep things fresh. And from that, you can also see why the scope kinda blew up. Building the environment, especially the caves took much longer than I anticipated.
This is especially ironic because originally I restarted the development of update 2’s area due to the original concepts being out of scope.
Original design - Layer 1
Original design - Layer 0
Here you have a 60x60 tile map of the original design. Every tile corresponds to a portion of the floor that is 400x400 unreal units in the engine. The original design was also supposed to include a certain verticality aspect so it basically had two levels layered on top of each other, including one connecting intermediate section. This level was almost entirely blocked out (with the exception of the ceilings), and it was clear that it was probably out of scope.
The area design should have probably been cut in half and for verticality, the four remaining sections should have been layered on top of each other.
Instead, I restarted the area at the design stage, which is probably okay (you don’t want to tinker too much with broken old designs), but I made one big mistake: Instead of creating another map like for the original design, I winged the details on the environment. Of course, I had things down on paper, I had the core ideas and some rooms mapped out, but I also left a lot of blank spaces in that design. So basically I had some rooms planned out but only in specific sections, and the rest of the map kind of grew from what was built.
That last part specifically proved to be a big mistake. Don’t “grow” your maps, because that will almost certainly cause trouble in terms of scope. It’s very likely that you will overscale the area that you planned out in detail and then the rest of the environment suffers from it. You will probably wish to bring the same level of detail to those parts of the map, but it’s simply out of scope and you will never finish your work.
I noticed this happening as I went along because the workload went out of balance, meaning, that there were portions of the map that were basically done in terms of regular geometry, but which would have been way too much work during detail passes and beyond - the parts of level creation where you basically go through every room again and add detail meshes, and then NPC and mechanics and lighting and whatnot. So I suspected this happening at first and when I was sure I had to rescale, which means, bluntly said, cutting parts of the level. That’s always unpleasant because you already worked on it and you spent time on it but you have to do it or the project milestone will fail. It’s basically a sunk-cost issue.
The good part of this is, you can still keep what you made for either another level or even another project. There is plenty of examples of this in released games, even in the Triple-A titles.
Either way, the remaining parts of cut-down levels are very often better for it. I firmly believe that’s the case with Monomyth’s update 2 area because I am quite satisfied with the end result. It has some very good verticality, a lot of complexity in terms of layout, interesting little mechanics, and secrets. So I feel it came out pretty alright even if it took way too long to finish.
The main lesson here is probably: Don’t grow an environment. Don’t improvise room designs. Properly plan section details ahead of time, at least to a point where you have a rough outline of how to progress through a section and you can estimate the full scale of an area and not just a part of it. Otherwise, the workload for different parts of the level will likely get out of balance and you will have to cut stuff and rescale, which will cost you a lot of time. And we don’t want that, especially when time and resources are sparse. That’s probably a fine way to summarize the issues with update 2’s level design.
Luckily I won’t have to deal with these problems in update 3, because there the level is already blocked out and scaled properly. Update 3 is also generally further along, which makes me confident that it should be done significantly faster.
But let’s move on. What else is in update 2?
I have worked on a whole bunch of new items, particularly weapons. I mention these specifically because I work on weapon models in batches, meaning the final items are not only meant for update 2, respectively the area from that update, but also for later parts of the game. So this is also a bit of preponed work that will save time in following patches. Something similar is true for spells. Most of these have been ported to the new codebase and are mechanically functional, they just need a visual workover.
The new area also features some new NPCs. Of course, that also means new dialogue. The dialogue in Monomyth is organized in dialogue trees or more accurately in multiple dialogue graphs per dialogue partner. The graph structure has to be planned out ahead of time - I do that in a simple spreadsheet. That spreadsheet then has to be transferred into the game’s data tables from where dialogue data is read. As a result writing dialogue was quite a pain in previous updates. Not only did I have to take great care in planning the graph structure coherently, but I also had to spend significant time transferring the finished graph into the respective data table. I did this manually, which is of course always a potential source for error and therefore bugs. So in update 2, I decided I want to have no more of this and I implemented some tool support. I can now do an automatic transcription of planned-out dialogue graphs into Unreal’s data table format.
Old dialogue workflow
New dialogue workflow
I use a simple python script for that, which transcribes a CSV into JSON format. The JSON file can then be appended to UE4’s exported data tables, which are then just reimported into the engine’s editor with the new data. This already saved me a ton of time and I am very glad I implemented this relatively small tool. It isn’t full tool support for writing dialogue but it automates the most time-consuming part of it.
So that’s it for update 2. As I said it is currently building. I will be going through it a few more times, applying some last fixes here and there and it will be in the beta branch very soon. And then it is on to update 3, which, as I said, will hopefully be done a lot faster this time. During the next Kickstarter update I will probably still be busy with it, but hopefully wrapping it up soon at that point. I believe that Kickstarter update will also be a good opportunity to go into detail on the remaining tasks and to outline another little roadmap to release, or at the very least, the open backer beta. As I mentioned in previous updates, the open backer beta will be released sometime between updates 4 and 5, depending on how much polishing I still need to do beforehand. Either way, stay tuned for more updates, and see you soon!
Best Wishes,
Michael
.
