Hanse2.0

To making the game more interesting, i knew the next step would be to add ship building and fleet control. Thanks to my modular approach for this game (Entity Component System), it was fairly easy to add multiple ships, essentially just adding the keybinds and logic to switch the active ship. However, adding the shipyard meant the introduction of a new component called “ShipBuildOrder” as I decided, that the ships would need resources as well as time to be built. In combination with a new System this task was fairly easy once again thanks to my modular approach for this game.
The UI is not final, i will probably have a new approach on it in the next major devlog.

Economy Devlog

I heavily edited the parameters of the economy calculations and therefore adjusted the entire system. This includes changes to the algorithms, such as a price stabilisation if the city demand is zero (because it’s only produced but not demanded, which previously resulted in prices stuck on the base price, due to a missing NaN check in the algorithm). On the otherhand all productions have been lowered to 1/7 of the previous values.

Following a productive testing session in Slack, it became clear that a dedicated tutorial system was essential for helping players grasp the core mechanics and objectives. I have integrated this educational component alongside several key polish updates to ensure the game is ready for shipping, such as refining the ship’s texture and optimizing the visual rendering of ship names. To enhance the overall user experience, I also implemented a dedicated fullscreen button that allows players to toggle between display modes seamlessly. The new tutorial itself can be accessed at any moment via a question mark icon located conveniently next to the fullscreen control, providing comprehensive guidance that covers both the technical input schemes and the nuances of the gameplay strategy.

I tried to balance the game as much as possible, as the algorithms have become quite complex. In addition the gametime system was updated and is now shown to the HUD.
As it turned out, there were cities filling bankruptcy within 2 weeks game time, caused by the shadow market algorithm, which bought the overflow way to cheap and then sold it to profit.
The system is still not perfect but it has been approved a lot. Future steps are the addition of multiple ship (naturally) and the ability to actually build kontors in other cities. And a new tutorial will be the very first next step.

I am currently implementing a few new algorithms to control the economy, which is very tedious and will take atleast 3-5 hours from now. There are four central algorithms, which i will implement:

• PriceAlgorithm (Done)
• DemandAlgorithm (In testing)
• ShadowMarketAlgorithm (Next devlog, in testing)
• SatisfactionAlgorithm (TODO)

Also updated tutorial sequence design, to fit better in the with the new design.

I did an major overhaul of the GUI including a new trade interface, which will be the central instrument for my game. I was inspired by the slide functionality which is used by the awesome inspiration for this project, Patrician IV. It took a few minutes to figure out a good UI. The GUI is reactive, meaning it instantly updates when important values change here. If the player can buy or sell a good, it is indicated by the green or red gradient. Trading is as simple as dragging the handle, the slider uses log scale, so the user can buy a wide range of quantities.

I sucessfully implemented the pathfinding, in this code it works by letting the player select a destination city on the map, usually by shift-clicking on it. When this happens, the system first finds which city was clicked by checking which city is closest to the click position within a certain radius. It then finds the player’s ship and determines the ship’s current position. Using the navigation graph, it looks up the nearest node to the ship and the node for the destination city. If the ship is not already at the destination, it uses the graph’s findShortestPath method to calculate the shortest route between these two points. The resulting path is a list of node IDs, which are then converted into world positions. To make the route look smooth and natural, the code applies a smoothing function to these positions, creating a curved path instead of a jagged line. Finally, the ship’s navigation components are updated so that it follows this new path, moving from its current location to the selected city along the calculated route.

I implemented the basics of an Entity-Component-System, including a render system. Using the graph data (=> Devlog 1), I was able to load the harbors/cities from a json file, making the game data-driven. This update lays the groundwork for further advancements. Moving on from this, I will implement a pathfinding algorithm, make the HUD actually work and implement a trading system

I implemented the intro which launches on first game start. I spend like 20 minutes finetuning the background until I was happy and i believe it conveys the medieval vibe quite well. I also tried music generation via Gemini and was quite shocked how good it was. After the intro is finished, I moved on to editing the world map. This is a smaller devlog after all, because i dont want to spoil everything. Just one more thing to say, we are just getting started here and i am looking forward on what comes next.

I just started the project, setup a simple HTML dev tool which I used to map the entire Hanseatic League region. It will be the base for future pathfinding of the merchants ships. It consists of harbors and guidance points, which are the vertices, and edges between those two (Yes, its straight up Graph Theory). Each edge has a cost (currently just the length, maybe i add a few more modifiers) which will be used to determine the quickest path between two harbors and eventually enable AI players (in the future!!!).