1 registered members (AndrewAMD),
678
guests, and 6
spiders. |
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: unreal engine 4
[Re: AlbertoT]
#440790
05/02/14 10:25
05/02/14 10:25
|
Joined: Nov 2007
Posts: 2,568 Germany, BW, Stuttgart
MasterQ32
Expert
|
Expert
Joined: Nov 2007
Posts: 2,568
Germany, BW, Stuttgart
|
Maybe but Transform is an obligatory component and thus can't be seen as a component of an object but just a fixed part of it. In Gamestudio there are similar concepts of "Components", but are called "action" here. Only thing is that those actions aren't really controllable compared to modules / components. A system with a single class per actor also isn't really viable because it is too limiting. You have to write a lot of code in order to share code between two classes (e.g. an actor. you would need the same code for input in a character, a vehicle, but for NPCs you need a different "input". This is much more complicated than a component based system.)
Imho the best way is to use a mixture of both (In fact, Unity supports such behaviour: Just create a base module for all your classes you want to have for your game and use this as a base class, not MonoBehaviour)
|
|
|
Re: unreal engine 4
[Re: MasterQ32]
#440800
05/02/14 14:14
05/02/14 14:14
|
Joined: Oct 2006
Posts: 1,245
AlbertoT
Serious User
|
Serious User
Joined: Oct 2006
Posts: 1,245
|
Maybe Transform is an obligatory component base class It is an obligatory component only for a "component based engine " If you define a class Actor which contains a variable such as " position " or a method such as " Move " then you dont need to have a class Transform You simply write, in the Loop() function myBot.position; myBot.Move(); instead of attaching a script to myBot : transform.position; rigidbody.Move(); You are right 3dgs is basically a component based engines but in the past there were engines with a different archictecture ,ex TrueVision Having said that , I dont mean that components are bad, I mean that in my opinion they lead to a ugly code I did hope that UE4 resumed the old fashion programming style
|
|
|
Re: unreal engine 4
[Re: AlbertoT]
#440802
05/02/14 14:40
05/02/14 14:40
|
Joined: May 2005
Posts: 2,713 Lübeck
Slin
Expert
|
Expert
Joined: May 2005
Posts: 2,713
Lübeck
|
I never even looked at UE4, but from what I read at different places, it seems to be based on classes and inheritance. So you got a base class with some properties, another classes inheriting from it adding some more properties and so on. But they could still provide a way to also attach components like a physics body or something. Also it could make sense to have a special transform object holding the transformations, so you would still have something like:
void MyClass::Update(float delta)
{
transform.position.x += delta;
}
|
|
|
Re: unreal engine 4
[Re: AlbertoT]
#440803
05/02/14 14:51
05/02/14 14:51
|
Joined: Nov 2008
Posts: 946
the_clown
User
|
User
Joined: Nov 2008
Posts: 946
|
If you define a class Actor which contains a variable such as " position " or a method such as " Move " then you dont need to have a class Transform
Having said that , I dont mean that components are bad, I mean that in my opinion they lead to a ugly code
I did hope that UE4 resumed the old fashion programming style
As stated before, having actor classes with variables such as you list is fine, but a component oriented design does in fact lead to better code in the long run. Imagine you have another class that needs a position, a move method or similiar, but isn't in any way linked to your actor class so deriving is not an option - that'd lead to a lot of duplicated code. Say for example you want skeletal animations - believe me, you'll love to have a reusable transform class then. You're right in that it's somewhat strange at first, and the component system was one of the reasons why I didn't like using Unity when I just came from Gamestudio (which imho doesn't have any characteristic of component based design, or any solid design whatsoever), but once you get used to it it does make work easier. A nice balance is good, though - I don't like the approach of stuffing EVERYTHING into components, either, there are cases where inheritance is a better solution. However, with UE4, if all you want to do is create gameplay logic, you won't have to deal with much C++ anyways.
|
|
|
Re: unreal engine 4
[Re: the_clown]
#440810
05/02/14 18:12
05/02/14 18:12
|
Joined: Oct 2006
Posts: 1,245
AlbertoT
Serious User
|
Serious User
Joined: Oct 2006
Posts: 1,245
|
Imagine you have another class that needs a position, a move method or similiar, but isn't in any way linked to your actor class so deriving is not an option - that'd lead to a lot of duplicated code.
actually this is the main advantage of component based game engines " over traditional game engines You attach to an entity just the methods / variables which are strictly needed The weak point of "components" is the interaction between entities As I said in my first post, you would accept that it is more elegant to write : Actor john = new Actor() Actor Bill = new Actor() distance = John.position - Bill.position Rather than in John's script GameObject Bill = GameObject.Find("Bill") distance = transform.position - Bill.transform.position 3DGS in principle use components Have you never been fighting with those bloody void pointers ? This is typic of components
|
|
|
Re: unreal engine 4
[Re: AlbertoT]
#440812
05/02/14 18:34
05/02/14 18:34
|
Joined: Nov 2007
Posts: 2,568 Germany, BW, Stuttgart
MasterQ32
Expert
|
Expert
Joined: Nov 2007
Posts: 2,568
Germany, BW, Stuttgart
|
It doesn't have to be. This is not a problem of component based style but of the strict programming languages: E.g. you could write similar code with lua:
local go = GameObject:new()
go:attach(Transform:new())
go:attach(Character:new())
go:attach(Animation:new())
-- same as go.transform.position
print(go.position)
-- same as go.animation:playAnimation("walk")
go:playAnimation("walk")
So you see this is just a matter of language
|
|
|
Re: unreal engine 4
[Re: AlbertoT]
#440819
05/03/14 09:11
05/03/14 09:11
|
Joined: Nov 2008
Posts: 946
the_clown
User
|
User
Joined: Nov 2008
Posts: 946
|
[quote] 3DGS in principle use components Have you never been fighting with those bloody void pointers ? This is typic of components Void pointers have nothing to do with components, they're just a (rather handy) part of C. You can use them to set up a component system in lite-c I guess (as there are no templates in C), but they don't indicate any component based design in the engine at all. You do have a point about the interaction, that can seem kind of unintiutive, and finding the desired object may even seem like undesired overhead, but I do actually prefer that over having all my objects in a global scope.
Last edited by the_clown; 05/03/14 09:14.
|
|
|
Re: unreal engine 4
[Re: the_clown]
#440820
05/03/14 11:24
05/03/14 11:24
|
Joined: Oct 2006
Posts: 1,245
AlbertoT
Serious User
|
Serious User
Joined: Oct 2006
Posts: 1,245
|
Yes they are related items 3DGS is , in principle, a component based engine
"Actions" are components which you attach to the entities in the scene my is a pointer to the associated entity you is a pointer to the entity you want to interact with
if you write :
john = GameObject.Find("John");
john is a pointer to the entity john , same as "you" in 3dgs
Same as in all component based engine the interaction among entities is a weak point Scripts must continuously Exchange information
This makes Unity and even worse 3DGS code so ugly, in my opinion
Leadwerk engine seems to have found the right compromise It is a mix between traditional and components engines
I wonder whether UE4 offer a similar or even better solution
Last edited by AlbertoT; 05/03/14 11:32.
|
|
|
|