Paths through the Shadowlands lead the Skycrag Six far from home. Discover a strange new world where giant creatures rule…and an insatiable hunger feeds upon the unwary…

Eternal: Behemoths of Thera is now live, introducing 200+ new cards featuring some larger-than-life mechanics! Explore everything the new set has to offer, including:

• Hunt: Take down some big game!
  
• Versatile: Equip your units or take matters into your own hands!
  
• Deliveries: Get exactly what you need, right on time!
  
• Nightfall & Spellcraft: Two iconic mechanics return!

Behemoths of Thera roam the land, bringing with them new risks, new challenges, and new opportunities for those brave enough to bring them down!

Good luck out there...you'll need it!

Hell Terrain Fixed

Hello and welcome to the first post in the occasional devlog series!

It's been over a month since the reveal of Jump Adventures, and I would like to thank everyone for the compliments, but most importantly, for all the constructive criticism that I received. Your input is incredibly important in making sure that the game is as enjoyable and polished as it can be on release!

Anyway, a lot has changed since that reveal trailer. Let's take a look at what's been cooking under the hood!

Starting off with something more exciting: Customization!



Keep in mind that the UI is a work in progress draft. The final revision will have more customization options and will receive general improvements. For now, it's extremely barebones, with the focus on testing the functionality instead of getting the most polished result.




The customization heavily relies on a brand new unlock system, designed in a general-purposed way, allowing me to not only make skins and colors locked behind certain conditions, but also things like level sections, and so on.

That is everything I can share at the moment. Well, at least until I have something for a more spectacular form. So far, the development is going as planned, so it shouldn't take long for more exciting news. Meanwhile, stay tuned for more updates!

Until next time,
Daniel.

Balancing:

• Chainstorm: Takes less time to reach full spin-up, and it gains accuracy as it spins up. Heat cost has been reduced slightly, while projectiles were sped up a little.
  
• Aftershock: shells travel significantly faster. Spread has been tightened a bit, and delay between shots fired has been reduced very slightly. Finally, the total reload time has been reduced while the arming distance was increased significantly.
  
• Railgun: Reduced the heat dissipation upon firing.
  
• Mallet: Reduced reload time and heat cost. Projectile now accelerate from slow to fast very quickly, making it a little easier to land targets.
  
• Skythorn: Reduced reload and the projectile's lifetime.

Bugfixes

• Changed spawning logic so that bots can pick Rook and Overhauls once again.
  
• Fixed exit screen's "don't show again" toggle to actually work now.

Improvements

• Aftershock's audio was remastered to have its timing be dynamic relative to gameplay changes.
  
• Added support for Saitek Pro Flight Combat Rudder Pedals.
  
• Added support for VKBsim Gunfighter MCG Ultimate Twist.

Greetings, Adventurers!

Aeternum is an ever-evolving world, and as such, we continue our efforts in providing an assortment of ongoing new features, content, and changes. Similar to the activities leading up to our latest major update, we are approaching the release of Leaderboards and would like to invite you all to participate in the next cycle of our Public Test Realm (PTR)!

The Public Test Realm (PTR) is a limited-availability server-set that grants an early look at upcoming features. These preview builds are snapshots of upcoming major releases and are not final versions — you may encounter bugs, crashes, missing text, or other issues. Between our internal testing efforts and your reports, we hope to catch and resolve all serious issues before they reach the live servers. Hundreds of changes have already been made — with more to come — and the full release notes will be shared on release day. However, not every bug or feedback piece will be actioned on before release — some changes need time to be investigated further, and may arrive in a subsequent patch or two.

To help with the feedback process, all newly created PTR characters will have the opportunity to instantly level to select level-ranges outfitted with appropriate gear and items.

The PTR will officially open tomorrow, January 19 at 1 PM PDT. If you encounter a bug, exploit, or have suggestions to improve a feature or piece of content, we’d love to hear your feedback on our PTR sub-forum (you can also utilize our in-game feedback tool). We will do our best to address as much of your feedback as possible before the content update makes its way to our live servers. Your participation will help us to deliver awesome content and updates in the future!

Leaderboards will recognize players, Companies, and Factions across the following categories:

• Mutated Expeditions
  
• Faction War
  
• Vs. Environment
  
• Vs. Players
  
• Trade Skills

Every category contains subcategories. For example, Faction War includes Territory Control Score. Finish at the top of any weekly, monthly, or quarterly Leaderboard rotation for exclusive skins and titles. Rewards cannot be earned in the PTR.

The Leaderboards screen is accessible through the Navigation bar in the menu under Modes. Look for the Leaderboards Tab to see how you compare to the competition.

This special preview client will be made available for download through the stand-alone Steam application, “New World Public Test Realm” (which should already be in your Steam library if you own the main game). When the test period is complete and the main New World game is updated with the previewed content, the PTR world will shut down and may be wiped clean. You will continue to see the New World PTR application in your Steam library, but there will not be an active server until the next time we announce a public test

