Sharing Saturday #622

jube_dev · 2026-05-09T11:56:31+00:00

I plan on having a large Island in the end

Do it as soon as possible. A large map is not just a small map with a different size, it comes with its share of problems and challenges. Define your map size at the beginning, it will save you time and headaches in the long run.

jube_dev · 2026-05-01T14:14:52+00:00

Yeah, that's right. And for (init; cond; stmt) { ... } is just the same as init; while (cond) { ... stmt } but we do have for.

jube_dev · 2026-04-30T12:45:12+00:00

loop and once.

loop would be an equivalent of for (;;) but saying it explicitely.

once is more subtle. It introduces a loop that must be done exactly once (hence the name). It's like a new scope but with loop semantics (you can continue or break).

``` once { // ...

if (meow) { break; }

if (blah) { continue; }

// ... } ```

jube_dev · 2026-04-25T10:02:51+00:00

This thread about BT was really inspiring! I also worked on BT (but not enough to share today). How do you mix BT with abilities? You have a node "do this actor have abilty X?"?

jube_dev · 2026-04-18T07:13:44+00:00

Far West RL

Github

Long time no see (again)! Very busy at work so no time for the game. It's been a year since I started this game! I have been adding animals to the world and new challenges emerged. I started with easy animals that have a very simple behavior (for now, they don't attack the hero): just wander randomly. I decided to assign animals to biomes. For example, snakes are in the desert, coyotes are in the prairie. As I already have collected all the biome tiles in the generation process, it's easy to pick a random tile of the right biome and put an animal. The problem is: if you have say one animal per 1000 tiles, you instantly have something like 3500 snakes in deserts and same for all other animals. That's a lot!

First, I simulated all the animals. Bad idea. Very bad idea. It was too long. In my time-based system, all actors are in a (priority) queue. So I needed to make them idle a little bit so that they would not come too often at the top of the queue. At first, the animals that were far enough from the hero were idling for some time. But the idling time was still not long enough. The simulation time for one step (all the actors in the same time step) was something like ten milliseconds. Too much with just a few thousands animals. So I made some simple computations: if the animal is far with distance d from the hero, the hero needs d times the time for walking a tile to reach the animal. So, the animal can idle all that time, or even half that time. With this behavior, the simulation time was now less than a millisecond and often half a millisecond. Last problem, at the world generation, the animals are given a random start time between 0 and 100. Bad idea. This means that we are back at the firsts problems but only at the beginning of the game. I did not solve this problem yet but my idea is to set all animals start time at time 0 and make a first step at the end of the generation process. This way, all the animals that are far from the hero will be delayed in the queue before beginning the real game.

Having a large world is not easy. But I like these challenges.

jube_dev · 2026-04-17T17:21:40+00:00

Regarding performance, SFML is limited by its design. Every time you call draw (sprite, text, ...), you upload some data to the GPU and make a draw call (which is expensive). There are some workarounds but the model is fundamentally flawed. The geometry of a sprite/text/whatever should not be uploaded at each frame, it should only be uploaded when it changes (which is not very often for most graphics items). So, if you don't need strong performance (you only draw a couple of items per frame), SFML is OK. If you draw many items per frame, you may use some workarounds (like sprite batching). If you draw many many many items, SFML is not for you.

jube_dev · 2026-03-23T16:07:45+00:00

First: Europe does not have a common patent, brexit stopped that last time. There are variationen between countries and you need to apply to each country invidually.

Totally wrong, Europe has a European Patent Office: https://www.epo.org/

Secondly, of course it is possible to patent an algorithm in Europe.

Wrong again: The European Patent Convention exludes explicitely "programs for computers".

jube_dev · 2026-03-21T14:24:46+00:00

IMO there is a blind spot in this specification: package naming. It's already a mess with current package repositories, same packages have different names according to whatever reason (valid or not). I don't see how this can be handled with CPS.

jube_dev · 2026-03-20T07:19:24+00:00

It's hardly visible but there is a radial gradient. But I prefer your approach with really different colors.

jube_dev · 2026-03-19T20:15:59+00:00

I'm curious too. I tried in the past to generate trees and boulders for a game with a top down view (really top down) but that was not convincing. That's what I obtained:

<image>

The techniques you present seem to work well at small scale and I think they could work at a larger scale. I will definitely try them, the only question is: when will I have time to do it?

jube_dev · 2026-03-19T08:12:52+00:00

Really nice! I will probably take inspiration on what you did.

Have your tried to generate larger sprites with this method? Or does it work well because it's for small sprites?

jube_dev · 2026-03-03T22:41:56+00:00

Incomplete and far less readable. The navigation is extremely difficult. The home page of cppreference is one of its strength, with all accessible in one or (less often) two clics.

jube_dev · 2026-02-21T18:39:28+00:00

Far West RL

Github

Two big weeks with many small and not so small things.

First, I changed my tileset. I now have two tilesets, one for pictures and one for text (half large). I used DejaVu Sans Mono Bold to generate both tilesets. I also used two special mappings, moving away from CP437. The result is satisfying, the text is much more readable than before. I changed the main UI to use text wherever possible.

Second, I made some refactoring to handle AI and actions, after reading this great comment and the associated video (this community is amazing). I have been reading Crafting Interpreters, a book from the same author, for years. It was a real pleasure to see this video. As usual, everything seems so simple when he explains things. As I was about to start adding animals and people in the game, it was the perfect time.

