Will my future programmer be furious?

Hi guys,

I have a question.

I am building a 2d sidescroller game. Right now I am hacking together blueprints to get the desired results… with the intention
of “finishing” the game, then handing it over to a programmer and having him fix everything and make it all better.

Is this how its done? Or am I going down a dangerous road.

As long as it’s readable and documented, it shouldn’t be too hard for a programmer to clean up the mess. A lot of pseudo code and documentation would go a long way. But a huge network of stuff that’s jumbled together would be an awful mess, and a programmers worst nightmare. Be clear with what you are trying to do, and how you are doing it, and the math involved.

I like to think of the BP as “prototyping fase” once a programmer is intended to migrate it all to C++.
So it shouldn’t be a issue. Tho, I don’t think the situation would be great if the BP’s are all messy and no sense can be made of it.
(Which is the problem I had with my programmer xD)

Blueprints do have their purpose as well. I suggest you make sure the programmer knows which variables and processes you want to keep exposed in blueprints. If you hard-code too much then you’ll be reliant on a programmer to make any balancing tweaks you want to make.

I would actually argue that the more you move into blueprints the better, as it means you can quickly and easily tweak things such as jump height, player health, rate of fire and so on. C++ should cover all the “behind the scenes” stuff that you would never need to modify, like the jumping logic, networking (if you’re doing multiplayer), damage routines etc.

I guess the rule of thumb is “if I think I am likely to modify it for any reason, keep it in a blueprint, if not then put it in C++”.

Thanks guys you put me at ease. I am not doing anything complicated, plus I have a tendency to over comment on my blueprints for my own sake.

When you have to read another person’s code, there’s no such thing as over-commenting. :slight_smile: