SFML community forums

General => SFML projects => Topic started by: Tank on November 14, 2012, 08:34:25 pm

Title: Game Development Design articles
Post by: Tank on November 14, 2012, 08:34:25 pm
Hey guys,

I recently decided to do some writing work on some game programming topics. The first article is finished and I'd like to show it to you guys – articles that don't get read are quite useless. :)

Further articles will follow irregularly, when there's time and I'm in the "writing mood".

Feedback is very welcome. It would be interesting to know if the article is of any real help for you and if you'd like to see more of that sort about other topics.

WEBLINK: Game Development Design (http://stefan.boxbox.org/category/game-development-design/)

Laurent: Not sure if this fits into the projects section, as it's not primarily targeted at SFML. Feel free to move it anywhere you like. :)
Title: Re: Game Development Design articles
Post by: Nexus on November 14, 2012, 09:04:13 pm
This is great. Especially that topic, just the day before yesterday I had a look at several articles concerning component-based game design :)

The third approach (self-attaching components) looks interesting, but it sounds too good with this short description. Do you plan to explain a little bit more detailed how it is implemented, or do you have links with deeper explanations? The behaviors still need to access the properties somehow, how is the recognition "automagically" performed?

Some remarks: You write "leave a commit" instead of "comment" (too much Git recently? :D) and the example EntityFactory::create_tree() doesn't return a value. Apart from that, the text is well-written, without much bla bla, and easily understandable. Continue like this!
Title: Re: Game Development Design articles
Post by: FRex on November 14, 2012, 09:31:08 pm
Maybe it's more of a thread that should go into General forums.
I'll be sure to read them all thoroughly.
The beggining just cracks me up, 'preview' shows:
Quote
I’d like to congratulate you [...]
and then after a click the full rest of the sentence turns out to be:
Quote
for choosing one of the hardest and most difficult areas of programming.
which is so ironic and funny to me.
Quote
You write "leave a commit" instead of "comment" (too much Git recently? :D)
;D ;D ;D

Not that I disagree about mad inheritance but:
Quote
Multiple inheritance is really bad, because it can lead to severe problems (e.g. in the example above, TreeWithLeavesAndApples inherits Tree twice!).
I'm not sure about that so correct me if I'm wrong:
wouldn't that be ok since c++ will create two Trees withing TreeWithLeavesAndApples?
Or even better: wouldn't virtual inheritance fix that and create single Tree(actually mandatory if Tree is interface)?
Title: Re: Game Development Design articles
Post by: Tank on November 14, 2012, 11:34:34 pm
This is great. Especially that topic, just the day before yesterday I had a look at several articles concerning component-based game design :)
Good timing then. :)

Quote
The third approach (self-attaching components) looks interesting, but it sounds too good with this short description.
I was afraid it's not explained enough. I think a second part that covers some more implementation details or more detail in general would make sense. Besides that, I have a working implementation of the approach in a game; so it's nothing in theory only.

Quote
The behaviors still need to access the properties somehow, how is the recognition "automagically" performed?
Yes, the controllers do access the properties of entities, because that's what they are working on. The automatic attaching works by defining rules in each controller that tell what properties it requires. I will cover all of that in part 2.

Quote
Some remarks: You write "leave a commit" instead of "comment" (too much Git recently? :D) and the example EntityFactory::create_tree() doesn't return a value.
Not only recently, but always. ;) Thanks for pointing it out, both mistakes have been fixed.

Quote
Apart from that, the text is well-written, without much bla bla, and easily understandable. Continue like this!
Thanks for your feedback!

@FRex:
No, inheriting from multiple classes results in one single class. That's why it's problematic, especially when different base classes have one equal ancestor. I personally think it's okay (and required) for inheriting interfaces or utility classes. But inheriting from two full-blown classes is mostly a design flaw in my opinion.
Title: Re: Game Development Design articles
Post by: masskiller on November 15, 2012, 02:42:26 am
This looks quite interesting indeed. I was going for a sort of mixed approach of justified use of inheritance and separated entity work that relate themselves with either pointer or instances (when needed), but this got me to start thinking outside of my self-imposed box. I'd like to see a source code example to fully understand this approach.

Quote
I think a second part that covers some more implementation details or more detail in general would make sense. Besides that, I have a working implementation of the approach in a game; so it's nothing in theory only.

Indeed this would help a lot with further understanding.
Title: Re: Game Development Design articles
Post by: Lo-X on November 15, 2012, 06:58:40 am
Yay !

