rapidprototypingproject

[rapidprototypingproject]

Unreal Engine: designing new obstacle tiles

I wanted to create new tiles that would help the player to utilize the full extent of their movement- so I focused on making multiple routes around these tiles. This first one accomplishes this by providing multiple methods of approach:

The code inside this child actor will randomly choose one wall to activate, and one platform in each row with this code:

Another cool thing about this floor piece is that it is actually 4 "tiles" long. This was really easy to do because I can just move the SpawnPoint scene to the new end of the longer tile, and my spawning code can handle it. The other new tile I made spawns one of two moving hazard blocks. One of them you can slide under, one of them you jump over, both you can maneuver around.

The code for the movement uses a timeline and looks like this:

After testing this tile by myself for a bit, I realized you could just jump over both blocks anyway. To fix this I made the higher hazard block much taller, encouraging the use of a slide if the player has it:

I was going to make a test level where only these two obstacles spawned, but I realized that wouldn't be accurate testing. I should test them around other obstacles to make sure they feel fair and fit in, so I did that instead and here is the result:

I think the difficulty of these tiles is much higher than the others, which is fine but it made me think of adding some progressive difficulty. Or even an alternate path the player can run on that has these harder tiles, but greater rewards. I don't have time for either of these, but I would love to do something like that if I took this project further.

[rapidprototypingproject]

Unreal Engine: Iterating the slide code

While watching people playtest, I noticed a few people getting hit by the slide-barrier obstacles because they started a slide too early, then when they rose after the preset 0.5 seconds, got hit by the barrier. Maybe this meant they player wasn't used to the time of the slide, or they shouldn't have pressed it that early, but it didn't feel fair to me. Because of this I proposed to some playtesters a new slide where you would hold the slide button instead of pressing it, and they all approved of the idea so I attempted to create it.

I first tried doing this on the release of the slide key, no extra changes. However, because my slide code would always set your position after a 0.5s delay, that caused repeated slides to end early.

My next approach was to use event timers, which would decrease a SlideTime variable while you had the slide button held. When it == 0 (or you release the slide key) you would stop sliding.

Here's what that looked like:

And this is the result:

The code works really well, but while using this feature I honestly found it less useful and intuitive than the previous version.

Sure it allowed for advanced control over your slide, but just pressing once is much easier and more comfortable versus having to hold it down. Additionally, its much harder to jump out of a slide now, because you would have to be holding down the slide and jump button at the same time.

If I had more development time, I'd love to get a round of playtesting on this feature but as it stands I'm going to opt to keep my old system for simplicity. Because I still wanted to do something about the initial issue, I increased the slide duration by 0.15 seconds, to hopefully reduce the amount of unexpected bonks on barriers.

[rapidprototypingproject]

Unreal Engine: chosen upgrades list

This is just a textbox in my HUD that I change the value of:

As I already had a reference to my HUD in the player, I started the code for the feature here. My first approach was to create a variable in my HUD, and set the text using that variable:

Then I would update the text in the HUD every time I got a relevant upgrade, I even put it in a collapsed node to make it look nice:

This may have worked, but I realised that I could just make the textblock a variable, and directly edit its contents using a SetText node:

and now instead of an Append node, I would use Format Text.

This didn't work though, the value of In Text (aka new text) was nothing, even though I was passing it in though the collapsed graph. When I hooked up a Print String I got this weird error:

The current value (NSLOCTEXT("[D2684906477417720D81AFBB4C161CD7]", "ABE0AA894E8535CB2F61C2BA907B3858", "Wallrun [hold movement key while against pink wall]")) of the ' In Text ' pin is invalid: 'In Text' in action 'To String (Text)' must have an input wired into it ("by ref" params expect a valid input to operate on).

Looking up the issue gave no helpful results, but the fix I landed on was just, making the text into text using the Make Literal Text node:

And this was the result:

It's nothing special visually, but this will help players remember what upgrades they have to use them to their fullest potential. I also really like the elegant solution I coded.

[rapidprototypingproject]

Changes I want to make based on feedback

With limited dev time left, I'm making a list of changes from most to least important that will improve the gameplay of the game to help me prioritize my actions:

Give a reason to take the speed upgrade

List of taken abilities

Improve the slide (hold/release)

More unique tiles that use your abilities - Longer wallrun with a gap in the floor - Multiple blocks in a lane - Moving hazards

HP system with blue blocks

[rapidprototypingproject]

2nd wave of feedback

To truly get the most out of playtesting, I need to do them after every major feature addition. Now that I've got the basics of my roguelike system I thought now would be a good time. I got responses both from previous playtesters and new ones to make sure these systems were understandable to someone who had never played before.

I also thought it was important to keep some (not all) of the questions from my previous playtest form. This meant that if my movement changes went against what my players wanted to see, they could still voice it in this form too.

This simple question is really valuable to find easy to fix annoyances, OR mechanics that players think are bugs. For example one response mentions the wallrun being inconsistent, which may be an issue of them not understanding how to use it, or it isn't lenient enough. This feedback suggests that I many need to give my wallrun another pass before it's in its best state.

I'm really shocked that player's thought these upgrades were as impactful as they are. After watching people play I didn't really think they liked them as much as these responses say. Some later responses go on to say ways that they could be more impactful which I agree with, so there is still room to improve here.

A common theme with these answers: people never take the speed up. Now I could just remove the speed up and be done with it, or I could give people a reason to take the speed up by tying positive things to speed or the upgrade. Maybe the upgrade also increases your score multiplier? This is definitely something to think about.

Again, people resonate with the idea of speed up == bad. Additionally, a wide variety of favorite upgrades means there's no one overpowered choice/meta- I'm happy with that.

These are all really cool ideas so going through them one by one:

Active rewind: I think this could look really cool, and would reward the player for identifying when they're in a bad situation before it causes them to lose. However, I know a feature like this would take at least a week of development time, so its not in the scope of this project.

Score multiplier: This would be really easy to add, and would help to dilute the upgrade pool. I already mentioned the speed upgrade also gaining this feature and I think that approach would be better. If I think of another positive attribute to give to a speed up though, this could totally be its own upgrade.

Hovering: Funnily enough, the code to make this work would be basically the same as my wallrun. Because of this though, I don't think an upgrade like this has a place in my game because it's too similar to a wallrun but you can just do it anywhere. To make t really feel like a unique upgrade I'd have to spend time I don't have developing a new system for it.

Shield/Extra life: A lot of endless runners have upgrades like these to prevent instant death. However because I plan to have the blue "doesnt-kill-you-in-one-hit" blocks, and the red "does-kill-you-in-one-hit" blocks, something like this might be redundant. Still, an extra life might be interesting.

Longer slide: This could be an upgrade, but after talking to some playtesters. I pitched a feature which they all seemed to like: you would hold down the slide button to keep sliding, and releasing it would bring you back up. This allows the player more control over their movement and is something I think is really important to help the feel of the game.

Coin Magnet: I don't think this idea really fits in with the rest of the upgrades, because it would be too strong if it was permanent. Having it be temporary would also be different to the other upgrades.

List of active abilities: This is just something I should have had by default, and is a high priority for me to add now.

Grappling hook: This is cool, but doesn't fit in with the other upgrades and would take far too much time to add.

Limited speed boost: I don't think players would really take this as they were opposed to the speed up, so I'm not too sure about adding this one.

These responses tell me that the roguelike system does give some variation to the runs, but there needs to be more obstacles and more upgrades to make each run truly unique.

I'm happy that people still think the movement is just as polished/responsive as before. The biggest response here does mention a kind of meta progression through the upgrades, but I think that's just their choice. It's a good strategy, probably what I would do in a run, but it's not the best and only choice so I wont be changing anything based off of it.

This feedback here is great- players both understood and enjoyed the movement abilities. This leads me to believe I've somewhat achieved my goal of making good gameplay already and now I only need to improve what I've already got to make sure players are using the full extent of their movement kit.

Again the long response gives some really good feedback. Pseudo-randomness would be awesome to experiment with, and I think it could be easily achieved by increasing the length of a tile.

I agree with the frequency of upgrades and I will increase the distance between them further every time you reach one.

The feedback on wallruns applies to all my upgrades- I need to add more obstacles where they become easier if you have a certain upgrade.

Abolishing the sped cap would be funny, but after testing it the game quickly becomes ridiculous and unplayable. I like the idea of moving blocks, though.

[rapidprototypingproject]

Reviewing my plans

I'm nearing the end of this project, in the final week now, so I want to look over my plan and MoSCoW to see how on track I am and if I need to make any changes to hit my goals for this project.

I'm really happy with my progress on my plan up to the refining week, which is this week. This is where I think I need to deviate from the plan. I optimistically made this plan thinking I wouldn't need to make any major changes to my game that would take up more time than a week, but based on my 2nd wave of feedback (covered in a later blog post) I want to make some big, gameplay focused, changes that I think are more important than giving the game other visual/audio features. One reason I think this is because my biggest focus in this project was to make good gameplay. Audio and visuals are a part of this process but I need to get a satisfying game loop first.

As for my MoSCoW:

Must have: Everything is in already, so I'm happy with that. I would like to add a few more obstacles however to add more depth to the game.

Should have: The stat tracking and HP system aren't implemented, so these are a priority for me at the moment.

Could have: These are all things that I mentioned I don't think I'll have time to do. So instead of being indecisive, I'm going to focus all of my dev time on getting the gameplay 100% perfect, and then these features can be thought about only afterwards.

Won't have: I still wont be spending time adding these, so there's nothing to change here.

[rapidprototypingproject]

Unreal Engine: Wallrunning

This is a feature I wanted to add because I thought having it as an upgrade could make some runs feel more unique than others. The first problem i needed to tackle was finding out when to wallrun. The walls only appear on the far left and right, so I thought the best method here would be to cast a line trace when my player moves in either: direction

This was a good start, note the IsWallrunningLeft variable. This doesn't do anything at the moment but I thought it would be good practice to declare a variable like this now in case my final solution ends up needing something like it- it would be easier to add it now.

Now I needed to decide what happens when you actually begin a wall run. I found that setting the player's velocity and gravity to 0 would make them slide in the air, not attached to the wall in anyway but it looked correct as the position of the walls are directly to the side of the player:

Now that the I could detect when to start a wall run, I needed to find out how to maintain it and correctly end it when the player reaches the end of the wall, or lets go of the wall run key. With the current event I'm firing - the default key press - it's hard to do something like this as I only have 'Pressed' and 'Released' events to work with.

I decided to change my event to a 1D Input Action to take advantage of all the other methods of event firing:

Now I could use the 'Triggered' event, this fires every tick the IA is held down, perfect for detecting if I was on a wall or not during the entirety of a wallrun:

This is what a the line traces for a wall run looks like- note how you can see the initial cast go perpendicular to the others (this is explained in the next paragraph), and how at the end the cast doesn't hit anything, causing them to stop:

It was at this point in testing that I thought it was a bit difficult to attach onto a wall because if you were just a split-second too early the line trace would miss as it fires out the middle of your body. I changed the initial line trace to a box trace to try and give some lenience to this initial cast:

This worked very well, but honestly a box trace is overkill for something like this. I later realized I could accomplish the same thing by casting the initial line trace a few units in front of me, so I changed to that.

I now needed the final of the 3 parts of a wall run: coming off of the wall. I could detect this easily enough - if a line trace missed or the player let go of the wall I could detect that - but what did I want to happen? Just dropping the player off of the wall would be easiest, but not very satisfying or intuitive to the player.

I thought about other games that had wallrunnning in them, and looked at videos of Titanfall and Mirror's edge to better inform my decision:

These games let you choose between just falling off the wall or having a 'jump off', where you get a horizontal and vertical boost. I really liked how the jump off looked in those games, and I think it would translate well into this one to help the player movement flow.

My first attempt at developing this feature used the launch character node, and just sent me off of the wall (note the WasOnLeftWall? boolean, this is the best way for me to check which side I was on because the IsWallrunning variable has to be off at this point):

This caused me to bounce off of the wall after ending a wall run- great. However, this meant I wasn't in any specific lane now which messes up my lane swapping code. I found the best solution to this to be setting the lane of my player after a wall run to the middle lane and then launching the player roughly in that direction:

and this worked, but there were still more bugs I needed to fix before I was happy with this feature.

Most notably, the player could still input any of their other moves (jump,dash down, etc). while wallrunning, leading to unintended results. This was an easy fix, I just needed to check an IsWallrunning variable before letting my player do any of those moves. for my jump I actually put this inside the CanJump constant in my player, not sure if its any better this way but it made sense to me:

The last bug I faced was that the player could "re-wall run" after bouncing off of a wall. This meant you could spam move into a wall and keep wall running and by extension bouncing upwards. I fixed this by adding a new Variables, CanWallrunLeft & CanWallrunRight. These get set to false after you jump off of a wall and true when you touch the ground, OR after you run on an opposite sided wall- this fixes the bug and still lets you jump between walls like a parkour pro, which I'm really happy with.

After all that development, here is the result:

I was really happy with my development of this feature- from start to finish it only took me one day to get it into this state. My processes I've learnt over my previous projects helped me to develop this much faster and relatively bug-free.

[rapidprototypingproject]

UnrealEngine: Creating/Spawning my upgrade tile

I wanted this upgrade tile to spawn after every X amount of normal tiles. My first idea for this was a bit overcomplicated- I tried to use the modulo (%) operator on a TilesSpawned variable to spawn one every time it equaled 0. The modulo operator tells you the remainder of a number (dividend) divided by a another number (modulus). For example, 15 % 15 == 0, and 15 & 14 == 1.

The code to use this modulus looked like this:

This might look OK, but as I was testing it I ran into a few issues, such as too many upgrade tiles spawning on begin play, and making adjustments to how many tiles I wanted to spawn before an upgrade tile wasn't as easy as I wanted it to be. So I looked for an easier method, which I found very quickly to just be to have a new variable, TilesUntilUpgradeTile, and decrement that every time I spawned in a tile.

The code for that looked like this:

This was much more modular and easier to manage. There's no issue with this now, I'm totally happy with the current state this feature is in!

[rapidprototypingproject]

Unreal Engine: Creating the Roguelike Upgrade System

To create a proper roguelike choice system, I needed an element of randomness between my three upgrades. To do this, I needed to select an upgrade based on a value, and I first tried this using an integer and a Switch on Int node, like this: (this code is in the UI element that appears during upgrade selection)

These custom events are linked to upgrades in the player. I think these will need a balance pass, but that will require a round of playtesting, so I need this to actually work first.

This gave the player the upgrades correctly, but I wanted to remove certain upgrades after the player chose them, such as the slide ability- I only want them to be able to see/pick that once. This method wouldn't work with that feature because using the Remove node in the list of upgrades would change all of the indexes, changing the outputs of the Switch on Int node.

After realizing this, I tried using a enumeration, but that didn't help me anyway, because it just had the same problems as a normal array.

Finally, after way too much thinking, I landed on the Switch on String node, which gives an output based on the inputted string- this is litterally perfect. Now I could delete values in the list after seeing them, without worrying about messing it up. I wrote a small custom event that did this and put it in the EventConstruct code:

However, having it here caused upgrades to get deleted prematurely even if I hadn't chosen them. I failed to see why this didn't work for a good while, but the reason was is because I was calling the RemoveUniqueUpgrade node immediately after setting the Upgrade value. So if it showed up, ever, it wouldn't show up again even if you don't pick it. To fix this I needed to call the custom event after clicking the upgrade button:

This was the mechanics behind the system done, now I needed some visuals to let the player choose their upgrade. I made a new Widget Blueprint and created a screen of 3 choices:

To display the correct upgrade, I just had to use the Switch on String node again:

To get the longer text to wrap correctly, I sized the text boxes as shown above and ticked 'Auto Wrap Text' in their settings.

Now was the hard part, spawning it correctly. I created a new floor tile that was *not* a child of BP_MasterTile, because I didn't want some of the code in there. It still retained most things however, like the spawn point scene:

The collision box closer to the edge stops the player movement/input, and does all of the HUD stuff:

I'm using a variable called HUDUpgradeRef, which comes from here (in my player, off of EventBeginPlay):

This is a really cool trick I discovered to not have to create the widget every time I wanted to add it to the viewport. The second collision box, closer to the arrow, I added after I discovered an issue where if the player was going too fast while sliding, they could go past the upgrade tile and straight into an obstacle, dying. This collision box just stops the player completely:

After all of that, here is the result:

There a few issues I see immediately:

In the selection screen, you can have duplicate upgrades.

The next tile after an upgrade tile has a obstacle on it, which can make be hard to avoid if you're at a high speed.

It's really easy to become "overpowered" with these upgrades. With just a few jump height increases and a double jump, I can just avoid everything by jumping.

These are all issues with the balancing of the game. The second issue I have no problem fixing right now, but the other two I want to get player feedback on, so they can tell me how they would like to see these issues improved.

This new goal now sets my aim to get the game ready for another round of playtesting.

[rapidprototypingproject]

Plans for 4/10 (today)

Because of some extra playtesting I was asked to run, I only have today to work on my roguelike pause rooms and upgrades while staying on track with my plan. I want to lay out everything required for this to ensure I spend today as optimally as possible

For this feature I will need:

A new tile that:

-Spawns after a set amount of tiles

-Stops the player

-Pulls up a HUD element that allows them to choose an upgrade

-Smoothly continues play afterwards.

A HUD element that:

-Has 3 buttons

-Each button is a random buff/upgrade based on previous ideas

-Ideally these would be weighted/have a rarity system

-Grants the player their chosen upgrade after interaction.

I imagine I'll run into more requirements during development, but this is a good start.

[rapidprototypingproject]

Unreal Engine: fixing coins spawning in the obstacles

This was a weird bug I noticed while debugging:

The coins spawned on top of the tile markers, same as the obstacles so they were inside each other. I just fixed this by spawning the coins on a different X level.

[rapidprototypingproject]

Unreal Engine: sliding

This feature turned out to be a lot more complicated than I thought. For reference, my player is using the default Character blueprint, so there's things that are hard for me to change. For example- I can't change the rotation of the default CapsuleComponent, which would have been my first approach.

Because of this, I had an idea of giving my player 2 collision capsules, like this:

I would then toggle the collision of these capsules based on what state the player was in. This was great in theory, but when I disabled the collision of the default CapsuleCollision, the player stopped:

I looked on the internet for anything related to this issue, but I couldn't find anything except people saying how the default CapsuleComponent really didn't like to be edited.

After a lot of brainstorming I landed on my working approach, setting the half height of the capsule. This made it look like this:

Obviously this doesn't look right at all, but gravity in the CharacterMovement will pull the player down and make them "slide" along the floor. I would love to increase the radius of this capusle so it actually covered the player properly, but:

So no luck there. Suddenly increasing the width of the player's hitbox might make for some seeming unfair deaths where you don't gauge the distance correctly, so this isn't something crucial to fix.

Now that I could get into a sliding hitbox, I wrote the code to allow the player to slide:

I like having it on the same key as the downward dash like in Subway Surfers, as it reduces the total amount of keys the player needs to learn and because both of these moves "go down" in a way, so it makes sense. The CanSlide variable is also there for when I lock it behind my rougelike mechanics.

This is what puts my testing into actual runtime changes. It's a lot of nodes but not too bad- it just sets the capsule height and player rotation to what I tested in the viewport.

Then there's obviously the question of "what happens if the player slides then jumps?" The only realistic answer to this I could think of was to cancel the slide state and then start a normal jump. This was the blueprint change I had to make:

And this is the result of it all:

Obviously, there's no specific animation for this, but that isn't something I want to focus on for this project. I'm happy with the visuals as they are now- it's clear enough that your collision has changed and you are sliding.

There's also a bug where the player is stuck in the floor. My biggest problem with fixing this is that it seems to be random so replicating it to work on a fix is really difficult.

Aside from that issue, I'm really happy with my process of overcoming the problem I faced while implementing this feature and the final result.

[rapidprototypingproject]

Unreal Engine: new obstacle

This obstacle is added directly from player testing, where I saw one player staying only in the middle lane, jumping over every obstacle. This one will choose 1 of the 3 blocks to show and requires you to change lanes unless you can slide- which you can only unlock mid-game (when I add it). I hope this will shake up future runs and the player's movement.

[rapidprototypingproject]

Unreal Engine: Fixing the camera bug

As I said, I first tried to fix my camera by changing its location further above my player, away from the obstacles. This would stop the camera from colliding with obstacles and jittering. However it looked like this (first pic is after the change, second is before):

In my opinion, the second one looks much better- the environment is closer to you so you can see obstacles more clearly. The position of the player also feels better in the before picture- it feels right to have them in the center. This is something I could get feedback on next playtest, but for now I went with a different approach.

I added a collision box around the camera that destroys everything that it touches:

This was inconsistent, but closer to what I actually wanted.

The method that I finally landed on was really simple actually. There is a collision channel dedicated to cameras, and I just set that to Ignore on all my obstacles:

This was the result:

You can still see the shadows of the boxes, but the sudden jitter of the camera is gone, so I'm happiest with this approach. I'm also glad I tried other methods because the way this works also means that tall pillars also shouldn't affect the camera.

[rapidprototypingproject]

Setting SMART targets from my feedback

A SMART target stands for something that is Specific, Measurable, Achievable, Relevant, and Time-bound. I created three of this at different stages of my development to help me as I create this game:

I will fix mechanical issues players had during gameplay to make the game more engaging and varied. I want to fix the camera colliding with obstacles, add a sliding ability, and create a new obstacle that requires the player to change lanes. These are all things that I know are quick additions with tools/systems that I have already created in the game engine. Adding/fixing these things aligns with my goal of creating a fluid movement system, which is a key feature of the game. I want to complete these changes by the end of this week to keep myself on track with my plan.

I will add the roguelike upgrade system I mentioned in my proposal and feedback form to add variety to the game and make each playthrough new and interesting. To do this, I want to create a "pause room" that spawns after every 30 tiles where the player can stop and choose 1 of 3 upgrades before moving on. I want to create 10 choices for this. I have assigned myself a week of development time to add this feature from scratch in engine using tools that I've previously used such as widget blueprints. This feature aligns with my other goal of creating a unique endless runner experience that is different from most games in the genre. I want to complete this feature before the start of my next playtesting session to ensure that it gets tested.

I will add a basic theme and design to the background of my game to improve the visuals and give the player an interesting play-area. To do this, I will change the skybox and give unique materials to each obstacle. I have already asked for feedback for the game's theme and created multiple materials for the blocks/obstacles already. This isn't the most relevant addition to my game as I am focusing on mechanics/gameplay, but it is something I want to add to make the game proper and complete. I plan to have this done by the end of the project, as I have reserved a day for this in the final week.

[rapidprototypingproject]

Proccess of acquiring feedback and reviewing it

Recently, we had an established video game creator/producer/artist Sam Read-Graves from Read-Graves games come in and give some insight into his history in the industry, and to talk about the importance of prototyping. One thing that really stuck with me from his talk was how he said that the earlier the game has playtesters and sources of player feedback the better. Even if they're just playing as basic shapes in a blockout map, if there are things to get feedback on (mechanics, art, sounds, music) it's always worth playtesting.

My game only has it's core movement mechanics at the moment, but this is totally something I could get feedback on. To get as many different people to play my game, I created a private itch.io page I could share: Endless Runner Prototype by Paladin (itch.io) (password is endlessrunner). This allowed me to easily share my game with people outside of college and people less experienced with this genre and games in general.

For the actual feedback, I made a form with qualitative questions focusing on the movement and obstacles to see if player's even liked how it felt.

It's important for me to understand that these responses are from people who have played the game giving their thoughts on how I could make the game better, and it's up to me to determine if their suggestions would actually improve the game.

Response #2 stuck out as important to me- this way of playing the game definitely needs to be fixed. This would be as simple as creating an obstacle that you cant jump over, requring you to switch lanes.

Response #4 highlighted an annoying bug where the camera hits obstacles behind the player. The easiest way to fix this is to change the camera angle and put it above the obstacles. Alternatively, I could try and create a system where the camera deletes any obstacle it touches. This would prevent it from ever getting stuck on anything, ever. I believe this issue is also the jitteryness that response #7 is talking about.

I also like the idea that response #5 is suggesting, however I feel like a speed decrease might slow down the pace of the game to a point that I'm not happy with- this is just something that I'll have to test.

I'm really happy with the largely positive feedback here. This movement system is basically half of this game, so it needs to feel right.

Response #3 requested a slide feature, which I already have planned so I'm happy that that is something a player would want to see in the game.

Responses #5 and #7 are fair in their requests for animations, but at the moment I don't have any time in my plan for unique animations. I did play around with blend spaces in Unreal Engine in the prototyping phase of this project though, which allow you to blend together multiple animations based on variables. If I had more time, I would love to get some animations from a site like https://www.mixamo.com/ and mess around with them to create some better animations for my player.

I asked this question to maybe get some new games to research, but there's nothing here that I've not looked at before so I've not really gained anything from this.

This is was an interesting question to think over. I don't have a lot of time to create detailed environments and in an endless runner, the player will likely be going to fast to appreciate super detailed and small textures. Because of this, I think simplicity is important here.

Half of these responses mention a futuristic, cyberpunk, neon or vaporwave aesthetic and I think I could achieve that kind of style in the time I've allowed myself. When I think of game's with simple future/cyberpunk/vaporwave/neon aesthetics two games come to my mind, both endless runners actually: Run, and Slope.

What I really like about both of these is how they have a really simple background and only 1-2 materials on their platforms/obstacles but it still creates a nice, memorable look.

Run's bright solid color blocks stick out against the black, starry space background, making it easy to read the obstacles ahead and just giving it a nice look.

Slope does a similar thing, but everything has a harsh neon grid texture against a pure black background. While this is a nice affect, it does hurt my eyes after a long amount of play time. This is slightly alleviated when the color changes, but the problem is still there. I like this concept, but I think I would use less harsh colors and patterns.

Reflecting on this feedback survey, I think I should have included questions about my planned additions, namely the roguelike elements and pause rooms, but I'm really happy with this wave of feedback and the changes I plan to make from it:

create an obstacle that you cant jump over, requiring you to switch lanes.

change the camera angle and put it above the obstacles

Test a HP system and what happens when you take damage

slide feature.

[rapidprototypingproject]

Unreal Engine: Improvement to the movement

To achieve the movement that I want, I first tried to get rid of the timeline-based code that currently moves my player and replace it with a spline, as I had learnt how to use them in my block breaker prototype. I wanted to add a spline to my player character then instead of lerping their position with a Set Location node, I could launch them in a direction and have their position clamped to positions on the spline.

Unfortunately, I didn't get very far with this idea as I couldn't manipulate the spline when I added it to the actor's viewport. Even after doing some further research into splines:

Follow a Spline and Report Distance Along It Using an Actor Component | Epic Developer Community (epicgames.com)

I couldn't get it to work.

This made me go back and look at other ways to improve the speed and feel of my player. I changed the duration of the timeline from 0.1 seconds to 0.05 seconds, so the player switched lanes faster.

This also fixed another issue I had with timeline-based movement where if you started the timeline while already moving it instantly set your location, sometimes to the wrong lane. Now it's almost impossible to do this.

I increased the player's jump velocity and reduced their gravity to give them a "springier" jump:

this higher, slower jump makes it hard to gauge where you will land. but the next addition helps alleviate that problem: the downwards dash.

This is similar to what happens in Subway Surfers if you roll while in the air, you get a strong burst of speed downwards that brings you to the floor. To create this affect I used the Launch Character node:

Finally, another thing I did was add a system to ensure my character never slowed down if they tripped up on something. Later on, I imagine I would want to give the player more than one hit, but I don't want them to slow down after hitting an obstacle as it might throw the player off (this would be a good thing to get feedback of). To do this I made sure every tick I was setting my player's velocity to their max walk speed so they never slowed down:

This is the result of these changes:

This is good, but this video does show a few issues:

getting stuck on the tall walls

sliding outside of the three lanes (biggest issue)

clipping on the top of a wall and slowing down

I think the problems with the walls come from the fact they're solid collisions from the front- I don't know if I'd even want this is a later version. Perhaps only the top would be solid and then if you overlapped with the front you would take damage but go through it, keeping up the pace of the game. I'd also like to make it so the top is like a one way collision- I think this would help prevent the clipping at the top of it.

As for sliding outside of the lanes, I'm not entirely sure how to fix it at the moment. Locking my player's Y axis unless they're changing lanes might help with this issue, but I'll have to try it to be sure.

Update: constraining the Y plane did not work, as setting the player's location means it's unaffected by the plane constraint.