Roguelike

[comfyquest]

Hello.
I am making a classical roguelike using SFML in c++.

It is my first time making a game in c++, and using SFML, so progress is slow, both in learning game programming, the SFML library, and the c++ language. However, I am enjoying the process, even though it is all a bit overwhelming, and there is much I struggle with.

In-Game Screenshot:


Rendering the screen above takes a total of three draw calls, one for the tilemap and the wizard (single sf::vertexArray), one for the ui (sf::vertexArray), and one for the text (sf::Text) showing various values. The gui and its text uses the default view of the window when drawing so that it is always drawn in the same position on the screen.

I am considering rendering the text as a texture, part of the gui's vertexarray, since the tileset I am using comes with its own font. However, it is quite a bit more work then using sf::Text. That said, I am not sure how well using sf::Text will scale as I need more text displayed on the screen, but I have a feeling rendering it as part of the ui's vertex array is the way to go, even if I lose the flexibility of using a truetype font, and it will be more cpu intensive. Does anyone have experience writing up a method to map strings of text to uv coordinates and vertex positions?

Anyway, thanks for creating SFML. It feels very clean, simple, unbloated, and easy to work with it for a beginner like me, unlike so many other frameworks (like popular game engines).

[Hapax]

Hi.

Are you talking about using a "bitmap font" that uses your own image texture for the font or batching SFML's texts by rendering its font glyphs manually?

[eXpl0it3r]

Looks already quite neat!

As a tip, you shouldn't worry about performance at this point in time.
Creating a game is much more than just changing pixels on the screen as fast as possible.

Look at any graphics intensive game out there and think about the complexity of drawing a single frame. The meshing, texturing, shading, lighting, physics manipulation and much more. Now scale it back to you drawing a few textured quads to the screen and some text and in the future some shaders for effects.
It's not a bad thing to think about constraints and better solutions (like picking a vertex array over thousands of sprites), but your setup here doesn't require the level of optimization AAA games need for maxing the GPUs we have today.

Developing a game requires to build systems, for your entities, for your audio, for your resource management, for your level editors, for your UI, for ...
Invest your time into these systems and come back to optimizations once you actually run into performance issues. If you just keep thinking about "better" ways to do something, you'll only end up with some over engineered solution that might not provide the real benefits you were looking for and certainly not with a finished game.

Keep it up! I'm interested to see what you can create with SFML.

[comfyquest]

Are you talking about using a "bitmap font" that uses your own image texture for the font or batching SFML's texts by rendering its font glyphs manually?

I meant something like "ABC" being transformed to uv coordinates in the tileset texture, (u_A, v_A), (u_B, v_B), (u_C, v_C) These are then used to set texturecoords for quads in some vertex array at positions (x,y), (x+l,y), (x+2l,y).

As a tip, you shouldn't worry about performance at this point in time

You are right, I have spent a lot of time thinking about performance, which slows down implementing features. I guess it is because I am used to games running poorly on my hardware.

I guess my biggest hurdle will be learning the various aspects of game programing.

[yyam]

This looks super cool already! Looks like you're learning quickly

I agree with what the others have said regarding optimization. It's almost always never productive to think about low-level optimization at this stage, just write your code in a simple and straightforward way so that low-level optimization will be easy to do later on. It can sometimes be a good idea to think about higher level optimization at this stage though. For example, a resource manager so that you don't load the same texture multiple times. Having said that, if you're learning the basics, it will be difficult to judge whether something is worth worrying about. My advice would be to try not to get stuck in analysis-paralysis and just try doing stuff any way you want! You'll learn much quicker

Good luck!

[bitano]

Keep it up and good luck! I'm working on a dungeon crawler game myself (not really roguelike), but i fear if i post about it i will likely not finish it lol (happened before).

Love to see your updates though!

[FRex]

I personally really like NetHack, Elona and Dungeons of Dredmor so I wish you lots of luck too and will follow this thread.

[comfyquest]

I'm currently working on implementing a lighting (and vision) system when I came across something interesting...

Apparently, sending floating point values larger than 255 to sf::Color gives some very cool, if not odd, looking graphical effects when rendered:
https://imgur.com/a/QuqC9

