BaseClass.cpp derived from AActor > BaseBP (blueprint) > ObjectBlueprint (blueprint)
i thought about this structure with these objectives in mind
use baseclass cpp to insert common complex code logic
use basebp to insert common “easy” logic
use objectblueprint to contain peculiar “easy” object logic
example:
BaseTile.cpp > BaseTileBP > StreetTile(BP)
Question one:
is this a wrong approach for some reason? i can’t find online any information about how to structure hierarchy to achieve both cpp flexibility and the quick and easy blueprint usage, is there a better solution ?
question 2
i noticed that with this structure, creating a simple 64x64 map at runtime causes the editor loading time to increase enormously ( 15 sec), but even after measuring construction times in the base class i only have a time measure of 0.6 seconds.
The actors are totally placeholders, so they only have a static mesh, and no logic, is the hierarchy the possible problem ? how can i find what is causing these loading times?
I see no problem with the approach:
class BaseClass : Public AActor
then inheriting a BaseBP from BaseClass which other things are built.
Just becareful to not bloat it, as this is a path leading towards bloat.
Many times its easier to add components(Interfaces and other methods) to objects that achieve your specific object’s goals. UE does this really well and encourages it by how its designed.
However, I don’t personally think its a good idea to make each tile of a tiledmap be its own actor/object.
For the 64x64, thats already 4096 actors. And I don’t imagine that’s a large map.
If its just a for terrain static mesh, there are ways to accomplish the same thing with only 1 actor and 1 mesh. You can have the logic of tile interaction live outside the tile being an actor with logic.
thank you for your feedback,
i believe you are right: the tiles would have limited interaction, so probably an actor for each tile is not needed. Could you give me some hint /suggestion on what to look for in order to fix this ?
There are numerous ways to approach the problem depending on your particular needs and art-styles.
Is it going to be 2d or 3d? (Or some fixed angle top down 3d? hybrid 2.5d)
Will all tiles be the same height?
Is it 2d?
UE4 has a built in TileSheet and tilemap system already https://docs.unrealengine.com/en-us/…per2D/TileMaps
There are tons of support for how to do tilemaps in an efficient way quite simply.
There are other ways, plugins, tutorials outside of Paper2D to do this, search internet and forums and you’ll find more.
Does it have 3d requirements?
If your artstyle permits it, the easiest go-to would be to using the built in terrain mesh.
It allows you to paint different textures onto the ground mesh. This could be grass, dirt, stone, pavement, whatever, etc…
Does it need to be dynamic? Be procedural at all? Change during runtime? If so this might be good
Next would probably be the Procedural Mes Component or Runtime Mesh Component https://www.unrealengine.com/marketp…mesh-component http://api.unrealengine.com/INT/API/…ent/index.html
The general approach would be to define 1 large mesh, composed of many quads (you can still have 64x64 quads inside 1 larger mesh)
Can it be 100% static? You could use any 3d editing tool and just make a large mesh that is flat, and that has 64x64 quads inside and set the texture for each ‘square’ to accomplish same thing. Its the same as before, but you can do it in a non procedural and non programatic way.
Thank you again, i’m new to ue, so i never heard about those components.
I’m trying to create a 3d procedural generated city model, nothing too fancy or realistic, just squared tiles, generated randomly at the beginning of the map, and not changing during the game.
I plan on making about 15-20 types of different tyles.
Each type of tile has different properties, but at the moment i don’t have plans to make different behaviors. the gameplay is based on the tiles properties so the map is just a visual reference to have “citizens” move from a tile to another and “do citizens stuff”