Re:creation - a top down action adventure about undeads [hiatus]

[Nexus]

I think the problem with the previous perspective was still what I mentioned earlier: mixing perspective and parallel projection.

Games with an actual top view (not a front-top angle) such as GTA2 are usually rendered with perspective, even if it may be faked implementation-wise. There are games that mix both successfully (e.g. Binding Of Isaac), but it works because the game focuses much more on action/enemies than on scenery and art.

[Elias Daler]

So, do you like the new perspective?

[Glocke]

Ah cool! I just found another solution without a base class - but with some heavy template meta-programming using C++11 parameter packs.

Neat. How can you access a particular system in your engine?

In a nutshell:

int main() {
        SystemA a;
        SystemB b;
        SystemC c;
        SystemD d;
       
        EntityUpdater<SystemA, SystemD, SystemB, SystemC> updater{a, d, b, c};
        updater.update(sf::milliseconds(20));
        updater.update(sf::milliseconds(19));
        updater.update(sf::milliseconds(23));
        updater.update(sf::milliseconds(30));
        updater.update(sf::milliseconds(12));
        updater.update(sf::milliseconds(20));
       
        std::cout << "Total time for System A: " << updater.getTotal<SystemA>().asMilliseconds() << "ms\n";
        std::cout << "Total time for System B: " << updater.getTotal<SystemB>().asMilliseconds() << "ms\n";
        std::cout << "Total time for System C: " << updater.getTotal<SystemC>().asMilliseconds() << "ms\n";
        std::cout << "Total time for System D: " << updater.getTotal<SystemD>().asMilliseconds() << "ms\n";
}

But providing something like

template <typename... Args>
struct EntityUpdater
        : MultiUpdater<Args...> {
       
        EntityUpdater(Args& ...args)
                : MultiUpdater<Args...>{std::forward<Args&>(args)...} {
        }
       
        // should also be possible
        template <typename T>
        T& getSystem() {
                return SingleUpdater<T>::system;
        }
};

In more detail:

(click to show/hide)

That was a huge problem referring to multiple inheritance (which is afaik necessary when using compile-time recursion). I solved this by explicitly reimplementing a "top level interface".

I pastebin'ed the code: http://pastebin.com/Z1VHevhk - but here are some explanations:
- SingleUpdater<> provides updating a single system. It messures the time used for the update and stores it.
- MultiUpdater<> inherits from SingleUpdater<> per passed type (using a C++11 parameter pack and compile-time recursion). On each update, the multi updater steps through its single updaters and calls the initial implementation
- EntityUpdater<> is the final "public" interface: it inherits from MultiUpdater (using the entire pack at once) and reimplements an API to access each system's time by accessing the correct baseclass explicitly. (see main function).

At the moment, I'm using this for my updates. Unfortunately (also because I'm using much templated stuff), the compile duration is too high for me. So I'll move to your approach using a base class.

But the approach itself is working

(Source linked)

[Elias Daler]

Glocke, that's a cool implementation. But yeah, looks like it may cause increased compilation time. Especially if you have lots of systems. And doesn't this approach creates a high compilation dependency between systems? By changing one system, you may cause lots of unnecessary recompilation.

Base class approach is working good, because most of the time you don't really care about what components this system works with. You just call update() and process() and you're done.
But, in case I need to get a particular system, I can do it by dynamic_cast.

Progress update
Can't really show much at the moment. Working on the cool fog system which I hope to show off soon. It's not just overlay sprites, clouds can actually be of any height and interact with objects they collide with!
I'm also prototyping some stuff. I've understood that this is absolutely neccessary.
This is something which I need to be used to. Drawing raw, unpolished sprites, making levels without lots of details, etc.
If I make a level with some detail (even not a lot of it), changing stuff becomes harder. So, raw prototyping helps here. Just draw some boxes, throw them on the map and change them to get a good level. And then I can start with details. But it's actually pretty hard, because I want the game to look good all the time, but I have to overcome this thing. Does anyone feel that about their games?

[Glocke]

Glocke, that's a cool implementation.

Thanks

And doesn't this approach creates a high compilation dependency between systems? By changing one system, you may cause lots of unnecessary recompilation.

Yes it does. But I'd recomment to use such an approach at the very high end of the module stack - e.g. right before the actual game's mainloop (e.g. at the game state if you're using something like a state machine to switch between different states like menus).

But, yes: The approach using a common interface (which virtually provides update etc.) is better for decoupling, because the Headerfile (where you declare the systems vector) only depends on the interface declaration and the cpp-File includes everything else. So everything that depends on the header (which provides the systems vector) doesn't need to be recompiled when a system is added (only the corresponding cpp-File which depends on the systems is needed).

About your dynamic casts: Personally, I could think of something like

class ECS {
    private:
        std::vector<std::unique_ptr<BaseSystem>> systems;

    public:
        // create system
        template <typename T, typename ...Args>
        std::size_t create(Args&& ...args) {
            // emplace system and return index
        }
       
        // query existing system
        template <typename T>
        T& operator[](std::size_t index) {
            return *systems[index].get();
        }
        // + const overload
};

plus some is_base_of etc.
But at the moment I use

// session.hpp
struct Session {
    MovementManager& movement;
    CollisionManager& collision;
    // ...

    // + ctor that initializes the references
};

// ecs.hpp
struct ECS {
    MovementSystem movement;
    CollisionSystem collision;
    // ...

    Session session;
    std::vector<Updateable*> updateables;

    // + ctor that initializes all systems, the session and the updateables
};

FooManager is the pure FooComponent container, FooSystem is based on FooManager and has update logic etc. (which is implemented for the Updateable interface). So I can pass that Session reference where ever I those component managers (e.g. to a factory that creates complete objects). So the factory depends on the Component definition (+ their manager definition which is very simple) but not on the actual system.

Well this isn't perfect either^^

About your progress update: Can you tell us more about your fog system? Personally, I'm using a simple lightingsystem in my game, which produces dynamic shadows. What's the idea of your (upcomming) fog system yet?

[Elias Daler]

About your dynamic casts: Personally, I could think of something like
*code*

Yep, that's how I currently do it. But this code won't work:

template <typename T>
T& operator[](std::size_t index) {
    return *systems[index].get();
}

Because you can't convert from BaseSystem to DerivedSystem
This is what I do:

template <typename T>
T& operator[](std::size_t index) {
    return *(std::dynamic_pointer_cast<T>(systems[index].get())); // systems are shared_ptr, can't do this with unique_ptr
}

But at the moment I use

It's okay when you have a small number of systems, but as it increases, this stuff becomes more difficult to work with.

About your progress update: Can you tell us more about your fog system? Personally, I'm using a simple lightingsystem in my game, which produces dynamic shadows. What's the idea of your (upcomming) fog system yet?

Something like this:

The height of the cloud can vary and the cloud can move, so I have to draw it differently depending on the object which are in it. I'll explain how I do it a bit later.

[Glocke]

Something like this:

The height of the cloud can vary and the cloud can move, so I have to draw it differently depending on the object which are in it. I'll explain how I do it a bit later.

Looks very interesting. I'm curious about your explanation!

[Elias Daler]

Okay, here's how the fog looks in the game


Notice, that it's not just an overlay. It actually has some height and draws depending which objects are in it. Just a neat simple effect...

This wasn't easy to make, though. Here's how it works:

Suppose we have one object. First, we draw the part of the fog which is behind it. Then we draw the object itself. After that, we draw the rest of the fog sprite in front of the object.
It all depends on the line which divedes the front and the back.It's easy to get it by substracting fog height (in pixels) from lowest Y coordinate of the object.
So, I split one big sprite in smaller ones depending on objects around.

Stuff becomes a lot harder if there are several objects in fog. I won't explain how to deal with it, as it would take too much time, but stuff works mostly the same.
And by the way, the most interesting thing about it is that the fog sprites don't move. Only textures move on sprites. This is done to make tiling of fog easier. I don't have to create additional sprites to do this, sprites just follow the camera if it moves.

There are other stuff I can do with this system. Like simulating water (some stupid undead forgot to turn off the taps...)


Or deep snow...

You get the idea. It's always cool to reuse stuff like that!

[shadowmouse]

May I suggest that if you are going to do water effects or snow effects then use a texture. Before I read the whole post, the second and third images just looked like a sort of weird version of fog of different intensities. Either giving it a texture across the whole  thing, or by the edges would make it clearer what the effect is.

[select_this]

I think it was more of a demonstration of the versatility of his solution rather than "this is how I want it to look", but I do agree that it does look rather odd to have flat colours - especially the snow one, due to the lack of translucency

[Elias Daler]

I think it was more of a demonstration of the versatility of his solution rather than "this is how I want it to look", but I do agree that it does look rather odd to have flat colours - especially the snow one, due to the lack of translucency

Yeah, that's just to show off that it's possible to use the solution in different ways . Of course, I'll add texture if I decide to use in in some level. Snow would have some footprints on it, some snowdrifts, etc.

[Nerevar]

What size of sprites(objects,tiles,gui) you use in your game?

[Elias Daler]

What size of sprites(objects,tiles,gui) you use in your game?

Most of the gifs and screenshots I make are upscaled 2x. So, you can take any screenshot/gif and check it out for yourself. The original resolution is 256x240.

[Elias Daler]

Fixed one big bug where hero's sprite was shaking during camera scrolling. Turns out, I was setting the updated camera view too late (somewhere in the rendering phase, he-he). This took me like 3-4 hours to find! I'm not a clever man, heh.

As for 256x240 resolution. I've chosen this resolution because of SNES (but actually SNES is 256x224!).
So, I'm thinking about changing resolution to either 256x244 or 320x240 (4:3!).
320x240 would actually be cool because it would give me more horizontal space.

16:9 ratio for resolution would be cool, but I think that this would make my game look weird and too much horizontal space is not needed anyway (it's better for platformers).

[Hapax]

Your fog (/water/snow) effect looks pretty cool!

I noticed that they're all at the same height (from the ground) though. Is it possible in your system to adjust this height as required or is it hard-coded at that height?