Skip to main content

Graphics mode and lighting setup.

Another roguelike developer who blogs as VJOinteractive commented on my last blog about the lighting system. Actually lighting is a problem with the blender game engine, because it can have a maximum of 8 light sources. That means either having a single light source and modulating it to take in to account the number of lights in the main viewport (Simple lighting), or using up to 8 lights and moving them around as the camera view moves (dynamic lighting).

Dynamic lighting is my preferred option, but it's not easy to represent a single torch with a single light in an isometric view. If I place the light at the location of the torch the top of the walls and anything above the player is not lit. If I place it too high up, the lighting on the character looks wrong.

There's also the fact that I'm using an old fashioned graphics mode, per vertex lighting. It's really fast and it'll run on almost any computer, even one with a crappy integrated graphics card. But the lighting options are poor. If I use a point light it has infinite distance and no fall off. The only way to fake a pool of light cast by a torch is with an overhead spotlight, but again the lighting direction looks a little weird.

So I have to decide whether to continue using per vertex lighting, or switch over to per pixel lighting with the advanced GLSL graphics mode.

GLSL lighting.
GLSL uses open GL graphics, and as such it is not well supported by older graphics cards. You need a fairly good card to get it to run. That means many tablets or laptops won't be able to run the game. It's also slower. With the older style graphics mode you get the same speed with 8 lights as you do with one. It's all calculated in a single pass. With GLSL you get slowdown with the more lights you use. However, I've checked out the latest builds of Blender and they've done some great optimizations, especially regarding armatures and mesh deformation (which can now be threaded) so performance is not quite the problem it once was.

I did some work to get my demo to work with the GLSL mode, setting textures differently and tweaking the lights. It's not something you can change with a click of a button sadly. It's not possible to provide an option for either mode depending on your computer's capabilities. I have to choose a graphics mode and move forward with development in that mode. The result was very nice, though it also highlighted some mistakes in my lighting script, such as the fact I was only using 4 lights, not 7 as I had intended, or the fact that the lights were being knocked out of alignment when they were recalculated and re-parented.

Anyway, here are some screens to show what the game could look like if I switch over to GLSL mode:

Much darker and atmospheric, but maybe too dark if you don't have a torch.
The back of characters carrying a torch is plunged in to shadow, though I could correct this by using an extra "filler light" parented to the camera.
It's also possible to have dynamic shadows with GLSL, but it really requires two shadow casting lamps per light source, reducing the overall pool of dynamic lights by half.


Popular posts from this blog

Make your game models POP with fake rim lighting.

I was watching one of my son's cartoons today and I noticed they models were using serious amounts of simulated rim lighting. Even though it wasn't a dark scene where you'd usually see such an effect, the result was actually quite effective.

The white edge highlighting and ambient occluded creases give a kind of high contrast that is similar to, but different from traditional comic book ink work.

I'll be honest, I don't know if there's a specific term for this effect in 3d design, since my major at university was in traditional art. I learned it as part of photography.

You can find plenty of tutorials on "what is rim lighting" for photography. It basically means putting your main sources of light behind your subject so that they are lit around the edges. It can produce very arresting photographs, either with an obvious effect when used on a dark subject...

..,or as part of a fully lit scene to add some subtle highlights. See how alive the subject look…

How to... build a strong art concept.

So you want to make some art assets for your game. The first on the list is a Steampunk Revolver for your main character to shoot up Cthulhu with. Quickly opening your internet browser you start with a Google image search. Ah, there is is!

It might be a good idea to find a few influences so you don't accidentally end up copying a famous design.

Just mash them up and you're ready to go! Off to your favorite modeling program.
But wait! isn't there more to building a strong design concept than that?

Of course there is.
One of the diseases of modern design is that of recursion. Everything is a copy of a copy of a copy. This is especially a problem with "historical" concepts. Over the course of that recursive process the concept becomes infected with modern design elements, and ends up looking very similar to everything else that anyone else has ever made.
If you want to come up with a really fresh idea, you have to get beyond secondary references and go look at real …


Ok, so it's not exactly skynet, but I have got my first AI state working, kind of.

The first state is "HOLD" in which case the agent stays in place where they are and shoots at any unit that comes in range. When I started writing this module, I found that the existing method of triggering actions wasn't good enough to allow the AI to choose the best weapon or target. It worked by simply sending a command to the unit to trigger the currently selected action.

If the action is valid, it triggered, if not it didn't.
That's fine for play controlled units, as that's all they need to do. But AI needs to know in advance if the action is valid. The player can get that info from UI feedback, but that wasn't available to the AI player.

There were three problems:

1. The UI feedback duplicated code in the action trigger function. These  two sets of code could get out of phase so that UI feedback was wrong.

2. The action trigger didn't give enough feedback for …