Wednesday, 18 February 2009

Still here...

Eek, no updates for yonks! In my defense, the day job is winding up towards some serious deadlines, and I'm still wrestling with immutable entities rather than making gameplay progress. Despite my desire to learn, I'm not sure I'm capable of using it in this project. I may admit defeat and return to the world of imperative updates on mutable state, but it'll make me sad if I have to.

Anyway, one of the things I've been playing with is post-processing, and generally sorting out the rendering architecture. The rendering framework started as a clone of my previous C++ efforts, and I think it's a bit ugly because of that.

Here's the current look with a post-process slapped on top. I wanted a bloom type effect, but went for a six-pointed star rather than a normal separable Gaussian affair. Sparkles should fit with the way I want to render magical spells and suchlike...


And yes, the stars aren't actually that visible with such large bright areas. And yes, it is hugely overdone for testing purposes. Expect a little more subtlety... eventually. For now, huge glow was damn satisfying!

Hmm. Just noticed the water appears to be glowing, too. That's not right.

7 comments:

Knarkles said...

I made some changes to my entity system too since the last comment I made here. I got rid of entity types and I'm creating entities based on prototypes now. However, the prototype is only referred on creation, not afterwards. Also, there can now be multiple components of the same type in the entity, and as a consequence, components now share data by storing relevant attributes in the entity, not in the component itself. I'll make a more detailed post on about the new system on my blog when I get some kinks ironed out (mainly about linking and compositing entities). So far it seems much better than the previous system.

Jotaf said...

The water is not glowing. Have you been eating some of those strange mushrooms? :P Hehe just kidding. Looking great!

(Hey look at this captcha: relol. ?!)

Snut said...

Knarkles, that sounds quite cool. What kind of uses do you find for having multiple components of the same type? I'm not hugely familiar with python, is extending the number of attributes stored in the entity easy?

I experimented with using a property bag as a weird kind of serialisation target, such that components are packed/unpacked from the bag and individual properties rarely directly used. I still end up with a plethora of Maybe/Option objects kicking around, but it might be useful eventually.

Snut said...

Jotaf, thanks :P

I found the source of the (admittedly very subtle) glow. I added some faked caustic stuff, but hadn't tested it. It's currently just making underwater areas very slightly blue and unlit, but it's almost impossible to see except in dark areas. In any case, not the desired effect.

Still, at least the mushrooms aren't to blame!

Knarkles said...

At the moment I'm only using multiple components of the same type for artillery shell triggers in my game; shells can explode on impact, above ground, after a set time, when they begin to fall etc. Another obvious use would be multiple visualizations for a single entity.

Adding attributes to objects is trivial. If I have an object "a" and want to add the property "b" with value "c" to it, I would simply write: a.b = c. I used to do components like that when there was only one of each type, where a was the entity, b was the component type and c was the component.

Now I'm just using a list for storing components and storing commonly used attributes, such as the tranformation, in the entity. So I couldn't access the physics component (which obviously takes over updating the transformation) by name, but I can access the transformation itself by using entity.transform.

Snut said...

Ah, simplicity - score one for dynamically typed languages!

I like the approach, as there are many attributes which are read by multiple components and systems, but written by very few. The transformation matrix being a great example... *g*

Out of curiosity, do you enforce read/write access so only the physics component can update the transform, or just leave it as convention that other components treat it as read-only?

Knarkles said...

Generally, I don't enforce anything, because it's not very Pythonic :) In the case of the physics component, when it's created, it replaces the transform object with a physics transform object, which directly accesses the transformation of the rigid body when reading and writing.

So for example, entity.transform.rotation would return physics.body.rotation.