Knights of Frontier Valley News

[h3]Venerable Knights,[/h3][p][/p][p]When riding through Frontier Valley in search for adventure and glory, you travel across a dynamic world that goes through constant change. You will see the sun setting in the distance, trees swaying in the wind, and snowflakes painting the land white. When moving around, your path will be set up automatically to lead around obstacles in an efficient way.[/p][p]Those features, and many more, are driven by the custom engine developed for Knights of Frontier Valley. To stay with above examples: the time when the sun should be setting is managed by the "Time Manager", a component that controls and keeps track of game time and ambient light. Precipitation and trees swaying in the wind rely on the "Weather Manager", and snowflakes are drawn by the map renderer using particle effects. Characters moving across the map use the custom Pathfinder algorithm.[/p][p]If you are interested in how some of those things work and why I chose to write my own engine in the first place, you came to the right place!
[/p][p]There is also a video where I talk about the engine:[dynamiclink][/dynamiclink][/p][p][/p][p]Tthe sun sets in the Valley[/p][p][/p][h3]Motivation[/h3][p][/p][p]Let's start with the "Why". Creating a game engine from scratch for a game like this is a massive project. Engine features include rendering an isometric view (2.5D), sophisticated memory management, procedural generation of different types of maps, complex character behavior and interactions, persistence (save/load), both realtime and turn-based mechanics, custom pathfinding, and much more. You can expect work in the order of years.[/p][p]Since there are mature game engines out there to choose from, some available for free, why would anyone go through such an effort? It is about the goals you are trying to accomplish.[/p][p][/p][p]When I started working on the game in 2016 my role models were early industry pioneers like Richard Garriott, Sid Meier, and Peter Molyneux who made their first games in the golden age of RPGs in the '80s and '90s. They didn't use third-party engines back then, and as I saw it, walking in their footsteps meant learning how to make a game from the ground up. Building my game on top of someone else's code base that I didn't fully understand and couldn't fully adjust to realize my vision was not something I was interested in. Also, I thought it would be fun (most of the time, it is).[/p][p]While Knights of Frontier Valley was my first game, I looked back on a Software Engineering career spanning two decades, working on software for desktop, web, embedded systems, and mobile devices. Some of my past projects in Silicon Valley included GPS software, early iPhones and the original iPad, and the Infotainment and Autopilot systems in Tesla cars.[/p][p]So there was a programming background, but developing games is a very distinct field and I had a lot to learn. I had a busy day job when I started the game, so any work on it could only happen evenings and weekends. After about three months, I had a prototype of a basic game loop where a character could walk across a map and do some simple interactions. While this prototype worked, I realized that the current approach would never produce a game with interesting visuals. The technologies I had used just were not meant for making games, so I threw everything away and started over - this time utilizing libGDX, an open-source Java framework that simplifies OpenGL rendering and some other gaming-related functions. I chose Java as the language and OpenGL for rendering as those technologies had been used in other successful games, including Minecraft and RuneScape, and I was familiar with the language.[/p][p]Now I was on the right path, and over the following years, the game and its engine would continue to grow.[/p][p][/p][p][/p][p]The world map: early prototype vs today[/p][p][/p][p]Making the engine from scratch took around five years of part-time work, and if someone was to ask me whether they should do it for their own game, I would say this: it is not for everyone. I would not recommend it to someone new to programming. But even for experienced developers, the advantages of full code-control, ease of mind regarding possible royalties, added learning effects, and the great feeling of accomplishment must be weighed against years of work without income and a good amount of frustration. If you do not know whether you should do it, you probably should not. The will to finish what you started has to be strong, young Padawan, or else you risk putting a lot of time into something that you might eventually abandon.[/p][p][/p][h3]Engine basics[/h3][p][/p][p]But what exactly is the "game engine"? You might get different answers depending on who you ask, but in my case, I consider the engine to be all parts of the software that do not deal with the logic or appearance of a specific game. It is core functionality, separated out, so it can be used for other games as well, if they are of the same type.[/p][p]Two things about software design: first, to make code readable, maintainable, and reuseable, functionality should be encapsulated. That means that separate parts of the code base should not contain logic for different features. And second, behavior and visualization should always be separate. [/p][p]Following those two principles, my custom engine was designed to consist of several modules, each handling a particular game functionality. At runtime, those modules are used as needed, controlled by one core component that holds it all together: the main game loop. [/p][p]The main loop is a function that runs many times per second. Each run, the entire game world gets updated and a frame is rendered that shows the world in its most up-to-date form on the screen. Ideally, the main loop runs at least 60 times per second (= 60 FPS) - this number has to do with legacy monitor hardware, which was refreshing up to 60 times per second (= 60 Hertz). Today the number is often higher, usually 144 Hz.[/p][p]If your system isn't powerful enough to produce 60 FPS (the bottleneck is usually the GPU), you might notice lags and choppy animations. But with Knights of Frontier Valley, you don't have to worry about your video card: graphics are mostly pre-rendered, so the GPU can basically take a vacation while the game is running. On my old laptop I do not see any lag even when the game is running on integrated graphics.[/p][p][/p][p]All parts of my engine include:[/p]

• [p]Main loop[/p]
• [p]State machine[/p]
• [p]Memory Management[/p]
• [p]Persistence Handler[/p]
• [p]Renderers for the map and entities[/p]
• [p]Video playback system[/p]
• [p]Sound output[/p]
• [p]Mouse/keyboard Input handling[/p]
• [p]Networking features[/p]
• [p]Game time management[/p]
• [p]Pathfinding[/p]
• [p]Map Models[/p]
• [p]Weather Model[/p]
• [p]Character Model and character action queues[/p]
• [p]Character Travel Module[/p]

[p][/p][p]Not part of the engine are:[/p]

• [p]Anything story related and quests[/p]
• [p]Graphical assets, music, and sfx[/p]
• [p]The UI[/p]
• [p]Procedural map builder logic[/p]
• [p]Game-specific characters, objects, and items[/p]
• [p]NPC behavior[/p]
• [p]Anything game-specific including character creation, combat workflow, special effects (like magic), custom shaders, mini-games, and much more[/p]

[p]I'll go into more detail on two of the engine modules: the character model (and the related action queues), and the component that controls traveling NPCs, the character travel module. If you'd like to know more, there are also dev logs about pathfinding and rendering on the game's website.[/p][p][/p][h3]Character Model and Action Queues[/h3][p][/p][p]The character model is a software container that holds all characters that currently might need to act - those characters must be loaded in memory to update their behavior. It includes all those that are on the same map as the PC, as well as some others that might need to act for other reasons: faction leaders, traveling characters (more on that later), and important quest characters. When the PC is in a city, the character model contains hundreds of NPCs - many of them in buildings, others walking around outside.[/p][p]The game world is populated with many more characters than those that are in the character model at any given time, but since most of them are on different maps (= not visible to the player) and do not have any reason why they might need to act, there is no point in keeping them in memory and wasting CPU cycles on keeping them updated. Those "dormant" characters are stored in the database and will be loaded into the character model when the need arises.[/p][p]When the PC moves to a different map, the character model decides which characters need to be added to it (and which ones can be kicked out), and then performs the necessary steps. Newly added characters then go through a function where their last stored state gets evaluated - if their position and activity is no longer fitting to their current behavior cycle (work, sleep, leisure, etc), they will be teleported to the right spot on the map and start an appropriate activity.[/p][p]Internally, the character model does not keep track of individual characters but of "character groups". Every character, even when acting all alone (including the PC), is always part of a group, possibly with only one member. If there are several group members, they always remain on the same map and move in formation, following a designated group leader. If a group member dies, his corpse is moved to a new single-member group. If the group leader dies, a new one is determined, going by power and rank.[/p][p]When group characters need to be able to act individually (= not move in formation), such as during tactical combat, the group temporarily splits up, and each character gets their own single-member group. After combat ends, surviving NPCs re-join their old groups or form new ones.[/p][p][/p][p]Listing the characters on the current city map that are outside buildings in developer mode[/p][p][/p][p]Now that you know which characters are kept in the model and are able to act, let's take a look at what "acting" means in the context of the engine.[/p][p]Each character has an "action queue", which is a list of actions the character will execute in order. Such actions include things like "move along a path", "interact with an object", "talk", "attack", "play music", "read from a scroll", etc, or even just "wait".[/p][p]When a character isn't already busy performing an action, the topmost one is taken off the queue and gets started. Only if the queue is empty, the character is truly idle.[/p][p]The queue might contain many actions, and some of them could split into several new ones when their execution starts. It is a complex system where every possible character action needs to be pre-defined and clear about when it is completed. There are currently 36 different types of actions, some representing sets of several sub-actions. One action is called "custom action" and can basically do anything, so there literally are no limits to what characters can do in the game.[/p][p]If something unforeseeable happens while an NPC is working off their queue (like the PC attacking them), the queue gets cleared and the behavior is re-evaluated, spawning new actions on the queue in response.[/p][p]When the game is saved, action queues also get saved and will be restored upon loading, so all characters continue right where they left off.[/p][p][/p][p]A character's action queue can be printed on the screen in developer mode. In this example, the PC will walk towards the noblewoman, then turn towards her, then stop his walking motion, and finally interact with her using interaction type "Communicate"[/p][p][/p][h3]Character Travel Module[/h3][p][/p][p]NPCs in the character model may travel from any point in the world to any other point in realtime at any moment, even across maps that are currently not loaded in memory. The engine's "character travel module" will reliably determine all actions needed for the trip and put them on the group leader's action queue. If, for example, a character was to travel from the attic of his house to the cellar of another house in a different city, the following actions would need to be taken:[/p]

