Vapourware Codexian Game Development Thread

[rap2h]

My free open-world text-based RPG has now a steam page: https://store.steampowered.com/app/2271590/The_Secret_of_Darkwoods/

 

[Tavernking]

I have made the greatest football game in a few days.

Foci

Please find and use some free assets instead of using your current 'programmer art'. All your games could be masterpieces but I would never know because the terrible art deters me from trying them. Please please please please please follow this advice.

 

[what am i doing]

I replaced a mess of OpenGL draw calls in my game engine with a Vulkan renderer based off Victor Blanco's GPU-driven engine (vkguide.dev - probably the best Vulkan tutorial out there since it focuses less on a technical walkthrough of Vulkan and more on how it's used in practice). Main difference - aside from using the C++ headers rather than C headers, for convenience - is the scene layout. Since this engine is for grand strategy, the main rendering task is a 2D-looking world map, without much occlusion culling opportunity, no need for depth testing (currently - that may change), and a large number of elements being transparent. Accordingly, instead of one scene sorted by materials, each kind of map element has its own "layer" which is one material, and layers are drawn sequentially, following the painter's algorithm (stuff that should be overwritten is drawn first).

Integrating the Vulkan renderer started with turning off basically all rendering and a bunch of rendering-related tasks so that the engine could compile without GLAD and then run, initially without drawing anything, then just rendering Dear ImGui, then rendering a sample collection of map tiles, then fixing the camera to work with Vulkan's coordinate system and the new shader model (basically, changing where certain transforms took place, if at all - some bloat was gotten rid of). This evening I updated the cull compute shader and the main draw loop so that there is a main, west, and east instance buffer, and the cull compute shader does culling for all of these (setting instance count to 0 for anything outside the view frustum), with a negative and positive x offset of the world scale constant (16384) for the east and west instance buffers respectively. Then each layer is drawn three times with the same view offsets (albeit with most of the extra two culled), and if the camera is overlapping the "edge" of the world, the other side of the world is drawn there, yielding seamless wrapping. This was done a bit differently in the old OpenGL code, but overall the principle of checking visibility with a camera offset, and then rendering three times with a camera offset, is the same.

