Gameplay planning

First let’s have a look at some concept art. These are drafts of the world and the planned gameplay loop.

World

Concept art of the game world

The player will be progressing through multiple areas from the “Stranded Beach” to “The Volcano”. Each area is supposed to have distinct features and enemies and should require the player to prepare and adapt.

The Ninja Village is different from the other areas as it is the main hub where shops, quest givers, etc. are located. It will be a safe area.

Gameplay-loop

Concept art of the gameplay-loop

The planned gameplay-loop is a mix of fighting, exploring and upgrading the character. It repeats for every of the aforementioned regions.

Complex Dialogues & Lua missions

To enable this kind of complex gameplay there has been progress on complex dialogues and Lua missions.

Complex Dialogues

Dialogues can now be prepared in .json files. They can be interactive, meaning the player can choose different answer options and Lua scripts can be called at arbitrary points in the dialogue.

Example of a dialogue .json file	One path of the resulting dialogue

As you can see the dialogue changes depending on the player’s choices and, in this demo specifically, the time of day is modified by an internal Lua script at specific points in the dialogue.

Lua Missions

Lastly, missions can now also be defined in .json files. They are rather complex files containing various entry points for Lua scripts and will likely be a backbone of game-scripting and the environment reacting to the player’s actions and choices.

Example of a .json mission file

That’s it for this month

See you next time! 👋

Dungeons like this can now be shipped as a world preset!

This month has been all about technical improvements to the save system.

As is widely known the player’s progress data has to be stored in some way. Also, the player is able to interact with the environment and modify it. Therefore, the different worlds (i.e. the overworld or the dungeon) need to be written to the save file too. What lead to a problem so far was that save file data and loaded world data were strongly interconnected. Meaning it was not possible to have only a certain world loaded at a time, but instead all data from the save file had to be loaded and deserialized at once.

For the current pre-alpha.0.3 this was so far not an issue, as two worlds is still not a lot. Nonetheless, going forward and potentially having dozens of worlds in a save file, there needs to be a way to only deserialize part of it at any given time.

New save structure

The new save structure allows for single worlds to be deserialized on demand. While the entire file is parsed and loaded into RAM when a savegame is opened, only the necessary worlds will be deserialized and initialized as game world objects.

The structure loosely looks like this:

The new save file structure

As you can see the world data are neatly available in a list to be selected and deserialized into actual game objects when needed.

World presets & The preset editor

Another addition this month has been separate world presets. Up until now all world data was included in the single savegame that shipped with the game. It is now possible to include pre-made worlds in the games files. They can be loaded into a savegame on demand.

Here is a little glimpse of the new world preset editor:

The new preset editor

This editor allows for editing and easy management of world presets in the game’s data directory in order to create unique game environments (i.e. special dungeons or boss fight areas).

The world preset editor is available by pressing F2 in the main menu.

Thanks for reading!

See you next month!

Impressions from the game

The overworld	The dungeon

Try it now

Download: here (Windows 64-bit only)

Installation

Extract the zip to your PC and run sacb.exe.
If that causes errors, try installing the accompanying “Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019” (VC_redist.x64.exe)

AI Steering

The entities are now able to seek certain positions and pursuit entities (for example the player). These actions are performed using a logic called ‘Steering Behaviors’. These behaviors can be used to calculate movement from simple A → B navigation, to complex movement in a group. Currently, only the aforementioned simple behaviors are implemented.

A frog seeking a point in the world

A note on pathfinding

I spent a lot of time getting navmeshes and pathfinding to work. Its current state is API-complete and integrated in the game engine, but still contains a lot of bugs and crashes. Therefore, the implementation will probably need a rewrite that won’t make it into the next build.

Luckily, steering and pathfinding work mostly independent of each other and steering produces good results for simple worlds like the current one.

AI Behavior-Trees & Frog AI

Aside from navigation, the second key element to game AI is defining how entities behave and interact in certain situations. For this task the game engine now uses behavior trees. These trees are used to model complex AI behavior in games and robotics. Below are behavior trees for the frog AI from different stages of development.

An early sample of the frog behavior tree	A more recent example