• [p]Start the appropriate move animation (walk, run, or fly...in other scenarios maybe also ride or swim)[/p]
• [p]Walk towards the stairs leading down[/p]
• [p]Take the stairs from level to level until arriving at the building's entrance level[/p]
• [p]Walk to the entrance door[/p]
• [p]Interact with the door to exit the building[/p]
• [p]Walk to a point where the town can be exited[/p]
• [p]Exit the town[/p]
• [p]Walk across the world to the destination city's entrance[/p]
• [p]Enter the city[/p]
• [p]From the entrance, go through city quarters as needed to get to the one with the destination house[/p]
• [p]Go to the entrance of the house[/p]
• [p]Interact with the door to enter the building[/p]
• [p]Take the stairs down until arriving at the destination cellar level[/p]
• [p]Go to the destination position in the cellar[/p]

[p]Those actions will be executed one by one, but pre-calculating the full list of required actions before the trip is not optimal. Something unexpected could happen along the way which might force the character to re-evaluate their behavior: a critical door could be locked, or the character could just get too tired to proceed. And of course, traveling between towns is not without danger in the Valley. The character really doesn't know what will happen on the trip, so the engine only calculates one step at a time from above list. When arriving at a waypoint, the situation gets re-assessed (taking the character's new environment into account) before calculating the next step on the trip, if nothing else of higher priority turns up.[/p][p]Making the decision on how to proceed at each waypoint rather than in advance makes the system very robust and avoids calculating actions that might have to be discarded. It also spreads out the computational effort, which is a good thing when many characters travel at the same time.[/p][p]Traveling characters remain in the character model even if they leave the PC's map, so they can continue acting until they arrive at their final destination. Now, while the character is on the PC's map, any obstacle on the path is in memory and known, and can be routed around using the Pathfinder component. But if the character has left to a different map, how does the system know how to route around obstacles there, and determine how long it will take, if that map is not in memory?[/p][p]I solved this problem by adding the concept of "off-map routing", a system that uses average travel times when moving a certain distance across different types of maps. I determined those average travel times by doing a large number of routes on each type of map. That means that when an NPC leaves the PC's map and disappears from view, and then the PC follows him a bit later, the player will find the NPC just at the right spot where he should be at that time.[/p][p]It is an approximation, not a real caclulation, and it is a bit of "faking" this part of the trip. But it works pretty well and players will never know that parts of the route were fake, MUHAHAHAHA. Ok, well, YOU do know it now - consider it your reward for reading all the way to the end. Your attention span is admirable and you probably have what it takes to write your own game engine.[/p][p][/p][p]Until next time,[/p][p]Martin[/p][p][/p]

Honorable Knights,

Let's talk about maps today. Maps are fascinating. They can be decorative and inspirational, making us dream of faraway places and the spots that haven't been explored. There may be tigers here.

But before diving into the topic of how maps are made in Knights of Frontier Valley, I'd like to share how the Alpha 3.fun release is going which went out to testers a week ago.

The amount of feedback is absolutely fantastic. I am reading all of it and try to address issues quickly, and it is amazing how much the game has improved in just in a few days. First, of course, there were bug fixes. The game seemed stable before the release, but players have a knack for finding weaknesses in the code right away. Many of them were reported by Alpha tester Eric Hensel - I appreciate his contribution.
64 bugs have been addressed since the release, with a few more on my radar. If anyone is interested in the detailed change list:
https://steamcommunity.com/app/1085830/discussions/0/601897333646473798/?ctp=6

