Dida is coming along really nicely. I'm actually working on the gameplay part again, and it probably won't last that long until I will have a first playable (or what goes for a first playable these days).

This weekend though, I got interupted by an unexpected issue. The thing is, that I was using the managed directx 2.0 beta, and that appeared to have a timebomb in it, which just exploded (it actually threw a TimeBombException:)). The means that the beta has expired, and I'm not allowed to use the beta anymore, and that I had to upgrade to the final version. The final version of mdx2.0 is actually integrated in XNA, so I was pretty much forced to start using XNA.

Well, XNA seems quite nice. The part I was working with still contains mostly the same functionality as MDX, ie. it's quite low level, it only got a bit of an API overhoul. Besides that, there are also supposed to be many more things, like mesh loading, and content management, but I haven't really looked into those yet.

posted by Lieven 22:17



Dida Q&A Suite

Those two people who occasionally check out this blog may be wondering if Dida is still alive, or that I maybe got seduced by
XNA or something.

Well, I am still very enthousiastic about Dida, but I gotta admit that I'm currently working on a little side project (though it should still be considered a part of Dida). It's a very advanced unit testing/development visualization whatever tool, that's especially designed for game related stuff.

A big part of it is the unit testing framework, but it's a bit more advanced than the usual one. A big feature of it is that you can edit the parameters of a unit test using many different kinds of views, like a 3D view, or a timeline or so.

For example, if you're working on a box intersection test, you create a so called parametric test class, which has 2 boxes as parameters. In the tool, you can in turn create multiple instances of that test, which can all have different boxes as parameters. These parameters can be edited as normal text, but you can also place them in a 3D view, or any other view that particular parameter can be edited in.

In the future you should also be able to do many different kinds of visualization, while debugging your code. A bit like the watch window in visual studio's debugger, only with more advanced ways of visualization.

posted by Lieven 22:26




Well, the collision detection and tree are working. I have my stacked spheres character, and when I let it move downward, it is successfully stopped by the collision hull. Not really cool whatsoever, but it's what a collisionhull is supposed to be doing:). So now I guess it's time to actually do something with the collision detection, and go working on the gameplay mechanics.

Some time ago, there was an article in the gamedeveloper magazine, about building up your gameplay objects using small components. Back then I skimmed through it quickly. It seemed to be interesting, and it was definitely something I needed to look deeper into, but unfortunately that idiot of a roommate of mine took that magazine with him on a trip to his parents, and forgot to take it back. His parents also live like 2000 km from here, so I guess I won't be able to read it again in a while. Anyway, I tried to find some stuff about it on the internet, and I stumbled upon this paper:
Traits: Composable Units of Behavior. This paper presents a new concept of inheriting functionality from other classes, using the so called traits. The basic idea behind traits is: A trait is a building block of a class, that can implement methods, and also define new abstract methods. A class is then built up from a bunch of traits, where these traits are connected to each other by implementing each others abstract methods. It is not like with normal inheritence where it's a linear hierarchy of inheritence, which has the disadvantage that once some functionality is in a class, it's tightly bount to that class, and other functionality of that class can't be reused without reusing this functionality aswell. The way they implemented traits in this paper is as a language feature, which they implemented in some smalltalk dialect, but I think the concept should be implementable in C#, using events, delegates and reflection(without modifying the language;)).

