Hello I have been working with UE 4 for a while now.
And there is one question that keeps coming up for me.
When you work on a project, how do you structure your code?
What do i mean by this is?
e.g: Your Pawn/Character class will get new methods specific to your game.
And more general stuff like Health and Stamina or something else.
But revolving around your player like in a RPG.
You have Inventory, Equipment, UI and so on, all with there own use and methods.
Now I would want to divide this up maybe make a inventory component for my player.
Or the player inventory i maybe just leave in the Character class so it can stay laying around if the player dies and so on.
Weapon behavior i keep in the Weapon class just firing of the virtual method present for all weapons actors.
Am sure we do stuff differently, and i think alot of us will benefit form a discussion on this.
Food for your thoughts.
I guess it all depends on the project itself. I would typically use composition over inheritance if the desired behavior falls under the ‘has a’ category and I would use inheritance if it falls under the ‘is a’ category. The aim for me is always writing less code, reusable code whilst remaining readable and efficient. But ultimately it depends on how you are most comfortable structuring such things.
hm well for me so far i have always asked myself will the system im making be used by more then a single pawn, like if my inventory was used with different pawns i would make it its own system.
and i agree that a lot will benefit from this type of topic, i would love to hear more about this im still very new to c++ and would love to hear about this
Thanks for getting the conversation started guys.
I definitely agree with has a, is aapproach.
And re-usable code is definitely a must.
But in UE 4 terms at some point you have to decide.
Is this a UObject, Actor, Interface, SubclassOf.
Different systems have different needs and get structured there after in many cases.
That’s where things become a bit fuzzy for me atleast.
Always knowing what suites you best and creating the system the way Epic intended the API to be used.
Considering what I “guessed” from U4 structure, I did changes on the “PlayerState” to just holds what could be used on Multiplayer, as example, the other players doesn’t needs to know all the questlists, flags from each other, and about inventory, unless on trades (that I’ll design after) the players doesn’t needs to know all the contents on the “stashs” from each other. On the other hand, variables used to combat (e.g. DPS, Armor and suchs) alike character look (Mesh IDs to multipart character) and name goes there.
All remaining info (including copies from what goes inside PlayerState) are stored on a LocalStructure, that holds all things as an array of GameItems (the inventory), Skills, etc, etc… I’ve placed everything inside this guy because on save it to a file, I have a savegame. The playercontroller holds a local copy from this loaded from disc each time the character is loaded and deals with value changes while on gameplay, on finish, bye bye to disc til new game session. posted a savegame sys somewhere on wiki.
Each client has DATAASSETS with the lists of possible quests, skills, items, classes to consultation, most “cosmetic Strings and icons” goes there and are just used by the UI system, as example:
Dataasset:
Index[13]
Skillname: “Whatever”
Skilldesc: “Says whatever”
Icon: TEXTURE(Someimage)
I have no idea the way Epic intended the API to be used. I wish there was more general use case tutorials, not ‘how’ or ‘what’ to program in c++, but ‘why’ do I program it this way in ue4.
There is an intimidating amount of information to learn. I came from my custom c++ engine and my day job is programming in pure standard c++ 98. so most of the time when i am learning c++ in ue4 i honestly felt more comfortable hacking in my old code without specifically coding it in the ue4 structure. (i still do this from time to time when prototyping because its so natural for me to program this way) This was and is horrible because im so used to the standard lib and i need to keep it fresh for my job that even thinking about learning essentially an entirely new standard send shivers down my spine.
When i want to implement something i goto the docs and source, try and find then read how a similar system was programmed if there is one. if there is; try and re-implement the thing, not by copy paste but retyping it character by character. Then once it works, i plan for what i wanted and try and recreate my original idea. This honestly leads me to allot of AActor programming, because replication works so naturally with it (There is no UObject replication if im not mistaken). Also i tend to write all of my code that is reusable in a plugin and i try and separate pure game specific content in the actual project source.
I can expand on this a little more later, but for my game I wanted a variety of different actors to have Inventories, Health, Ammo etc, loads of different values.
To get around it I made a custom ActorComponent, which acts as more of an interface and big data storage for each object. I considered using interfaces but it proved to be way too complex, but this way I can just do my custom game stuff in my component and I’m golden. I even do view-changing through this component, though that’s proving hard to replicate at the moment.
It’s weird… Everytime I read about people using Actors to store data I felt as I’m doing something wrong or that this guy saw something I don’t.
Am I wrong on still use “old” engine definitions when designing classes? Never got a clear answer about this, it’s always the “depends…”.
I prefer composition over inheritance.
I always try to keep inheritance as flat as possible. For most of the time in game development there is really no good reason to have complex or deep inheritance structure.
I use interfaces over class inheritance.
In other words, I try to keep everything as component, and interfaces. Interfaces usually help to communicate between components, as well as separate modules of project.
For you particular question about RPG, you can check my project below.
Inventory in my case is ActorComponent. Items in inventory are UObjects. Everything is replicated. is small detour from my policy of keeping inheritance as flat as possible. The inventory items are can be quite deep (3-5 levels), but in that case it is justified, as those objects store information specific to their contained items.
Weapons, Spells, Abilities, usable items are all actors. For the ease of use with networking. Replicating UObjects is not terribly complicated, but unless you are aiming at MMO it’s not worth the effort of setting up complex system imo.
All of them are spawned as needed, per each actor (each actor have their own instance).
I’m a big fan of composition like the others. So I make components to do small parts of functionality (InventoryComponent for example) and composite them together using events etc. Sadly the components and actor stuff in UE4 isn’t quite up to what I’m used to (yet) but its moving in that direction a bit.
The reason for using the component method of building, is that you can concentrate on narrow functionality (InventoryComponent deals with the inventory data and saving/loading it from central DB for instance). You composite bigger behavior by combining smaller ones. So you might have InventoryComponents and InventoryUIComponents (renders an inventory components inventory) and the like.
To be honest C++ is a new thing for me, all my coding experience is in Java to which we have generics, I wasn’t aware of such a thing in C++ so thanks for pointing this out.
I love Inheritance personally, but then I’ve always liked things to be a modular and uniform as possible. In my cases it usually makes sense to use Inheritance, certainly for my recent games.
Don’t want to start a flame war or anything, but I’ve found that inheritance essentially kills modularity. Try using a component oriented architecture and see what a difference it makes to productivity/creativity. You’ll understand why so many of us have gone that way.
Write monolithic code first with small tests. Every time I found a repetition I consider to wrap it (into structures, classes, unions, functions, methods, templates, whatever) or not. I try to avoid useless inheritance and useless vertical polymorphism in favour or composition/aggregation and horizontal polymorphism respectively. Yes, data is more important than code, not the opposite. Data-Oriented Design and C++ | CppCon 2014 | Channel 9
This is true for high performance demanding applications.
Gameplay code is certainly not demanding. For most time in any case.
I consider resuability and useablity first. Performance is not problem as long as it is not problem.
DOD, lots of time makes things actually harder to reuse or use in any easy manner.
TBH, I’m not really experienced enough to know how to even go about it. Essentially you mean program everything completely separately of everything else right?
When planning a certain piece of game, it might seem kind of bizarre and like parts will need to be forced to work with each other, where as it could be working by the pure nature of components. When we program in an object oriented arch we are able to better visualize and express the existence of an object that we want to model from the real world. so for example a ‘lathe’ would be a class that defines various things of a ‘workpiece’, like length and radius along axis. The ‘workpiece’ however is analogous to an object since, it’s created based on the lathe. We use (not limited to)encapsulation, inheritance and polymorphism to make better use of oop. Problem is, code reuse for one, everyone thinks we reuse as much code as we possibly can and that really is just wishful thinking and untrue.
the basis for both component oriented arch and object oriented arch are one in the same; breakdown problems into its logical components. in component arch, our code is composed of reusable pieces. for example in visual studio you can override the default M$ intellisense component with say a VAssistX component. A good analogy for component oriented architecture is the car industry. car makers buy individual car parts, like engines and gearboxes nd such, from other various makers and then assemble ‘their’ cars from these components. In component oriented architecture, the pieces can be used as is. I personally love component oriented arch because the essence is striving for the most interoperability(in context; interoperability means the overall ability of the components working together) You can use object oriented concepts in conjunction with a component base to build flexible and powerful objects that can easily be reused by other developers.
Encapsulation hides the implementation of an object from a user of the object. users of an object can access only the object’s interface. if we use prebuilt objects we are only interested in the expected behavior that object supports. component arch formalizes that notion of expected behavior from an object and a client. each object declares what it is capable of by implementing interfaces, the only way to access a service of an object is through an interface that it supports. such expected behavior is the basis for component based interoperability.
An interface is a super simple related set of methods grouped under a single name. An interface is basically a strongly typed expected behavior between a component and its client; it is an articulation of an expected behavior and expected responsibilities, and it gives us a concrete entity to use for referring to the component. Two objects that implement the same interfaces are said to be polymorphs. not explicitly a strict requirement of this model but, you should try and factor interfaces in so that they can be reused in a variety of contexts.
Did i explain that at all correctly ? If not someone please correct