Upon character creation on the PTR, players will be given multiple caches of special armor and weapons. Each cache has a designation based upon a general build and a main attribute: CON, DEX, INT, FOC, and STR.

To help manage the sudden onset of new items, do not open all provided caches at once, or you’ll risk becoming encumbered! Instead, equip all provided bags and then follow-up with opening each cache deliberately. Any undesired caches can be dropped or deposited into your personal settlement storage.

Everyone with a copy of New World will be automatically granted access to the secondary PTR app. The PTR is not compatible with the live game, so you will need to download a separate client (and have the hard drive space required to support it). From there, we will have special worlds available within supported regions. Not all regions will initially be supported. Access is on a first come, first served basis. There may be queues.

Unfortunately, no. These are separate ecosystems, so at this time it is not possible. However, to make testing easier, we will occasionally provide our play-testers with special accommodations such as instant levels, special gear, etc.

Preview game builds on the PTR are finished with their core development and are in their final phase of testing and bug fixing. Our main focus at this phase is improving quality, although we will appreciate any feedback you have to share.

Our policies and Code of Conduct cover the PTR, and in-game moderation will continue to be supported. Unfortunately, due to the temporary and potentially unstable nature of the PTR, general Customer Service assistance through both Live Chat and through the Support Website will not be available.

Don’t worry, no offense taken. Players can manage visibility of the New World Public Test Realm Steam Library entry. Opening up the game options (right-click > Manage) offers the “Hide Game” function.

Thanks for your support and participation! We'll see you in Aeternum.

• Added a checkpoint to the landing phase.
  
• Ending cutscene now has the correct paint color.

• Added all the tooltips from everything shown (now called advanced view) to simple view.
  
• Changed starting song.
  
• Changed music player.
  
• Changed Menu quiting.
  
• Added Borders to all menus.
  
• AI Stun and AI stun time immunity changed to count down instead of up.
  
• Added custom game settings Battle Start Time CountDown Length and Battle Start Distance Multiplier to custom menu.

Some users have put in requests recently, but I have been super focused on getting the new online tech ready so I haven't been able to make many new builds. This build is focused specifically on some of the requests users have made recently and fixing some bugs.
If you have suggestions or requests, jump into the Discord and lets chat!

v0.5.75
-Improved input logic for player movement so that it doesn't require the move button to be pressed again on keyboard after leaving a menu
-Fixed a menu button scaling issue that would happen on low screen resolutions in the merchant buy menu
-Setup a Settings menu option to turn Titan proximity attacks to a very small distance to allow for a calmer world experience option.
-Updated Sprint FOV Toggle in settings screen to also turn off the sprint camera pull in per user request.
-Setup a center screen reticle option in the settings menu for people who find it improves motion sickness.
-Setup a popup dialog on quit to confirm if you want to save your game or not before quitting. It will only show up if you haven't shaved withing the last X seconds though.
-Increased time between Titan respawns after a Titan has been killed
-Increased Distance Titans can spawn from the center of the world to distribute them more.
-Increased Titan Melee Damage
-Improved fish swimming logic to better handle shallow water.
-Changed Damage points ui feedback to also show up on the killing blow.
-Prevented player attacks from happening when mouse focus is returned to the game
-Improved foam rendering so the player needs to be deeper underwater before it will fade off
-Updated pause menu logic to prevent closing while the save popup is open
-Improved save file naming and renaming logic
-Updated German and Spanish translations with improved text

The test branch has been updated!

This is mainly a bug fix release, with some UI and AI improvements and rebalancing to The Sacred and The Profane DLC following player feedback.

Notable changes:

• Rebalancing of Sacred and Profane cults and clergy opinion bonus
  
• Network system changes re-enabled
  
• Added Retry option when cloud games fail to upload
  
• AI improvements
  
• Many bug fixes

Full notes can be reviewed here:
https://github.com/MohawkGames/test_buildnotes/blob/main/Old%20World%20Test%20Update%202023.01.18

These changes can be accessed on the test branch. To switch to this version:

Right click on Old World in your library, and hit properties, then navigate to the Betas tab and use the dropdown menu to switch from 'none' to the test branch.

Dear Scholars,

I usually try to focus on one thing per entry but this time I have several different things to write about. I'll try to keep them condensed in return. [note from future self: alas, I failed]

