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

Author Topic: [WIP] Racod's Lair - a coop dungeon crawler [Demo Released]  (Read 84486 times)

0 Members and 1 Guest are viewing this topic.

SpeCter

  • Full Member
  • ***
  • Posts: 151
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #60 on: April 08, 2015, 12:15:20 pm »
Ah ok, you stripped out so much of the header that it seemed to only be a container which holds component data :D

But doesn't this mean that each system can only hold one specific ComponentType e.g. the PhysicsSystem only holds PhysicsData?

How do you update the position of the Sprite then?Does the PhysicsData only point to/reference positional Data of the Sprite?Or do RenderSystem and PhysicsSystem know about each other? :o

I'm particularly interested because I made many different component-based systems before and this seems new to me :D
There are some interesting articles about component-based systems with data-oriented design (too many to post links, nearly each article is useful). Especially a talk by Mike Acton at CppCon was interesting (not about ECS but data-oriented design in general; https://www.youtube.com/watch?v=rX0ItVEVjHc).

But the entire system isn't just data-oriented. Some internals are data-oriented, some object-oriented. And the major API is also object-oriented. So I'm using a hybride of both approaches where it makes sense in my opinion :)

I have already seen that talk(and most probably all the links you could've posted ;)), but thanks anyway ;D

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #61 on: April 08, 2015, 12:41:24 pm »
Ah ok, you stripped out so much of the header that it seemed to only be a container which holds component data :D
The shown class is only the base class - at yes, it is only a container. The actual derived systems (physics) inherit from this container and provide their logic.

But doesn't this mean that each system can only hold one specific ComponentType e.g. the PhysicsSystem only holds PhysicsData?
Yes, that's the idea of my design: Seperation of concerns / domains. If a system needs data from another system, it needs to know it. E.g. my render system holds a const reference to the physics system to be able to query e.g. for the world position of an object. Some kind of coupling is always needed :D

How do you update the position of the Sprite then?Does the PhysicsData only point to/reference positional Data of the Sprite?Or do RenderSystem and PhysicsSystem know about each other? :o
Well, the physics data contains the position and face direction of the object. If one of these changed, the render system is notified in order to recalculate the transformation of the sprite. In my case this is done via dirty flag.

Other communication is done via events. E.g. in case of a collision, the physics system propagates a collision event without knowing who's listening. Listeners are registered through an interface, so they are notified about each event. So e.g. the (later) sound system could register for collision events to play "blobb" if a player runs towards a wall - without letting the physics system know about the sound system.
But this kind of messaging and decoupling is up to your personal view. Of course you could solve all communication via messaging, leaving all systems decoupled. E.g. the render system would request the obejct position via event... up to you how you life it :)
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

SpeCter

  • Full Member
  • ***
  • Posts: 151
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #62 on: April 08, 2015, 01:23:44 pm »
I see :)

In my current component-based system the systems have handles to components they need(Transform,Velocity,Render etc.).
If the entity in question has all the components it needs, the system adds the handles and processes them in its update method.

The MovementSystem for example is like this:

