How do you structure your code?

[WCode]

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.

WCode.

[ULLS]

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.

[ArdentDrako]

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

[SaxonRah]

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.

This is mostly true for me too.

Do you take advantage of templates ULLS?

[WCode]

Thanks for getting the conversation started guys.
I definitely agree with `has a`, `is a`approach.

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.

[creasso]

Great! RPG discussion!

My framework is rough yet, but I did this way:

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. Rama 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)

On LocalState:
PlayerSkills[0] = 13;

This player now knows how to say Whatever.

Was a pain to implement, but works. LOL

[SaxonRah]

Thanks for getting the conversation started guys.
I definitely agree with `has a`, `is a`approach.

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.

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.

[TheJamsh]

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.

[creasso]

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...".

if(does this goes on level)
Actor
else
{
if(does it have functions on it)
Object
else
Struct
}

If someone could clarify, I'll thanks a lot. LOL

[iniside]

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. Here 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).

[zoombapup]

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.

[ULLS]

This is mostly true for me too.

Do you take advantage of templates ULLS?

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.

[TheJamsh]

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.

[zoombapup]

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.

[Alessiot89]

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. http://channel9.msdn.com/Events/CPP/...sign-and-C-P-P