Help with mulitple BP Store and efficiency.
I am making a simple idle killer mobile game which has about 20ishs store to buy and sell items.
I have started buy making each store a separate BP with all the coding for each sale and production in individual BPs & one main BP to control cost and production times.
After making the fourth BP, I realised how much redundant scripting there must be.
Is there are way with maybe Child BP or one main BP to do all the calculations and sales through castings or alike.
The game follows the following primes:.
Store 1 buys Product A and from that produces Product B, Store 2 buys Product B and from that produces Product C. Store 3 Buys Product A & B and from that produces product D etc etc, you get the drift.
It is done in 3rd person with thumbsticks for movement and touch to activate widgets to control the sales such as purchases / Sales.
I have thought about putting the stores in an array and pulling the data, but I am not sure if this would be the best method as there are many different stats that vary in each store, such as sales price fluctuating with sales trends.
Also the game will allow the player to buy NPCs to work as runners, ie, deliver Product A to Shop 3.
I am not looking for the final solution, just some guidance to the most efficient way to do this.
asked Jan 14 '19 at 08:06 AM in Blueprint Scripting
Have you looked into using a Blueprint Function Library or a Blueprint Macro Library? These will allow you to create custom blueprint function nodes that are accessible throughout your project.
As another option (which you hinted at), you could create a high-level "Store" blueprint that contains some core functions that you want to be able to re-use. Then you could derive your individual stores blueprints from that high-level, master blueprint (e.g. right-click your "Store" blueprint to create a child "Store1" blueprint, "Store2", "Store3", etc.).
In a similar vein, you could create a generic, master "Product" blueprint that contains any of the shared variables or functions that all products have. Then, derive individual product blueprints from that master one (e.g. right-click your "Product" blueprint to create child "ProductA", "ProductB", "ProductC", and "ProductD" blueprints).
Using this approach, if you make your core blueprint functions accept the generic "Store" or "Product" blueprint types, any subclass (child blueprint) of those types will be acceptable parameters without needing to do any casts. (This is because you don't need to cast 'up', only down.)
Hopefully that makes sense and helps you organize your project in a way you like.
answered Jan 14 '19 at 04:56 PM
Follow this question
Once you sign in you will be able to subscribe for any updates here