Then there were balancing and QoL improvements. Some opponents are now easier to beat, and the effects of bleeding have been further reduced, to name two examples.
The code now supports displays with an aspect ratio other than 16:9, which seem to be more common than I thought (or the Steam hardware survey would suggest).
There is a new indicator when moving between city quarter maps now, better showing where you are going. Many more things are on my list, mostly about making it clearer just how some of the unique features that you won't find in other games work.

This simple overview makes navigating between city quarters much clearer

But what really blew my mind is that Alpha tester ChavaiotH managed to make the game run smoothly on a Mac, in this case on Apple silicon. We have our first modder! To me it's amazing since the game code includes native libraries compiled for Windows, but it is great. Maybe we are closer to a Mac version than expected. ChavaiotH is also a Patron and I am very grateful for the support.

Testing will continue for another week; then, after a short break, I will jump right into moving towards the next milestone: the public demo. Work on the demo really has already started on the side over the last few days; I designed the story for the demo quest, and new graphics are in the works.

Now on to Maps!



in Knights of Frontier Valley, maps for the world, the towns, dungeons, buildings, and the wilderness all have their own map generator logic and are created differently, so I will talk briefly about each of them.

[h3]World map[/h3]

The world in KoFV is quite large - I once calculated it to be around 138.000 square kilometers big, roughly the size of the country of Greece. If you were to travel across it at a normal walking pace, or even on horseback, it would take a long time.
No one enjoys walking for days to get from one place to another in a game, so time passes much quicker on the world map, and large distances can be covered fast. Since the world map's sole purpose is to get around easier, I often refer to it as the "travel map".
The design intend was to make it so that players could get lost in the wilderness, so you still need to spend some time traveling between places, and you can lose your way if you stray off the roads.

Visuals are abstract on the travel map. It shows grasslands, forests, hills, mountains, cities, dungeons and other points of interest, but intentionally not in very high detail.
You can encounter and talk to other characters there, but real exploration or complex interactions, like combat, happens on any of the detailed local maps desribed below.
The travel map is also the only map that is internally built on hexes - all local maps use squares. This design decision was made with "The Isle of Dread" in mind, one of my favorite D&D tabletop modules.

You can see further from hilltops on the travel map

The world map is procedurally generated, making it look differently in each new game. But what does "procedurally" really mean? First off, it does not mean "random". A map that is completely random will be hit or miss... sometimes, if you are lucky, things might make sense, but in many cases they will not.
"Procedural" means the map is auto-generated, but rather than just randomly placing stuff, the world-builder code follows a set of rules to ensure the map will always make sense. Those include:

Terrain selection:
There are various algorithms to fill a world with areas of different terrain. The one I am using, known as "Cellular Automata", can quickly generate maps with a natural and diverse terrain distribution. Cellular Automata starts by adding "seeds" for hills, mountains, lakes, forests, and other terrain features all over the map. Those seeds then "grow" in a natural manner in different directions, following a specification that dictates things like a forest's maximum size.
The algorithm is very easy to implement and the results look good, but its simplicity also has a drawback: it produces a terrain layout that looks similar all across the world. Unless adding additional logic, there will not be any areas that are particularly forested (or without forests), for example. There will not be any oceans or large mountain ranges that divide areas of the map. It looks good, but is a bit repetitive.
Other terrain algorithms work differently. The Simplex algorithm, for example, does not place forests or lakes on the map. Instead, it generates natural elevation patterns which can then be used to fill the world with fitting terrain features. Water tends to flow downhill, so it would be placed in areas of lower elevation, while forests need water to thrive and will not appear above a certain altitude. Switching to Simplex for more natural-looking world maps is something I have on my to-do list for a later update.

POIs (points of interest):
Points of interest include settlements, dungeons, countryside inns, farms, windmills, and much more. In KoFV, the world builder is making sure settlements are not too close and not too far apart either, and they can be connected with roads (and are not accidentally surrounded by unsurmountable mountains, for example). Dungeons should not be too close to cities, and dwellings of warring factions should have some distance between them. There are many more rules like this.

Pathways (roads and rivers):
Roads should lead around lakes, hills, and mountains and should preferrably not go through dense forests if it can be avoided. This makes roads behave just like a normal character path, which also does those same things. Hence, for placing roads between towns, I am using the same code that also calculates a character's path.
Rivers work slightly differently, as they do not have a specific end point. Where roads and rivers cross, bridges might be placed.