I write myself some articles from time to time... (even if it's been a long time since the last one :p) and I really like to read someone else articles, especially about Component system !
Title: Re: Game Development Design articles
Post by: Tank on November 15, 2012, 08:38:19 am
Quote
I'd like to see a source code example to fully understand this approach.
The next part will not really include full source code. Like described in the intro, I will definitely add crucial parts as source, pseudo-style, to understand how things are meant to be. But hopefully the text will be detailed enough for the readers to continue in their source code.

Quote
I write myself some articles from time to time... (even if it's been a long time since the last one :p) and I really like to read someone else articles, especially about Component system !
Show them! :)
Title: Re: Game Development Design articles
Post by: Lo-X on November 15, 2012, 12:28:40 pm
Quote
I'd like to see a source code example to fully understand this approach.
Yes me too :D

Quote
I write myself some articles from time to time... (even if it's been a long time since the last one :p) and I really like to read someone else articles, especially about Component system !
Show them! :)

Unfortunatelly, theses articles are in french (and a link is provided on the french forum.. somewhere :p)
I wanted to write some articles or translate existing in english, but I never had the time to. Furthermore, I'm not so good in Eglish :p
Title: Re: Game Development Design articles
Post by: panithadrum on November 15, 2012, 12:38:13 pm
I read it and looks awesome. I'm waiting for the next part!
Title: Re: Game Development Design articles
Post by: Tank on January 19, 2013, 02:48:48 am
Part 2 of the component system article is now available. (http://stefan.boxbox.org/2013/01/19/game-development-design-the-component-system-part-2/) Have fun! :)
Title: Re: Game Development Design articles
Post by: eXpl0it3r on January 19, 2013, 02:57:23 am
YES! So much win! ;D

Will there be more parts?
Title: Re: Game Development Design articles
Post by: Tank on January 19, 2013, 03:00:30 am
Parts about the component system? No, I don't think so. About other topics? Yes, I'd like to do that. However, like stated in the opening post: When there's time, I'm in the proper writing mood and people can make use of the articles in any way. ;)
Title: Re: Game Development Design articles
Post by: masskiller on January 19, 2013, 09:59:03 am
Great! I've been expecting this one for a while now, after reading more on move semantics this seems like the best way to go on what I've been wanting to learn lately.
Title: Re: Game Development Design articles
Post by: Laurent on January 19, 2013, 10:53:41 am
Quote
use dynamic_cast<> in debug builds and reinterpret_cast<> in release builds
Isn't it rather "static_cast<> in release", if you're talking about downcasting? Or even boost.polymorphic_downcast ;)
Title: Re: Game Development Design articles
Post by: SuperV1234 on January 19, 2013, 02:25:50 pm
Is there a noticeable overhead in using Property<int> instead of actual ints?
Title: AW: Re: Game Development Design articles
Post by: eXpl0it3r on January 19, 2013, 03:28:42 pm
Is there a noticeable overhead in using Property<int> instead of actual ints?
I guess it really depends on the use case and implementation. I guess it could be possible to write it in a way, so the compiler can optimize to an int directly.
Besides that a component system isn't about a certain type, but about any type, which are part of the whole system. But I guess if you only use/need ints, then you won't need such a generic way, as said in the article , it is only needed because we want one type that fits all types. ;)
Title: Re: Game Development Design articles
Post by: SuperV1234 on January 19, 2013, 03:54:28 pm
Thanks for the reply. I'd like to see an implementation of this :)
Title: Re: Game Development Design articles
Post by: cire on January 19, 2013, 07:44:26 pm
It's not exactly an implementation, but Game Programming Patterns (http://gameprogrammingpatterns.com/component.html) does a pretty good job of illustrating the component pattern with a realistic example using C++ code.
Title: Re: Game Development Design articles
Post by: Tank on January 19, 2013, 10:25:57 pm
Laurent: That is correct, thanks for the pointer.

SuperV1234: Yes, there is overhead. If it is noticeable depends on your implementation. It is possible to reduce the complexity to one single indirection operation when accessing properties. For example, you can fetch pointers to the property values when the controller is created and store them as members in the controller.
Title: Re: Game Development Design articles
Post by: FRex on February 09, 2013, 03:07:52 pm
Are there going to be more? :o What will be in them? Will you write about Lua in general/Lua in FlexWorld?
Title: Re: Game Development Design articles
Post by: Tank on February 10, 2013, 02:02:03 am
Yes, I'm planning on writing more articles. Like always, that depends on time and mood. ;)

I already have some topics in mind that are probably worth writing about. Mostly things that are discussed/explained again and again, especially on the IRC channel, like basic code dependency problems in games, separation of logic, data and rendering and much more.

Your idea of writing about embedding scripting languages for game development is also a nice topic. I think it might be useful for a lot of people, because it allows rapid prototyping and completely separating logic into an external language, which can be mostly reloaded during runtime.

However my main focus for the next articles is clearly code design. In my opinion game development is very often tried by newcomers not having a solid C++ background, so knowledge about designing the core structures is missing. When development in a project is progressing, people are not refactoring their stuff, and soon realize the mess they've produced, which results in losing overview, frustration and therefore cancellation of projects, unfortunately. I'd be happy if I could at least help some people to avoid making such "mistakes".

But still, I'm of course very open for ideas!
Title: Re: Game Development Design articles
Post by: Tank on February 10, 2013, 04:41:46 am
Game Development Design 2: Good Habits, Techniques and Workflows (http://stefan.boxbox.org/2013/02/10/game-development-design-2-good-habits-techniques-and-workflows/)

Have fun, feedback appreciated.
Title: Re: Game Development Design articles
Post by: FRex on February 10, 2013, 11:59:53 am
Quote
like basic code dependency problems in games, separation of logic, data and rendering and much more.
Awesome!
I'm looking very forward to that (esp. that this last article was mostly correct when it said I'm probably sighing).
I'm also looking forward to scripting article because you probably have Lua bias(and so do I  ;D ).
Title: Re: Game Development Design articles
Post by: downtimes on February 11, 2013, 02:05:40 am
If you keep the Quality of your work on the same level it doesn't really matter much about what you write. All the topics you stated have enough stuff you can write about.
Very interesting article. After reading it i was instantly temptet to try a little prototype of your described system (talking about the self-attaching Component System; not enough time currently though).

Looking forward to your next Article.
Title: Re: Game Development Design articles
Post by: Tank on February 11, 2013, 08:21:47 am
Quote
After reading it i was instantly temptet to try a little prototype of your described system
Using test-driven development, I hope! ;)

Quote
I'm also looking forward to scripting article because you probably have Lua bias(and so do I   ).
I'm actually more biased to Python than Lua, but in my opinion Lua is much better embeddable, faster and more lightweight. Keep in mind an article about using scripting languages won't be a tutorial on how to do it in detail. What problems do you exactly have in that area?

Thanks for your feedback.
Title: Re: Game Development Design articles
Post by: FRex on February 11, 2013, 12:58:09 pm
Quote
What problems do you exactly have in that area?
I'm just learning Lua 5.2, so far I know stack managment, in-Lua syntax, C function calling and creating (meta)tables for user data or functions. But as always : I have no
Quote
solid C++ background, so knowledge about designing the core structures is missing
and I don't know how to put that all to use together. :P
Quote
like basic code dependency problems in games, separation of logic, data and rendering and much more.
But that is really more interesting, I'd rather not double the amount of languages I have design problems in. ;D
Title: Re: Game Development Design articles
Post by: Tank on February 11, 2013, 07:48:51 pm
I see. :) I guess general design issues are most popular among developers. ;)
Title: Re: Game Development Design articles
Post by: FRex on February 11, 2013, 08:27:14 pm
Right ;), what is a good way to split rendering and logic? And how do entity components in entity system communicate?
Title: Re: Game Development Design articles
Post by: Tank on February 11, 2013, 09:12:57 pm
Quote
what is a good way to split rendering and logic? And how do entity components in entity system communicate?
Those questions are very general. I'll probably talk about the first one in another article, because it can't be explained in two sentences (at least I can't). Regarding the second question: Do you have an example/use-case? I'm not quite sure what you're trying to do.
Title: Re: Game Development Design articles
Post by: FRex on February 11, 2013, 09:22:32 pm
Scrap the second question, I'm probably too new to entity approach to understand it yet.. that's alright.
Quote
I'll probably talk about the first one in another article,
Is it going to be based on mvc? It apparently can be used in games: http://www.gamasutra.com/view/feature/2280/the_guerrilla_guide_to_game_code.php
Title: Re: Game Development Design articles
Post by: Tank on February 12, 2013, 07:57:44 am
If you separate your data model, business logic and rendering, you're always doing "MVC", so yes.
Title: Re: Game Development Design articles
Post by: FRex on February 23, 2013, 11:05:24 pm
Unrelated to GDD, I finally trusted your vim article and got gVim and it's not that bad, GUI makes it a bit better because prompt flashes nastily if you keep pressing j while at last line and you can always look up the command in the menus, I might use it for taking notes, typing code for languages that don't benefit from vs and maybe integrate it into vs as tips wiki says, and if ever on Linux I'll probably not use gedit, emacs or whatever at all. It's actually easy to use, I mean really.. optional number + operation + optional number + move is just genius and intuitive way to edit things. It'll probably take me some time to learn it all but getting used to hjkl instead of arrows was quicker than I'd thought, the tutorial is right. I'm really surprised, normal editors seem a bit cumbersome. And running command in and then dumping command result into file without quitting vim by just typing few letters and then the command.. wow.. :o

And of course, you look so damn pro to someone who's watching when using it and things just pop in and out of the text seemingly at random very quickly. 8)
Title: Re: Game Development Design articles
Post by: Tank on February 24, 2013, 01:54:47 pm
I'm so glad that I could help to enlighten someone. :P Congrats on your decision, you won't regret it. :)
Title: Re: Game Development Design articles
Post by: FRex on February 24, 2013, 02:07:19 pm
It's not like I'm writing much anyway and vs10 still wins for c++ but I'm really surprised by the functionality I've seen so far.
Title: Re: Game Development Design articles
Post by: Indorile on March 24, 2013, 07:18:04 pm
Hey there.
I started writing my platformer game in C++/SFML and inspired by your article I went with the self-attached component system route. So I started implementing and came with a working solution. Thing is its a "working solution", my C++ skills are rusty as hell after spending about 6+ years with C# and NeoAxis engine, so code could use some refactoring even at this early stage. So here are some relevant parts of the code:

