Best practices in structuring a game

Hi UE4 community.
I am a beginner dev working full time on an indie game (VR flight game). I am amazed how far I have gotten with online learning resources and have solved most issues that I have faced. ANd writing here under the BP section as I am so far only using blueprints.

About learning material I have gone through - most online resources are great for solving a detail issue or having a heavily simplified path from zero to a product. Both are great but I am having bit hard time finding more “meta” learning material (I don’t mind paying btw) that would cover more abstract topics. I mean more broad strategies of where to store what values, which element is responsible for which functions, smart ways to construct enemies/NPCs etc.

For example now I have PlayerPawn, which contains the VR hands but mostly just relays (via interface) inputs to other systems. A separate Player-Aircraft the acts based on the inputs. No idea if that is smart or not. When checking for enemies in range should my ship seek for the enemies and activate them or should the enemies look for my ship?
Is it bad to split my Aircraftcraft to several Blueprints/entities (targeting computer, physics system, PA/radio/dialogue etc.) or have all of the functions in one?

I know all this is very context/need/case dependent but I am looking for info to teach me to do those choices well.

Cherers,

Heikki

An here is my latest work in progress video

I really liked the demo and normally I DGAF about VR, as its such a nest-of-vipers design-wise especially as regards movement :p…

Feedback:

The landscape and props look bland and take away from the overall effect imo. There are just so many freebies floating about though, that there has to be a better mars landscape and props you can grab quickly and plug into what’s there, and it will look 10 times better instantly. What about the Epic MissionAR demo, anything there???

As regards your questions about best practice… These aren’t always easy to answer, as sometimes ‘structure fights progress’ and you need to accept that you will have to refactor / rework a lot of things later anyway (even if its more painful then). So I say just keep rapidly developing for now and keep things simple (sacrificing structure where needed). Or not, you can ofc ignore the ‘it it ain’t broke don’t fix it’ mantra and start compartmentalizing the flying BP into smaller BP’s and components and add more functions / macros maybe. But you may start to curse yourself soon after. :smiley:

So just keep adding features for now I say. Personally I would work on the cockpit displays next, since those will already be compartmentalized just by utilizing the UE framework. Also, I think I saw something similar once from @vr_marco. I don’t know how far the project got… But maybe there’s some tips there if you can find the thread…

Good luck!

thanks for comments. about the demo: it is mostly placeholder stuff now. I have pretty strong 3D/visual background (my old work is at machinista.com) so especially the props is my least worry - kinda know what needs to be done. Landscape is also just a debugging one - one tiling color map and one roughness map - not a visual benchmark. Landscape will be a learning process of its own so not worrying about it yet.

I figured that structure is heavily case by case dependent and I know learning the hard way is powerful - just not sometimes not the most efficient time wise.