The process of creating games was always something I was very passionate and enthusiastic about - not any less than about the end goal to release the game and see people enjoy it. Because of that the idea of live streaming the development process has been lingering in my head for a long time. The reason that I've waited so long to do it is probably that I haven't really had time to do much 3D art in the recent years since programming has always been the most time consuming and high priority thing to work on for Selenwald. I also mostly stopped doing 3D modelling for hire years ago because I needed a more time efficient way to earn for a living. Tech art (shaders, tools, etc.) and programming are paid better and they excite me no less than 3D modelling so I transitioned naturally. Ironically though, it's art that's the most interesting thing for people to watch as indicated by a little poll I conducted over on our Discord server. The most requested topics were 3D modelling and shaders/VFX so I chose to create a model of a fireplace and then make a fire effect to burn inside it.

Creating a full blown 3D model from scratch using a traditional workflow is something too complex to be done from scratch within a time span of a single stream session, let alone along with the VFX. In order to make the show more digestible I decided to split it into two separate sessions.

My friend Jakub was kind enough to lend me some professional lighting equipment and a camera and after a failed foul start caused by some hardware and connection problems I've managed to get my first stream going.



The goal of this first session which took place on 4th January was just to create the 3D model, without the fire effect. As I said, the traditional workflow would still prove too long for such a prop to be done over ~3 hours (especially that my 3D modelling skills are very rusty these days). This is why I've chosen to model a fireplace in the first place as it wouldn't require me to go through all the usual steps - it's an unusual prop. Typically when you create a 3D model for a game, you need to go through the following stages (as I've described thoroughly in Dev Diary #3):

• Draft / block-out (making sure the dimensions and the general form are good)
  
• High-poly (modelling a high fidelity version of the model with tons of geometry)
  
• Low-poly (modelling an optimised, simplified version of the model that will be used in the game)
  
• Baking (transferring all the detail from the high-poly to the low-poly through special textures containing all sorts of information on the form, enabling the low-poly version to imitate the high-poly one)
  
• Textures (creating textures by utilising the baked maps in a texturing software)
  