BaseAttribute:
// HPP
#ifndef BASE_ATTRIBUTE_HPP_INCLUDED
#define BASE_ATTRIBUTE_HPP_INCLUDED

#include <string>

namespace ksg
{
    class BaseAttribute
    {
    public:
        virtual ~BaseAttribute() = 0;

        const std::string& getName() { return m_Name; }

    protected:
        std::string m_Name;
    };
}

#endif // BASE_ATTRIBUTE_HPP_INCLUDED

// CPP
#include "../include/BaseAttribute.hpp"

namespace ksg
{
    BaseAttribute::~BaseAttribute()
    {
    }
}

Attribute:
#ifndef ATTRIBUTE_HPP
#define ATTRIBUTE_HPP

#include <string>
#include <memory>

namespace ksg
{
    template <typename T>
    class Attribute : public BaseAttribute
    {
    public:
        Attribute(T value, const std::string& name)
        {
            m_Value = value;
            m_Name = name;
        }

        T& getValue() { return m_Value; }

    protected:
        T m_Value;
    };
}

#endif // ATTRIBUTE_HPP

BaseComponent:
//HPP
#ifndef BASE_COMPONENT_HPP
#define BASE_COMPONENT_HPP

#include "BaseAttribute.hpp"
#include <vector>
#include <memory>

namespace ksg
{
    class GameObject;

    class BaseComponent
    {
    public:
        BaseComponent(std::shared_ptr<GameObject> parent);
        virtual ~BaseComponent();

        virtual std::unique_ptr<BaseComponent> clone(std::shared_ptr<GameObject> parent) = 0;
        virtual void update(float dt) = 0;

        bool checkRequiredAttributes(std::shared_ptr<GameObject> obj);

    protected:
        static std::vector<std::string> m_RequiredAttributes;
        std::shared_ptr<GameObject> m_Parent;
    };
}

#include "GameObject.hpp"

#endif // BASE_COMPONENT_HPP

//CPP
#include "../include/BaseComponent.hpp"

namespace ksg
{
    std::vector<std::string> BaseComponent::m_RequiredAttributes;

    BaseComponent::BaseComponent(std::shared_ptr<GameObject> parent)
    {
        m_Parent = parent;
    }

    BaseComponent::~BaseComponent()
    {
    }

    bool BaseComponent::checkRequiredAttributes(std::shared_ptr<GameObject> obj)
    {
        if(!obj)
            return false;

        std::vector<std::string>::const_iterator iter;
        for(iter = m_RequiredAttributes.begin(); iter != m_RequiredAttributes.end(); ++iter)
            if(!obj->getAttribute(*iter))
                return false;

        return true;
    }
}

GameObject:
//HPP
#ifndef GAME_OBJECT_HPP_INCLUDED
#define GAME_OBJECT_HPP_INCLUDED

#include "BaseAttribute.hpp"
#include "BaseComponent.hpp"
#include <unordered_map>
#include <vector>
#include <memory>

namespace ksg
{
    class GameObjectFactory;

    class GameObject
    {
    friend class GameObjectFactory;

    public:
        void update(float dt);

        std::shared_ptr<BaseAttribute> getAttribute(std::string name) { return m_Attributes[name]; }

