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

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