Game Development and programming Direction

My question here relates to something ill refer to as “programming vision”.

I am beginning to see programming in general in a class type structure.

obviouslly you have ( using UE% as an example )

Main () {

Stuff() {
Sub stuff;
}

going on in Cpp in background behind the scenes in Ue5, but HOw much efficiency is actually lost in the implementation of the machine code - CPP - UE5 interface ?

eg.

what Is the actual difference in terms of performance with a bunch of

If (stuff happens) {
do stuff
} ;

else(stuff){
Do this stuff
}:

vs a UE5 Branch node ?

at what point Do i actually need to start considering these kind of things ?

obviously at this point my game creations are not really going to know the difference, but Im interested in learning Good code practices to accompany my use of blueprints… I much prefer learning with blueprints as a reference material in real time To better learn cpp, but TBH id much rather work in Blueprint.

A final Question. Im sure you hav all been here or perhaps still are.

imagine I have a unique idea, Something ive not seen done before but is Way out of my realm to be able to program and create at this point… how long did it,or does it take on average to Realize a game youve envisioned ? obviously complexity being a thing, lets for arguments sake say I had the idea for grand theft auto before it was a thing.

what would a realistic timeframe be to achieve the ability to make this a reality, Im asking for the timeframe to fully be able to build any part of it by myself, but obviously not thinking a solo dev could do this… i just want a target for where id be when i finally understand how all the gears actually move.

:slight_smile:

thanks, I feeel at times like this journey, though exciting is so vast and its like trying to memorize all the charactors of a phone book lolz … :slight_smile:

The difference between Blueprint (“branch node”) and C++ (if statement) can be quite drastic – for any one node, a 20x cost of entering the node can be the case.

The main reason games don’t run slow as molasses, is that the insides of the node (“set bone transform” or “add control rotation” or whatever) generally does a lot more than the arcs between the nodes. So, while the arc between the nodes costs 20x more, the overall cost of those arcs might be only 1% of the overall cost of the game, so you’re comparing “99%” versus “99.95%” (in the hypothetical 20x faster C++ case)

This is why benchmarking and profiling is so important. You should figure out where the time/overhead is actually going, and work on making that better. Guessing, or rules of thumb, doesn’t get you very far. Experience can help, too, but mainly in figuring out what bits require more design (anything dealing with hundreds or more of items) versus can probably just be mashed in the simplest way possible until proven otherwise (anything that you only do once per frame or whatever.)

2 Likes

thanks for the reply, Im pretty new to programming in general though i have some limited Cpp experience as well as some c basic from long long ago its a lot to absorb.