Friday, September 9, 2011

Using the benefits of lambda functions with a component based game object model

Hi everybody!

Today I'd like to introduce a feature of the new C++11x standard, which is implemented in the Visual C++ compiler of the 2010 edition of visual studio and newer versions of gcc.

The new feature I'd like to talk about is the Lambda Function.

A Lambda Function is an anonymous function...
What exactly that means is demonstrated in the code below.

I'm going to refer to my last blog post (Component based game objects) and take components as an example.

 class IComponent
{
public:
virtual void update(float gameTime) = 0;
virtual bool handleMessage(Event const & componentEvent) = 0;
};
This is the (simplified) interface I'm using for components.

Now think about what you would do if you have, for example, a game object which needs to respond to mouse movement events.

You really need this behaviour only for this particular object and nothing else.

So far one had to write a new IComponent implementation for this.
Think about the mass of this kind of components you'll have at the end of your project...

Fortunately the Lambda Functions will help us with the mass of implementations for this "one purpose components".

Consider the following IComponent implemention:

 typedef std::function<void(float)> UpdateFunction;
typedef std::function<bool(const Event)> HandleEventFunction;
class VersatileComponent : public IComponent
{
public:
VersatileComponent(UpdateFunction updateFunc,HandleEventFunction handleFunc){
this->m_updateFunction = updateFunc;
this->m_handleFunction = handleFunc;
}
void update(float GameTime){
m_updateFunction(GameTime);
}
bool handleEvent(const Event &gameevent){
return m_handleFunction(gameevent);
}
private:
UpdateFunction m_updateFunction;
HandleEventFunction m_handleFunction;
};

What this component does is taking 2 functions as parameters and performing them.
(for those of you who are not familiar with std::function (or std::tr1::function) check out Effective C++ (Scott Meyers has some great items in there which covers std::function) or this link.)

What you can do with the above implementation is something like this:

 bool handleMouseMovement(const Event &gameEvent){
if(gameEvent.getType() == MouseMovement){
//DoStuff
}
}
void update(float deltaTime){
//DoStuff
}
int main()
{
VersatileComponent *vComponent = new VersatileComponent(update,handleMouseMovement);
//DoStuff
}

Here we just define 2 functions which takes the same parameters and return the same types as the update and handle function of the VersatileComponent class... We just pass them as parameters so they get called in the VersatileComponent update() and handleMouseMovement() function.

(Look here if you need a refresh in function pointers)

So...That's nothing new so far, but now I'm going to use Lamda Functions (or anonymous functions, if you prefer).

I'm just going to throw this code at you, before I'll do any explanation:
 int main()
{
VersatileComponent *vComponent = new VersatileComponent([](float gameTime){
//DoUpdateStuff
},[](const Event &gameEvent)->bool{
if(gameEvent.getType() == MouseMovement){
//DoStuff
}
});
//DoStuff
}
I know this does look weird at first, but I'm just doing the same as in the previous code example...I'm passing two functions as parameters...two Lambda Functions.

As you might see, Lambda Functions are getting defined at the point where they are needed.
They don't get named (well they get internally,but you don't know the name of them), so you can't call them in other places of your code.

They also have some kind of unique initialization syntax, which you can look up here (the link also features more informations about Lambda Functions).

The benefit of this approach is, that you don't have to declare functions in other places of your code only because you need them once. (see the example with the function pointers)

With the new Lambda Functions the VersatileComponent truly gets maximum versatileness.

BTW: Just for your information : I don't get nothing for linking to Amazon items. ;)

Wednesday, August 10, 2011

Switching from hierarchical to component based game object design.

Hi everyone,

I read some interesting articles about component based game objects the last few weeks and after testing and playing with this kind of game object architecture, I decided to throw away my existing hierachical game object architecture and stick with the component based instead.

I know it's unthankful work and I really try to not think about it too much, but while I was playing around with this kind of architecture, I defenitly saw the advantages compared to the hierarchical one.

As you can see on the left, I already created an UML diagramm for better understanding.

I don't know if I will stick with this implementation, as I threw it together in just no time, but I think it's defenitly going into the right direction.













Enough on that topic, now I want to say a little bit about my private stuff.

As some of you might now, I just finished my apprenticeship about 5 weeks ago. I currently still work in the company I made my apprenticeship in, but I really want to get into this gaming stuff so I applied for a place in a german college of computer science - specialisation game development (FH Heidelberg).

After some really, REALLY annoying bureaucrazy I finally got the answer from the college that I can matriculate. So from the 1st October 2011, I'm officaly a student :)

Monday, June 27, 2011

Particle implementation.

Hi internet!

I've just successfully finished my oral exam (damn that sounds dirty).
So my time as an apprentice is officially over, which means I have more time now to focus on my 2D engine.

In this post I want to show you how I implemented the particle system in my engine using the decorator pattern.

First some UML:

As you might see here I decided to derive the particle emitter into a finite and an infinite subclass. The finite emitter stopps after it spawned n particle (determined by the setParticleAmount() method) whereas the infinite emitter runs as long as isStarted() return true.

The most difficult thing was to cover all the things a particle system must do (e.g. transparency, spreading, collision detection, etc.).






To provide all those contingencies I decided to use the decorator pattern (I just read the book Head First Design Patterns (a really good book), so all that stuff was still in my mind ;) ).

The particle system runs pretty well, although some of the subsystems (especially the transparency) don't work as expected yet.

Tuesday, June 21, 2011

Interesting article

Yesterday one of the guys I'm following on twitter posted this link :
http://www.agner.org/optimize/optimizing_cpp.pdf

It's a link to a very good article about optimizing C++ applications.

Sunday, June 5, 2011

Personal point of view (game engine).

(This post is absolutely IMHO so if you disagree with some points, that's just fine ;) )

Since I'm registered in the GameDev.net forum I noticed many people who were quite clueless wether they should make their own game engine or use a premade one.

I kept asking these questions myself back in the days I started game development and so I though it would be a good idea to make a little post about my personal point of view when it comes to game engines.

Before I start, I'll give you some examples of what I'd like to call good premade game engines:
  • Ogre3D (which is open source)
  • Unreal Development Kit (which is free for non commercial games (I was surpised when I heard about this))
  • Unity3D
  • RPG Maker (Which I made my first game with back in 2001...Man, that game was shitty!)
Check out the websites of these engines to learn more about them.

The first thing you should ask yourself when it comes to choose between selfmade and premade is why you want to make a game (engine).

Are you doing it for the sake of learning or just to, well..., make a game?
And, secondly, are you just doing it for fun or to make some sort of portfolio to get your foot into the industry (and if so,what kind of job do you wish to get? Developer, designer, etc.)?

Thats the points you should be certain about.

If you just want to make a game and don't care about the stuff going on in the background you should be fine with a premade engine. The learning curve should be much higher compared to a selfmade engine. (If you wish to work as a designer even a level editor like the Hammer editor from Valve (which you can get on Steam), or the Unreal ED (which is included in the above mentioned UDK and a part of nearly every installation of a Unreal related game (Unreal Tournament,Unreal)) should be enough to improve your portfolio).

I know that many people disagree with me on this point, but if you are interested in how things work (and especially as a developer) you should definitely start with your own engine. I learned tons of stuff since I started to work on my own 2D engine. Of course, programming your own engine shouldn't be your first project. I would recommend you to start with 2-3 simple games like Pong,Tetris or Pacman(especially Pacman is harder to realize then you might think at first) to get a feeling what components it takes to make a game.

If you are interested in starting your own engine, I can recommend the following books:
If you're stuck at one point and definitely have no idea what's wrong you should register in the above mentioned GameDev forum and search for your issue...Maybe some guy had the same issue before.

Monday, May 23, 2011

Addiction 2.0

Can't post...Must...play...Terraria...such a....great...gaaaammmeeeee aHAHHHAAAA