Messages

1

SFML projects / Veritas Framework

« on: June 19, 2014, 04:41:37 pm »

Hello everyone! Although this project is not directly related to sfml, I thought that it may be useful to the community.

Veritas is a C++ framework that I have been working on for some time and it's design is
based on the entity-component-system software architecture pattern.

It's goal is to provide a flexible core that allows for fast implementation of features while keeping maintenance to the minimum.

Although the framework is by no means completed yet (the messaging system is not yet completed and the code needs some polishing), for those interested the source can be found at GitHub.
Also, since this is my first serious project (and the first time I'm using GitHub), any feedback is largely appreciated!

Documentation and examples should be finished within a few weeks due to the exams not having finished yet.

2

SFML projects / Re: [SFML 2.1 and C++] 2D Shooter - Pew (Open Source)

« on: June 15, 2014, 01:09:43 am »

new X and new X() are perfectly equivalent. This was not an error.

To the OP: you should have opened a new thread. Now you're requesting help, you're not adding to your project's presentation. And you should show the call stack, so that we know exactly where it crashes.

Just nitpicking here but they are not necessarily the same depending on whether X is a POD or not.

3

Python / sf.Keyboard.is_key_pressed() expensive?

« on: June 08, 2014, 10:15:15 pm »

I was wondering, is sf.Keyboard.is_key_pressed() expensive?
My tests lag considerably when there are 70+ controllable objects at a time (about 300 calls).
The profiler showed that 90% of the time was spent in the is_key_pressed() function so either I am doing something wrong or the function is expensive (after many calls that is).

4

General / Re: Framework Design Advice

« on: June 06, 2014, 06:31:56 am »

I assume with the 2D matrix you're referring to the setting where entities are columns and components are rows? Well, you needn't poll through all the entries and check whether they're there. An entity can hold a list of its components, so you only iterate through those that actually exist.

They it's exactly what I'm referring to. I think the original upside of the implementation is to be able to tell in constant time if a given entity has a given component, so it basically requires the entity to hold a bitset of the size of the total number of components possible (cf https://github.com/alecthomas/entityx).
Anyway I really don't understand the point of it all, except for prototyping maybe. You have a powerful language and you end up just structuring it such that all the elements are int, who hold a set of int, and the actual logic is just delayed "whenever". This really feels like it's "design for primary schoolers"

While this is a common implementation, the entity-component system is not required to work that way. You could even use a hash map for the components. Personally I don't like the data-driven approach of some implementations, as long as performance is good enough I prefer a clean and intuitive design that allows for faster prototyping.

As for your last point, there are no dependencies between classes and so it provides good modularity and decoupling. Maintenance is also easier for the most part.

5

General / Re: Framework Design Advice

« on: June 05, 2014, 08:29:37 pm »

A bit off-topic, butI keep reading all over the web about how entity system is so great and useful, but tbh it seems like total BS to me. All you are basically  doing is creating a giant matrix of tickable boxes, then constantly poll aller over the place to see what is ticked. Also they never explain how the logic to actually exécuté action is supposed to work at all. To me it seems l'île this concept was popularized by people who are awful at programming and who think they can solve every issue by using a big 2d table and checking all the combinations...

I also had troubles with finding info on how actual actions are implemented on an entity-component system. There is very little info on this specific area and the only examples deal with straightforward stuff that work great on a particle system but are pretty worthless when it comes to actual game logic. What I have done in some testing prototypes is implement all the logic in the systems and keep the data that implements the state in components.

Also keep in mind that what defines the entity-component system is not really keeping matrices but avoiding class hierarchies and keeping things decoupled. This can prove very helpful in larger games but for small games I also have my doubts.

By the way, what I also found very important is implementing a messaging system that runs independently from the main pipeline. This can prove very useful when implementing achievements or even if you don't want to continuously keep track of the components for stuff like GUIs. Not everything should be a component or a system.

~Veritas

6

General / Re: Framework Design Advice

« on: June 05, 2014, 07:00:45 pm »

To be honest I haven't really prevented sharing a component, I just don't think it makes sense.
As for the enums, I am not using them because of maintenance reasons. I don't think it's necessary to maintain an enum for each component just to use them as identifiers. Would you mind to elaborate on only caring about the component type when created? Systems still have to check for them and retrieve them so maybe I am misunderstanding something.

~Veritas

7

General / Re: Framework Design Advice

« on: June 05, 2014, 06:20:22 pm »

Components are used to represent an object. Sharing those between different objects does not seem logical to me even though some of their components' attributes may be shared. Of course copying components should be possible. The systems are supposed to take some components and modify them the same for every object depending on the data that they hold. If you want to implement a two players systems you can either create a different system for each player or implement the key bindings in the input component. In any case allowing for systems of the same type doesn't make any sense.

Since components possibly take parameters themselves, I don't think it's meaningful to only pass a type to the entity. Passing a function object that is used to create the component (i.e. a factory) is a possibility, but I wouldn't use this indirection unless it brings actual advantages. Points to consider are rather whether multiple entities might share components, and whether components can be used outside entities.

I don't see the big inconsistency here. It may seem so because of Python's dynamic typing, but in C++, the methods would be quite symmetric:

class Entity
{
public:
    template <typename Component>
    void AddComponent(Component c);

    template <typename Component>
    void RemoveComponent();
};

Another option is to allow to specify the constructor arguments as function parameters but I wouldn't call it an elegant solution. Like you suggested, it may actually be that I am using python.

@Lolilolight It's like you are typing random c++ concepts, I have no idea what you are saying.

~Veritas

8

General / Re: Framework Design Advice

« on: June 05, 2014, 10:55:11 am »

I am not sure what you mean. Systems don't have a one component type limitation. If you want them to register entities with multiple components just put the requirements in the registration_condition function.

~Veritas

9

General / Re: Framework Design Advice

« on: June 05, 2014, 10:12:46 am »

I agree that it doesn't really make sense as it stands. One question I'd like to ask is why you've got the limitation of one component type per system - I would guess that it's because a component encapsulates a specific piece of functionality as opposed to a traditional component of a larger object (which in most cases you would expect to be able to have multiple).

Systems don't have a one component-type limitation.

An entity may have different components but not multiples of the same type. Same goes for the engine class. It can have multiple different systems but not multiple of the same type. This makes sense since you don't want two PlayerInputSystems for example or two GraphicsComponents.

~Veritas

10

General / Framework Design Advice

« on: June 05, 2014, 08:51:25 am »

Hello everyone,

As some of you may already know, I spent some time designing a small game framework
in order to help me with my future projects. Unfortunately, because of the
university entry exams, I didn't really have a lot of time to spend on it.

Now that the exams are almost finished I thought I should start working seriously on
the actual design of the framework. I did make a prototype but C++ didn't prove that great for prototyping.
I am now making a prototype in Python and I will port it to C++ if the performance proves inadequate.

My goal is not to make a framework with incredible performance. What I want to achieve is a core which will allow me to easily implement features, without worrying about dependencies and coupling while also keeping the maintainable code to the minimum.

I have settled on a self-registration entity-component system where the entities register to the systems according to the components that they hold. All the registration functionality should remain hidden and the user should only have to provide a registration condition for each system.

Here is a small example in Python:

import veritas_framework as vf

class TestComponent:
    pass

class TestSystem(vf.System):
    def registration_condition(self, entity):
        return entity.has_component(TestComponent) # Take note that we use the type here
    def update(self, delta=0):
        for entity in self.entities:
            print "updated"

engine = vf.Engine()
test_system = TestSystem()
engine.add_to_systems(test_system) # Here we use the object
engine.add_to_pipeline(test_system)

entity = vf.Entity(engine) # The entity will signal the engine when it updates it's components

engine.update() # Nothing happens

test_comp = TestComponent()
entity.add_component(test_comp) # Passing an object again

engine.update() # Prints "updated"

entity.remove_component(TestComponent) # Here we use the type

engine.update() # Nothing happens

What I am having troubles with is small inconsistencies in the design.
We actually pass the objects when we add a system or a component but we use the types
to remove them or test if they exist.

This is because both the engine and the entity classes should only
keep 1 object per system or component type accordingly. I think this is not obvious with the current design.

One way to solve this is to actually use the type when we add a system/component and the function would return
the created object for further manipulation, however I am not sure whether this is acceptable .

Any help is much appreciated!

~Veritas

11

SFML projects / Re: Unnamed "Tug-Of-War" Strategy Game

« on: June 05, 2014, 08:33:41 am »

I really dig the concept! Please keep us informed.

12

SFML game jam / Re: Game Submissions now open

« on: June 02, 2014, 05:28:38 pm »

Nice! By the way the ChromoShift download links are broken.

13

SFML projects / Re: Killer bubbles from outer space

« on: May 29, 2014, 07:29:37 pm »

Nice work!
By the way, the bubbles remind me a texture that I had seen when working with unity3d.

14

SFML game jam / Re: 3rd SFML Game Jam soon!

« on: May 28, 2014, 09:19:21 pm »

I would love to take part in this but the exams won't be over until next week

15

SFML projects / Re: Occult Classic - 2D Dungeon Arena Spell Based Fighter

« on: May 17, 2014, 06:55:11 pm »

Wow this is actually pretty smooth! Just a minor detail, the camera rotation seems a bit out of theme (but that may just be me). Have you considered keeping it steady ? Other than that (and the crash) it looks great and I would love to try it out after it is released. Keep up the good work!