This might be a fun technique for procedurally generating tiling type textures. It seems to be a repeating pattern too.

[eXpl0it3r]

It will just overflow and start at 0 again.

[comfyquest]

I'm having trouble trying to combine "baked" lights and "dynamic" lights in my tilemap.

My tilemap is a vertexarray, like in the tutorial, but I am using the vertex colors to "bake in light", meaning this light is only computed once and doesn't change. Bright lights have white vertexcolors, while no light has dark vertexcolors.

Then I have another vertexarray for "dynamic" lights, lights that are recomputed often when moved, grow or fade etc.

Right now I draw the tilemap's vertexarray first, then the dynamic lights' vertexarray afterwards, setting the dynamic light's vertexarray renderstate's blendmode to sf::BlendAdd.

The result looks like this:


The left light source is the baked-in light, while the right is the dynamic light. As you can see, the result looks pretty terrible... 

What I want to achieve is for the two to look identical, though when overlapping the strength of the light should combine to form an even brighter image. Is there some sort of blendmode that does multiplication, where the resulting pixel is always brighter?

[FRex]

You should draw all lights with additive blending into a render texture and then draw that on top of your normal drawing with multiplicative blending.

Your world without the lightning multiplied into it should be 100% bright (as if everything is perfectly lit with pure white).

You can experiment with shaders too if you want something different from that.

There was a similar topic before, there is an example code for how light add together and then multiply the scene: https://en.sfml-dev.org/forums/index.php?topic=22180.msg156556

[comfyquest]

Update
I added a basic vision/light system and my own text type that maps strings to uv coordinates in the tileset I am using, with support for colors and various symbols. The text is essentially vertex arrays with colors set by the vertex colors for each substring, and can easily be moved around and have its text replaced. It might be interesting to extend this string mapping to all kinds of  tiles so that I can save/load levels from just a set of strings.

To add these features I had to rewrite 90% of my code as it was becoming very messy and hard to work with. I foresee writing maintainable code will be challenging throughout. The vision system operates on two states: visible, and explored, being either lit by the player's light, lit by ambient light, or completely black. Right now the lights are drawn with sf::BlendMultiply from a textureless vertexarray. For the future I might draw to a rendertexture instead to allow more fancy lights, but it looks OK for now. I also added a simple scanline shader and zoomed in the view. Still, the game is a bit dark.

[comfyquest]

Update:
Well, it's been a while, but I've been quite busy. After investigating animated tiles, I eventually went down the path of making a tilemap shader. Unfortunately, great tilemap/tileset editors like Tiled did not support storing the tilemap data as an image, where each pixel contains information about uv, animation frames and length in the rgba channels. Rather than try to mess around with export scripts I made my own. This led to me abandoning the quad system I had in place before; so,  once again, tons of rewrites. I also started working on the tileset for the game, to give it a unique look and feel.

Here's an image of the very simple tilemap editor I wrote to allow me to make the fixed maps (as opposed to procedurally generated) and that stores the information in the specific format I am using (as 1 pixel per tile for graphics). I would love to hear some opinions on the tileset's tiles.


 
Before proceeding I want to plan a little better, since I've been doing so many rewrites this far, and I have barely the skeleton of a game. I am ready to (once again) put moving character in the game. However, I foresee the need to have some graphical effects which would be difficult to support with my simple tilemap shader, so I want them to be sf::sprites, or at least quads so I can animate and move them in a more complex fashion (for attacks/walking/taking damage /special effects etc.).

With a tilemap size of about 32x32 tiles to maybe 64x64 tiles (but no more) I am looking at a maximum of 1024-4096 animated characters. It sounds a lot, and it is, but it would be fun to a have level swarming with that many monsters to hack through. Now if they were each a sprite, I would have to make upwards of 4096 draw calls, which sounds a lot. If I did it with vertexarrays, would it be better? Does anyone have experience with animating many 2d characters and moving them around (maybe even smoothly) each frame? Did you solve it with vertex arrays and the cpu animating them (by changing uv coords) while updating their AI?

[FRex]

There isn't anything special about Sprites, you can do anything you can do with Sprites with Vertex Arrays too.