So, where before I was getting 45 FPS average on a Quadro M1200 when viewing the whole world, currently I am getting 104 FPS average. A lot of map elements still need to be added, and labels will need to be reworked since their old model was very inefficient, but overall it's a massive performance improvement and was well worth the six months or so spent on Vulkan. It is far more of a gain than I expected. Also, it's worth noting that drawing the scene three times, because most of the extra two are heavily culled (or if the camera's sitting at the edge of the world, one is entirely culled and the other two are each half culled) doesn't actually cost much, performance-wise - it's just a small number of added function calls and descriptor bindings; the GPU's overall workload is barely increased.

 

[rusty_shackleford]

What would be your initial impression of an RPG that had graphics like this?



I think it's a decent, functional style as a whole, but the big thing that's missing is variety and detail of character faces.

I wonder if it might also be overall too cartoonish for some players, and feel tonally dissonant if your game has serious themes.

that it's another low quality asset flip using the same exact assets as dozens of others on the steam store

 

[anvi]

I used to write ideas for games and make designs for them. But I gave up when gaming turned to crap. If teams of professionals are so far from being able to make decent games then there's no way I could. The way things are going I wonder if gaming itself will even last. I think it will go the same way as music. It will get shitter and shitter each year and the next generation of people will have zero interest in it. Eventually it will become a minor background thing that nobody cares about.

 

[TheDeveloperDude]

I am thinking about trying the 7DRL Challenge 2023. 7DRL itch.io
Can I use these tilesets? tilesets for Dwarf Fortress
Is it enough for good graphics?

*edited: added tilesets link

 

[Zed]

I am thinking about trying the 7DRL Challenge 2023. 7DRL itch.io
Can I use these tilesets? Is it enough for good graphics?

Looks fun. If I remember, and find the time, I might join as well.

 

[what am i doing]

Fixed a few bugs with the cull compute shaders. I had misunderstood the nature of glsl atomicAdd function and in turn what was going on with a couple of buffers, causing certain objects to be rendered more times than they should. Cull compute now works properly.
Re-added tile borders.

Re-added generic map shape borders, where a map shape is a collection of borders formed by the union of an arbitrary number of tiles - this can be the border of a "zone" of tiles, the border of a country, etc.
Had to add handling for "virtual" meshes eg meshes with no geometry. Sounds like a silly concept but the way the renderer works under the hood is that every "render object" also contains a handle to its mesh, and due to certain requirements for having somewhat dynamic meshes (because a state's borders can change when it gains or loses territory, for example), and the fact that map shapes can have zero tiles and thus no mesh, means that there had to be a mesh object in the container, even if the mesh didn't really exist, in order to simplify everything else. So for the function to add a mesh to a cartographic layer, if a mesh has no vertices then it is marked as virtual and the count of meshes with geometry isn't incremented (and when a mesh with geometry is removed this count is decremented); when rendering, if a layer's count of actual meshes is false it just isn't rendered. This gets around the problem of Vulkan not liking null descriptors and empty buffers and whatnot, without having to add the extensions that support them.

I do have to change the shader for map shape borders to handle colour differently. Like tiles, they originally used vertex colours for their colours on screen. This is an efficient way to colour an object, but not if the object's colours are dynamic and can change rapidly - reuploading geometry as you update it is expensive, especially if you're doing it to thousands of objects, and you have to either have a noticeable freeze in your program, or have a limited number of objects change colour each frame, which looks bad. Conversely, using vk:CommandBuffer::copyBuffer() from a staging buffer (that you upgrade over time, with an alloted time limit such as 2500 microseconds work per frame, without affecting what's drawn to show the user) to a shader storage buffer object is ridiculously fast. So for colours that can change often (such as the user picking a different mapmode), an SSBO is the way to go.

This is what I'm using for tiles now. So I will probably do this for borders as well. I'm just not sure if I want to reuse the tiles' structure (a container of ten glm::vec4 objects, because tiles can contain a variety of colours that are then filtered through a texture array of alpha channels to produce a Victoria 2 style hatching effect), which would be less efficient even if the filter code is removed from the fragment shader, or have a different structure that uses just one vec4, at the cost of having to complicate some of the rendering code when checking for different descriptors. Conversely, if I decide not to have borders change colour with map mode, perhaps it makes more sense just to go ahead and use their vertex colour, since they have to have their meshes replaced periodically anyways.

Then I should be able to move on to labels. I would kind of like to replace my line-of-best-fit for label placement with an attempt at copying the algorithm I've seen a Paradox dev describe for their label placement, but some parts of it are unclear. I will probably take a shot at it when I do get to labels anyways.
I also cleaned up some of the UI code and got started on sorting source files into different folders. I would like to begin breaking some of the larger classes into multiple source files for better readability, as well.

 

[RobotSquirrel]

Is it enough for good graphics?

Yeah but I recommend using REXPaint if you're not aware of it because I've found the results look the best in that program and its fairly hassle free to migrate it into your game engine, at present I've been exporting BBCode and having it show up looking pretty awesome. I run REXPaint through proton works great in Linux.

 

[LarryTyphoid]

When creating a first-person, 2D, textured maze (in the style of Wizardry 6/7), would it be a bad idea to store each segment of the screen as individual sprites, which would be placed together to create the entire view?

Couldn't you draw an entire image, like this, and then cut it into little pieces, as in storing each highlighted segment here as its own image file, then swap them in and out as needed? You'd think that this would save space, because otherwise you'd need to store several variations of the view to account for all the possible variations. This would be pretty much exactly the same method you'd use to draw a wireframe maze, except that you're loading in images instead of manually drawing in lines. I feel like I'm missing something important here, though.

 

[zwanzig_zwoelf]

When creating a first-person, 2D, textured maze (in the style of Wizardry 6/7), would it be a bad idea to store each segment of the screen as individual sprites, which would be placed together to create the entire view?

Couldn't you draw an entire image, like this, and then cut it into little pieces, as in storing each highlighted segment here as its own image file, then swap them in and out as needed? You'd think that this would save space, because otherwise you'd need to store several variations of the view to account for all the possible variations. This would be pretty much exactly the same method you'd use to draw a wireframe maze, except that you're loading in images instead of manually drawing in lines. I feel like I'm missing something important here, though.

Not really. Storing them as separate sprites in a space-efficient format and/or compressing them on disk, then composing the final image out of these segments is fine.

Drawing an entire image and cutting it like this would work as a solution to a non-existing problem that causes more problems later down the line -- what if you wanted to have a 3D-style effect (e.g. objects drawn from different angles) on walls, which could bleed into other images if you stored it this way?

 

[LarryTyphoid]

Drawing an entire image and cutting it like this would work as a solution to a non-existing problem that causes more problems later down the line -- what if you wanted to have a 3D-style effect (e.g. objects drawn from different angles) on walls, which could bleed into other images if you stored it this way?

Unless I can think of any other problems on the way, I think I'm gonna go ahead and implement it the way I've described. I don't plan on having any 3D-style effects or any flair besides the kind you can see in Wizardry 6 or Ultima 5. In Gardens of Imagination, the blobber development book I was recommended a few months ago, the author recommends splitting the display into 3 segments: left, right, and forward. Kind of like this:

But if I did it that way, then there'd really be only a couple of variations for the side views for doors, gaps, walls, etc; but there'd be a shitload of variations of the forward view, especially if I'd want the view to be more than two spaces ahead. I don't see the point of doing it this way when I have the option of splitting all the segments of the view into individual textures, mixing and matching them to form the view as the player progresses through the maze.

 

[Justinian]

Can someone recommend some free tools for taking footage of your game? I currently use OBS studio but it's kind of a pain to use and won't work when my game is full screen.

 

[RPK]

Can someone recommend some free tools for taking footage of your game? I currently use OBS studio but it's kind of a pain to use and won't work when my game is full screen.

I've just been using the windows+G key to bring up the built in windows recorder and it seems to work ok. might as well try that and see how you like it. it's free and built in

 

[RobotSquirrel]

I'd use this method especially if its coloured tiles because you can swap out individual tiles. You will however have wasted pixels in your tile map atlas due to irregular shapes.
The other segmented method is great if you're working with limited colours and need it to be super efficient but will have the draw back of having to make more variations in the sprites to support the different possible tile combinations but it'll be a lot easier to atlas because its all squares.

It really comes down to what your limitations are. If there were no limitations just use the tile method.

 

[Justinian]

Can someone recommend some free tools for taking footage of your game? I currently use OBS studio but it's kind of a pain to use and won't work when my game is full screen.

I've just been using the windows+G key to bring up the built in windows recorder and it seems to work ok. might as well try that and see how you like it. it's free and built in

i'm still using win7, so that doesn't seem to be an option.

 

[ERYFKRAD]

i'm still using win7

Bless you

 

[LarryTyphoid]

Would it be a good idea to create my own method for generating a texture/sprite atlas, or should I just use some pre-existing software? It seems like making your own is a big pain in the ass, but maybe it'd be better to do regardless.

 

[Ysaye]

Would it be a good idea to create my own method for generating a texture/sprite atlas, or should I just use some pre-existing software? It seems like making your own is a big pain in the ass, but maybe it'd be better to do regardless.

Depends how far you want to go, but this has quite a lot of options.

https://dungeoncrawlers.org/tools/atlas_generator/

There was also one I saw on Itch.io which had a good variety of options.

 

[what am i doing]

Integrated Viktor Chlumksy's multichannel signed distance fields library into the engine. Basically, it's a font atlas generator, plus he was kind enough to provide a fragment shader that takes the msdf textures and renders them as text. The advantage of a signed distance fields vs plain bitmaps is that they retain sharpness when zooming in, so you can have varying sizes of text without needing multiple atlases to keep them all crisp. SDFs do have a few visual aberrations, but msdfs basically fix those. There are more advanced font rendering techniques, like the Slug library, but that allegedly costs a lot of money, while MSDFgen is free. It did take some tinkering and adjusting to get the plane and uv coordinates correct, but now it works. Kind of. There are some screenshots attached, with zones assigned a random colour and numbered label for testing purposes.



You can see the problems.
1. Line-of-best-fit using tile centres works ok with some shapes, not with others. Sometimes the text isn't centred in the map shape it's supposed to label; sometimes it's partially or even entirely outside the object. Something like Paradox does, where they use a sequence of lines to determine the overall largest curve they can fit inside a polygon, would be better. But some parts of the description I've read (from one of their developers) are a bit unclear in their meaning, perhaps because I'm not a math guy. Of course, there's probably some value adjustments I could do to my label baseline generation function that might help, but at the end of the day the Paradox method is much better.
2. Signed distance fields look great when zoomed in (that is of course the weakness that plain bitmap text faces) but not so great when zoomed out. Fragment shader tuning may help (adjusting a certain value in it shifts between texts looking reddish and blurry, or plain black and transparent but with some loss of shape when zoomed out , and I'll mess around with that more at some point, but there are issues there. Some sort of culling mechanic for very small labels might work (so they just don't show up until zoomed in enough that they'd be readable), but I'm not sure how I'd implement that; perhaps having a bunch of layers for labelling and add labels into them with the selection being based on their overall span, and then exclude small-span layers from the rendering list when zoomed out.

Ultimately, I'm probably going to leave the labels as is for the time being; they aren't good for a release state but they're serviceable enough for development, and I've spent long enough on rendering and want to move to a different part of the program for now; specifically I want to begin filling in the mechanics of pop simulation, starting with basic staffing of agricultural operations. Although before I do that I need to do some research on soil.

 

[Victor1234]

Integrated Viktor Chlumksy's multichannel signed distance fields library into the engine. Basically, it's a font atlas generator, plus he was kind enough to provide a fragment shader that takes the msdf textures and renders them as text. The advantage of a signed distance fields vs plain bitmaps is that they retain sharpness when zooming in, so you can have varying sizes of text without needing multiple atlases to keep them all crisp. SDFs do have a few visual aberrations, but msdfs basically fix those. There are more advanced font rendering techniques, like the Slug library, but that allegedly costs a lot of money, while MSDFgen is free. It did take some tinkering and adjusting to get the plane and uv coordinates correct, but now it works. Kind of. There are some screenshots attached, with zones assigned a random colour and numbered label for testing purposes.

View attachment 33185View attachment 33186View attachment 33187View attachment 33188

You can see the problems.
1. Line-of-best-fit using tile centres works ok with some shapes, not with others. Sometimes the text isn't centred in the map shape it's supposed to label; sometimes it's partially or even entirely outside the object. Something like Paradox does, where they use a sequence of lines to determine the overall largest curve they can fit inside a polygon, would be better. But some parts of the description I've read (from one of their developers) are a bit unclear in their meaning, perhaps because I'm not a math guy. Of course, there's probably some value adjustments I could do to my label baseline generation function that might help, but at the end of the day the Paradox method is much better.
2. Signed distance fields look great when zoomed in (that is of course the weakness that plain bitmap text faces) but not so great when zoomed out. Fragment shader tuning may help (adjusting a certain value in it shifts between texts looking reddish and occluded, or plain black and transparent but with some loss of shape when zoomed out , and I'll mess around with that more at some point, but there are issues there. Some sort of culling mechanic for very small labels might work (so they just don't show up until zoomed in enough that they'd be readable), but I'm not sure how I'd implement that; perhaps having a bunch of layers for labelling and add labels into them with the selection being based on their overall span, and then exclude small-span layers from the rendering list when zoomed out.

Ultimately, I'm probably going to leave the labels as is for the time being; they aren't good for a release state but they're serviceable enough for development, and I've spent long enough on rendering and want to move to a different part of the program for now; specifically I want to begin filling in the mechanics of pop simulation, starting with basic staffing of agricultural operations. Although before I do that I need to do some research on soil.

You seem like you've already committed to this approach and Paradox are the king of map games, but they've had ~20 years of raking in money to spend on maps, so their maps are very shiny. What do other people use to make theirs, that you could use, that does the same basic job but don't look like 70% of the game budget/time went on the map?

https://store.steampowered.com/app/603850/Age_of_History_II/
https://store.steampowered.com/app/1248060/Realpolitiks_II/
https://store.steampowered.com/app/1823600/Power__Revolution_2022_Edition/

The first game seems popular, the second is not (but it's not the map's fault), the third is buggy, but the map is usually reliable (if a bit ugly).

https://store.steampowered.com/app/314980/Supreme_Ruler_Ultimate/

These guys literally use hexes overlaid on a satellite map, might be another way to approach this.

 

[RobotSquirrel]

Line-of-best-fit using tile centres works ok with some shapes, not with others. Sometimes the text isn't centred in the map shape it's supposed to label

You could try and take the individual edge province tiles (treating each province as a vert in a polygon) and find the centroid of their shape. Just a possible solution because it appears you're not getting true centre from this method.

 

[what am i doing]

Ok, I fixed the weird reddish inner glow. There was a very, very dumb typo in the fragment shader that I made while adjusting some stuff, forgot was there, and then completely missed while re-reading it several times. Very small text is now more readable. There are limits, of course. Zoomed in shown as well. It does start to show a bit of a blurred edge, but is still much crisper than plain bitmap text.

Line-of-best-fit using tile centres works ok with some shapes, not with others. Sometimes the text isn't centred in the map shape it's supposed to label

You could try and take the individual edge province tiles (treating each province as a vert in a polygon) and find the centroid of their shape. Just a possible solution because it appears you're not getting true centre from this method.

This sounds like a decent approach to getting the text centred a better and I may try it out as an interim means of getting better label placement.
I also found a decent-looking C++ library for splines this morning which covers one of the major parts of the described Paradox method which I found iffy, so I might actually take a shot at implementing their method, or something close to it (my tiles' shapes are defined by vector graphics / polygon geometry rather than a collection of pixels in a bitmap, so conceptually it's a bit different). The other part of that step I find a bit confusing is exactly how to generate the linear least squares fitting lines, but I can probably muddle my way through it eventually. The rest of it makes sense.

 

[Justinian]

Interesting way to "generate" a random map.

 

[Viata]

Not really random, she was placing the rice around the paper instead of dropping all of it at once.