Posts Tagged: Prototype

Final Prototype Update

Overview of Movement Scripts

An overview of the core movement scripts, also showing a fix I made for an issue with the camera not returning to the right position after a movement is made (added an extra level of Rinterp). I was able to create the overall movement for my prototype with the help of George and users on the UE4 Forums.

Movement Values

Highlighting the effects of certain values used to adjust the feel of the movement. I am continually tweaking these and other values to find the perfect balance.

Variable Cleanup

As I progress with my learning, I am becoming better at understanding how to refine and organise my scripts. Here I made a quick improvement by using only one instance of a variable rather than the six I first started with.This creates less bloated scripts overall, but also makes editing slightly easier.

Making tunnels

I made use of some methods I learnt in my first UE4 session with George to create some very quick level assets for testing purposes. I used ‘Add’ and ‘Subtract’ shapes to quickly hollow out a square and use it as a tunnel.

Damping value

This value is an important one within my movement mechanics, as the damping effect it results in helps recreate the momentum experienced underwater. When the character stops accelerating, they should continue floating forwards and gradually decrease, not come to an immediate stop. I found that this value in UE4 is what can be used to adjust that.

Move with Mouse Control

It was very simple to add the ability to change direction entirely by aiming the mouse. I simply added the Mouse Y axis into the Input settings, with an initial value of 2.0. I later moved this down to 1.0 for slightly more control when moving.

Collectible

I also added a basic collectible object. The character can collect the sphere, and it will disappear upon overlap. The game will then print a string with the total count of collected objects. Eventually these will be Weedy’s eggs.

View post on imgur.com


Above shows a quick clip of my up-to-date prototype in action. The movement is now much closer to how I envisioned it, I simply need to carry out playtesting while continuing to iterate (during the next project), and I can perfect it and possibly even look to develop the full concept. This easily meets the goals I set myself for this project submission, so I am pleased with the progress I have made up to this point.

There is only one issue left in the prototype, which unfortunately I don’t believe I can fix for submission, but I will continue trying and can at least fix it inbetween now and April. When using the mouse, the camera often ‘judders’ which can be really frustrating, and reduces the fluidity of the movement. I believe this could be to do with the various mouse-based interactions conflicting with each other, but it will take more research and most likely some guidance to fix it. Other than this, the prototype is in a good state to submit.

Prototype II Progress

Since last working on my prototype I have started a fresh with a slightly different and much simpler script (with the help of George). This should help editing and troubleshooting easier, as there is much less complex script to cause errors or confusion. I can build up more features and in-depth movement later on, such as in BA3b. For now, though, I am still experimenting with different methods and figuring out how everything should function.

1_Flippy

The current state of the revised prototype (Prototype II)

As shown above, the current prototype:

  • Looks around/change direction using mouse
  • Move vertically with LMB/RMB
  • Forward/Left/Back/Right with WASD
  • An overview of all scripts
  • [Current] Core movement script
  • The script used to tilt on strafe
  • One attempt at fixing the pitch issues
  • Various methods used to try and fix problems

The character successfully tilts on up and down movement, which I had some problems with initially where the actor was rotating but the camera wasn’t Various attempts at fixing this are shown in the gallery above, but I eventually managed to fix this by simply attaching the Rotation to the Camera as a second target, as well as being attached to the FlippyMesh (For some reason it didnt work when attached to the SpringArm, only the Camera).

  • Before
  • After, the camera is also attached

However, this also causes the camera to rotate on MoveForward as well. This is a problem I still need to fix, as I only want it to happen on MoveUp (on Moveforward, the Mesh should rotate but not the Camera).

My next step to try and fix this will be to try copying the logic and hooking each function up separately, making one catered to rotating both components while the other only rotates the Mesh — this should fix my issue.

Next steps (goals before submission):

  • Make it so the MoveForward tilt only applies to the Actor, not Camera
  • Tweak all values such as pitch, speed, etc to refine the movement further
  • Build a more substantial testing level/zone

UE4 – 3D Third Person Character Movement – Development

