Marketplace products - Thoughts on BP nativization

Development Programming & Scripting Blueprint
, , ,
1

Hello all,

I have been developing my product using full BP because I want users from all levels to have full access and flexibility in improving the logic if they want to.

However, I’ve come to a point where some of the core scripts would look & perform much better in code, and that they will probably never change in future updates.

I am aware of the technical pros & cons of BP vs C++, but I am curious of how the users would perceive changes like this, so here are my concerns:

  • As a user, when you purchase an all-BP product from the marketplace, do you really care about the accessibility to all the logic within? Would you really care about understanding how things work? or, as long as it works fine and performs well, thumbs-up?

  • As a product developer, what are your experiences in nativizing part of your product in a later update? Did your users like it? did they push back? Any red flags I’m not seeing, from a business standpoint?

Thanks in advance for reading and joining the discussion!

2

As a user, I’d say stick to BP, if you can.

The problem with C, and presumably, it then being a plugin, is twofold

  1. BP users can’t make updates / fixes

  2. If the vendor walks away, you have to spend time stripping the plugin out of your projects.

  3. Ok, threefold. Despite what anyone says, UE will not package plugins without the use of Visual Studio. Which is a massive pain in the tushie, if you’re a BP only maker.

2 Likes
3

I see it slightly differently - the speed increases you can get from c++ are so big that it can well be worth converting to c++ at times.

It’s a matter of implementing it in a way that keeps it portable. If you can make your plugin Editor Only, it’s really not a problem at all, nothing is then reliant on the plugin.

If it is a run-time plugin, make sure there are ways to convert what is using it to working without it easily - make the plugin c++ code easy to port if people need it.

But I think the most important thing is, if you’re going to release a runtime plugin - make sure that you are going to be able to support it for at least the next 5 years - even if just in your spare time.

I see people take over the porting job of other peoples runtime plugins too - if there is a demand for your plugin, people will put the effort into keeping it up to date if you don’t (but you should).

1 Like
4

Runtime plugins are the problem. When you try and package, you get an error about target.cs. You need to get VS, just to write a tiny text file… :joy:

5

Yeah I guess I’ve always got VS installed, it’s free and not too big - a handy thing to have close at hand for any game dev I think.

But you’re right - the balance is between ease of building your project and how much of a speed increase the c++ provides.

1 Like
6

Thanks for the quick replies!

Awesome information & perspective already from both sides. I’m going to read more about best practices in writing a plug-in for others. But to @ClockworkOcean 's point, since my main target audience is full BP users (and some likely don’t have any experience with VS, they just want something that works), I should probably keep it in full-BP for a while.

Well, until performance actually becomes a concern at least. Maybe all I need is better blueprinting so my programmer part of brain would stop screaming for nativizing. :sweat_smile:

1 Like