How do you structure your code?

[iniside]

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

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.

[TheJamsh]

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.

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?

[WCode]

Realy cool to see so many engaging in this discusion.
And i think we can safly say there are no one way of doing things.

Are there things you never do when programming in UE 4?

[iniside]

Realy cool to see so many engaging in this discusion.
And i think we can safly say there are no one way of doing things.

Are there things you never do when programming in UE 4?

Hah. Good question. Because I have yet to encounter things that are off limits.

Here interesting article:
http://www.randygaul.net/2014/06/10/...ntity-systems/

[SaxonRah]

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.

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

[TheJamsh]

I get you, but then Car Parts have categories of their own, like 'Engines', 'Wheels'. If you know every engine you ever want to make has an output 'Rotation', why not just inherit from that whenever you want to make a new type of Engine. At least that's how I look at it. In this case, interfaces between classes would just seem really unclean to me, the analogy for me is it's like bodging a cruise-liner engine into an aeroplane. We want 'Rotation' to be 'Thrust' now for example. Doesn't make sense to me.

In my case, I know that all the Vehicles in my game need to share a lot of the same functionality. The various sub-classes of vehicles might hover or fly or drive... but each sub-class of vehicle can still set that independently, while still allowing for variables like "Occupant" or "Array_Occupants" etc.

IDK, the inheritance/sub-class system just makes the most sense to me, at least in cases where I've needed to program in code, rather than programming loads of discreet classes that might do the same functionality in a lot of cases, but involve you having to go through an interface to actually use them.

[TheAgent]

I tend to make a baseclass for most things, in my game I have an Item class, where in blueprints I can make different versions of that Item but it generally has the same functionality (eg: pick up / destroy). I did the same for the base pawn class, which has all of the main functionality then I just create a blueprint of a different character. I don't know if this is an inheritance method or composite, since I came straight from UnrealScript. However, it makes the most sense to me.

[iniside]

I get you, but then Car Parts have categories of their own, like 'Engines', 'Wheels'. If you know every engine you ever want to make has an output 'Rotation', why not just inherit from that whenever you want to make a new type of Engine. At least that's how I look at it. In this case, interfaces between classes would just seem really unclean to me, the analogy for me is it's like bodging a cruise-liner engine into an aeroplane. We want 'Rotation' to be 'Thrust' now for example. Doesn't make sense to me.

In my case, I know that all the Vehicles in my game need to share a lot of the same functionality. The various sub-classes of vehicles might hover or fly or drive... but each sub-class of vehicle can still set that independently, while still allowing for variables like "Occupant" or "Array_Occupants" etc.

IDK, the inheritance/sub-class system just makes the most sense to me, at least in cases where I've needed to program in code, rather than programming loads of discreet classes that might do the same functionality in a lot of cases, but involve you having to go through an interface to actually use them.

http://www.gamedev.net/page/resource...-systems-r3013

In nutshell. The easiest way to approach component based design is:
1. Create aggregate class, which will aggregate various more or less related componenets.
2. Create base component class, which might implement core functionality needed by all componenets.
3. Create specialized componenet classes.

In case of Car, you would have class Car. You don't care what exactly car it is, or how many wheels it have or how many engines.
Engine is component.
Wheel is componenet.

Subclasses of these componenet may or may not implement additonal functionality. In most cases they will just differ by default properties values.

Implementing each car as separate self containing entity doesn't make any sense, since there are many discreete componenet, which are used to assembly single car.

There is place for everything.
But IMO it's best to implement not really related functionality in small componenets, and the use inheritance if you need to add new functionality to these componenets, which might be specific to them or when you need different default properties.

In unreal this system would be even more awesome if we could create blueprint componenets, and swap default subobjects (componenets) in actor at runtime.

[Alessiot89]

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.

Data Oriented Design is not only about performance, it's about focusing on the problem (data) and not about the tool you are going to use (code), it's a different and reverse approach to Object Oriented Design.
DOD does not preclude object oriented programming or meta programming or structured programming or whatever and it doesn't preclude abstraction. You can apply it even on managed and interpreted programming languages, not only to native like C/C++/Objective-C. It's a different methodology of think the problem and solving it. In my experience a data oriented designed code is simpler to read, simpler to write, simpler to maintain and simpler to debug (and of course it is simpler to improve its performance).
Yes, if you learned high-level programming as a synonym of object oriented design only it could be difficult at first to change your design (idea) of programming, but you should give it a try, and not only on critical performance code.
Unfortunately a lot of people do not learn how hardware works, what semantic is, how compilers works and they see OOD as the only way to code with abstraction; or they code in a OOD way since they think they have not to deal with pointers, but in reality they are adding pointers everywhere and they only throw away pointers' arithmetic (which doesn't cover nullpointerexception XD).
How I deal with pointers in DOD code? I usually use them only in the lowest level of abstraction and a lot less I did when I coded in a OOD way.
Bad HS teachers and very bad Uni professors everywhere.

[envenger]

I mostly am using deep inheritance structures for my classes. Mostly cause one of the first professional codes which I studied was the UT3 present in UDK. Sometimes I have wanted to use ActorComponents but have not used it until now.

It will be really helpful if some one could make a guide on the best way to use ue4 actor components. Also I wanted to know how does a component based system and replication work with each other.