MovementSystem : public EntitySystem<Transform,Velocity>
{
...
   void Update(float delta) override
   {
      for(auto&& component_pack : components)
      {
         auto position = std::get<0>(component_pack);
         auto velocity  = std::get<1>(component_pack);

         if(position->x > 800 || position->x < 0)
         {
            velocity->x *= -1.0f;
         }
         if(position->y > 600 || position->y < 0)
         {
            velocity->y *= -1.0f;
         }
         position->x += velocity->x * delta * 0.1f;
         position->y += velocity->y * delta * 0.1f;

      }
}

The template parameters depict which Components an Entity(just an id) needs to have to handle said entity.
If an entity has all needed components I add them to the component_store(components) as a tuple.

If there are other systems like physics which need Transform, Velocity and e.g. Volume it references the same Transform and  Velocity as the MovementSystem.

That way they are decoupled and the only downside is that I have to keep track in which order systems are executed(e.g. if the movementsystem updates before applying physics the positions will be one frame behind)

But enough of my shitty ecs,  I don't want to flood your thread with my stuff, we are here to enjoy your stuff(at least I do!)

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #63 on: April 08, 2015, 01:29:25 pm »
I have to keep track in which order systems are executed(e.g. if the movementsystem updates before applying physics the positions will be one frame behind)
That's also true for my system! First input & ai system to generate object behavior events, then physics. Later avatar (aka rpg-system), then animations and finally render.

But enough of my shitty ecs,  I don't want to flood your thread with my stuff
No problem. Your approach is also interesting (but of course I'll keep mine xD). My current code is around ~370kb and makes heavy use of my system :D But I like your idea!

we are here to enjoy your stuff(at least I do!)
Great! ;D
« Last Edit: April 08, 2015, 01:31:22 pm by Glocke »
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #64 on: April 08, 2015, 06:26:52 pm »
In the last days I implemented several features and now, here's a demo video and a list of these features:
  • Multiple Dungeons accessable through stairs ("door" through the ground :D )
  • Simple AI (using A* for pathfinding). Now, there are enemies who can chase the enemy, melee attack him, lose track and return to their spawn position.
  • Fading objects (Characters and projectiles, see fireballs at the end)
  • Strafing movement (using a modifier key to lock the face direction)
Currently, enemies are not chasing through doors. But this will be implemented for some type of enemy. In general, enemies are able to use doors and traverse the entire dungeon if necessary.


/EDIT: Also follow the project on IndieDB ;)
« Last Edit: April 09, 2015, 12:33:05 pm by Glocke »
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #65 on: April 22, 2015, 09:09:19 am »
Hey folks,

because a new semester has started, the work on rage will be slowed down. Up to my freetime I plan to do some unit testing and want to create additional sprite sheets and other graphics. Stay tuned!

Greetz, Glocke
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #66 on: June 14, 2015, 09:48:20 pm »
Hey folks,

while testing in my rare freetime I discovered lots of bugs. So I decided to heavily push the unittesting part of the game architecture in order to be able to get rid of those bugs. Also, some refactoring (yees, again :D) will occure.

During this process I'm planning my further steps. Feel free to discuss on features you would like to see in the game!

Greetz, Glocke
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #67 on: August 19, 2015, 12:46:35 pm »
Meanwhile, I'm nearly 100% focused on refactoring the entire(!) codebase and applying unit testing to it. Up to now, I found lots of bugs (undefined behaviors, annoying copy-paste-based fails and lots of other crazy stuff) by applying unit testing to the yet refactored parts of the codebase. Additionally, I'm going to improve the overall architecture (more loose coupling and fast event-based notifications) to improve the quality of future enhancements.

Up to now:
Linking CXX executable rage_test
Running 296 test cases...

*** No errors detected
 
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re: Rage - a "modern" rogue-like
« Reply #68 on: August 19, 2015, 01:23:36 pm »
What unit tests do you have? I can't think of anything reasonable in my game to test with unit tests... :D
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #69 on: August 19, 2015, 02:01:09 pm »
I can't think of anything reasonable in my game to test with unit tests... :D

I'm unit testing for example collision detection, movement interpolation and the culling of visible objects. I also test lots of conditions within this cases, e.g. that the object - that is going to be moved - is really assigned to an existing scene. (else the interpolation algorithm should throw an usable exception). Therefore I create demo scenes where the exact result is easy to describe.
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #70 on: August 27, 2015, 11:29:06 am »
Meanwhile, the core systems (collision detection, sprite animations etc.) has been (re-)implemented and tested. So I started focusing on more high-level features like inventory and quickslot implementations. The quickslot is supposed to allow the player to create shortcuts for spells and items. Both inventory and quickslot implementations are also great for unit testing ;)

