Vapourware Codexian Game Development Thread

[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.

 

[Catacombs]

"Interesting" map generation ... on TikTok.

 

[Zed]

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.

I've done exactly this. Well, not exactly, as I didn't load or swap images, just hide/show (they were always loaded).
Actually I've done it a couple of times.
Only game I ever finished though was this for a 64x64 frame size contest: https://phantomax.itch.io/totaq

The actual game has all logic in a grid on the side with simple wall collision for showing/hiding walls, and the rendered first person view is all the player sees.

 

[Justinian]

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.

Only game I ever finished though was this for a 64x64 frame size contest: https://phantomax.itch.io/totaq

I remember playing that ages ago.

 

[what am i doing]

Changed the way labels are registered with the renderer. Each letter is now a separate render object. Character mesh quads are reused.
Changed label generation to be something similar to Paradox's method, although I don't do the secondary main least squared fitting line (yet). A spline is now generated that is supposed to generally fit in the shape.
Changed label registration to use the supplied spline for model transformation.

Broadly, this actually works. As you can see in the attached image, it's not altogether correct - text is not centred along its advance, and tends to extend out, and then, once it's extended, go off in crazy directions - but I believe this is primarily a tuning issue and can be fixed by massaging values to get the text advance set correctly & keep the far ends of the splines under control, rather than needing a fundamental rework. At any rate, curved labels. I will never make fun of silly Paradox names on a map again. This shit is hard.


EDIT - improved with some tuning and moderation, eg the points used in the spline are now averaged with the main linear-least-squares-fitting straight line to soften the amount of overall variation. There's more to be done (middle of the shape should be preferred unless an offset line produces a longer length by a certain factor, not just any longer length), and some edge cases that aren't quite right, but this fixes the most egregious issues.

 

[RobotSquirrel]

I will never make fun of silly Paradox names on a map again. This shit is hard.

I mean it is hard to do, but remember that they got to this point by decades of refinement, if you go look at their first titles the implementation is a lot simpler. They've been at this for a long time. EUIII was the first as I'm aware to use this method of drawing country names.

 

[Victor1234]

I will never make fun of silly Paradox names on a map again. This shit is hard.

I mean it is hard to do, but remember that they got to this point by decades of refinement, if you go look at their first titles the implementation is a lot simpler. They've been at this for a long time. EUIII was the first as I'm aware to use this method of drawing country names.

Indeed, although others also did it before them (1997):

 

[cigaretteEnjoyer_despirit]

Thanks for your reply. Unfortunately what I want to make is more of an action RPG, with lots of character customization. So if you have 2 genders, 10 hairstyle options, 10 weapons, 20 armors... all animated in 8 directions with movement, attacks, etc... if you try to do all that in traditional pixel art and animation, I think you're looking at an effort best measured in years.

I think you're heavily overestimating the amount of effort it would take. Especially if you start form a premade template. That'd take like a week or two of intensive work imho, depending on the size and complexity of animation. You obviously dont need to animate every possible character separately, just have a body sprite + armor layer + weapon layer + hair on top.

 

[LarryTyphoid]

The whole texture atlas business is a bit over my head right now, so for the time being I'm going to load each texture individually from separate image files, and worry about packing all of them later. Hopefully I won't have to dig up too much of my own work when I get to that point. There's a whole bunch of texture packing applications on github and elsewhere, including the one from dungeoncrawlers.org that was posted in this thread earlier, but I would like to have a command-line variant that can be run along with the compiler in the makefile, and finding a suitable candidate for that has left me spinning my wheels for almost a week.

Besides that, the only other formidable obstacle I see in my immediate future is properly implementing thin walls (IE, a Wizardry-style in which any given tile can have any combination of the 4 walls surrounding it, rather than tiles merely being full or empty, as was discussed at length in Grauken's thread on the subject). Thankfully, some insight on that subject has already been given by experienced devs in the aforementioned thread.

 

[RobotSquirrel]

texture individually from separate image files

try using a texture array instead then, its the alternative method to atlasing. They can work together too but in some scenarios such as tiling textures we'd want to avoid an atlas and preference the array instead. I would check if your engine supports it (most do).
edit found a good video on the subject

 

[LarryTyphoid]

try using a texture array instead then, its the alternative method to atlasing.

It sounds like the easier method just from the name alone. I might try it out later, but for now I'm just gonna have all the textures sloppy and unorganized so I can make some visible progress that I can show off to someone. I've told friends that I'm trying my hand at gamedev and I don't want them to think I'm a slacker (even though I am).

 

[TheDeveloperDude]

No-nosense Football. You manage a football team. Buy new player, make tactics.
How can I improve the grafix for this game? I have no idea. Any suggestion?

 

[Ysaye]

No-nosense Football. You manage a football team. Buy new player, make tactics.
How can I improve the grafix for this game? I have no idea. Any suggestion?

You could have panels flanking each of the left and right squares respectively; I was thinking something like:

• For the recruitment pages, you could had footballer silhouettes with the left panel backgrounded with one of the colours, and the right panel with the other;
• For the tactics pages, have coach silhouettes down the side; and
• For the actual game, have some supporter babes silhouettes (because you have to bring some sex appeal?) or otherwise some fat drunk beer flinging supporters - in this one the colours at the back are different and outline the seats or stadium or something.

Was also thinking maybe underlining the squares you could at least have the football field markings, and for the game picture, having netting represented with some hatching for the locations where the netting.

 

[Bad Sector]

The whole texture atlas business is a bit over my head right now, so for the time being I'm going to load each texture individually from separate image files, and worry about packing all of them later. Hopefully I won't have to dig up too much of my own work when I get to that point.

What sort of scene complexity do you have in mind? If it isn't anything complex you may not need texture atlases at all.

This old engine of mine didn't use atlases at all, it even had a separate lightmap per polygon yet it worked fine even on some on-board Intel GPU that a Pentium 3 PC i have from 2000: