Okay so i'm making a top down classic styled RPG using SFML. But i have a question, and i only ask because yes I've done some googling and either its a stupid question or i cant find the right keywords.

So about a week ago now i discovered Entity Component Systems, and its variations and i fell in love with the structure. So i built a test program to see if i liked it. and i think 2 days of reading articles and then 3 days of programming later ive got a game that functions exactly the same (the bare basics, a player and a world that the player moves on) Nothing super fancy, but i like everything so far

For reference ill just describe what i have, hopefully that'll help answer my question that ill write in a second.

-So ive got an Entity class, that's got an id and a vector of Components.

-Comonents are added as needed to each entity. Originally each Component had data and an update function that messed with its data when it needed. I later moved the contents of the update function up to the System Managers after reading some more articles, (i might revert back to the original, not sure witch way of updating the components i like better) Examples of some Components are Physics, Input, Graphics.

-Then I've got System managers that manage updating for its component type

-And lastly a Manager that holds the System Managers and any other variables i need stored there like my RenderWindow

I'm still tinkering with it, but i like this a lot better than the traditional OOP approach. However there's one problem (lol it could totally just be an issue of me overthinking) that's arisen. So every entity is functionally the same, its the components it stores that make it into something different. So back in OOP if i wanted to create a Player for instance, id probably have to make a player object, and then just create an instance of it. Now if i wanna make a Player, i make a new Entity, and add all the appropriate components, creating any new components as necessary. So my first question is should i define each new type of object i need in some form of file(if so what type would be best) or should i just manually code them in as needed somewhere in a System Manager or something? Im not really sure if this makes sense -.- let me know if im just rambling or if some part of this didn't make sense!

I also had another question but forgot it while typing this oh well, maybe it'll come back to me later.

I'm still tinkering with it, but i like this a lot better than the traditional OOP approach. However there's one problem (lol it could totally just be an issue of me overthinking) that's arisen. So every entity is functionally the same, its the components it stores that make it into something different. So back in OOP if i wanted to create a Player for instance, id probably have to make a player object, and then just create an instance of it. Now if i wanna make a Player, i make a new Entity, and add all the appropriate components, creating any new components as necessary. So my first question is should i define each new type of object i need in some form of file(if so what type would be best) or should i just manually code them in as needed somewhere in a System Manager or something? Im not really sure if this makes sense -.- let me know if im just rambling or if some part of this didn't make sense! blink.png

What you are looking for is probably what Unity calls "Prefabs". You basically store a set of components with specific attribute values as a prefab. Later on, you eigther place or spawn entities specifying just this prefab instead of manually specifying all the components the object needs. Yes, this can be its own kind of file(format). However, you should try to make as little distinction between a prefab and a regular entity both structure and storage-wise - optimally, a prefab just stores a (hidden) entity, has a set of child-entities (only if you need to propage prefab changes in case of an editor), and uses the same serialization routine as a regular entity would (I assume you already need to store some entities as part of your level/map).

Hope I got your problem/question correct, and hope that this helps.

Well from what you've said it at least sounds like im on the right track. As of yet i haven't done any file reading in this particular program, my map and character are the only objects ive worked at initializing. Mostly just for testing purposes. So referring to file reading, in your opinion what would are the advantages to different choices, i understand that every different option would have drawbacks, but as programming goes for reading from files like this ive only ever worked with .txt files, and then reading in PNG's for my game study. I've read that XML would maybe be a good choice? idk Thoughts?

So referring to file reading, in your opinion what would are the advantages to different choices, i understand that every different option would have drawbacks, but as programming goes for reading from files like this ive only ever worked with .txt files, and then reading in PNG's for my game study. I've read that XML would maybe be a good choice? idk Thoughts?

XML is totally viable. I'm using it myself, an entity/prefab might look like this:

<Entity>
    <Character>
        <Positioning>Normal</Positioning>
        <ZOffset>0</ZOffset>
    </Character>
    <Position>
        <Position>
            <X>0.0</X>
            <Y>0.0</Y>
        </Position>
    </Position>
    <Sprite>
        <Texture>NULL</Texture>
        <Blending>Normal</Blending>
        <Tone>
            <R>0.0</R>
            <G>0.0</G>
            <B>0.0</B>
            <A>1.0</A>
        </Tone>
        <Frame>0</Frame>
        <Angle>0.0</Angle>
    </Sprite>
</Entity>

alternatively you could use JSON, which has a less verbose syntax (might be good if you intent on manually creating/editing those entities for a while). Though I havn't used it myself, so I cannot give any opinion about JSON compared to XML in terms of code integration/usage.

You have a factory method in your runtime that delivers a new instance of the requested kind. The factory method knows a recipe for every kind that can be requested. The recipe may be

a) a hardcoded routine; this has the drawback of not being as flexible as a data driven approach, and hence causes maintenance problems in the long run; it is, however, quickly implemented;

b) a prototype, i.e. a completely assembled instance, that is deeply copied and perhaps partly re-parametrized by the factory; this variant is what Juliean suggests if I understood it correctly;

c) a prescription of how to instantiate and assemble a new entity; the prescription is processed (e.g. interpreted) when needed;

You can use combination of them. For example, a) or c) can be used to generate the prototype for b). Moreover, both the prototype as well as the prescription can be read from mass storage.

d) In the former case of the prototype we speak of de-serialization. It requires that the instance is build and serialized once, and can be deserialized then as often as needed (once per application start in our use case). As such the representation on mass storage is close to the representation in memory, so that loading it is relatively fast and re-interpretation of what is read is reduced to a minimum.

e) in the case of a prescription loading is a breeze, because you load just data that is, however, then later to be interpreted by the factory nonetheless. You can use a binary format or a text format for the file representation. The text format, together with a "human readable format" specification", may have the advantage that you can use any text editor to define the prescription at your will. XML and JSON (and similar formats) are often used to do so. However, XML is somewhat bloated but provides additional stuff like their attributes.

Thanks everyone for your responses, I'll be taking JSON and XML into account as potential candidates for what ill implement. I appreciate your input!

You might want to consider an alternative option: using an embedded language such as Lua for your data description. Object descriptors are expressed as Lua tables, parsed by the embedded Lua interpreter. The framework code uses this table to populate the actual game object. I recently wrote a journal entry talking about exactly this, if you are interested.

One of the advantages of such an approach is in allowing object descriptors to be generated procedurally, or to otherwise allow the execution of code in the process of creating an object descriptor. For example, in the linked article I talk about different types of fireball spells. One of the types is called Chain Fireball, and implements a fireball effect that bounces from target to target, doubling damage each time. The effect is created by generating an object descriptor for a bouncing fireball that includes a component, Object Spawner, that accepts another object descriptor for the object to spawn. This Object Spawner component is given the object descriptor for the next fireball in the chain. By chaining objects with object spawner components, the result is a deeply nested Lua table describing the entire fireball chain that, when instanced, creates the desired effect.

The chief drawback for this scheme, of course, is the much greater relative complexity. If such complexity is not desired, then the simpler options of XML, JSON, or YAML are preferred. XML is the de-facto standard, though it is somewhat awkward to use if you generate many of your object descriptors by hand. (Lacking comprehensive tools, such as in the case of a home-brewed engine framework, means that you might end up doing a lot of this.) JSON is very simple to use, but it also tends to be unwieldy, given the amount of " marks. YAML is a bit easier to hand-type, given that you are not required to use " marks around strings.

I've seen mention of people using Lua as i was Lurking around. From the description of your spawner and fireball spell code you've definitely got me interested, and ill definitely go check out your journal. My one question is is there a steep learning curve for Lua? I've only looked into the XML option so far, and it seems like something i could get running in a day, at least with what code ive got. whats your opinion of learning Lua?

Learning Lua isn't all that difficult if you have proficiency in other languages. To be honest, however, going this route is somewhat more difficult than simply using XML. It significantly adds to the complexity of your framework, so if you don't really have a genuine need for it and are a relative beginner, you might be better off starting with simple XML/JSON/YAML instead.

Thanks for your input. I'll read your article, and maybe some more, and see if it seems like a good fit.