One thing the quake engine had was a group of user defined variables that were part of the base class and were available for use by mods. These variables were not used by the engine itself, so the mod maker could define their purpose as desired. That was a really handy thing to have and I think the AActor class could use a similar implementation. At the very least, I’d like to see a replicated field (int32 or whatever) for storing a team assignment to all actors. Being able to assign a team thru a base class would make life a lot easier for team-based game development. Currently, it’s rather tricky to take team assignment into account for things like TakeDamage() because you need to parse the actor to see if it’s one that has a team assignment or not.
I read twice and still didn’t get for what exactly you need new variable.
Why don’t you derive from the AActor class and implement your variables there and do your implementation of the teams there?
Not all games require the concept of teams, and I for one am against adding unneccesary replication bulk to the actor class because then all games will have it. It already has a lot.
Create an Actor Component for team assignments, and replicate the variable through that - or use an interface (both of which are designed specifically for this purpose).
Just think a bit further, if AActor gets more variables for team Management:
your map and every static Mesh will have a team then, because everything extends AActor at some point.
Actors are indeed extremely bloaty classes already, if anything they need less.
First, only replicated variables that are changing get replication. So that’s not an issue. Second, since AActor is the base class and the root of everything in your map. That makes defining team interactions with objects, bots, and other players much easier. Currently, you need to assign a Team variable to all your interactive game objects. That means some of the objects have a Team field while others don’t. So, if for example, you get an OnHit event that you want to react to one team but not another, you have to iterate thru the list of Actor types to see if it’s one of the objects that has a team field or not. Not very efficient.
AActor is the BASE class of pretty much everything. As TheJamsh said, AActor should be reduced, not bloated.
If you need a special Actor for everything, derive from AActor and use this as your base class for everything.
It still has to be sent once for every actor, right?
If your game requires specific things like a team for every object, you could just grab the engine source and add it yourself, without causing more overhead for games that don’t need it.
Yes and no. The initial state will be sent as part of the initial packet, and replicated variables are also constantly checked by the replication system to see if they have changed - which has CPU cost of it’s own. Suddenly every actor you want to replicate over the has an extra int32 attached to it. For a game like mine (an FPS / RTS hybrid with a LOT of projectiles to replicate), that’s a big deal. Even now lot’s of junk data is needlessly sent over a network for many objects.
Not all games require the premise of ‘teams’. I for one want to move the engine away from it’s FPS-orientated past because in many cases it’s actually restrictive. Some classes still have leftover code from the UT days which adds a lot of bulk, and is unneccesary.
The correct approach is to use an Actor Component or an Interface for your team-based objects, that way you require no iteration at all. Actor Components are designed exactly for this purpose, to extend the actors’ functionality. In your case, you check to see if the actor has the component / interface, and if it does do ‘X’.
What is the problem with adding one rep variable few interfaces and few functions to manage the stuff? also, as other said, components.
Why should the AActor have a team ID when they can’t even be possessed by any controllers? Pawns are the base class of entities that can be possessed, and they already store a team ID if I recall correctly. What you’re asking is complete nonsense.
Because there are things in a map that need team assignments that are not pawns. (Think doors, trigger hurts, alarms, etc.) Think outside the box.
Its project specific, i would recommend you to think out your own box and develop some basic programming skills, such as making systems out the tools available.
Actor component is the answer for you, still have NO IDEA what kind of “outside of ONE replicated variable + ONE interface function” you requesting and why its need to be in AActor for everyone.
I had been doing that and it worked great. It was so convenient to not have to add components to assign an object to a team. But there are issues with building your own engine. The biggest is that there’s been problems with plugins not wanting to work. I’ve also discovered that an engine built from the Git source behaves differently when creating or recompiling a project than the pre-built binaries.
Have you tried making your own pre-built binaries? Supposedly this is how the launcher ones are built.
https://docs.unrealengine.com/latest/INT/Programming/Development/InstalledBuildReference/
What about actor tags? Component tags?