Alright, I’m not English so I’ll try my best to explain:
I’m currently working on a simple climbing game. Its like an infinite accelerating sidescroller, except that it moves upwards. The player has to jump on spawning platforms to prevent falling down below the screen and losing the game. Super Smash Bros have a few levels like this.
The game will keep running until the player dies. This means that the building the player is climbing has to build itself.
I made a blueprint with a mesh (the cubical “room” you can see in the gif), which essentially spawns another actor of the same class a specified amount above itself whenever it hits a trigger parented to the moving camera. Basically, when the wall has reached a certain point on the screen, it will spawn a new one above itself to continue the cycle.
Let me know if its hard to understand.
I have attached a gif to make it easier to see, but the file size required is way too small to be practical, so this will have to make do.
Here is the problem:
As you can see, a new wall is spawned the first time, but not the second time. The wall is actually ignoring the trigger completely. Keep in mind that it is the camera, floor, and trigger moving upwards, and not the walls moving downwards. The small cubes are present to visualize the movement.
Tl;dr, the self building wall ignores an overlapping trigger, and therefore doesn’t spawn a new wall above itself, which breaks the cycle.
I’ll accept both solutions for the overlap ignore or another method for making the wall build itself alongside the camera.
Here is the blueprint for the selfbuilding wall. The trigger is a box trigger placed in the world, and attached to the camera at beginplay. I’m grateful for any help.
The trigger is just a trigger box dragged into the world from the Modes Panel to the left. The overlapping actor is a blueprint with a wall mesh. These two are overlapping. The box trigger is attached to the camera.
How is this?
I think I should mention that the camera moves by the level blueprint, not its own actor.
I added a color to the wall actor to help distinguish it from everything else.
I don’t know why I picked the trigger, it was just the first and best thing I found. I didn’t know there was much of a difference to be honest. I’ll try with collisions instead.
Anything else you would like to see/know?
Who owns the trigger? Who is overlapping who? It is kind of hard to tell what the exact setup here is. Need screen shots of the components for both the wall and the moving floor including where the overlap is. Also, using a “trigger” class is odd, I would think you just need a box collision on the wall/floor depending who does the overlaps and use that to determine when things have “ended” overlapping and need to spawn again. Perhaps your trigger reference is only functional for the first instance. Many things, can’t tell with the limited info.
i think your making this a bit too complex for your use case. below i made a simple example of how you could handle your walls in a manner similar to a endless runner (since thats basically what your making). so at the most simple you need an endless stream of floors, this can be done two ways while actually moving the platform as you like. you could spawn new floors as they come on screen and destroy the old as they leave (many ways to do this). or you could just move floors and cycle them, so when one moves off screen you move it to above the screen and reuse it (better performance). ill be looking at the first method since its easy. for this method we will want to spawn a new room once something begins overlapping the current room, so if the platform is overlapping the room then we want to spawn the next one. for this we will need a collision volume (box), you will need your wall mesh, and to be used later you will want a scene component (i added a arrow to show placement). the actual script will be much like yours, on begin overlap spawn wall. in this case we add a little extra check to make sure the overlap isnt another wall to ensure it doesnt spawn more walls than needed. we also use a do once for the same reason, we dont want to spawn a wall bp for a overlap of the character and the platform. another little change was the use of the scene component to determine the new spawn location, this makes things much easier, versatile, and eliminates the need for the math your using. the last bit i included was a way to destroy the wall on end overlap, basically when the wall stops overlapping the player character we set its life span to 1 second meaning it will be destroyed in that amount of time. you may want to use a different method to destroy your wall sections since it seems like your looking to have exponential acceleration, you may need a variable lifespan or a different method.
personally i would incorporate the destroy into the platform and have that as its own bp actor. your platform could incorporate the camera as well then it would be easy to make a very modular setup to have multiple levels.
Hey, thanks a lot for the help. I’ve tried to do the same as you, but had some complications. here’s my blueprints.
EDIT: I don’t know where that last picture went, but you should be able to download it or open it in a new tab by the attached images below.
I haven’t gotten around to trying it out properly because the game keeps telling me I run into an infinite loop. It then directs me to this macro from the DoOnce node. It directed me to the BeginOverlap node as well one time. Don’t really understand what’s happening.
Also, I need to tell the game to use the camera in the platform blueprint, but the component is not a valid variable for Set View Target With Blend. Any idea what I could do with this? Also, the way the platform moves up at the moment is a little clunky. It works, but I’m wondering if you have any better ways to move it?
I’m also wondering if i could have a box collision trigger in the platform blueprint, about a wall’s length below the platform. This could take care of destroying the wall actor.
And lastly, how difficult would it be to use the wall loop instead of destroying them? The game is supposed to be easy to run on as many computers as possible, and performance is fairly important.
k i just looked into it and i made a simple mistake with the not equal node, i was thinking it was a class reference for some reason but thats actually a object reference. so you could just do a get class node (like you had originally) and work with class references or you could just use a cast instead of the != and branch, basically cast to walls class and if fail then do once.
whilst testing this i actually came upon another issue where the do once was actually letting two executions through when i had a setup testing for anything not a wall as shown above. what seems to be the best method to solve your current issue and the one i stumbled upon would be to create a bp actor for the platform, use a get player character and then use a equal node, or simply cast to character
.
Aaaaand it works! I’m using the object class method, and no problems so far. I created a box trigger and attached it to the platform blueprint. When a wall ends its overlap with it, it destroys itself. Basically, walls are building and destroying itself when supposed to. Thanks a lot for the help, I learned a lot!