    private:
        std::unordered_map<std::string, std::shared_ptr<BaseAttribute>> m_Attributes;
        std::vector<std::unique_ptr<BaseComponent>> m_Components;
    };
}

#include "GameObjectFactory.hpp"

#endif // GAME_OBJECT_HPP_INCLUDED

//CPP
#include "../include/GameObject.hpp"

namespace ksg
{
    void GameObject::update(float dt)
    {
        std::vector<std::unique_ptr<BaseComponent>>::const_iterator iter;
        for(iter = m_Components.begin(); iter != m_Components.end(); ++iter)
            (*iter)->update(dt);
    }
}

GameObjectFactory:
//HPP
#ifndef GAME_OBJECT_FACTORY_HPP
#define GAME_OBJECT_FACTORY_HPP

#include "GameObject.hpp"
#include "BaseAttribute.hpp"
#include "BaseComponent.hpp"
#include <vector>
#include <memory>

namespace ksg
{
    class GameObjectFactory
    {
    public:
        GameObjectFactory();
        ~GameObjectFactory();

        static bool initialize();
        static std::unique_ptr<GameObjectFactory>& getInstance() { return m_Instance; }

        void createGameObject(const std::vector<BaseAttribute*>& attributes);
        void update(float dt);

    private:
        static std::unique_ptr<GameObjectFactory> m_Instance;

        std::vector<std::unique_ptr<BaseComponent>> m_Components;
        std::vector<std::shared_ptr<GameObject>> m_GameObjects;
    };
}

#endif // GAME_OBJECT_FACTORY_HPP

//CPP
#include "../include/GameObjectFactory.hpp"
#include "../include/ScrollingBackgroundComponent.hpp"

namespace ksg
{
    std::unique_ptr<GameObjectFactory> GameObjectFactory::m_Instance;

    GameObjectFactory::GameObjectFactory()
    {
        ScrollingBackgroundComponent::initRequiredAttributes();
        m_Components.push_back(std::unique_ptr<ScrollingBackgroundComponent>(new ScrollingBackgroundComponent(nullptr)));
    }

    GameObjectFactory::~GameObjectFactory()
    {

    }

    bool GameObjectFactory::initialize()
    {
        m_Instance.reset();
        m_Instance = std::unique_ptr<GameObjectFactory>(new GameObjectFactory());

        if(!m_Instance)
            return false;

        return true;
    }

    void GameObjectFactory::createGameObject(const std::vector<BaseAttribute*>& attributes)
    {
        std::shared_ptr<GameObject> gameObject = std::shared_ptr<GameObject>(new GameObject);

        for(std::vector<BaseAttribute*>::const_iterator iter = attributes.begin(); iter != attributes.end(); ++iter)
            gameObject->m_Attributes.insert(std::make_pair((*iter)->getName(), std::shared_ptr<BaseAttribute>(*iter)));

        for(std::vector<std::unique_ptr<BaseComponent>>::const_iterator iter = m_Components.begin(); iter != m_Components.end(); ++iter)
            if((*iter)->checkRequiredAttributes(gameObject))
                gameObject->m_Components.push_back(std::unique_ptr<BaseComponent>((*iter)->clone(gameObject)));

        m_GameObjects.push_back(gameObject);
    }

    void GameObjectFactory::update(float dt)
    {
        std::vector<std::shared_ptr<GameObject>>::iterator iter;

        for(iter = m_GameObjects.begin(); iter != m_GameObjects.end(); ++iter)
            (*iter)->update(dt);
    }
}

And finally something more specific - ScrollingBackgroundComponent:
//HPP
#ifndef SCROLLING_BACKGROUND_COMPONENT_HPP
#define SCROLLING_BACKGROUND_COMPONENT_HPP

#include "BaseComponent.hpp"
#include "Attribute.hpp"
#include "ScrollingBackground.hpp"
#include <SFML/Graphics.hpp>
#include <memory>

namespace ksg
{
    class ScrollingBackgroundComponent : public BaseComponent
    {
    public:
        ScrollingBackgroundComponent(std::shared_ptr<GameObject> parent);
        ~ScrollingBackgroundComponent();

        std::unique_ptr<BaseComponent> clone(std::shared_ptr<GameObject> parent) { return std::unique_ptr<BaseComponent>(new ScrollingBackgroundComponent(parent)); }
        void update(float dt);

        static void initRequiredAttributes();

    private:
        std::shared_ptr<Attribute<ScrollingBackground*>> m_Visual;
    };
}

#endif // SCROLLING_BACKGROUND_COMPONENT_HPP

//CPP
#include "../include/ScrollingBackgroundComponent.hpp"

