You can run it, Press space bar to move the bird, and press enter to generate the pipes.
I wrote this code to generate the pipes (Tuberia is a pipe in spanish):
Tuberia := TuberiaFactory.ComponentLoad(FreeAtStop) as TCastleTransform;
Tuberias.Add(Tuberia);
Tuberia.Translation :=Vector3(0,0,0);
Now I want to move the pipes up down. So I thought in make a a class inherit form TCastleTransform, and in this class put a timer and a speed to move up/down the pipe.
I create the class that inherited from TCastleTransform, but the constructor has other parameters, so I don’t know to continue.
Where can I find a demo or code, how to do this.
Thanks
/BlueIcaro
The TCastleTransform is a descendant from the standard TComponent, so it has an additional “AOwner: TComponent” parameter. In your descendant classes, you need to override it:
type
TMyDescendant = class(TCastleTransform)
public
MyNewField: Integer;
constructor Create(AOwner: TComponent); override;
end;
constructor TMyDescendant.Create(AOwner: TComponent);
begin
inherited;
MyNewField := 123;
MyInitialization;
end;
As a general advise, note that extending functionality by making TCastleTransform descendants is often not the best way.
While you can of course do this, but sometimes it results in inheritance that prevents you from expressing what you need.
Using “composition” is often a better choice, an in particular developing new “behaviors” ( Behaviors | Manual | Castle Game Engine ) and adding them as children to TCastleTransform is often a better choice. This is great to “attach a logic”, like “this pipe is moving”.
Rewrite the constructor has many unwanted consequences.
I going to work with Behaviors as you say is better choice. I think the code is more clean.
I going study the links that you mentioned. I hope back with my flappyBird game finished.
/BlueIcaro
It separate setting logic from creation logic. A dumb but working way
Maybe this way not so elegant, but I can be sure constructor works as he must. Not busy about things, that somebody already made fine
But I don’t know, is it good for use with the Factory.
I think what you show - is a completely normal approach , so I would not call it “dumb”.
As my wife says: “if something is dumb but works, then it’s not dumb”
When the component is constructed by deserialization (from .castle-user-interface or such files) or using TCastleComponentFactory then naturally only the standard constructor (Create(SomeOwner)) is called, and you have to make sure to call AfterConstruct (because it needs some parameters that cannot be known at construction) on all instances yourself. Which is OK.
( You can also add more published properties and design your component visually, registering it in the editor, Custom Components | Manual | Castle Game Engine . But this is not supposed to be a “solution for everything” , i.e. it’s not strictly an “alternative to constructor with parameters”. If you really need to call some additional initialization, with some custom parameters, then a method like AfterConstruct makes total sense IMHO. )