Well, I think those traits are great to compose gameplay objects. To give an example:
  • The basic player trait only provides a handfull of functions, like an abstract Update, and a GetPosition and a SetPosition.

  • The collision-world-movable-trait adds a DoMotion function to the class, which does collision detection, and then sets the new position using the SetPosition function.

  • The walk trait lets you generate motions using your joystick, and applies them using the DoMotion function.

  • The inventory trait, which implements an Update function, and listens to the dpad of your joystick to select items. This trait provides a method GetCurrentWeapon()

  • The shoot trait, also implements an Update function, and lets you ahoot using the weapon returned by GetCurrentWeapon()

  • Get the idea?

    Now if you for example want to use a different type of inventory handling, you just reimplement the inventory trait, and mix it in your class.

    Ok, I know that this sounds like something you could just as well do with interfaces (and it is true that interfaces try to tackle the same problem as traits), but the idea of traits is that a component can both implement, and request new functionality. If you wanted to do this with interfaces you would have to create lots of (very small) interfaces, whos implementations have pointers pointing to each other. Another problem with interfaces is that you will have to know in which interface a method is defined (by example, was the DoMotion function defined in the collision-world-blabla trait, or in the base trait (The one that has the SetPosition function). Traits on the other hand are extremely flexible and self containing.

    posted by Lieven 18:05



    Debug Drawing

    Today I continued working on the CollisionTree, and I *think* I should have the basics working by now, but I don't really know it for sure;). The thing is, that I didn't really have a convenient way to test it yet. In my experience, the best way to test something like this, is to make everything, from triangles, to node boundingbox, to whatever, visible in 3D. Up until now, I simply did these kind of things by directly calling the opengl drawing functions from the main graphics loop. But the CollisionTree is pretty complex, and so to do this well, I would have to actually put OPenGL code inside the CollisionTree class (which is in a module which I try to keep clean of any graphics related api related stuff).

    Because I'm certainly going to need this kind of debug drawing more often, and since it would be nice to be able to keep this visualization code in my engine, I decided to make a library with some debug drawing functions. It contains a static class, containing functions like DrawLine, DrawBox, which let you draw stuff to the screen, It also contains a DebugMesh, which can be used for static meshes, like a collision world.

    But the real cool things are DebugDrawContexts. These contexts allow you to render debug information totally independent of the graphics thread and framerate. You can request such a context from any thread, at any time, draw your stuff to the context, and forget about it. The context will then automatically be visible, in the next graphics frame, and won't disappear until you explicitely remove it from the scene. If you request the same context again, you can redraw it (and while you're drawing, you will still see the old context), and after you call the EndDrawing function, this new "drawing" will be visible. This allows you to easily do debug drawing of gameplay stuff that's running in a different thread, and probably at a different framerate.

    There are also timed contexts, which will disappear after a given time. These contexts are very handy for showing things like text balloons, which give information
    about a certain event in your scene.

    posted by Lieven 01:11



    Collision Detection

    The last couple of days I've been working on the collision detection. I am going for the sphere -> triangle approach, and I'll represent the collision hull for characters using multiple spheres that are stacked on top of each other. At
    work (before our engine was brutally murdered and replaced whit some ever famous fps engine), we used to use one ellipsoid to represent a character. This worked fine, and it wasn't much harder to progam than the sphere test either, for we just scaled the whole situation to a sphere triangle test, but it had one major drawback: You wouldn't be able to do collision detection against rotating objects, that were rotating around any other axis than the y axis. (Because that would scale to a situation where the triangle has to morph over time. And believe me, that's not something you want to make a collision test for).
    In my engine, I want to be able to have objects rotate in all possible ways, so I went for the sphere approach.

    I've got the sphere -> single triangle test working already. It went actually pretty well. I used the same algorithm we used at work before, so I know it's a working and stable algorithm, but it still is a tricky to implement (I didn't have any reference whatsoever, only what's in my head). Anyway, I've implemented it, and tested it, and it seems to be working fine, even all special cases I've tested didn't show any problems.

    Tonight I'm gonna continue on a CollisionTree to speed up collision testing against a wolrd that contains many polygons It's definitely gonna be very cool, so stay tuned!

    posted by Lieven 13:31



    Dida blog

    Since overybody (
    link link link) seems to be blogging about his coding advantures lately, I couldn't stay behind, so here it is, my development blog about my hobby project Dida.
    Dida is going to be a game engine, that for once isn't focused on graphics, but is focused on gameplay, animation game logic. etc. Just everything a game really needs to be fun, not just eyecandy.

    Until now, gameplay wasn't really something that was part of an engine, because it was thought to be way to specific to make a general solution for. Imho, that's true to some extends, but I still think that it should be possible to make a framework that will make gameplay programming a hell of a lot easier than it is now. By example things like interaction with the world, state management and stuff should all be way easier than they are now. Oh, and I want code that's written for dida to be clean, modular and maintainable, and not like in some other engines just a big blob of code that's hacked togehter, and will fall apart when the tiniest thing is changed.

    posted by Lieven 13:29

    Other Bloggers
  • nervedemosystem
  • Boson
  • Walter Tamboer
  • Eternal lands development
  • walter still rules
    Cool Projects
  • Mono, .NET for linux n co
  • OGRE
  • walter still rules