Thursday 7 August 2008

Monsterous

Many bugs to fix, but instead of fixing 'em I've been dithering between the best way to represent my world using immutable state (I suspect monads may be involved, and these horrors just won't fit in my brain) and... getting a model in game!

In this case, a very crappy monster has made the long and torturous transition from Blender to screen. Behold, the Cave Anemone (the five-tentacled starfish thingy):


It even casts shadows! Doesn't receive them yet, and frankly it needs better normal and diffuse textures than a few minutes in the GIMP can supply.

The screenshot also highlights the evil problems with normals at block boundaries (witness the horizontal and vertical smears visible to the left of the brave @dventurer) and the general horror that are the shadows. If you look closely, you can even see the wonderful mipmapping errors introduced by the sub-textures on the floor.

First goal will be to slap some more meshes in there, even if they're placeholders. I want one other monster type (Tentacle Mouse?), at least one inventory item and a player model. This will be enough to finally dispose of the glowing unlit spheres and @ model, and give a better clue as to scale issues.

2 comments:

humpolec said...

I'm curious, does the functional style benefit roguelikes? Why do you want to represent world by an immutable state? Will there be any advantage comparing to traditional mutable data types?

Snut said...

Primarily this is educational. I certainly can (and do) use mutable state all over the place, but I want to learn how to do things in a more functional style and slowly pare it back to a sensible minimum.

For roguelikes in particular, I think the temptation to side-effect gets pretty strong as the number of objects and interactions goes up, and once it starts things seem to spiral into a big ball of mud. Combine this with the turn-based nature of RLs, and I think they make pretty good cases for adapting to a functional style.

Advantages? Well, I definitely seen to end up with more (and more obscure) bugs when using mutable state, especially when concurrency gets a look in. There are also some interesting debugging possibilities, such as saving a world state and restoring to it later without writing any [de]serialisation code, which would be complex at best in the presence of mutable state.

Mostly though, it all comes down to a gentle way to learn about functional programming. I write spiels of C++ at work, and want to do something different (and preferably better) at home *g*