namespace ksg
{
    ScrollingBackgroundComponent::ScrollingBackgroundComponent(std::shared_ptr<GameObject> parent) : BaseComponent(parent)
    {
        if(parent)
        {
            m_Visual = std::dynamic_pointer_cast<Attribute<ScrollingBackground*>>(parent->getAttribute("sb_visual"));
            std::shared_ptr<Attribute<sf::Vector2i>> position = std::dynamic_pointer_cast<Attribute<sf::Vector2i>>(parent->getAttribute("sb_position"));
            std::shared_ptr<Attribute<sf::Vector2f>> scrollSpeed = std::dynamic_pointer_cast<Attribute<sf::Vector2f>>(parent->getAttribute("sb_scroll_speed"));
            std::shared_ptr<Attribute<bool>> autoScroll = std::dynamic_pointer_cast<Attribute<bool>>(parent->getAttribute("sb_auto_scroll"));

            if(position)
                m_Visual->getValue()->setPosition(position->getValue());

            if(scrollSpeed)
                m_Visual->getValue()->setScrollSpeed(scrollSpeed->getValue());

            if(autoScroll)
                m_Visual->getValue()->setAutoScroll(autoScroll->getValue());
        }
    }

    ScrollingBackgroundComponent::~ScrollingBackgroundComponent()
    {

    }

    void ScrollingBackgroundComponent::update(float dt)
    {
        m_Visual->getValue()->update(dt);
    }

    void ScrollingBackgroundComponent::initRequiredAttributes()
    {
        m_RequiredAttributes.push_back("sb_visual");
    }
}
 

Somewhere in the Game.cpp:
std::vector<BaseAttribute*> attr;
attr.push_back(new Attribute<ScrollingBackground*>(&back1, "sb_visual"));
attr.push_back(new Attribute<sf::Vector2f>(sf::Vector2f(1, .25f), "sb_scroll_speed"));
GameObjectFactory::getInstance()->createGameObject(attr);

attr.clear();
attr.push_back(new Attribute<ScrollingBackground*>(&back2, "sb_visual"));
attr.push_back(new Attribute<sf::Vector2i>(sf::Vector2i(0, 32), "sb_position"));
attr.push_back(new Attribute<sf::Vector2f>(sf::Vector2f(16, .5f), "sb_scroll_speed"));
attr.push_back(new Attribute<bool>(true, "sb_auto_scroll"));
GameObjectFactory::getInstance()->createGameObject(attr);
       
attr.clear();
attr.push_back(new Attribute<ScrollingBackground*>(&back3, "sb_visual"));
attr.push_back(new Attribute<sf::Vector2f>(sf::Vector2f(1.5f, .75f), "sb_scroll_speed"));
GameObjectFactory::getInstance()->createGameObject(attr);
attr.clear();

All runs fine so far, though as I said my C++ skills are rusty and I need code revision badly :)
For start I would like to change the way of storing available components into the game factory, having empty components for the sake of it is just meh to me.

Anyway thanks in advance for help, and thanks for your game design articles :)

P.S. Two links I found during my research that could be of some use:
Pitfalls of Object Oriented Programming  (http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf)
Theory and Practice of Game Object Component Architecture (http://www.gdcvault.com/play/1911/Theory-and-Practice-of-the)

EDIT: Is there like some spoiler tag or show hide code option? Too much code = unnecessary lengthy post  :-\
Title: Re: Game Development Design articles
Post by: Tank on March 28, 2013, 08:32:06 am
Your approach looks quite good! I can find some similarities between mine and yours. :)

Quote
For start I would like to change the way of storing available components into the game factory, having empty components for the sake of it is just meh to me.
That's what I mean in the How to tell the system what controllers exist section. Having "dummy" objects is indeed quite meh. ;) Here's what I do in my implementation:

The components all have a static function get_requirements(), which returns what the component needs (in terms of properties, in your case attributes). In order to register a component at the system I use component factories. Two classes are needed for that:


What you now do is you store those factories in your component system's manager or whatever you call it. And whenever an entity is created or attributes are added/removed/changed, you check that entity against all the factories by calling their requirements. If the requirements match, you call the factory's create function to get a new component for that entity.

Feel free to ask if anything's unclear.
Title: Re: Game Development Design articles
Post by: Indorile on March 28, 2013, 07:10:09 pm
Yeah, I went with the BaseFactory/Factory<T> approach and I have renamed GameObjectFactory to GameObjectSystem, so in the constructor now I do this:

m_Factories.push_back(std::unique_ptr<Factory<ScrollingBackgroundComponent>>(new Factory<ScrollingBackgroundComponent>()));

