A Touch of Colour

A warning: this picture will show a dramatic change from my last post.

Yes, things have colour now! But surely, colour doesn’t mean much, does it? In WPF, one simply would say line.Brush = *some coloured brush*, and you’re done. In basic OpenGL tutorials you would just add glColor3f(r, g, b) inside your glBegin and again, you’re done. Not so with Direct3D11.  In Direct3D11 its a shader’s world; there are no hardcoded variables such as colour, position, size. Instead, its all values that get passed to the shaders. In the case of this picture, all of the colours are constant over the whole shape, ie it doesn’t change per-vertex, so I stored the colour data in a constant buffer. Constant buffers store per-thing data, some value that should be used for the whole shape. Its more efficient than having a copy of that value for each vertex in the whole shape; less memory is used, as well as less bandwidth.

So now (fun)gine supports the use of constant buffers, which is a major thing when you’re talking shader support. Right now it just supports the use of one buffer, with one value, and its expected to be used as a colour, but it is trivial to generalize this to using n buffers with any values stored within. Such values could be a time value for animation, information for lights/shadows, etc.

(Tic tac toe) is getting close to done. The obvious thing thats left is user input, and game logic.

After reading a post on  AltDevBlogADay, I have rethought my approach to scripting languages. Previously, I was trying to make a semi-full featured language that you would program in. It included a bunch of things that you would need to code something, but not what you would need to write rules.

In his post, Jake talks about unnecessary language features like complicated math support. He argues that doing computations on values is problematic: it can lead to exceptions, its going to be slow to interpret, and it makes scripts very dependent on map values not changing. If you have a script that does something to an object located at some point [x, y, z], and then you download a mod that moves that object, the script is now broken.

When I was designing my scripting language, I wasn’t actually considering how I would use it to make a game, I was just looking at other languages in use and basically competing with their feature lists. But Jake’s post has made me rethink this approach. Sure, having such a language would allow you or modders’ a great deal of flexibility, but it also gives you enough rope to hang yourself.

I’m now taking the approach of having a set amount of script functionality built into (fun)gine, and then that’s it. You won’t be able to write what would amount to “engine” code in your scripts. You can only use the functions given to you by the engine to make rules and decide logic. This means you won’t have control over memory, ability to write functions, etc. If you want more behaviour then you’ll have to wait for an update to the engine, instead of trying to hack that in yourself.

I’m hoping that this will make scripts safe and efficient, and at the same time be easier to write game code with. This is what I imagine a Tic Tac Toe script would look like:

when player clicks a space

    make “x” at space

    if space is centre

        make “o” at row(space) diagonal

    or if space is diagonal

        and row(space) has middle

            make “o” at row(space) diagonal

Or something like that. Space would be defined similar to the template syntax shown earlier, when/make/if would all be functions defined in the engine.

---