No announcement yet.

How do you decide what to implement in C++ versus Blueprint?

  • Filter
  • Time
  • Show
Clear All
new posts

    How do you decide what to implement in C++ versus Blueprint?

    I understand the basics of oop, I understand variable types and (probably) all the basics of scripting. I've messed around in UnrealScript back in the day for basic things even.
    Now that the introduction is over, I want to tackle something that is probably WAY beyond my abilities and that is to create a foot-based version of Onslaught for UT4.
    I've purchased Tom Looman's and Ben Tristem's C++ courses on Udemy and have started following along (not sure if I need them but it was a package deal for 20 bucks and couldn't pass it up) but I don't feel like I'm learning anything to give me independent thought/creativity. It's just monkey see, monkey do and I can't figure out how I am going to apply what I learn there to this task.
    How do I decide where to start? How do I decide what to do in C++ (if anything at all) versus BP?
    How should I organize the states for actors like a power node that need to be active/inactive/owned by red or blue/available/unavailable/vulnerable/invulnerable/when to spawn weapon lockers etc...?
    I think I should start with just a power core for each team and then once I get damage and game end conditions move on to creating power nodes?
    I'll probably export the scripts from ut2004 and look through those and see how much of that I can translate to BP first?
    Last edited by King Mango; 03-02-2019, 01:51 PM.

    Primarily this is a philosophical question and largely depends on your design needs. You can of course expose (virtually) everything to blueprint, but this can be abused.

    To point at an example, the UT2004 Onslaught power node had something like 2000 health, took 10 seconds to build (if not damaged), etc. The characteristics of a node were static between maps. However, there were a few maps, notably ONS-Maelstrom, which had customized power nodes with less health. The latter worked in the one-off context of ONS-Maelstrom, but in general the principle of having nodes with less health might prove to be confusing for players. If a normal node has 2000 health, and therefore takes 8 direct Goliath shots to take down, then you can know how much firepower you will need to focus on the node to take it down, as well as how long it will take for it to build if someone starts constructing it. If some nodes on a map have 2000 health, some nodes have 1000, and other still have 50,000, the rules of the game become much more obscure and difficult to understand from the player perspective.

    That is a fairly contrived example, but exposing properties and functionality to designers has implications as well. Every actor has hundreds or thousands of properties, events, functions, and so on. If every setting were exposed to blueprint, it's entirely possible to accidentally create a blueprint with some kind of illogical / nondefined behavior. This drastically increases the difficulty of understanding the behavior of a thing, if all of its properties may be adjusted at design or runtime, and reduces the efficiency of designers who now may have to understand the underlying code to reason properly about the interaction of various configurable settings. The importance of that will depend on the complexity of the feature, size of the team you have to communicate with, and so on. If you are working on a team with an arbitrarily large team of designers, you can make life much easier on yourself by only exposing the minimal amount you plan to support. For example, in some teams I have worked on, you might be supporting one technical designer who has a good knowledge of how to program and is capable of responsibly using all properties. On another team you might have a team of designers ranging from technical & systems designers to level & narrative designers who all might be interacting with a thing and thus don't need access to most of these properties.

    In any case, that is a bit rambling but I help clarifies the question. TL;DR exposing everything might lead to porous design that ends up being confusing for players and content developers.
    Last edited by Wail; 03-04-2019, 11:03 PM.
    Join Project: Open Tournament: | Project Trello | Discord | YouTube

    Subscribe to /r/UnrealSeries - The subreddit for free & uncensored discussion of Unreal series games!

    Unreal Prime Weapons: Impact Hammer | Enforcer | BioRifle | Shock Rifle | Link Gun | Ripper | Minigun | Flak Cannon | Rocket Launcher | Sniper Rifle | Grenade Launcher | Dispersion Pistol