I'll have some more questions later on when I progress with my game's development :) Thanks for the help.
Title: Re: Game Development Design articles
Post by: danman on March 29, 2013, 10:36:51 pm
FRex : In my opinion:
components should not really interfere in their behavior other than by doing what they are aimed to on the properties.
In fact, it looks like a complete system and not like OOP. You have a component that must be designed to process data (for exemple a PhysicBody component would update the position of the object), and that data must then be handled by another component (Graphics API use the position to check if object is dawable and then draw the object on the screen).
They are multiple point very simplificated in my explanation, and certainly english mistakes, but you've got my point of view ;)

an #Altdevblogaday blogger has made 5 articles on that kind of system, you can check it ;)
Title: Re: Game Development Design articles
Post by: Indorile on April 01, 2013, 07:18:11 pm
Now that I think of it, is there some way to differentiate components that require same attributes? For example both PlayerController and AIController require Position and Velocity, how should system know if it should attach one or another? I could solve it by using different names like PC_Position and NPC_Position, but then Collision that requires Position wouldn't know about them...
Title: Re: Game Development Design articles
Post by: danman on April 01, 2013, 07:28:14 pm
The fact is that both MUST require the same position attribute, or it's not really an entity position.
Entity-system doesn't make entity handle the properties of subsystem, you won't add a AIi_node[] attribute for example. But if AI need position, it knows where to find it, and can eventually update it (though i don't see any advantage to edit it in AI_system :p).
Position is an ENTITY attribute and not an AI  attribute.

in this way, i'm thinking about adding a subset of properties as "capabilities" (for example collidable, gravitable, extandable, etc) that would induce a defined way to make entities, and I have in mind an incredible idea of adding "behavior" classes, but can't determine why either how implement this yet.

edit:
You must define a new attribute that represent the next position you want to get to, the AI calculator would set it, and the Physic/Logic/Interpolating system would use it to update the position/velocity or other.
Title: Re: Game Development Design articles
Post by: Tank on April 02, 2013, 10:33:51 am
Now that I think of it, is there some way to differentiate components that require same attributes? For example both PlayerController and AIController require Position and Velocity, how should system know if it should attach one or another?
The fact that only position and velocity trigger PlayerController AND AIController is too unspecific. Think of it: An entity being controlled by the player probably has something like "controllable = true", and AIController requires e.g. "brain_type".
Title: Re: Game Development Design articles
Post by: Tank on April 02, 2013, 10:52:16 pm
Hey guys,

I got some free time left and decided to write a new article. This one's about a technique for greatly reducing code dependencies, reducing compile times and a workflow that allows to add features step by step and isolated.

Please welcome the message bus.

WEBLINK Game Development Design 3: Message Bus (http://stefan.boxbox.org/2013/04/02/game-development-design-3-message-bus/#more-401)
Title: Re: Game Development Design articles
Post by: FRex on April 02, 2013, 11:10:44 pm
Quote
Please welcome the message bus.
Hi. :)

I opened it up and first thing that caught my eye is this :o:
http://stefan.boxbox.org/wp-content/uploads/2013/04/dependencies.png
I didn't even read a single line yet, but this.. wow.., this just looks like if a Java or C# Object Obsessed Programmer got his hands on  c++'s multiple inheritance. Crap, no, full arrow is composition. My bad. That still looks 'great' though.
Title: Re: Game Development Design articles
Post by: Tank on April 02, 2013, 11:18:42 pm
Haha. ;) Keep in mind that it's a negative example. The arrows are no UML-style arrows. They're just there to show what's dependent on what.
Title: Re: Game Development Design articles
Post by: FRex on April 02, 2013, 11:31:35 pm
Quote
Personally I chose to use hashed strings for performance reasons by still keeping readability
'by' looks like it should be 'but'. This sounds like the fact of keeping readability is a way to achieve hashing and performance. I might be wrong. ::)

The article might contain product placement adverts. http://www.flexworld-game.com/home.php
Just kidding. ;)
Title: Re: Game Development Design articles
Post by: Tank on April 03, 2013, 09:42:48 am
Quote
'by' looks like it should be 'but'. This sounds like the fact of keeping readability is a way to achieve hashing and performance. I might be wrong.
I replaced the "by" by "while". Thanks :)

Quote
The article might contain product placement adverts.
Of course, that's cheap advertising. Indeed the articles' only purpose is advertising my our game! ;)
Title: Re: Game Development Design articles
Post by: Tank on April 03, 2013, 01:32:34 pm
I decided to give everyone the opportunity to support the author of the GDD articles (existing and future) by doing a small donation and in return get a PDF/epub/mobi version of all articles. ;)

