Hi, I’ve gotten a wee way into my game and I’ve come across a few problems, mostly regarding trying to keep everything as adaptable and future proof as possible (as in, the future of developing this game), keeping redundancy of code down etc. I’m prepared to restart from scratch if necessary and thought I’d ask for general advice on how people make this happen.
So this game is going to have player controlled rockets, but for all intents and purposes “vehicles” will do. They (amongst a few other things) will have the same variables across each of them, damage, hull strength, protection from fire etc; and also have to be controlled in a similar way, even if the way that particular vehicle/rocket applies it might change (eg, UP might be main thrust, but one ship might use a thruster to do so, but not all will etc)
I want to have lots of these ships, so to me, it makes sense to have an interface or parent blueprint so hold all the bits that are the same amongst them, and then each individual vehicle will add it’s own meshes and the parts that are specific to that vehicle. It DOES NOT make sense to me from a good creation point of view to just copy and paste the fundamental variables that all the ships would have, especially if later on I decide I need another variable.
I am really open to all kinds of advice of the best way to do this. I have already tried a few ideas so I know what doesn’t work (at least I think I do).
I’d also like to, in general, talk about making your game “the right way” from the start, because it’s very easy to have a messy filesystem structure and no naming scheme but my game is still small and already I feel the pressure to redo it so I can do ALL those things correctly. I feel like a lot of these things are things that should be talked about from the start but most of the tutorials are about getting you get stuff done and it’s good to get your confidence and excitement up but not so good from a longer term point of view
What you are describing is known as “object oriented programming” or “object oriented design”. This is absolutely a great way to work. Part of object oriented design is the concept of inheritance. There is a “parent” data type and “child” types that inherit what the parent had, but add different functionality to it.
For example you could consider this hierarchy:
Item->Weapon->One handed Weapon -> Ax -> The Great Battle Ax of the Dark Realm
Each subsequent child inherits elements of its parent. So in this case if I wanted to make a new Ax, for example “The Not-So-Great Battle Ax of the Dark Realm”, I would just make a new “Ax” data type and define what makes this particular Ax unique. The game will already know that it is an Ax, which is a one handed weapon, which is a type of weapon, and is an item.
UE4 is designed in this way, and its the prevailing way most programming languages these days are designed to work.
Now just to be clear, there is a benefit to the “other way” too. Some people call it spaghetti code, but a more formal term would be “Procedural Programming”. This is wear you program things to make them work. The benefit comes when prototyping or working on a smaller project like a game jam. You could spend a lot of time spinning your wheels coming up with all of these datatypes to make things efficient, but at the cost of a much greater setup time. The nice thing about the procedural or spaghetti approach is that you can get something running pronto.
So it really depends on the project and the scale, and I think there may be room for both approaches in a single project. Going off of what you’ve posted though, I think it’s time to start getting object oriented.
This isn’t specifically related to UE4, but it is a great primer on OOP/OOD.
Yeah you’re spot on. Once I realised what object orientated programming was I realised it was exactly how I wanted to do things.
I guess my current problem is perhaps more of a specific case? Anyway I made a parent blueprint for my pawn, this contained an arrow and a capsule, to help future designs. Then I made a child and added the mesh and the things that made it “that ship”. The problem though then became, that my physics based movement pushes the static mesh around, and NOT the pawn as a whole. This meant that trying to follow the pawn as a camera target doesn’t work, because it follows the pawn ROOT not the mesh itself. As far as I can tell the only solution to this problem is to get the static mesh as the ROOT. But I can’t, because I inherited the ROOT and that can’t be changed to the mesh. Even if I added NO components to the pawn-parent, the static-mesh is never ROOT and can never be. This would work if there was a way I could move the pawn ROOT to the same location as the mesh.
So I was cut short in, what seemed to be a great approach, because it couldn’t work for my system.
So what do other people use as a parent pawn? Or how do they do it?
Just want to make sure, but in the components is your mesh properly parented? To properly parent it you need to drag the child on top of the parent so they are indented as shown in this screenshot. If the components are on the same “indent level” they aren’t related which would explain why the camera isn’t coming along for the ride.
If that isn’t the issue then maybe try looking through the example content for whatever behaves the closest to what you’re looking for, and see if maybe you could figure out how to copy that, but make it work the way you want. I’m sure either the Third Person Template or one of the vehicle projects might provide some guidance.
Yep definitely parented correctly. It’s just that the thrusters I am using to push the pawn around, push the mesh around, and not the whole pawn. In the example you’ve given, it’s like they push the HeroTPP mesh around but don’t move the arrow.
Although I’ve never looked at the CharacterMover component before. I could move the pawn in a more traditional way of just adding a transform or whatever but I really want the movement to physics driven
Unfortunately almost all of the example content that I have seen is one-off blueprints of pawns, so I have not seen any examples of this. It’s like I said, they’re get for “getting going” but past that not great as examples.
I’ll look into that characterMover. I also thought about constantly updating the ROOT of the pawn to be at the same location as the mesh but I suspect the meshes location will be relative to the ROOT so it’ll move the mesh when I move the root too…
Interfaces would be OK but they don’t hold variables so I’d still have to add all of those. Perhaps if I added functions like get/set health or whatever I’d have to always add those variables anyway? Unless someone can spot a different way to do this I might just have to do it the long way and NOT inherit my pawn like I wanted because of the mesh-as-a-child thing.
I suggest reading some of the books from this list. I recommend Code Complete, The Pragmatic Programmer and The Gang of Four Design Patterns, if nothing else. The last one will help you understand why the UE4 developers did what they did. And while they’re not aimed at game development, youll still find them very helpful in learning to architect your code for the future.
