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

0 Members and 2 Guests are viewing this topic.

Elias Daler

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #225 on: September 06, 2015, 09:02:45 am »
@Grimshaw, thank you for encouraging words!
Do you store components contiguously or not?

Sometimes the time you save in development by doing something slightly less correct can pay off as well. Engineering time is a resource as much as memory or CPU, consider that :D
Yep, but it can improve the engine design a lot and save me lots of time in the future. It's hard to be sure from the beginning. :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 #226 on: September 06, 2015, 03:47:02 pm »
It's hard to be sure from the beginning. :D

That's right! I faced this at my project, too. But finally my major performance problems were fixed after reimplementing my ECS. Btw I use a contiguously approach for components only. More highlevel gameplay elements (like items or spells) are dynamically allocated. I haven't tested this referring to performance yet, but I think (of course depending on the type of game) it might be acceptable.

Btw: Your screenshots etc. look really great! I'm curious about the final version :)
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

dabbertorres

  • Hero Member
  • *****
  • Posts: 506
    • View Profile
    • website/blog
Re:creation - a top down action rpg about undeads
« Reply #227 on: September 06, 2015, 08:12:42 pm »
Just to add other container types to the discussion, I've used Google's dense hash map (I exported from Google Code, I haven't found an official repository since it closed) and haven't noticed issues with it.

In addition, I've found and heard b-trees (not binary trees) can be a good choice as well.

lezebulon

  • Full Member
  • ***
  • Posts: 235
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #228 on: September 06, 2015, 09:58:50 pm »
Events. Collisions don't happen frequently, so this is not a big perfomance issue.
Sorry I don't get it,
I'm assuming that for collision you run the collision update method on something like std::vector<ColisionCpt> , right ?
In that case, how do you know which entities the event should refer to ? Or does your collision component hold a pointer to an entity ?
And when firing the event, by what system do you know that entity A should respond to the collision by dying (for instance), and that entity B should respond by moving back? Is that because the collision response is a virtual method?

Grimshaw

  • Hero Member
  • *****
  • Posts: 631
  • Nephilim SDK
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #229 on: September 07, 2015, 02:31:21 am »
@Grimshaw, thank you for encouraging words!
Do you store components contiguously or not?

Sometimes the time you save in development by doing something slightly less correct can pay off as well. Engineering time is a resource as much as memory or CPU, consider that :D
Yep, but it can improve the engine design a lot and save me lots of time in the future. It's hard to be sure from the beginning. :D

Yes I do, but its not a hard requirement. I basically have one pool per component type, which hands me N component instances when I ask for them.. So most of them should be contiguous, most of the time, but the world subsystem will work with even components allocated with new if I prefer it. You should totally commit to making the best library of components you can, either with behavior in component or component + system.

How you put these components together could and should be less hardcoded and allow more flexibility from game code.
« Last Edit: September 07, 2015, 02:36:02 am by Grimshaw »

Elias Daler

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #230 on: September 07, 2015, 08:48:31 am »
@Glocke, well, reworking the system didn't help me. Guess the performance of my game was always pretty okay. Storing components contiguously was more like an exercise, I guess. And thanks!

@dabbertorres, thanks, that looks interesting. Didn't know about those structures.

@lezebulon, yep, all components store the pointer to Entity which owns them. (But I would store entity's id in the future, because I can quickly get entity by its id). So, one system may construct event which contains entity's id and other system will process it.
But I sometimes use the approach which Nexus has told about. Sometimes it's better for system to handle multiple components. In my case, if I need to change some components in one system, I may get this component by another component's owner pointer.

And when firing the event, by what system do you know that entity A should respond to the collision by dying (for instance), and that entity B should respond by moving back? Is that because the collision response is a virtual method?
This is all done by scripting. When two entities collide, a Lua function for each entity is called which does all the stuff.

@Grimshaw, did you notice any perfomance differences when storing components contiguously and not contiguously?
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 #231 on: September 07, 2015, 01:00:16 pm »
Please forgive me if I'm being dense here (I haven't used Lua) but what advantage does the scripted onCollision function have over a C++ std::function callback? Is it purely so that you can change it on the run without recompiling? Or is it something else?

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #232 on: September 07, 2015, 01:35:49 pm »
Guess the performance of my game was always pretty okay.
This is all done by scripting. When two entities collide, a Lua function for each entity is called which does all the stuff.
On which type of system have you tested that your performance is pretty ok? I'm curious about testing it on my netbook (despite it is of course no gaming computer^^).
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

lezebulon

  • Full Member
  • ***
  • Posts: 235
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #233 on: September 07, 2015, 09:20:12 pm »
This is all done by scripting. When two entities collide, a Lua function for each entity is called which does all the stuff.

Sorry I'm really not being clear :)  what I didn't get was, how do you determine which Lua function to call on the entity? At this point, you only know that 2 entities collided, and each entity is defined only by the list of its component (if I understood). So based on this, how do you figure out which Lua response to call ? I can think of several ways of doing it, but none that would be flexible enough and be in O(1)

Sorry I'm asking so much btw, I've always seens tons of ECS thrown around , but on every implementation it seems they never manage to make the whole thing work in constant time (with respect to the number of total component, system, etc). Whereas for me the point of ECS is that it's really easy to scale

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6259
  • Thor Developer
    • View Profile
    • Bromeon
Re:creation - a top down action rpg about undeads
« Reply #234 on: September 07, 2015, 11:02:45 pm »
Implementing a double dispatch system in O(1) is relatively easy: you create a 2D table of function objects/pointers, where each row and column is indexed by the entity type. Each cell contains the function for the combination of the row and column types. The type can be any criterion stored in any component.

You should really have a look at aurora::DoubleDispatcher, it uses std::unordered_map and thus amortized O(1). :)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

lezebulon

  • Full Member
  • ***
  • Posts: 235
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #235 on: September 08, 2015, 01:05:55 am »
Implementing a double dispatch system in O(1) is relatively easy: you create a 2D table of function objects/pointers, where each row and column is indexed by the entity type.
Yup, but how is the concept of "entity type" even defined ? Usually the "type" is defined by the class hierarchy, but since there's no class hierarchy in an ECS, for me it's either:
- an entity type is an instance of an entity, which means a full vtable for each instance (still doesn't explain according to what criteria it should be filled)
- an entity type is a given combination of components, which means that they are 2^N possible entity types for a total of N components. Which means that we have to careful think about which combination of component should be dispatched to which virtual function.

I mean, it seems to me that there's always a point where, if we want to keep everything flexible, we are facing a combinatorial explosion simply because an entity could be any combination of components

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6259
  • Thor Developer
    • View Profile
    • Bromeon
Re:creation - a top down action rpg about undeads
« Reply #236 on: September 08, 2015, 06:18:15 am »
Yup, but how is the concept of "entity type" even defined ?
The type can be any criterion stored in any component.

It may be meaningful to store an attribute in the collision component, if dispatching is used for collision response. Make your dispatcher generic so that it can extract the type as you wish -- that's also what Aurora's implementation does.
« Last Edit: September 08, 2015, 06:20:21 am by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

Elias Daler

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
    • Blog
    • Email
Re:creation - a top down action rpg about undeads
« Reply #237 on: September 08, 2015, 08:09:22 am »
Please forgive me if I'm being dense here (I haven't used Lua) but what advantage does the scripted onCollision function have over a C++ std::function callback? Is it purely so that you can change it on the run without recompiling? Or is it something else?
Yep, I could have used std::function for the same effect. Yep, I mostly use scripts to make quick changing possible. It also helps me to not search the source code when I want to see how some entity works: all entity properties and callback functions are stored in a corresponding script.

On which type of system have you tested that your performance is pretty ok? I'm curious about testing it on my netbook (despite it is of course no gaming computer^^).
I don't really remember which is the oldest PC I've tested it on, but I must say that my laptop is 5 years old and not that powerful. There's nothing to worry about in terms of perfomance. There isn't many sprites on the screen in one moment. There isn't any physics or complex AI.

what I didn't get was, how do you determine which Lua function to call on the entity? At this point, you only know that 2 entities collided, and each entity is defined only by the list of its component (if I understood). So based on this, how do you figure out which Lua response to call ? I can think of several ways of doing it, but none that would be flexible enough and be in O(1)
I store the corresponding function's luabridge::LuaRef in CollisionComponent (this is like a pointer to a function which lets you call this function). O(1)! :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 #238 on: September 08, 2015, 09:38:12 am »
I don't really remember which is the oldest PC I've tested it on, but I must say that my laptop is 5 years old and not that powerful. There's nothing to worry about in terms of perfomance. There isn't many sprites on the screen in one moment. There isn't any physics or complex AI.
5 years old? So the laptop might have a dual core cpu with >2 GHz per core? That's quite much for 2D gaming :) Personally, I'm focused to make my game's core (physics, graphics, basic gameplay logic) run on the very low end hardware (e.g. 2 GB Ram, 1.6 GHz Single Core, Intel OnBoard GPU ^^) .. sometimes it's pure pain, especially when using a heavy combination of non contiguous containers and lots of virtual methods (meanwhile is replaced all non contiguous containers and moved away from too much OOP). But I think the trouble is worth it, because it offers to use additional computer power for more highlevel tasks like AI.

Can you give us a short sketch of your architecture? :) You were talking about your ECS which is object-oriented. What I mean: How do the components message each other? Is there a virtual interface each (sub-)component implements of even overrides? Or do you handle all game logic by calling bound lua functions?
« Last Edit: September 08, 2015, 09:40:45 am by Glocke »
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Otherian

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re:creation - a top down action rpg about undeads
« Reply #239 on: September 08, 2015, 07:59:38 pm »
I really love the screenshots of your project. It is very motivating to see a project wich is already so far in its progress :)
I hope you will finish it that we can actually try and play it! Keep up the nice work! :3

Have you taught the whole programming stuff to yourself?
And do you recommend the ECS engine for a 2D-SFML-Game or would you like to change it after you've got to experience it yourself for quite some time? I just ask because I'm planning to start a game-project by myself and am still not sure wich approach to choose...

 

anything