Irrlicht Engine

Ok i found the following while surfing the net for a good way to keep track of my entities and make them flexible as possible.
Well know i'm interested what do u guys think about that system.

http://cowboyprogramming.com/2007/01/05 ... -heirachy/

If you're writing a general purpose engine or the first of a series of games, then sure, that looks like a reasonable design.

If you actually want to get a game complete, then you're just prevaricating instead of knuckling down and defining exactly what you need to implement, then implementing that and only that.

So, the usual answer, really.

hmm yeah i was tinking about making a easy to reuse entity system with that. well yeah really the usual answer ...hehe

I thought a little bit about your answer and my initial idea why to use that concept. i wrote some games in the past and did it like u dicribed how to get stuff done....i just implemented what i really needed. well works until u finish the first few things and then yeah...then i always tried to add new features and i ended up recoding a whole lot of stuff. well just wanted to say that. maybe someone else has encountered something similar.

This sounds kind of interesting. But I don't completely understand it.

Would you still have, say, your Character class, but it instead contains a list of components. I suppose that is the "object as a component container".

I'm not sure how the "object as pure aggregation" bit works though...

In your game start function instead of creating a Character object would you just create separate, physics body, animated character etc.. Objects and link them together? does that sound about right?

and then define these component collections in XML or something

it'd be nice to see some UML or example code using this

well actually i'm already implementing this as pure aggregation.
a entity in my engine is nothing more than a ID and when i create a component i push it to the component managerwith the id of the entity. in other words all cmponents from all entities are in one huge list. and only linked by the entity ID. works pretty well actually and makes stuff like networking pretty simple to integrate. in other words the is nothing like a entity any more. u just create the components and push them to the component manager with the entity ID. thats it.

Sudi wrote:i just implemented what i really needed. well works until u finish the first few things and then yeah...then i always tried to add new features and i ended up recoding a whole lot of stuff.

I'd class that as a problem of insufficient planning, not inflexible code.

If you're working to someone else's design, it's a good idea to code in flexibility, because they will change their mind. A lot.

If you're designing and writing your own game (and a game, rather than a game engine), then you'd be far better off spending more time designing than coding. The cheapest bug to fix is the one that you never introduce.

true rogerborg.
but yeah in group projects its always hard to plan out everything in the beginning. but otherwise u r right.
well but right now this system seams to work perfectly with editors. it makes it really easy to add new entities and stuff even through scripts.
well i might post some of the stuff when i'm done with it.

This is quite interesnting.
If my group team grows I will think seriouly in using it.
But comments apart I think that the problems that this resolves is because a bad requiriment and analysis stage.
Maybe because most software engineier do system information sotware and not video games or because due to publishers, games developer must focus in fast realeases. That because some of them are using scrum. But this is for small teams.

But again, the problems that the speecher is resolving is problem of INITIAL bad requiriments and oo analisis.
Of course as I mentioned before you maybe had not enough time for well focusing on this stages but retinking I realy don't understand how a game desinger don't have the intial requiriments. It is a game, requerimients are given for client few people and besides you don't have contact with user (maybe different from client) so requeriments are easyier to obtain.

Anyway this is very good and interesting. And IN THE CASE of this guy and his team he used and work quite well in a such complex game as tony hawk.

The reason that I bailed on commercial games development was that it's abundantly clear that it's not a mature development environment.

Publishers - and specifically 'producers' - can and do change their minds about what kind of game they really want right up to the Gold Master date, and it's never anybody's problem but development to make reality bend to the insane whims of the producers.

It seems to be a little "better" working for someone like EA, but only because you'll be working on Sportsgasm 2008, which is just Sportsgasm 2007 with live updated advertising hoardings. Oh, and doing 90 hour weeks.

So if you're doing commercial development, a flexible model really is a good idea - and to be clear, I like the model presented here. It just bugs me that it's still necessary now that we're living in the Future.

rogerborg wrote:The reason that I bailed on commercial games development was that it's abundantly clear that it's not a mature development environment.

Publishers - and specifically 'producers' - can and do change their minds about what kind of game they really want right up to the Gold Master date, and it's never anybody's problem but development to make reality bend to the insane whims of the producers.

It seems to be a little "better" working for someone like EA, but only because you'll be working on Sportsgasm 2008, which is just Sportsgasm 2007 with live updated advertising hoardings. Oh, and doing 90 hour weeks.

So if you're doing commercial development, a flexible model really is a good idea - and to be clear, I like the model presented here. It just bugs me that it's still necessary now that we're living in the Future.

But Publisher and producers CAN change in run the requiriments?
I mean, they can say that "must have this and that" on run time but they can change basics requeriments to have to rebuild your whole desing (if we use hirechical object and not components) ?
That makes nonsense,it is like a producer change the whole script in a movie in runtime (can change here and there but not the basics).

It is clear that have to be flexible for adding quitin functionality but flexible for adding quiting the whole basic concepts?

Do you imagine a producer saying on half development to gear of wars to change from that kind a game to a metal gear style!!!. It have non sense.
He can ask for addin this functionalyty or that and that is ok, cause it is obvious new functionlity will arise, and your desing must contemplate this. But can not ask for a requirmient/s that will change basic architecture and deising. Because will be a different kind of game with a differenc (complete) new desing.