NPCs:
Roaming NPCs on the world map are not placed by the world builder, but their presence is continuously managed by a "wilderness behavior pattern". This behavior pattern is just one of many I developed to control NPC behavior in certain areas or for certain NPC roles. There are patterns for controlling NPC buyers and sellers at the town market, for example. There is one for the town watch, for guard patrols, and for the guards standing in front of the city gate or on top of towers. More behavior patterns are planned for the tavern (controlling the behavior of staff and patrons), residential houses, and more. With more behavior patterns being added to the game, the overall NPC behavior will become increasingly complex, but it is modular and easily controllable.

[h3]Dungeons[/h3]

Dungeon maps are also procedurally generated, but in a very different way. The map maker produces a layout based on the purpose of dungeon rooms, including strorage rooms, cells, underground forges, and many more. Those rooms are connected via hallways in the most efficient manner. While the layout and the contents of a dungeon will look differently in each new game, rooms will always be laid out in a way that those that should be close to each other will indeed be close. There is also a concept of "public" and "private" dungeon areas... one example of a private room would be a treasure room with a locked door, so wandering NPCs cannot help themselves and loot the place before the player gets there.
There are various kinds of dungeons, and they all look differerently and are built using custom code. Natural caves are assembled in a different manner than goblin caves or human underground prisons.


Yes, I know. Undead skeletons should not suffer from tissue damage. It's fixed now.

[h3]Buildings[/h3]

I found that maps of buildings that are created in a fully procedural manner just do not look right. Buildings are very complex, and we all have developed an instinct of spotting something that looks odd here right away. There are walls, doors, windows, stairs, chimneys, furniture, decorative items and more, and trying to place those automatically in a way that looks natural and liveable will require complex generative AI and custom machine learning. Not only would such a project exceed the scope of this game (remember, this is a one-man show), but I also decided a long time ago not to use any generative AI in KoFV whatsoever.

My goal was to present the player building maps with such a large variety that it would appear to be endless. Players are able to enter every building in the game, and they should not feel like they have seen the same room layout and furniture setup elsewhere. But while there should be an endless amount of varieties, those maps should also be human-made to make sure everything is placed logically. How could those conflicting goals be reconciled?

I did the following: using a building map editor I made for this purpose, I created a number of base layouts for every different type of building and each potential orientation it might be placed in the world, and then added procedural logic to make the material of the walls and floors variable. Additionally, the types of furniture you would find in the house, and the container contents, are also variable. So a table would always be at the same spot in houses using the same base layout, but it would stand in a room that might have different walls or floors, and it could be a different type of table and have different things on it. There are more than 160 different base layouts (it took weeks to design them), and together with the procedural variations, now every house in the world looks differently inside.

There are a few buildings in KoFV that are unique and have no procedural variation at all, and those are the taverns. Taverns are the "home bases" in fantasy RPGs, and I wanted the player to feel at home here - a feeling that never really comes up when the map looks differently in each game.

Villas like this are great places for finding loot, if you see the law as just a recommendation

[h3]Cities[/h3]

City maps are the only ones that are not procedurally generated in KoFV. I started with an attempt to also auto-generate those, but quickly found that it is no fun having to look for the general store in every new game. Additionally, medieval towns often had a similar layout (market near the center, stores placed around it, cemetery outside, loud and smelly businesses like smiths or tanners in a separate quarter, and so on). When creating town maps procedurally using that logic, the result would often look quite similar, which defeats the purpose of having procedural maps in the first place.
So I stopped doing it and created all city maps by hand. I made a different map editor for it, and it's fun to use!

Thyle West, known as "The Patch", is not exactly a prime real estate area and should be avoided at night

[h3]Wilderness[/h3]

When combat starts on the world map, the view switches to a local wilderness map where trees, bushes, rocks, and every blade of grass is shown. But the player actually can decide to switch to that view at any time outside combat, too, which can be useful when looking for food like berries or mushrooms, rare plants, firewood, or other useful items nature provides.
Local wilderness maps are procedurally generated, but once objects like trees or bushes on that area are determined, they will always remain there (well, mostly).
Those maps also go by the terrain type found on the travel map, so if you switch to the local map while at the edge of a forest with a mountain nearby, those same terrain features will accurately be placed on the local map at the right spots.

You will be fine, they said. Just stay close to the road, they said. But where did the damned road go?!?

Now you learned everything there is to know about maps in Knights of Frontier Valley! If there are any questions, let me know in the comments.

Until next time,
Martin

