Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Re:creation - a top down action adventure about undeads [hiatus]  (Read 157210 times)

0 Members and 2 Guests are viewing this topic.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6158
  • Thor Developer
    • View Profile
    • Bromeon
Re:creation - a top down action rpg about undeads
« Reply #300 on: September 29, 2015, 10:21:09 pm »
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

Elias Daler

  • Hero Member
  • *****
  • Posts: 570
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #301 on: September 30, 2015, 12:26:35 am »
So, do you like the new perspective? :D
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #302 on: September 30, 2015, 08:36:53 am »
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)
(Source linked)
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Elias Daler

  • Hero Member
  • *****
  • Posts: 570
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #303 on: October 02, 2015, 07:47:06 am »
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? :D
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #304 on: October 02, 2015, 01:19:51 pm »
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? :)
« Last Edit: October 03, 2015, 01:11:58 pm by Glocke »
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Elias Daler

  • Hero Member
  • *****
  • Posts: 570
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #305 on: October 04, 2015, 10:24:37 am »
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. :)
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #306 on: October 04, 2015, 11:19:10 am »
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!
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Elias Daler

  • Hero Member
  • *****
  • Posts: 570
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #307 on: October 06, 2015, 01:33:42 pm »
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!
« Last Edit: October 06, 2015, 02:28:22 pm by Elias Daler »
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

shadowmouse

  • Sr. Member
  • ****
  • Posts: 302
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #308 on: October 06, 2015, 05:25:33 pm »
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

  • Full Member
  • ***
  • Posts: 130
  • Current mood: just ate a pinecone
    • View Profile
    • darrenferrie.com
Re:creation - a top down action rpg about undeads
« Reply #309 on: October 06, 2015, 06:09:03 pm »
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 :)
Follow me on Twitter, why don'tcha? @select_this

Elias Daler

  • Hero Member
  • *****
  • Posts: 570
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #310 on: October 06, 2015, 08:30:57 pm »
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.
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Nerevar

  • Newbie
  • *
  • Posts: 7
    • View Profile
    • XGM
Re:creation - a top down action rpg about undeads
« Reply #311 on: October 06, 2015, 08:38:13 pm »
What size of sprites(objects,tiles,gui) you use in your game?

Elias Daler

  • Hero Member
  • *****
  • Posts: 570
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #312 on: October 06, 2015, 09:54:02 pm »
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.
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Elias Daler

  • Hero Member
  • *****
  • Posts: 570
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #313 on: October 09, 2015, 09:00:56 am »
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).
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Hapax

  • Hero Member
  • *****
  • Posts: 2706
  • My number of posts is shown in hexadecimal.
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #314 on: October 12, 2015, 04:53:58 pm »
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?
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

@Hapaxiation - Hapaxia on Twitter

 

anything