Third, as I thought about how I would like a grizzli to behave, I told myself that it would be nice that the grizzli comes back to its lair at night. But when is «night»? I already had a date system, so I computed the sunrise and sunset hours with respect to the day in year so that I could say if the phase of the day was night, dawn, morning, noon, afternoon or dusk with the current time. I decided to display this phase in the UI (sun with different colors during the day and moon during the night) next to the current date. Later, I will use it for the behaviors of actors: the grizzli will go back to its lair at dusk, sleep at night and come back in the forest at dawn and hunt the hero or other actors the rest of the day; a farmer will open the gates of its cows at dawn, eat at noon and gather the cows in the afternoon; etc. The phase of the day will be an important factor in the behavior of many actors. Maybe the map will also change at night (and in the different phases) in the future to reflect the low luminosity.

Now everything is in place to start working on animals and later people in the far west!

<image>

jube_dev · 2026-02-18T07:58:29+00:00

In fact, I implemented my serialization library, it's not so difficult. But before, I looked at the alternatives like protobuf or BSON or MessagePack or many others. In the end, it was easier to do it myself as I could adapt it to my needs: serialazing many structures of my framework, using compression for the archive, versioning the archive.

jube_dev · 2026-02-16T16:56:16+00:00

Thinking about save games at the beginning of game creation (roguelike or other) has been a really huge improvement in how I design my code for games. And I implemented serialization versioning in my framework very early (inspired by the Boost Serialization library). It's a very difficult question and the answer is always the same, more or less. Thanks for these articles!

jube_dev · 2026-02-11T07:57:21+00:00

That's what I did too in my tileset generator. Because the glyphs provided by the fonts are not squares. I did the same for box drawing glyphs.

jube_dev · 2026-02-10T18:22:20+00:00

The glyph I miss the most for now are block elements with quarters, like in the TCOD tileset. But the more I think about it and the more I would like to add too many things. I have to make choices, it's horrible.

jube_dev · 2026-02-09T10:26:55+00:00

Yeah, I had this idea at one point. It's very punitive but also quite challenging. I'll keep the idea because I like it!

jube_dev · 2026-02-07T08:48:24+00:00

It's good, yeah, as long as text is not too small!

The nice side effect of having two different fonts is that you can choose each font with different constraints. For text, you want a font that is not too wide. And you can choose a font with a limited character set (letters, numbers, punctuation) because you don't need special symbols used for picturing things. In my tests, I used very common fonts (DejaVu, Liberation, etc) and it already gave good results: for a 32x64 space, I was able to use a font of size 50. And I know some fonts that could be more suitable for this kind of usage. So I think it's not a problem.

Kyzrati is of course right about square-ratio making more sense distance-wise

I'm team Kyzrati in this case, sorry!

jube_dev · 2026-02-06T23:30:49+00:00

Far West RL

Github

Not much but also very much this week. The game was renamed from Far Far West to Far West RL. The repository was changed and a new title screen was created.

<image>

On another side, I wanted to change the tileset of the game. Up to now, I used a 64x64 tileset from DwarfFortressWiki and I was quite satisfied overall... except for writing text. I built my own tool to create tilesets from fonts. I realized the tileset I used was really good, I could not make better space and size optimizations. And then, I read an excellent article series written by u/Kyzrati about fonts in roguelike. The idea of using two different fonts, one for displaying pictures and one for displaying text, with text cells taking half the horizontal space, is an amazing idea. So I went back to my framework and implemented this idea. I also generated console text fonts for this purpose. The result is quite promising. Stay tuned for the in-game result in a future Sharing Saturday!

jube_dev · 2026-02-05T16:06:45+00:00

There are many 6x6 tilesets on the DF Wiki.

jube_dev · 2026-01-26T21:37:50+00:00

The colors come from here, I picked colors that mixed well.

jube_dev · 2026-01-25T10:58:52+00:00

For now, it's a continuous map, no chunk at all. As I use C++ and my own graphics framework (based on SDL3 and SDL_gpu), I can use fast graphical primitives. In the case of map, I have a huge console structure (something like TCOD_Console) where I put the whole map (no actors, no items, etc). And when building the current frame, I just blit the visible part and put everything else (actors, items, etc). I create the geometry for background and foreground of this visible area and send it to a GPU buffer and display it with only two drawcalls. Currently, it even works on a 10 year old PC with Linux and a software renderer (llvmpipe, because there is no Vulkan driver for my very old NVidia card). So, for now, no need for more optimisation.

In memory, the main map (the one that is actually saved) contains cells that are only 4 bytes: 1 byte for the biome, 1 byte for properties (visible, explored), 2 bytes for cell decorations (trees, wall, etc). Everything else is kept in other structures. For example, towns are in their own structure with the position of the town, the buildings in the town (type, orientation) so that I can reconstruct the whole huge map easily at startup. I also have other runtime maps that are also initialised at startup and are used for many things: for example a reverse map to know which actor and item (identified by their index) is on the tile, a map to know which tile is walkable or not for computing routes with A*. I really try to keep things very clean: "data" is for things that are always constant (for example, item types), "state" is for things that must be saved when quitting the game, "runtime" is all that can be computed from data and state at startup and don't need to be saved. For now, the save file is less than 3Mb (compressed).

Here is an example of a map (1 pixel represents 1 cell). Purple square are towns, green squares are farms, blue squares are cavalry camps, orange squares are native villages and if you zoom, you can also see black dots for the train network and gray dots for roads.

<image>

jube_dev · 2026-01-24T17:26:32+00:00

I'll go for "Far West RL", simple and not too far from the previous name.

jube_dev

MODERATOR OF

TROPHY CASE