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 369142 times)

0 Members and 1 Guest are viewing this topic.

Elias Daler

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #60 on: May 15, 2015, 04:27:16 pm »
Could I suggest filling the empty spaces with dense forest (just copy and paste your trees), because that makes it look more realistic, while still means you don't have rectangular levels.
There's no need to do that, player won't ever see those areas, that's why keeping information about this areas is a waste of space.
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 #61 on: May 15, 2015, 04:30:55 pm »
I was thinking along the lines of if you were going to make the big open areas scroll continuously or if you might start zoomed out when the player enters a new area, so they got some idea of what it was like, and then you zoom in to their position. Oh and for the record, I didn't mean program in data about the trees I just meant have some record that that area was empty and make something that fills all empty areas in whenever they would be visible.

Elias Daler

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #62 on: May 15, 2015, 04:34:42 pm »
I was thinking along the lines of if you were going to make the big open areas scroll continuously or if you might start zoomed out when the player enters a new area, so they got some idea of what it was like, and then you zoom in to their position. Oh and for the record, I didn't mean program in data about the trees I just meant have some record that that area was empty and make something that fills all empty areas in whenever they would be visible.
Yeah, if player will be able to see it zoomed out, I would do it. But probably I'll just make a map which won't represent game world 1:1 but will be like in A Link to the Past.
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Elias Daler

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #63 on: May 19, 2015, 10:19:53 am »
Doing some animations. What do you think?


Old animation for comparison (it sucks!)
« Last Edit: May 19, 2015, 10:49:45 am by Elias Daler »
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1485
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #64 on: May 19, 2015, 10:21:41 am »
I'm no designer, but: Nice! :-)

Elias Daler

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #65 on: May 19, 2015, 10:30:58 am »
I'm no designer, but: Nice! :-)
Thanks. It's very hard to draw in that perspective. I've tried different shapes for character sprite and this one looks the best. It's very styled (don't even compare that with Chrono Trigger or Secret of Mana! :D) but I think it looks okay.
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Hapax

  • Hero Member
  • *****
  • Posts: 3058
  • My number of posts is shown in hexadecimal.
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #66 on: May 19, 2015, 08:03:16 pm »
The top (new) graphics do look better than the bottom (old) graphic but the top-right one (new, clothed) looks like he has had his left arm amputated! :o

By the way, this project looks really well done. Good work! :)
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

@Hapaxiation - Hapaxia on Twitter

Jabberwocky

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #67 on: May 20, 2015, 12:46:50 am »
Looks great, Elias.  Thanks for sharing.

I enjoyed your write-up on the ECS model you're using.  I'm also using ECS.  It can be a bit of work t get set up properly.  But once you do, there's massive flexibility in designing different kinds of game objects.  I doubt I'd ever go back to using anything different.

Elias Daler

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #68 on: May 20, 2015, 01:18:17 am »
@Hapax Thanks!
Well, the right arm... it's just one pixel wide (instead of two). It looks a bit weird, but with two it looks even worse, but I'll try to find some balance (can't make it 1.5 pixels, unfortunately!)

@Jabberwocky Thanks! Glad you've enjoyed it.
Yeah, once you get ECS, there's no way back. I've tried to do normal OOP and ended with almost ECS (all classes differed mostly by data, so why not get rid of classes at all in that case? :D)

Oh, and I'm working on attack animation now. It's not perfect but starting to actually look decent.
« Last Edit: May 20, 2015, 01:20:00 am by Elias Daler »
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Jabberwocky

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #69 on: May 20, 2015, 05:19:29 pm »
I hope you don't mind a bit more discussion on ECS. 

Overall, our implementations of ECS seem pretty similar.

One minor, although significant difference is that you store a vector/array of pointers to components.  That will be totally fine for a game which doesn't have a huge number of entities/components operating at once, as looks to be the case with your game, given that it works screen by screen.

For a game that does process a huge number of entities at once, say a large, dynamic, open world game with entities that continue to operate while off-screen, you would lose some performance because of the pointers.  It's a cache miss problem, because while the pointers are arranged sequentially in memory, the actual component data is not.  So when a system iterates over an array of components, it's jumping all over memory.

It's more optimal to store a straight up array of components, not component pointers.  i.e.

class ComponentSystem
{
private:
   // not this:
   // std::vector<Component*> m_components;
   // but this:
   std::vector<Component> m_components;
};

Then, when you iterate over m_components, it's all sequential memory, which is really fast.  The biggest problem with this approach is that when m_components grows, as can happen when you add new elements, two tricky things happen:

1.  It invalidates any Component pointers or references which may currently be in use by your gamesystem code, since the vector moves in memory.  This can lead to some nasty dangling pointer/reference bugs if you're not very careful about when you add components to the vector, in relation to when you operate on components within the vector.

2.  It calls constructors and destructors on every component in the vector, which can lead to unintended consequences if you treat your constructors and destructors as meaning the entity/component is being created and destroyed in a gameplay sense.

Bottom line, arrays of pointers are easier (avoiding the problems above), provide all the flexibility of an ECS, and work great for most games.  They do lose some of the performance benefits of an ECS, but that's only important for a few kinds of massive, open world games.  So this is not a critique of your approach at all (it seems really good!), just some of the thoughts I've had. 
« Last Edit: May 20, 2015, 05:53:57 pm by Jabberwocky »

Elias Daler

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #70 on: May 20, 2015, 06:13:32 pm »
I don't mind this disscussion at all. In fact, I pretty much welcome it because it may lead to something interesting and help me and other people find out about different approaches and tricks.

std::vector<Component> m_components;
Nope, can't do that. How do I store different components in one vector? Only through pointers (well, I can use shared_ptr, but I'll fix that later). If you try to store derived classes instances in one vector, object slicing happens. :)