Building on my initial tests, I have been further developing my 3D Prototype Controller. I started by creating a simple 3D model in Blender to use for the prototype in order to better visualise how the movement is working with my particular character, Weedy the Sea Dragon.

  • Using a reference image of mine to begin modelling a rough shape
  • Adding fins and refining the shape
  • Adding the finishing touches to the model

By modelling manually like this I am improving my ability to quickly knock out prototype models for a faster workflow. Previously I have made most of my models by creating Voxels in Sproxel and then using the Decimate Modifier in Blender to generate a low poly model, which results in much less control over the shape and less desirable topology. I think it’s important to improve my ability to model more traditionally and manually. Although I have little knowledge of 3D and my topology is far from ideal, it still functions perfectly fine for a prototype, which is all I need.

A turntable of the final model.

4_Import

Importing the model into UE4

I exported my model from Blender as an FBX and then imported it into Unreal Engine. The image above shows the model as a Skeletal Mesh, but I soon realised a Static Mesh would be fine for this stage and re-imported it. If I need to rig or animate at all later (which is likely depending on how I progress with the movement controls), then I can make use of a Skeletal Mesh. For now though, I wanted to keep things as simple as possible so I can focus on one thing at once.

View post on imgur.com

I first opened up the Flying Starter Content and replaced the mesh with my own, just to quickly test how those controls felt as a starting point. It worked fine and I could tell this would be a good place to start editing the Blueprints to refine the movement myself.

View post on imgur.com

However, I also wanted to try the “Space Shooter” Starter Pack I had found in my earlier post. It took a fair amount of trial and error and lots of extra research and troubleshooting to get the content into my new project and tweak it to work with my model and my ideas. I studied the blueprints and other assets carefully, removing what I didn’t need in order to give myself the most simple resources to start working with. This has taught me a lot more about UE4 and Blueprints. The above image shows an early test, controlling the character after setting up my model with the Blueprints and other content I had imported, and after making several tweaks.

View post on imgur.com

I continued to play around, refining what I had and learning more about how it works. I adjusted some Speed values and also the Input Bindings quite a lot, resulting in a control scheme that I feel works more fluidly — although there is still a lot I would like to continue to change. For example, I altered it so that up/down movement was controlled with the Left/Right Mouse Button. The player would already be using the mouse to steer the camera, along with WASD to steer the Pawn, so it makes sense to make use of LMB/RMB. Previously, this was set to use Shift and Control, but I found this much less natural.

The above image shows the current state of my prototype. I began adding in some blocks to practice navigating around in order to get a better feel for how the control is working. The game would most likely feature tunnel-based levels so it’s important to create a controller that works well with tighter spaces. It’s also important to experiment with the up and down movement, not just the forward/back/left/right, as the vertical movement in the water is something that is important for me to get right.

A few details I would like to work on from this point are:

  • Further refining the input bindings to feel more intuitive
  • Create fluid controls between both Game Pads and Keyboard/Mouse
  • Increasing the speed of up/down movement
  • Increased Yaw rotation when turning left/right
  • Adding Pitch rotation when moving vertically up/down
  • Re-introduce the speed boost function
  • Create a more elaborate grey-boxed level
  • Build a better understanding of the Blueprints used so far

It is important to me that I end up with a movement controller that is uniquely my own. Although it is very useful that I have found starter content I can make use of as a starting point, it’s necessary that I actually do fully understand it and am not relying too heavily on the work of someone else. In order to do this I will continue to deconstruct the Blueprints and try rebuilding them from scratch so I can break down each section individually and examine how it works. I will then continue to build my own adjustments into it until the product is something unique to myself and my concept.

I also think it is very important to begin collecting feedback from others at this stage. The way that people interact with control schemes varies a lot person to person and some feedback would be very valuable in order to understand where I should put my focus next and what details need more tweaking. It may be necessary here to add the option for inverting the controls, as some people may require this in order to give accurate feedback. The way in which the camera moves is similar to how the control of a FPS or in-game Flight works – these are examples where a lack of option to invert can sometimes be completely game-breaking for players, resulting in them feeling very frustrated.

My next steps should be to address the areas above and look into creating a set of play-testing questions regarding the control so far.