Today I have some more info about the upcoming release "Alpha 3.fun". The plan is that this will be the last closed release, followed by a free demo available to everyone.
After the demo, I will start the "Beta" branch as the game moves forward towards the public release. It is not yet decided if there will be an Early Access... it depends on the feedback from the demo.

The February update already went into detail about Alpha 3.fun, but today I have some new info, including a release date. But first things first. Here's what I have been working on recently:

• The main character's first set of voice output is now in the game, including matching portrait lip animations. I already have a lot more recordings from the hero's voice actor Alan, so this feature will continue to grow over time.
  
  Read my lips! What do you think he is saying? Leave a comment below!
  
  
• New items have been added. Adding items can sometimes be a quick and easy thing, but for equippable items, new animations are needed which is always time-intensive work. The new items I find most interesting are the polearms:
  
• Some previously locked locations are now accessible, including the windmill, farm, and the logging camp. A few other wilderness sites have also been added and can be found on the procedurally generated world map.
  
  The logging camp is not yet populated, but will be soon
  
  
• Several quality-of-life improvements were made. This includes things like being able to eat food items directly from a loot container now, without having to transfer them to your inventory first. Volume controls have finally been added, too.
  
  
• Story mode chapter 2 quest is well underway. This is the most complex quest in the game so far, as it should be for a main quest! Creating it requires work other than creating the actual quest - aside from new characters, items, and places that are being added, the custom engine also needs extensions to support certain quest features. Completing this quest is the main focus right now.
  

Creating any quest is currently a lot of manual labor, so I am considering making a Quest Editor after this version (and, like the Map Editor, make it available for modding at one point). Interesting quests always include custom behavior, so it will likely require programming skills to make quests that are more complex than simple FedEx deliveries.
I imagine it could be interesting to some which modding/workshop features are planned, so I will dedicate a future update to this topic.

Notable internal changes:

• The video playback engine has been replaced. I had been using the VLC video player for cutscenes so far, but it caused issues. The new one is open-source and custom-made for the libGDX framework I am using. It did away with all the issues I had, and it is also faster and has a smaller file footprint than VLC. The VLC player is generally a very powerful player, it just was not quite the right fit for this game.
  
  
• I spent some time bringing the Mac version up to speed, but there is more work needed. It fully runs, but only at a frame rate of 1 FPS regardless of the Mac's power. I suspect it has something to do with OpenGL (which is deprecated on MacOS), but it requires more time to investigate. This will have to wait until later.
  
  
• Lots of bugfixes! MicroProse organized a week of professional testing by an experienced QA team, and it was very productive. I think we have a pretty stable game now! It is still Alpha, so there are some bugs, but nothing game-breaking.
  

Now regarding the release date for Alpha 3.fun: I am targeting Monday, May 26. Some of you have asked about becoming a tester... you will hear back from me before that date, if you haven't already.

Rob's Note:
As you know, I am working with D&D design legend Robert J. Kuntz, and when Rob saw the new polearms, he was reminded of the interest Gary Gygax, co-founder of Dungeons & Dragons (*) and Rob's mentor, had in such weapons:
"Gary was a huge fan and student of Medievalism, especially those battles described by the military historian C. W. C. Oman in his seminal work 'The History of the Art of War in the Middle Ages (Volumes 1 & 2)'. From there his research centered around his 11th edition Britannica articles, the last scholarly encyclopedia of its kind, with a focus on the arms and armor of that time period. The result was to finally form the Castle & Crusades Society to promote Medieval articles and miniatures games. He was also a fan of Japanese arms and armor.”



Until next time,
Martin

(*) "Dungeons & Dragons" and above image are trademark owned by Wizards of the Coast and are used here for historical purposes only.

Honorable Knights,

We are thrilled to announce a publishing partnership with the legendary publisher MicroProse!
Watch our new trailer:

[previewyoutube][/previewyoutube]

This partnership will help the game in many ways, the first of which is the involvement of someone significant for role players worldwide...

In fact... In a major development for the RPG community, tabletop gaming legend Rob Kuntz — one of the founding pioneers of Dungeons & Dragons — joins the project to bring his unparalleled experience and creative vision to the game.

[previewyoutube][/previewyoutube]

Rob’s influence on tabletop fantasy gaming is immeasurable.
This extraordinary collaboration marks a rare moment where the origins of fantasy role-playing meet the cutting edge of indie game development. As a close friend and collaborator of Gary Gygax, Kuntz co-created the iconic Greyhawk setting, penned some of the earliest D&D modules, and helped lay the foundation for modern RPG storytelling.