Graphics & copyrighted assets

There has been progress on improving graphics and removing copyrighted assets. As mentioned in “What’s to come until August”, some assets need to be removed or redone before publishing a public build due to potential copyright issues. There has been some progress on that.

Updated Graphics

The shallow water, deep water and sand textures have been remade and added to the game. A lot of steps can still be taken to further improve graphics. Some smaller changes will be implemented in the course of August.

That’s it for this progress report

There has been a variety of smaller changes, fixes and balancing that would not fit in this list. From now on development will focus on preparing the game for the prealpha-0.3 release on August 28. Stay tuned people.

What is a navmesh?

A navmesh is a representation of the game world in which walkable areas are stored as polygons. Obstacles get cut out of the navmesh to ensure the AI does not try to move to regions where it could or should not walk.

A navmesh representation in the current implementation looks somewhat like this:

A navmesh

The different colored polygons are walkable areas. Each area is convex. That means every point in an area can be reached from any other point in the same area by walking to it in a straight line. This makes pathfinding a lot easier since we now have to only find a path of colored areas from the start to the goal. The pink dots are the vertices of the polygons and the green lines are all possible connections between vertices for each individual polygon. Pathfinding from A to B now consists of these steps:

• Find the closest vertex to point A (va) & find the closest vertex to point B (vb).
• Run A* on the generated vertices and edges from va to vb.
• Return A ⇾ va ⇾ A*path… ⇾ bv ⇾ B as the final path.
• Shorten the path were possible (not implemented yet).

How it looks in the game

This is an example of a currently generated navmesh for a game world:

The game world	The corresponding navmesh

As is clearly visible, there are a couple of fairly wide polygons between the trees. This should not turn out to be an issue as the total number of polygons is reasonably close to optimal and path smoothing will make entities move more efficiently.

The entities will be able to use this navmesh to find a good path from A to B or determine that there is no such path.

Area transitions

Lastly, I want to talk about “areas” in the navmesh. It is important that an entity can recognize different terrain types. The entity can then avoid areas where it would be slow or even dangerous to move (like water or lava) and prefer areas that give a speed bonus (like roads).

The navmesh implements a way to define areas and their types and movement cost. With this information better paths can be found. Currently, there is one issue with this system though:

Path from A to B

The blue area is water. It slows the player down and should therefore be avoided. What’s currently happening is that while the area is perfectly avoided in the path itself, it does not take into account the width of the entity. The path goes along the edge between the water and the ground area. The entity would still touch the water and be slowed down or take damage if the area was lava.
This issue is what’s going to be addressed in the upcoming days of development.

Thanks for reading

That’s it for today. If you want to know more about what’s to come in the near future, check out the previous post. Bye.

As you can see from this screenshot, progress on the project has been quite slow. (Game development is just a hobby for me.) What’s interesting though is that the very first preview has been released on 28. August 2019 and the second preview version on 28. August 2020. So you can guess what’s coming for this year’s 28. August 2021 ;).

Until then, I have a couple of additions planned which might or might not work out in this timeframe:

• Implement “auto-tiling” to allow terrain to be more flexible and pleasing to the eye
  • Add “auto-tiling” for all the available terrain types. So far it is only available for the “grass” tile. (Sneak peek in yesterday’s post.)

• Integrate Lua as a scripting language for later use (As of this point there is an ingame debug-console which has very limited commands. This is to be extended going forward.)

• AI
  • Navmesh ← actively working on this currently
  • Pathfinding
  • Steering behaviors
     
• Set up a working demo game (quest giver/storyline/etc.)
• Give credit to the awesome open-source game assets (It’s only a few as I’ve designed most of the game myself, but I will look through the files and give appropriate credit where it’s due. Also, open-source software.)

The last two points are, as you might have guessed, the most important ones out of all of them. I am going to continue working on the other stuff for now, but will eventually have to cut some of it short in order to have something “playable” on publishing day. Unfortunately it is not entirely possible to load up the save data from the last preview version, since some things have changed internally. That being said, some of it can be used effortlessly and some of it is supposed to be extended anyway.

I will see how it goes and keep you guys updated, see you!