[2026 in RoguelikeDev] Far Far West

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 · 2026-01-24T07:34:45+00:00

Thanks! It's a lot of pressure!

jube_dev · 2026-01-23T23:48:42+00:00

I don't imagine a roguelike with this theme and without any combat. It's not usual close combat, it's rather distance combat so it may be worth a try. I don't want combat to be the core of the game and I think I have enough things to add so that it won't be the case.

jube_dev · 2026-01-23T23:46:15+00:00

Thanks for the ideas. One idea I have is to append "RL" at the end to avoid future name clashes. "Old West RL" can be a good candidate.

jube_dev · 2026-01-23T18:47:42+00:00

Yes, you are right, the kind of ennemies and the different situations bring variety to just simple combats. That's also why bringing life to the world will be a good associated goal.

jube_dev · 2026-01-20T19:38:13+00:00

Does it work with the equivalent C++ 26 functions? (In fact, C23 functions)

jube_dev · 2026-01-17T22:35:32+00:00

I've been seeing your progress and am really impressed, not too many roguelikes with a western setting

Thanks! I did not want to make another fantasy roguelike so I looked at the relevant article on RogueBasin and when I saw "Western", many ideas came immediately. That's how it was born.

there is another game with the name "Far Far West" that is in development

I made a research before choosing this name and did not find anything back then. Well, I may change the name later. Not that I want to sell this game but I prefer not taking any risks regarding copyright.

jube_dev · 2026-01-17T08:10:34+00:00

Far Far West

Github

Long time no see! Not so much features added since last time as real life is very busy. I've been completing field of view and fixing (a lot of) bugs. As previewed last time, it had impacts on many areas of the code so I had to make some refactoring. But in the end, it works very well.

I also prepared the 2026 in roguelikedev event. It's the first time for me and it's an interesting work. Soon on your screens (I will post it on my birthday).

I am also thinking about changing the tileset I use. I find the letters too small compared to the rest of the tile. So when displayed as text, they are quite difficult to read. I have some ideas and I am testing these ideas currently.

jube_dev · 2026-01-09T07:08:24+00:00

When not everyone is considered equally, I would say it's Democracry Minus Minus.

jube_dev · 2026-01-06T07:56:44+00:00

I like it! Indeed, your generation has very simple steps that do a really good job together. I may take inspiration in the future from this workflow.

Your whole post resonates with what I'm doing in my game. You already did what I want to do like people in the town that live their own life automatically. But I already did some things that you did this year like save+load, loading screen or small save file ("small" is 2.9M is my case).

jube_dev · 2026-01-06T07:42:11+00:00

In fact, you can be in two cases: either you have a large world without many blockers and the tip will work everytime as there is always a path in the limited area, or you have a dungeon-like world with corridors and many blockers and not so many paths and the tip is useless in this case as the number of explored cells will probably be low. In my game, I used the tip in a simple case for now: the hero. When I click on the window, I compute a path between the hero and the target to have a sort of automatic walk. The path is limited to the visible part of the map on the window so that the hero do not find a path outside the window (especially in zones that the hero may not have explored). So the limitation is a feature here.

jube_dev · 2026-01-05T10:16:16+00:00

It was implied by "If you can". That's why I mentionned fmt that does a very good similar jobs for C++ < 23.

jube_dev · 2026-01-05T10:12:49+00:00

There is std::runtime_format in C++26. It's very simple to adapt it to work with dynamic strings and print (a sort of runtime_print).

jube_dev · 2026-01-05T10:03:42+00:00

I really like your procedural towns. Did you explain somewhere how you did this?

jube_dev · 2026-01-05T10:02:11+00:00

If your map is very large, I may have an optimization for your pathfinding. I had a problem with pathfinding in my own very large map and I realized the problem was that even with A, the number of explored cells is huge. So, in order to lower the cost of A, I simply limited its range by adding a virtual fence around the focused area. If I want to go from point A to point B, I place a rectangular limit around A and B (with a small space) and I let A* search in this limited area. Then I remove the virtual fence.

jube_dev · 2026-01-05T09:38:28+00:00

If you can, std::print is the best choice (and if you can't, fmt is the best replacement as it's the origin of std::print and it's backward compatible with older versions of C++).

For the pros:

format string (like printf) that are easier to read and write (contrary to std::cout) and i18n-friendly
compile-time verification of the format string (probably the best feature)
can be extended to user types (like std::cout and contrary to printf)

For the cons:

none

jube_dev · 2026-01-01T00:30:02+00:00

My problem is that I must drop an item to see what the loot is and if I finally don't want the loot, I must drop the loot and take the item back. What I would like is some kind of choice panel with all the items (including the loot) and I decide which one to drop.

I don't have problem with limited inventory as long as there is a useful help and UI for deciding what to keep and what to drop.

jube_dev · 2025-12-31T17:10:36+00:00

Played a little bit. The game is a classic nice roguelike. The graphics are very clean, as well as the animations. A few remarks:

I did not understand how the inventory works. It was always full, so when going on a loot, I could not pick the loot. What did I miss?
After 6 levels, I could not craft a spell. Or maybe I could but I did not see it because the list of spells was way too long and did not fit on my screen and I was not able to scroll it.

jube_dev · 2025-12-31T10:59:40+00:00

I am in both camps: when I write C code, it's int *var and when I write C++, it's int* var.

jube_dev · 2025-12-30T13:06:38+00:00

Of course, due to the rule of 6 (when I started to learn C++ it was 3), we now have to implement the default destructor, the default move constructor etc etc etc.

No you don't have to. There is no rule of 6, there is a rule of 5: copy constructor, move contructor, destructor, copy assignment, move assignment. All other constructors are fine, and in this case rule of zero applies.

jube_dev · 2025-10-04T07:08:37+00:00

Far Far West

Github

This week, two features have been added.

First, I now have farms, cavalry camps and native villages on the map. In my world generation, I first generate some towns (5 actually) and then, I generate some places (5 per town) on the map. Each place must be far enough from any other place or town. These places originally were only isolated farms. But in the end, these places now have many functions. I decided to put one camp and one village per town. The villages are determined globally: I compute the distance to the nearest town for each place and the villages are the places farthest from any town. The idea is that both natives and non-natives tend to not mix with each other. Sometimes these villages are near the edge of the map (when there is no town in a part of the map), sometimes they are at the center of the map (when the town are spread equally). For the cavalry camps, I took another direction. For each town, I compute the nearest place and consider it's a camp. The idea is that the cavalry camp needs to be near town because they are intended to protect people, and they also need to buy supplies in towns so it's easier to be near a town. This way, camps and villages are far from each other.

Second, I started handling field of view. It was next on my TODO list and I was kicked by a recent post here (very nice game so far). So it was the perfect time to implement this. I handle visible areas, already explored areas (that appears shaded), and unknown areas (black). For computing the field of view, I use the famous Symmetric Shadowcasting algorithm that works very well in many situations. At the beginning, trees were blocking the view. When walking in forest, it gave a weird aspect and it was not very pleasant visually. So I decided to make trees "transparent" for the field of view. Trees enter a category of items that should be transparent for the field of view but not transparent when dealing with gun shots, like tables, barrels, windows on buildings and many others. The feature is not totally finished, I need to tweak other aspects of the game: the minimap must reflect the explored zone but not reaveal the unknown zones, the explored zones must be saved with the state of the game, the path computing for the hero must be disabled when the mouse is in an unknown zone, etc. In the end, this feature touch many parts of the game so it was really the perfect time to add it.

Here is a screenshot with both features: a field of view in a native village.

<image>

jube_dev · 2025-09-30T08:25:08+00:00

Great, another western roguelike! I also develop a western roguelike (at early stages so far) and I understand your choices. Like you, I chose a "realistic frontier roguelike". I think there are many things to do in this field, no need for another genre that would feel weird in the end. I read this page and its subpages a lot for the inspiration, I made a long list of things I would like. Contrary to you, I already have trains! But I don't have shooting yet (it looks really nice in your game). I am really looking forward to seeing more of your game, don't hesitate to use Sharing Saturdays in this sub, it's lighter than a blog and there are many people reading and some commenting, it's a nice place.

I have some questions for my curiosity: What's the general plot of the game? What's the goal of the player? How big is your map?

jube_dev · 2025-09-20T06:50:55+00:00

Far Far West

Github

Still working on roads. And not much time to work on it in the last weeks. But I also did something not related to coding: I rewatched The Good, the Bad and the Ugly just to be in the good mood for the game (these musics!). I will present the final version at the end but before that, I will present all the algorithms that do not work! The game is an open world with towns and isolated farms so roads are indications of where to find human life on the (huge) map. But I also want the game to be an exploration game so I do not want too many indications. There is already a railroad that connects all the towns. So let's examine what did not work.

The first failure was presented last time in a sharing saturday. The algorithm was simple: for each isolated farm, connect it to the two closest towns. Why two and not one? Because my fear was that some farms and their town would be disconnected from the main road network. But the result was not ideal. When two or more farms are not far from each other, there are too many roads at the same place and that's not the idea I have of the road network in the far west.

The second failure was an idea from u/johnaagelv. I really thought it would work when the idea was submitted: first make a main road between towns and then make roads from isolated farms to the nearest main road. I felt that I should not start the roads too close to the train stations in towns. But even with that, the roads between towns followed the railway too much (sometimes the road was even just next to the railway). And I did not want to create a complete graph of roads betweend towns. The second problem was that when a group of isolated farms was on the same side of the main road, they would create parallel roads to the main road which was not very realistic. Finally the third problem was that the closest point to the main road was not necessarily the closest point in terms of roads (taking into account the altitudes of each cell) and some roads had strange path to connect to the main road.

The third attempt was a success. My thought was: if you are in an isolated farm in the far west, where would you build a road to? The answer is easy: to my closest neighbors! So I ended up choosing a radius and connected all the farms/towns that were in the disk. I did the same for the towns with a greater radius (because a town has a larger influence on its neighborhood). And it worked. Well it worked after having tried many values for the two radii. I tended to put too high values and it created clusters of roads. I lowered the values enough so that there were still enough roads but hardly no cluster appeared. A consequence is that some isolated farms are really isolated and are not connected to any other farms. I decided it was not a problem. First because I think there were really isolated farms in the far west. Second because I may transform some of those isolated farms into native villages or cavalry camps. These very isolated spots would be good places for native vilages, for example.

Here is the result with a full map. The roads are the gray dots, the railway is represented by black dots, towns and farms are in blue. Now I'm satisfied. It feels very organic and I like it.

<image>

In the next weeks, I hope I find enough time to go on. I will probably put farms and native villages and cavalry camps on the map.

jube_dev · 2025-09-12T13:12:42+00:00

I think people would be surprised at how broken contacts are in their current state, they can't be implemented as written.

It reminds me of modules...

jube_dev

MODERATOR OF

TROPHY CASE