All future articles will of course still be published at my blog. I'm doing this because it's fun, and not to earn my daily bread, so no worries about this.

Check the Leanpub webpage to get the PDF/epub/mobi version. Price? Pay what you want!

WEBLINK GDD at Leanpub (https://leanpub.com/game-development-design)
Title: Re: Game Development Design articles
Post by: FRex on April 07, 2013, 07:39:51 pm
Tank, could you give us some examples of 'good' messages to send on the bus?
Title: AW: Game Development Design articles
Post by: eXpl0it3r on April 07, 2013, 10:00:48 pm
I'm not really sure, what you mean with 'good' messages, but you can basically send anything.
One easy example would be the whole window events (Lost/GainFocus, KeyPressed/Released, etc). Another example would be any UI interaction: "Button X was pressed" and anyone that cares about the button X can 'listen' for it; keep in mind though, that most of the GUI libs already have somesort of dispatching and thus it might be better to use these. ;)

It really depends on what you're doing and how you want the architecture to be.

Did I get the question right?
Title: Re: Game Development Design articles
Post by: Tank on April 08, 2013, 08:53:14 am
eXpl0it3r already answered your question, I just wanna add that everything that needs to be passed to other modules should be sent via messages. There's no "good" or "bad" regarding to what you send. Just make sure that you don't target your messages at specific receivers (like explained in the article).
Title: Re: Game Development Design articles
Post by: Tank on October 11, 2013, 02:56:23 pm
Hey guys,

a new article has been published which is about how to raise and work with errors. Hope you like it!

LINK http://stefan.boxbox.org/2013/10/11/game-development-design-4-errors/
Title: AW: Game Development Design articles
Post by: eXpl0it3r on October 11, 2013, 05:04:02 pm
Hehe got the mail from leanpub about a new version before checking my RSS feed or reading here.
Will dive into it later on. :)
Title: Re: Game Development Design articles
Post by: Tank on October 11, 2013, 06:08:06 pm
Sure, donators get the notification ~1 minute earlier. ;)
Title: Re: Game Development Design articles
Post by: Ixrec on October 11, 2013, 08:06:43 pm
Some of the code examples say &amp;&amp; instead of &&.  Otherwise, definitely a good article, especially for newbies.

Though it's a little ironic that SFML is the example when it says a library's error reporting has to be consistent, since most SFML errors are reported through the err() stream but a handful of functions, like the example, return bools instead (though I think Laurent said he'd like to fix that in SFML 3).
Title: Re: Game Development Design articles
Post by: Nexus on October 14, 2013, 04:17:31 pm
Good article, it gives a nice overview about different error handling techniques! I also like that you emphasize the importance of naming functions clearly ("find" vs. "get").

Some remarks:
Title: Re: Game Development Design articles
Post by: Tank on October 15, 2013, 09:11:13 am
Hey Nexus,

thanks for the feedback.

Quote
Saying error codes should be completely avoided is a bit too strict
Indeed it's very strict. I tend to follow my own guidelines in every possible situation without exceptions. It's true that using error codes is still widely done, even by the STL, but I don't agree to the idea (reasons in the article). There are for sure situations where an error code might feel easier to use or more straightforward, but I still want to stick to my guidelines to be consistent.

Quote
I would probably also mention the term "runtime error" here, since it is very common and differentiates the type of error from the language feature exception.
I thought about that for a long time but came to the conclusion that "runtime error" is too squishy. Even a programming error is evaluated during runtime.
For me "exception" and "programming error" are in the same category, just like "runtime error" and "compile-time error".

Quote
Do you mean "compilers" instead of "languages"?
Thanks, that's right. I will correct it.

Quote
You should catch exceptions by reference.
That's also right, typo will be fixed.

Quote
looks like code from beginners who don't know how boolean expressions work
Haha. :P Yes, it's my personal style. I like the verbosity and am used to it from unit testing, where you often exchange true/false in the expressions.
Title: Re: Game Development Design articles
Post by: Tank on May 22, 2015, 05:14:11 pm
I can't believe that the last GDD entry was made almost 2 years ago, phew! Time for something new, I guess. Here you go!

GDD#5 Optimizing & Engineering (http://www.optank.org/2015/05/22/optimizing-and-engineering/)
Title: Re: Game Development Design articles
Post by: Lee R on May 25, 2015, 03:37:34 am
Bullet point number one should have been 'Understand the hardware'. You almost touch on that right at the start by pointing out that it's slow to jump around in memory, but why is it slow? What is it about modern computer architectures that makes memory access patterns such a big deal when it comes to performance? You get the idea ;)