And besides component aproach is going agains a OO desing.
If we use this, then all the analisis and desing technics will not apply.
We must use programtion oriented to components, that it is not OO.

I repeat, it is clear that desing MUST be flexible, but flexible doesn't mean that can handle whatever new functionality no matter this functionality put upside donw the central architure that was initialy defined.

I am sure you don't mean than publisher can say: "make an rpg".
And then in half development say "better change it to a FPS". That will make no sense.

Anyway, as I said it is very interesting and will try to watch what are the strong and weak points. Every process/technice has them, nothing will be perfect for everthing.

From personal experience Eidos asked us to turn a mech combat game into a giant armoured spheres race game half way through the project.

Well all u guys say seams pretty obvious...i encountered a nother benefit of this model....just wanted to tell u...anyways its about the map editor of our game. it also uses the component system forthe objects u place and then the components are simple loaded when playing and the big benefit is the map editor guy is able to make new entities without touching the code with simply using the existing components and maybe adding some stuff via a script component. well its really great.

Vsk wrote:

rogerborg wrote:The reason that I bailed on commercial games development was that it's abundantly clear that it's not a mature development environment.

Publishers - and specifically 'producers' - can and do change their minds about what kind of game they really want right up to the Gold Master date, and it's never anybody's problem but development to make reality bend to the insane whims of the producers.

It seems to be a little "better" working for someone like EA, but only because you'll be working on Sportsgasm 2008, which is just Sportsgasm 2007 with live updated advertising hoardings. Oh, and doing 90 hour weeks.

So if you're doing commercial development, a flexible model really is a good idea - and to be clear, I like the model presented here. It just bugs me that it's still necessary now that we're living in the Future.

But Publisher and producers CAN change in run the requiriments?
I mean, they can say that "must have this and that" on run time but they can change basics requeriments to have to rebuild your whole desing (if we use hirechical object and not components) ?
That makes nonsense,it is like a producer change the whole script in a movie in runtime (can change here and there but not the basics).

It is clear that have to be flexible for adding quitin functionality but flexible for adding quiting the whole basic concepts?

Do you imagine a producer saying on half development to gear of wars to change from that kind a game to a metal gear style!!!. It have non sense.
He can ask for addin this functionalyty or that and that is ok, cause it is obvious new functionlity will arise, and your desing must contemplate this. But can not ask for a requirmient/s that will change basic architecture and deising. Because will be a different kind of game with a differenc (complete) new desing.

And besides component aproach is going agains a OO desing.
If we use this, then all the analisis and desing technics will not apply.
We must use programtion oriented to components, that it is not OO.

I repeat, it is clear that desing MUST be flexible, but flexible doesn't mean that can handle whatever new functionality no matter this functionality put upside donw the central architure that was initialy defined.

I am sure you don't mean than publisher can say: "make an rpg".
And then in half development say "better change it to a FPS". That will make no sense.

Anyway, as I said it is very interesting and will try to watch what are the strong and weak points. Every process/technice has them, nothing will be perfect for everthing.

Uhm, excuse me, it did in fact occur to Gears of War! Maybe not as much, but they were required to change design schemes in the midst of development for characters, especially Marcus.

Either way a publisher isn't going to change something like Gears of War, because as you know Epic Games didn't exactly need Gears of War to be finished, Microsoft needed it finished. Microsoft was in need for a Halo replacement, while Epic was readily selling $750,000 packages to every development company in the industry, and they had UT3.

Now with companies like Insomniac Games, they were in fact asked by SCEA to change the "scheme" of their game for Rachet and Clank because it was going in the direction that SCEA necessarily wanted.

But anyways, you have to realize that unless your a company like Epic Games, or Crytek, then your development group is pretty much going to be going off the whim of the publisher. The milestone sheets are especially ridiculous. As I said Epic Games didn't need a publisher, the publisher needed their proven process, and you can definitely expect Mark Rein to never reduce himself to the requests of Microsoft.

rogerborg wrote:From personal experience Eidos asked us to turn a mech combat game into a giant armoured spheres race game half way through the project.

Well, let me be sckeptic but if after that change your desing did not need to change to much (long hours saturdays and sundays) then you should comunicate to gamasutra your desing and must be adopted for most game developers cause it is a super flexible desing and could be used for every kind of game tipe .
I don't saying your lying at all, I am just saying that either the concept betewen both games weren't so differents or you spend a long run adapting the desing to to new concepts (cause it was realy different).

I always assuming that we are not saying "desing" like just a high level architure withoug almost any functionality (cause of course in that case it wouldn't change at all ).

Halifax: Yes, of course you are right, you take my examples too much specific, I named gear of wars just becasue was the first that came to my mind. Choose another one that can fix correctly my example.

But again, whoever it be, change from a gear war style to a metal gear style would need a reeingeniring of the desing.(I suppons we were in half development). If not, there would be already a "standard desing" for all kind of game. Which not exists.

[I am not talking of "standard desing" as patterns desings or good desing principles, these are general, I am talking in the meaning of the "bussinnes desing" , the one that describes how you acomplish with functional and not functional requiriments), after you have that, the only thing you must do is coding]