next »

[BlueSweatshirt]

@Jack: I disagree there, components have helped us develop things more rapidly once the systems are in place. Write physics code once then just attach a physics component - sounds a lot simpler than having to manually code in a physicsBody var on all physics classes manually.


Ontopic, we've had a bloody excellently productive week. Water level, wooden blocks, and a bunch of tidying behind the scenes? woot.

Well, there are quite the number of ways you could implement components, along with the varying degrees of extensiveness you use it. That's why I used words like "can" so often--I don't think component systems are invariably messy or "bad". And yes, I'd tend to agree a physics component is a viable use case for the architecture. However at the same time, if that's the only(or one of the only) components you ever really need(or don't need), then that hardly justifies the use of a component system. So, yeah, it seems it's actually a rather nebulous topic to discuss in general, since it's not really anything concrete enough to evaluate on a generalized basis.


My turn to talk about what I've done and why I'm happy about it rather than bantering on about concepts:

It's amazing how clear things are in your head when you've been away from a project for nearly a month and had all that time to sort out what you would do when you returned. I worked on Lizard Warrior again today after nearly a month of hiatus and it seems like everything went impeccably smoothly.

[Graham.]

Perspective is an easy thing to forget the value of.

[Graham.]

I've been looking into component-based designs recently also. After reading up a lot and implementing some stuff I've come to the conclusion that I like the core idea, but C++ is really the wrong language to be trying to express this with.

C++ is fine for components. Any language supports them well.

It can be far more efficient, in the interest of production, to merely plan out where to put which functionality and forego components entirely. Component systems are good in things like Unity because the developers don't know how the user will want to use each bit of functionality. You, as the developer of a game or application, generally know exactly what functionality you need and where you need it. You'll save time and your code will be a lot cleaner.

No matter what you do you have to be smart about it. Components are always a good idea as long as you don't fuck it up. "Planning" functionality and sticking with structured code is valuable if you know what you want, but then you sacrifice the advantages of "iterative" development. There's a strict upper bound on the complexity of a system that's been pre-planned. There's non if you evolve it.

It's never a bad idea to learn how to code components.

[Ludophonic]

C++ is fine for components. Any language supports them well.

No, I gotta disagree. Every component system I've seen looks like someone trying to smush the features of a more dynamic language into C++. You end up either ditching the component system to make certain things that should be simple less painful - like having basic properties like position in an entity object - or stay pure and take the long way around to do simple things - like get an entity's position. If you had a language that had a messaging paradigm more at it's core it would be much better.

Writing in a component-based style in C++ feels like writing in an object-oriented style in C. Sure it can be done, but it feels like you're using the wrong tool for the job. This sort of dynamic code is C++'s big weakness. Which is why you don't see any major window toolkits written in C++ for instance (QT and MFC use pre-compilers/pre-processors, Cocoa is objective-C, Android is Java...)

[Graham.]

Libraries are a different story.

There are a lot of poor implementations of "components" in C++. I stopped thinking about why these exist after I'd seen enough. But that doesn't mean the language has inherent problems.

Messaging can be accomplished with clever use of base-classes and following whatever paradigm you pick for yourself. Choosing a different language just ensures that other programmers who write in your system don't shoot themselves in the foot because they don't understand how to use it.

I think components in general is something the gets underestimated. For every good implementation there's 5 bad ones, and it becomes easy to lose sight of what it was really about in the first place. Code is as flexible as you'd like it to be. C++ gives you pointers and classes. You can do whatever you want. Though how you should do it may not be obvious, and the necessary discipline to ensure you don't tread over yourself isn't forced. So you can fuck yourself over. It's natural to blame the language. But programming languages are like speaking languages. They're tools. Their function is up to the creator.

Think of it this way. Why would you need a language with more restrictions to implement a system design that offers more flexibility? If you see the irony there, and you know the power of C++, you'll know components are possible.

Without pre-compilers - which you mention, and which I would never write a game without (and I mean a custom one) - there are some limitations on how easy it is to leverage the power of whatever component system you build. The ideal language is lisp, closures, macros - I mean, really. But we've got what we got. C++ gets it done and it does it well, and there's certainly no flexibility barriers that can't be overcome. Relative to the scope of a game and the advantages of a powerful system, taking the time to figure out modular architectures is worth it. You've just got to bang your head a little, or maybe a lot.

[rivon]

Are there any nice (and done the correct way) open-source examples of the component game architecture? And if there was also an example game to go with the framework, that would be awesome.

[st33d]

I think that if you're basing your code architecture around one paradigm then you aren't interested in making a game.

I have component-like elements in my code, because their transferable nature works. I just knocked up a basis for a game in 2 hours today because I had a transferable physics engine that I've built. I can do the same with my sound manager without making any alterations to it at all.

But I don't insist that all the code does that because games require unique code to make them interesting as opposed to generic-grey-clones.

I think it's good to start with a design, but as with everything, if you stick to it beyond the limit of common sense then that design becomes dogma.

[_Tommo_]

meh, I'm totally pro-C++ but I have to reckon that it's the wrong tool if you want to use a component based system.

The problem with C++ is that
-components don't really "merge" with their GameObject, you still have to manage different objects with different states, and this is bug prone and ugly (and inefficient)
-you can't have a transparent message passing system, IE - when you want to send an event to a particular Component, you have to manually check if it's present and take action, you can't just send it and have the language do the routing like, say, in Objective C.

To me a component system makes sense when the components are only a way to construct the capabilities of the GOs, and then you don't have to care for them in game code ever again. Having to remember which component does what and having to use components manually is just crap.
In C++, just use inheritance please!

[eigenbom]

you can't just send it and have the language do the routing like, say, in Objective C.

Afaik objective-c message passing occurs in the runtime, you could implement a similar thing in c++, without the specialised syntax. E.g., your entity could have a processMessage(..) function that broadcasts it to all its components. You could even set up some #define to make it look like MESSAGE(entity,health_damaged); But I totally agree with you, Obj-C already has implemented this stuff, but still, it's fun to implement specifically what you need, and for that, c++ is as good as any other language. imho.

[_Tommo_]

without the specialised syntax

"without a specialized syntax" you can do pretty much everything in any language, after all everything gets compiled to assembly.
But stuffing everything into a colossal if/else in a processEvent function looks BAD to me, and to some extent is something I'm already doing

[eigenbom]

not every language is compiled to assembly, but anyways .. in my system i've got...

Code:

void Entity::processMessage(Message* m){
  foreach(Property& p, properties){
    p.processMessage(m);
  }
}

It's a trivial message forwarder. If the property/component doesn't recognise the message then it doesn't handle it. Then in the property..

Code:

void PhysicsSystem::processMessage(Message* m){
  switch(m->type){
    case Message::JUMP: {
    // apply jump force..
   
    }
    default: {}
  }
}

It means I have to have a case: for each message type I'm interested in, but that's ok with me. The alternative, as u say, is to use inheritance to do the dynamic dispatch.. But in this example, I can easily have multiple systems handle the same message, e.g., the SoundSystem might play the boing sound when it receives the jump event..

[Ludophonic]

Reading articles on component-based programming there's often a bit of "why object-oriented programming is wrong" preamble. I think they're a bit off though. The problem isn't objects, it's classes.

Some sort of prototype-based OO extension, let's call it Prototypical-C++, that added a bit of Self to C/C++ kinda like Objective-C++ adds Smalltalk would be awesome.

[Geti]

we use a similar thing to eigenbom - this has the added bonus of being able to send the message very simply over the network.
Messages also have an optional bitstream parameter, which lets us send any serialised data between components and separate objects, as well as over the network.

As an aside, got 2d SAT physics detection and resolution working for arbitrary convex polys. Still gotta make a few special case primitives to reduce the number of comparisons needed (for say, a circle) and should probably consider some form of VR optimisation but I'm pleased for now, and gotta get back to KAG work

[wademcgillis]

YUUUUUUSSSSSSS

I got menus working with SFML on OS X!

Now the only problem is that menu usage blocks the game.

[eigenbom]

Messages also have an optional bitstream parameter, which lets us send any serialised data between components and separate objects, as well as over the network.

can u elaborate on this?