Just run this code and see what happens:

class A {
public:
    virtual void print() {
        std::cout << "A " << std::endl;
    }
};

class B : public A {
public:
    void print() override {
        std::cout << "B" << std::endl;
    }
};

int main() {
    A a;
    B b;
    std::vector<A> c;
    c.push_back(a);
    c.push_back(b);
    for (auto it = c.begin(); it != c.end(); ++it) {
        it->print();
    }
}
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Hapax

  • Hero Member
  • *****
  • Posts: 3058
  • My number of posts is shown in hexadecimal.
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #71 on: May 20, 2015, 07:33:15 pm »
@Hapax Thanks!
the right arm... it's just one pixel wide
Ah, I think I see it now. I stand, though, by the fact it looks initially like that single pixel-wide part is a part of the sword so the arm looks like it's missing below the shoulder  :D
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

@Hapaxiation - Hapaxia on Twitter

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6278
  • Thor Developer
    • View Profile
    • Bromeon
Re:creation - a top down action rpg about undeads
« Reply #72 on: May 20, 2015, 07:54:43 pm »
1.  It invalidates any Component pointers or references which may currently be in use by your gamesystem code, since the vector moves in memory.  This can lead to some nasty dangling pointer/reference bugs if you're not very careful about when you add components to the vector, in relation to when you operate on components within the vector.
As a solution to this problem, typical ECS implementations use a sort of handles (e.g. integers containing information to index) instead of pointers and references.

2.  It calls constructors and destructors on every component in the vector, which can lead to unintended consequences if you treat your constructors and destructors as meaning the entity/component is being created and destroyed in a gameplay sense.
This can be avoided by providing move constructor and move assignment operator. This adds more maintenance overhead however, so I wouldn't do it carelessly.

std::vector<Component> m_components;
Nope, can't do that. How do I store different components in one vector?
You don't. You use multiple vectors, one per component type.

Components would no longer be owned by entities; each vector would then store the components of multiple entities in the game.
« Last Edit: May 20, 2015, 07:58:11 pm by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re:creation - a top down action rpg about undeads
« Reply #73 on: May 20, 2015, 08:03:21 pm »
The biggest problem with this approach is that when m_components grows, as can happen when you add new elements, two tricky things happen:

1.  It invalidates any Component pointers or references which may currently be in use by your gamesystem code, since the vector moves in memory.  This can lead to some nasty dangling pointer/reference bugs if you're not very careful about when you add components to the vector, in relation to when you operate on components within the vector.
Only if the vectors .size() is equal to its .capacity() will it reallocate. As long as .size() is below .capacity() you are guaranteed that no reallocation will happen and all iterators etc stay valid. So, if you know up-front the maximum number of elements you'll ever need to store you can .reserve() the needed capacity at the beginning and be sure it will never re-allocate.

2.  It calls constructors and destructors on every component in the vector, which can lead to unintended consequences if you treat your constructors and destructors as meaning the entity/component is being created and destroyed in a gameplay sense.
You can avoid that by implementing move constructors and move assignment operators for the objects you store in the vector, since then they can just be moved when the vector reallocates instead of being copied. But remember to make those functions 'noexcept', since vector will only 'move_if_noexcept' to preserve the strong exception guarantee that C++98 mandates.

dwarfman78

  • Full Member
  • ***
  • Posts: 228
  • I'm bietzsche, Nietzsche !
    • MSN Messenger - cd4c@hotmail.com
    • View Profile
    • Email
Re:creation - a top down action rpg about undeads
« Reply #74 on: May 20, 2015, 08:11:26 pm »
i don't want to be nitpicking here but comparing ECS and OOP is like comparing mecanic and an internal combustion engine, one is just an organisation based on the concepts brought by the other. OOP is a paradigm and ECS is a pattern, well it's like you've discovered the lost ark but it exists among many patterns brought in the 90's by the "gang of four".  New paradigm brought by functional programing tends to make most of those design patterns a bit outdated but they still worth something in specific situations.

see here : http://en.wikipedia.org/wiki/Design_Patterns

To be more specific ECS is based on the Composite and Strategy patterns and polymorphism too.

In other words there's nothing wrong with OOP nor something "normal" or not with OOP, inheritance sucks over composition for sure and it tooks us a bunch of years and smell code to realize it, that's all.

btw Elias i'd love to be able to do my own pixel art for my own games as you do, they're very convincing. If i may try to be constructive here i would say that the archer guy is a bit too flashy compared to the other characters.
« Last Edit: May 20, 2015, 08:14:54 pm by dwarfman78 »
@dwarfman78
github.com/dwarfman78