Unfortunately, there is no "game code", yet. At the moment, the entire development is about designing, implementing and unit-testing piece by piece. So there's nothing to showcase, yet. Sorry :P
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #71 on: August 29, 2015, 12:54:02 pm »
Today I face another interesting use case of unit testing: I'm implementing a simple looting system: A dying enemy drops a set of its inventory to "his corpse". That corpse contains several items per registered player - so while looting the items is strictly player-assigned (in terms of who-is-picking-which-item). Then a player can loot the corpse (in fact: the items that were assigned to him). Creating such a drop distribution is interesting here, because my items are structured like that:
struct item_slot {
    item_data data;
    int quantity;
};
struct inventory {
    vector<item_slot> items;
};
where multiple items of the same type are stacked.

Let's come to the point: The distribution's implemented can easily be unit tested. To test whether its precondition is satisfied (that the items will be distributed to the players as equally as possible), can be tested by distributing some items to some players, counting the items per player and building up a histogram to finally verify the dimension of the distribution. Like: 7 items are distributed to 3 players, so two players will obtain 2 items, and one player will obtain 3 items.
« Last Edit: August 29, 2015, 12:57:10 pm by Glocke »
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #72 on: September 06, 2015, 02:31:26 pm »
Meanwhile, some features about the modability of the game has been implemented. So e.g. items or spells can be added by writing additional XML files. Also status effects (like "is burning") can be applied (e.g. by a fireball spell).. I hope this flexibilty will allow many cool stuff for the future development!

Hopefully, the current implementations (combat calculations and similar things) don't take too long .. I can hardly wait to present a brand new demo video, but this will take some additional time...

But stay tuned! This project is not dead ;D
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #73 on: September 08, 2015, 10:54:35 am »
Again, here are some experiences about unittesting parts of a game: I'm currently unittesting some sound triggerings. I have a dedicated sound system that is notified via events:
struct SoundEvent {
    int object_id;
    SoundAction action; // an enum, see below
    float pitch, volume; // where 1.0 is "normal"
};
My sounds are grouped to specific actions, specified by an enum:
enum class SoundAction {
    Attack, UseItem, CastSpell, Die
};
Additionally, my sound component per object looks like this:
struct SoundData {
    map<SoundAction, sf::SoundBuffer const *> sfx;
};
A note about those pointers: They are non-owning raw pointers, because all game resources (including sound buffers) are held by the game session. They are released if the game quits - as the soundsystem is destroyed as well.

Finally: When equipping a weapon, the actor's sound component's "Attack"-action is changed to the weapon's attack sound. This can be unit tested ... EquipWeaponChangesAttackSound ... EquipArmorDoesNotChangeAttackSound.
Additionally, triggering the sounds can also be tested: My systems message each other through those events (see above). So when testing the "equip-items"-code, I can fetch all outgoing SoundEvents (without forwarding them to a soundsystem - there is no sound system involved in this test ^^ But there's a SoundSender who produces SoundEvents) and check whether the correct sound (object id + sound action) was triggered. 8)
« Last Edit: September 08, 2015, 10:57:02 am by Glocke »
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re: Rage - a "modern" rogue-like
« Reply #74 on: September 11, 2015, 01:15:36 pm »
Meanwhile, I reimplemented lots of features (existing and new ones). But there aren't colorful pictures, yet... sorry ^^ But here's a list of features I plan to ship with the game.

Features
  • Free to play and distribute
  • Platforms: Windows, Linux; probably Mac OS
  • Very low system requirements (e.g. a Netbook)
  • Hack'n'Slay combat
  • Minor puzzles
  • Procedurally generated dungeons, enemies and loot
  • Cooperatvie gameplay via splitscreen / shared camera
  • Customizable keyboard and gamepad controls
  • Modable game content via XML and Lua (for AI scripting)
  • more tba

Visit Rage @ IndieDB for media.
« Last Edit: September 11, 2015, 01:19:00 pm by Glocke »
Current project: Racod's Lair - Rogue-inspired Coop Action RPG