Goblinson Crusoe


#1

Here are some recent images of my game, Goblinson Crusoe:

Goblinson Crusoe is a turn-based, hex-based hack-and-slash/rpg that I have been working on for a couple years now (in between kids, a house and a full-time job). The game features elements of crafting, a variety of encounters (boss fights, dungeon crawls, base offense, base defense, etc…), exploration, and intense turn-based combat. It is still very much in progress, but it is coming along.


#2

Looks quite nice. Is it based on Urho3D?
And do you have plans to open source and/or share some tutorials on how to make it,like the plants, and dynamic lighting effects?


#3

Yes, it is made using Urho3D. I use a slightly modified Urho3DPlayer.exe (that includes some of my own stuff, notably a few custom components and my Perlin noise library), and the bulk of the game is written in Lua.

The lighting is simple point lights in the basic Forward renderpath, a testament to the power of Urho3D “out of the box”, since I get decent performance even with a fairly large number of lights. I use the Bloom post-process, no gamma correction. The hex ground tiles use a tri-planar based shader that I have written about here on the discussion forums before. Those tiles are really about the only non-vanilla stuff I do; well, that and a high-light shader that gives a faction-colored highlight to objects when you hover over them with the mouse.

For the plants, I use a variety of techniques. Some of the small shrubbery-type plants were created using ngPlant. Larger trees were created in Blender using the technique described at https://simonschreibt.de/gat/airborn-trees/ though I’m still perfecting my modeling techniques there. Various other ground-cover type grasses and whatnot are created as billboard clumps.

I do all the artwork myself, mainly in Blender and the Gimp. I make use of procedural methods when I can, to save some labor. I have also lately been experimenting with using MakeHuman to generate humanoid (goblin and ogre type) characters lately, again to save some labor. I tend to write more frequent updates about the game in my dev journal at https://www.gamedev.net/blogs/blog/33-why-you-crying/


#4

Seeing some great improvements in graphics. I really like the tiles 'n trees.


#5

Thanks for the detailed explanations. Do you have playable demo download link so that we can try out? The screen shots looks really tempting.


#6

Thanks, guys. I don’t have a playable demo yet. I am working towards one that I can release to a small group for some feedback and testing, but I doubt I’ll do any kind of wide release any time soon. It’s not far enough along that I’d feel comfortable with that right now.


#7

I’d like to encourage you to share it out among this community at least. There are not many complex and beautiful demos right now using Urho3D(compared to other engines). Yours would be a great addition.
BTW, I enjoy reading your gamedev blogs. Thank you for writing it.


#8

It is great to see GC take its place on the forum, with notable improvements! and I’m hoping to see more as it evolves.

I started my own Urho Test Chamber with a port of your camera controller from your gamedev blog and your triplanar shader. :slight_smile:


#9

Looks beautiful. Long time project. Keep up the good job.


#10

Looks neat. I suggest you to add gamma coorection and tonemapping. It will make your lighting and effects look even cooler.


#11

I haven’t had good luck with using gamma and tonemap. Admittedly, I don’t know jack squat about either so I wouldn’t know how to tune it, but when I append Preprocess/GammaCorrection.xml to the render path I get this result:

Appending Tonemap.xml just makes it look even worse:

Personally, I prefer the “warmer” look without gamma correction.


#12

do you have HDR rendering enabled?
There are three methods of tonemapping in Tonemap.xml, it seems like you need to delete or disable two of them. Also, tonemapping might a have gamma correction be built in it, or it might not. I bet Uncharted does.

I recomend using Uncharted as I’m not sure wich of the reinhard methods the other two are.

It’s up to you of course, a matter of taste. But your second screenshot has a lot of excessively bright stuff and it should benefit from it.


#13

That first one looks much better in my eyes, there is less light burning vs your earlier screenshots.


#14

I think the first screenshots looks more old-school style, while the new one (the non-totally dark) looks a bit more “pastel” as seen in newer games.
Personally I’d prefer a custom post-processing filter to have a good compromise between the two and most of all, I would like to encourage the developer, as artist to make the game look as how he want us to feel it. :slight_smile:


#15

So, I’m trying to figure out this gamma correction and tonemapping stuff, and I just can’t seem to obtain a result that is palatable to me. Here’s what I’ve got. I enable HDRRendering, then set up some keys to toggle the gamma correction and Uncharted2 tonemapping effects.


In the top left is the scene with neither tonemapping nor gamma. On the top right is gamma correction only. On the bottom left is tonemapping only. And on the bottom right is both.

The result reminds me of this old VGCats strip that says ‘real is brown’: http://www.vgcats.com/comics/?strip_id=222

I could possibly live with the tonemap/no gamma version (with some adjustments to the particle effect colors so it’s not so brown). But anything with gamma just seems washed-out and basically unplayable to me. The only one of those 4 versions that seems in any way alive and vibrant and warm is the one without either postprocess filter applied. Am I just doing it wrong? Is this really how people play their games? Admittedly, I haven’t bought a ‘new’ game in over a decade, so I’m probably out of touch with what gamers expect these days, but if I did buy a new game and it looked washed-out like that, I doubt I would play it more than a few minutes.


#16

whoops, I forgot couple more things you have to do , sorry.
So if you still willing to try it out linear pipeline, and have some patience to not tell me to piss off with my nex-gen bullshit, here are they:

You have to add srgb tag in xml next to all your defuse textures (or do SetSRGB() in code):

<texture>
<srgb enable="true" />
</texture>

And probably readjust some of your lighting settings. Making lights brighter and ambient light darker.


#17

Heh. I’ve got enough assets in there now, I’m not to keen on the idea of modifying every texture definition, especially since I’m not really convinced of the need. Guess I could start with the terrain textures, though, and see if they make a difference.


#18

Enabling srgb on the textures doesn’t seem to have done anything at all. I found a setting in Graphics to enable sRGB mode, but enabling that one makes things even more washed out:

That one is with sRGB in Graphics enabled, and gamma correction enabled in the render path.

Thing is, I looked through some of the samples (like the PBR one) that have gamma and tonemapping enabled, and I don’t really like the looks of them at all, either. It makes everything seem just washed out and gray, kinda bleak to me. I mean, it probably has its place, but the look and feel I’m going for is a vibrant, cartoony, high-saturation world, so I’m not sure it’s really appropriate.


#19

I think the top left is the most charming one. Look forward to playing the demo some day.


#20

I agree that the original unfiltered version looks best, but I also think some color mapping could make it even better!

As I understand it, setting sRGB in Graphics has the same effect as adding the gamma correction post-process filter. (The first uses the graphics hardware, while the second uses software and loses some precision) If you use both you’ll get a double correction.

Assuming all your textures are in the sRGB color space (they almost certainly are), the “correct” thing to do would be:

  1. Enable sRGB on all your textures (is there a quick way to do that?)
  2. Enable sRGB output on Graphics

That way, the textures will be converted from sRGB -> linear as they’re read, the lighting calculations will use linear colors, and the results will be converted from linear -> sRGB so they look right on screen.

Your lighting values will need to be changed, probably reduced a lot, because they’ll be interpreted as linear rather than sRGB values. For example 50% gray (#808080) is fairly dark in sRGB, but looks much lighter as a linear color.

Here’s a great article that helped me get my head around sRGB vs linear lighting: http://filmicworlds.com/blog/linear-space-lighting-i-e-gamma/

Not doing any color mapping generally looks OK because both textures and screens are generally sRGB. It’s only when you start alpha-blending or doing lighting calculations that the results aren’t quite right.

Overall, though, you should definitely go with whatever looks best, whether it’s “correct” or not!