Follow us on our official channels and join our community discussions to share your thoughts and experiences. Your support and enthusiasm fuel our passion, and we are deeply grateful to each of you.

Together, let's venture into the unknown and forge legends anew!

Thank you for being an essential part of this adventure.

[h3]Honorable Knights,[/h3]

Today I have an update for you on the progress of the upcoming version "Alpha 3.fun". If you've been following, you might remember that this version was named after its purpose, which is to make the game even more fun.
To recap: while version Alpha 1 was a demo of the homebrew engine, Alpha 2 was a demo of the gameplay, though still very limited.
Alpha 3 then extended the gameplay significantly, but many things were still missing. Up to then, it was mostly about making the game "run"; now it is about making it "fun".
Although "3.fun" still has the previous version's number in its name, it is the biggest update yet and it is well on track to accomplish its goal.
We are about halfway through the dev cycle, the scope is now finalized, and I'm ready to share it. So - what's in there?

[h3]1) Character progression[/h3]

Making your character grow and improve is a core feature of any RPG. In the previous version, you were able to choose and customize your character, but there was no way to gain skills or level up during the game. No longer so! Character progression is now implemented, full blast.
At the beginning of the game, you will choose your character class from three possible options, setting your general approach to life challenges - will you, for the most part, take advantage of your physical strength, nimbleness and skills, or your wits?
When, after some playtime, certain requirements are met, you will be able to choose a profession - each of the three character classes will offer three different options here (so nine in total). But we're just getting started - you will also be able to further specialize in one of three "profession branches", which are unique to the each profession. In total, this means you will be able to choose from 27 different roles in the game, and they all come with individual advantages, titles, and unique perks! There will also be different quests tailored to each of them.

Perks are new, too. There are some basic personality characteristics that can only be selected at the beginning of the game, but most perks can be earned later on when their requirements are met, which for some might contain holding a certain profession or branch.

The Character Growth Tree: trunks are professions, branches specializations, and leaves represent perks


The character creation process has also been improved in many ways. Based on the character class you choose, you will now start with some experience in relevant skills. Most characters will be able to ride normal horses from the beginning, and everyone will be able to swim. In fact, the "swimming" skill has been removed altogether, but you will still be able to get better at it through a swimming-related perk.
The removal of swimming is not the only change to skills - several of them have been changed for more fun and balance.

Since we're talking about characters, there have been numerous other improvements which are not related to progression. As an example, the logic to determine relations between characters and whether they know each other has been overhauled. NPC behavior has also gone through some improvements, while further improvements will be the focus of the release after this one.

[h3]2) Story mode[/h3]

Alpha 3 was mostly a sandbox game - there were a few isolated quests, but no main story. That's no longer the case. Story mode has been added to the game, which means it is now (finally!) broken down into chapters. Each chapter represents one season (= three months) and comes with a main quest. If you manage to solve that quest quickly, you can choose to fast-forward the remaining chapter time. This is useful if all side-quests have already been solved, or if you just want to move on. Alternatively, you can play out the rest of the season and keep side-questing or explore the world free-style.
When the chapter ends, you will be rewarded for actions during the season and might level up.
Alpha 3.fun will contain the first three chapters of the game, which cover summer, fall, and winter of year one of your adventure. For the first time, players will be able to enjoy all seasonal visuals - they have been part of the game all along, but until now, there was no way to experience them... so far it had always remained summer.

New quests have been added, too, and permadeath has now officially been made optional. The intended way of playing is still with permadeath enabled (I explained in the previous post why that's the case), but you will be able to choose a more relaxed mode at the beginning of the game which will allow you to reload after your character dies. This comes at a penalty though, to keep death meaningful - you should still have a good reason to keep your character alive.

[h3]3) Combat[/h3]

In the past, each new version came with improvements to tactical combat. This is true this time as well, but there's more than that. I added a brand-new "quick resolve" combat mode, which can be chosen in most cases. Tactical combat is fun, and if played smartly, can give you an edge over your opponents. But this is an RPG, and there will be plenty of battles to fight, including some against inferior enemies. Having to make every move in a battle where the winner is pretty much clear from the beginning can quickly turn into a chore. And remember what this version is all about!
Quick combat will play the combat out in an overview panel. It is a real battle that's going on there, just much faster, and you can adjust the speed if you are involved. The panel includes information on all participating combatants, the combined power of each side, and (if you are involved yourself), an overview of your injuries. If things get too spicy, you can intervene and choose to escape - but it's best not to wait too long, as your chances of getting away will lower with any sustained leg injury and when there are fewer combatants remaining on your side.
NPC groups will also fight against each other on the travel map, and you can watch their battle from a safe distance, or join in.

We're going to stay on that hill and grab some popcorn

Another notable improvement to combat is the change of the size of local wilderness maps. When you run into enemies outside town, tactical combat will start on a procedurally generated wilderness map. In the past, those have been fairly large, which meant there was quite a distance to cover before you got to your enemy. By reducing the size of those maps (which, at this stage in development, was a complex change affecting many parts of the code), the frustrating few first turns where everyone was just running towards each other are a thing of the past.

[h3]4) A new type of dungeon[/h3]

This part isn't done yet, but I am working hard to get it in. So far, there have been two types of dungeons in the game, but many more are still on the list to be added. All of them come with unique visuals and are in an advanced state, but they aren't quite ready for release yet.
A new dungeon also means new music and sound effects, new characters who inhabit it (including their portraits, animations, and behavior), and new items, so this isn't a small thing. I'll see that I get one of them in this time though.

[h3]5) New objects, items, and characters[/h3]

Alpha 3.fun introduces new map objects and usable items. You will now be able to light your way using lanterns and candles, for example, not just torches. There are also new types of armor and many other things. Cities now contain street signs to indicate which city quarter is adjacent to the current map. Also new is the concept of having to identify special items, which is not automatically happening anymore.

A number of new characters have been added too. I don't want to give everything away, but I can say the faction of the Undead has grown.

It's safe to assume that those guys are going to cause trouble

And finally, some long-missing animations have been added - children can now also go to sleep!

[h3]6) UI additions[/h3]

When something interesting happens, a small message about it might appear at the bottom of the screen. Those messages used to be a bit of a mess - depending on the map's background color, they were sometimes hard to read, and there was no way of going back to earlier messages. The feature was also a bit buggy, and messages sometimes overlapped. That's no longer the case now. Like in many other RPGs, those messages now live in a dedicated panel, which can be scrolled to show earlier messages.

Another interesting UI change is your satchel, aka the "quickslots". The satchel has always been available on the inventory screen, but until now, you weren't able to use items from it during combat, which really is its main purpose. Sifting through your backpack to use an item while a troll keeps hitting your head with a club is (and was) not an option during combat. Now though, you will be able to use items from your satchel, a small bag at your belt which is easy to get to. Just like before, the satchel will start with three slots, but now it can also be upgraded (the low number of slots, by the way, is fully intended. Tactical combat should be won by avoiding overpowering enemies and making smart moves - not by hauling around a huge number of healing potions).

Two of the new UI parts: message panel and quickslots

Many other UI changes were made, including a custom mouse cursor which changes its appearance based on the default interaction of the entity you are hovering.

[h3]7) Audio additions[/h3]

New music tracks and sound effects have been added, but the bigger audio change is something else. I don't think anyone really knew this, but the game includes a custom speech engine which allows the PC portrait to speak with realistic lip movements. I once posted a video about it, but it didn't get much attention. The speaking PC portrait was implemented years ago and it always worked, I just never got to really use it. It's a fun feature, and this is version "fun", so the time has finally come for it to be unlocked. Your character will now drop the occasional comment when something interesting happens, and in the future, he will have more and more to say.

[h3]8) Technical improvements[/h3]

Lots of internal improvements have been made. This is tech stuff not everyone is interested in, but I will highlight some of the more important changes:

• Automatic crash reporting: since no one enjoys clicking their way through folders to locate obscure error logs and send them by email, I added a new feature which will send crash reports automatically. This can further be improved over time, but it's already working and will provide me with essential troubleshooting info without asking players for more than an approval click.
  
• Seamless loading of animations: new characters appearing on the screen used to freeze up the game for a moment while animations were being loaded. This is no longer an issue - they are now being loaded bit by bit in the background between renders, and the new character will appear when everything is done.
  
• Map change performance: improvements to memory management and the processes of loading and saving the map have massively sped up the process of changing maps, making the game more fun without a doubt.
  
• 20 leftover bugs from Alpha 3 have also been fixed.
  

That's it for today. There has been a lot going on lately, especially around the partnership with D&D design legend Robert Kuntz, but there are more news to share soon - stay tuned!

Martin