• Implementation (exporting the final version in a way compatible with the game engine's pipeline and setting everything up in the engine)

However, in the case of this model only 3 stages were required:

• Draft / block-out
  
• Low-poly
  
• Implementation

Why was that? That was because this fireplace was about to become part of a modular wall set that uses a workflow called trim sheets. In short, this technique is great for creating models that share common features and mostly utilise tiling patterns such as bricks or repeating reliefs. It enables you to go through the full high-poly modelling and texture map baking workflow only once in the beginning, creating a special texture set known as a trim sheet. Once you have the trim sheet, you can very effortlessly add more and more props that use it. Moreover, once you have many props using a trim sheet you can also create additional trim sheets using the same conventions you used when distributing patterns across the original trim sheet. This way you can easily create additional sets of props that share geometry but still look quite different - a more advanced version of so called "re-colours" if you will.

Both the trim sheet and the wall pieces that use it were originally created by my former colleague Aleksander and then finished/remastered by me.



Although I'm happy about how the model turned out, it still needs some tweaks as much of it isn't finished from a technical standpoint and it may need some additional details here and there. I intend to either finalise it before streaming the fire VFX creation or do it live alongside it - time will tell.

The next session is planned to take place on the upcoming Friday (20th January) at 7:00 PM CET over at the Twitch channel. Although it is unlikely for the date to change, I will send a notice via our Discord server in case it does. Join it if you don't want to miss the broadcast.

One of the most important things I've worked on recently was the dialogue system (which I made with the help of a framework called Dialogue System for Unity) and the disposition system. I have the basic setup ready and will soon bring it to a usable state so that I can implement a first friendly NPC and give existing hostile characters more character. That's right - hostile characters can be talked to on some occasions as well. Everything depends on their disposition towards you. Technically there's no distinction between enemies and friendly NPCs aside from the difference in disposition which you can influence.


Everything on the screenshot is work in progress!

I made the statue my debugging friend because it doesn't move much and doesn't attempt to kill me. However.. that doesn't necessarily cross out the possibility that you will be able to "converse" with it in the final version of the game.

For now, I placed the dialogue interface on the side because the traditional cRPG placement in the bottom has some serious downsides - not only it heavily limits the space on the screen but also partly conflicts with the existing UI in Selenwald. Besides, I've finally found some time to play Disco Elysium (which, by the way, also used that framework I bought) two months ago and have seen how well that kind of layout works there so I'm going to leave it like this for the time being. However, that doesn't mean it won't change since there some other viable options I consider. As a matter of fact, a lot of the elements in the current UI (mostly in the character/inventory screen) are very likely to change in the future.

That being said, I'll likely talk more in-depth about the dialogue system and the disposition system in another Dev Diary entry once they are developed further. Also, I plan to have the disposition system tied to other systems in quite a unique and interesting way so I'll gladly tell you more in the future.

Take a deep breath since you're about to read about the most thrilling story so far. Have you ever walked around with a full bladder for several hours that felt like ages to finally be able give in to the blissful feeling of letting it loose? Such a mundane thing, yet what a feeling it is! And that's exactly what what I felt when I finally brought order to all of the Selenwald's source files (primarily of 3D art) a couple of days ago after not finding time to do this for a year and a half. It took me around 3 days but it was well worth it.

As boring as it may sound, I find it very exciting for a good reason and want to tell you what mistakes I made along the way and what are some good practices related to storing source files (and working with people who send them to you in the first place).

So the trouble started as soon as I started to regularly hire freelancers in 2021. Most people are terrible at keeping their files neat so if you don't explicitly tell them how to name files, how to organise data between files and which files to send you for feedback, you're going to end up with a terrible mess of files that don't make sense and there's clearly too many of them but even their authors no longer remembered which files are good and which aren't so they sent you all of them for you to figure out yourself.

Accepting and keeping files like this kind of works at first when it's fresh and are in the loop. That's the trap because you're likely to leave it like this because you currently know what is what. And it will cause pain a couple months later when you need to find something among these files. It gets even worse if you leave the received files scattered across many locations - some in the Downloads folder, because hey, files have their "Created Date" and "Modified Date" so you don't really need to categorise anything. Files will be easy to scrub through if needed, right? Wrong! With tons of .zips and folders named like drive-download-20230118T194202Z-001 you won't even know what's inside, let alone decide what's actually the recent version. Especially that the "Modified Date" can get easily changed on many occasions without your intention and will also be changed by the source control system once the files are stored. You just can't rely on those. On top of that, people are likely to send you stuff in different pieces. For example, maybe they sent a folder of the final files but it turned out they forgot something so then they sent only what was missing. And you end up with 2 packages which both contain final files (and possibly some duplicates which makes things more confusing).

Things get even more messy when you're out of space and need to keep things on external storage devices. For me not only this happened but my primary monitor has died in January 2022 (and I was so broke at that time I couldn't afford a new one nor having the old one fixed) so I had to abruptly move my workstation to my laptop so I can have 2 screens again (it's impossible to work in gamedev with less than 2 monitors, trust me). So now some of the source files were on my stationary PC, some on my laptop, some on my portable SSD, some on my Google Drive and some on the cloud repository where the game project resides. If this doesn't sound like a nightmare I don't know what does!

And the thing that was making me anxious all the time was that many source files were not stored online. I was constantly worried that in a case of a tragedy such as my apartment going down in flames with both my computers inside, I'd permanently lose some some important source files. The project itself is - of course - hosted in a version control system since the very beginning. I used GitHub in the early stages of the development and later moved to Plastic SCM. But I was reluctant to put the source files there as well. And was was that?

Even neatly organised source files for a single 3D prop can weight like 2-3 GB which is more than the actual project files of the game are going to weight for a solid chunk of the development time. Now if your files are a mess, then they can easily weight several times more. For example, the source files I had for the game's UI weighted over 50 GB because they contained several packages I received from the artist and I didn't organise them while it was still an easy thing to do. Just dumping so many files into the source control sounded like madness to me as it would cost a lot of money to keep so much stuff up in the cloud so I only stored them locally. However, later on I realised that keeping source files in the source control system - just like the project itself - is the correct solution but I still needed to manually go through all the files and open them up one by one to make sure which are good and which aren't. That was the price of not enforcing order since the very beginning. Anyway, I knew doing the work now would enable me to compose a package of a manageable size and avoid worrying about bills eating me up.

Now that I've done it, my repositories containing both the project files and the newly uploaded and ordered source files weights over 75 GB which isn't bad. Everything is now relatively easy to find. And the stress is gone. What a relief!

So what are my takeaways from the source files adventure?

• Rigorously enforce naming conventions that have the date included. You can't trust the dates assigned automatically. I was actually taught to do this when worked for CView Studios / 4A Games several years ago but somehow forgot to introduce this in my own project. The convention I am likely going to use from now on is:
  [AssetName]_[FileType]_[YYYY]-[MM]-[DD]_[OptionalID]
  So for example:
  CutStoneFireplace_LowPoly_2023-01-18_2.fbx
  This would mean that this is the 2nd version of the low poly model of the fireplace received today. Also, the proposed date format is important here because this order will make it work with alphabetical ordering making things sorted chronologically.
  
• Instruct people on how to best organise the data so that you don't end up with different elements of the same thing scattered across many files.
  
• Immediately place all received files in one place. The best place would be the the target folder in the repository workspace, ready to be pushed to the server once you receive all the final ones and delete clearly useless old versions.
  
• Absolutely use a version control system for source files, just like you use it for the game project files. Just remember to have a separate repository for it so that the game's repository stays lightweight. Alternatively you can use a service like OneDrive, Dropbox or Google Drive but I think proper version control like Plastic SCM is just better for this and you don't have to pay for 2 similar services at the same time.

I hope you learn from my mistakes and save yourself some trouble by having everything both well organised and safe in the repository from the very beginning!

Thanks for reading,
Wiktor