Speedy Balls Group Project Finley Hill

I have jotted out 10 level ideas. 9 of these so far are based on introducing a couple of the things we have made per level and then level 10 being the level that puts it all into 1. Each level has a goal of ringing a bell. Each level will also use tracks. Here are some of the levels I have so far: 

Level 1: Rolling Start 

Spring Pads and Fans 

Level 2: Bumper House 

Bumpers: Teaching about rebound physics 

Spikes as the main hazard 

Bowling pins  

Level 3: Glass Break Run 

Glass breakable from building speed 

Level 4: Seesaw Playground 

Seesaws: Used for launching  

Requires Time and Weight Placement 

Level 5: Pinball Circuit 

Flippers, Bumpers and Buttons: Using both to hit buttons that unlock the bell. 

Tracks help with direction in areas. 

Level 6: Cannon Cascade 

Cannons and Spinning Wheels: Cannons used to cross the level and land in the correct areas.  

Team Meeting Week 7:

Discussing team names: Game Name decided: Speedy balls 

UI discussed: Stopwatch Timer & Speed meter made for in game UI. Speed meter will read the speed a move the dial based on this. Stopwatch timer will work the same as a digital clock which will be on the side. 

World Objects:

Bell:

Bowling Pin:

Cannon:

1

2

3

4

Movable Spikes:

Pinball Machine Flippers: Here is the Flipper mesh that was made by Adam. It is a simple flipper that will eventually launch the player in the direction it moves. In this viewport, the mesh itself has a box collision around the end where a pinball would normally be hit. This would trigger the following code.

This is the code for the flipper. Once the box collision is triggered by the player, a short timeline will player where the mesh rotates quickly like a pinball flipper. This occurs by using a lerp rotator so that I could set a start and end value on the timeline. This has to happen because the the timeline only sets how long this transition takes. On the timeline, in the second image, this shows the float track used to set the length on the timeline. I set mine to 0.20 seconds. I did this so that when playtesting, the flipper, it moves instantly and quickly. The last thing I did was create a Start and End Rotator variable. This would set where the flipper would rotate to and on what axis. I set mine from 0 to 45 on the z axis. This created the perfect balance between speed and interaction with the player.

Outcome: This video shows the initial outcome of the pinball flipper. The player approaches it and the flipper immediately flicks toward the player and launches them the direction the flipper goes to on the box collision. Now that this first one is made I will adapt it to work on the other axis so I eventually have to flippers at the bottom to be used in a level like a pinball machine.

Spinning Wheel: Here is a spinning wheel. Once rotating, it will act as a way for the player to progress through the level with timing. This was a very simple thing to make as I only had to add to the scene root in the viewport. The item in question was called a rotating movement. This allowed me to set the rotation of a certain mesh without any blueprint so it would automatically move without setting up code in the event graph. The setting was called rotation size which set how quickly this mesh would rotate. I only wanted a slow rotation so the player ball was able to climb on and move through the wheel. For this reason, I set the rotation speed to 45 on the Y axis as this was the correct axis I wanted to use.

Outcome: The outcome video below covers this wheel. It has a really smooth rotation speed and the player is able to climb it if needed and move along it with ease.

Seesaw: This is a seesaw. The plan for this was that it would use box collisions which would set off a timeline that acted like the ball weighing that side down. For this to work, The viewport consists of the seesaw mesh and a box collision on either side.

The timeline was a float track with a longer timeline of 2 seconds. This would give the feel of the weight from the ball slowly taking effect on the seesaw.

This code is similar to the pinball machine where It player the timeline on overlap of either box whilst setting a start and end point on the axis using the lerp rotator variables like the flipper. On the end overlap, the seesaw then returns to it's original state as the ball no longer weighs it down.

Outcome: When playtesting in the video, I found that this seesaw had a main issue with the timeline, after the timeline has player it proceeds to launch the player in the air. As this was only a test blueprint and a rough idea. We later decided not to continue with this actor as we had better ideas that we all felt were better to include.

Spikes: These are the spikes. This actor only consists of a spike mesh in the viewport as I had decided to just reuse some code Issac had made for the Danger Zone from a previous blog post. This would mean more development time on level design which was a key part for this game.

For the code, The player overlaps a hit condition which will destroy the player character. After a delay, the player character then spawns back into the level after getting the current level and opening it again.

Outcome: This outcome works really well. The player rolls up to the spikes and is killed on Hit. They then respawn in the same map and can proceed to carry on in game again. This loop works really well. The only critique I have for it is that it always spawn the player back at the start whilst resetting the level. It would be good to get a world location of the spikes and spawn the player at the start of the level sequence they were on. This would otherwise be seen as a bit frustrating for the player.

Anti Gravity: This was another one of my designs. I thought the ball could use a bit of zero gravity in order to gain enough momentum to land in high places. This is why I created this actor. The viewport contained a simple cube that had no blocking physics. This meant the cube was completely passable and this acted as the zero gravity zone.

In the coding, when the player overlaps the cube, it checks the gravity scale of the character movement and set it to 0. As extra buffer there is a set enable gravity node which is set to false. This allows this area for the ball to be controlled in Zero gravity. Once the overlap ends, Gravity is restored and the player has default movement.

Outcome: In this video, the player

Button:

Spring Pad Tweaking:

Initial Tracks imported: When Adam finished the basic track designs in Blender as shown below, I received the file and imported the into Unreal. Each track asset varied from straights, corners, Uphill and downhills etc... There were also some unique pieces like like spirals that lead to the middle to start momentum sequences on the tracks.

Collision Settings: The next stage was going through each Mesh and setting the collision. The main thing that needed changing was the collision complexity which basically sets the quality of the collision. This was set to complex as simple which helps to prioritise the better quality collision. This would help the ball to fit in all track pieces and roll along them with no errors.

I now need to place these into a test world so I can understand the right scale and test potential layouts for use in levels to come.

Interactable Actors Imported: The next set of meshes imported would be all the interactable actors. The interactable actors would be extra actors around each level that will either help or hinder the player depending on momentum. They include Fans, Springs Pads, Seesaws, Spikes, Bumpers, Buttons. There were also some Arcade themed objects such as: Pinball Flippers, Bowling Pins, cannons etc...

Track Testing: The first thing I tried to do was sort out the in game scale of the track pieces. The first image below shows thew majority of the key pieces of track that I wanted to use. I found that scaling them to 0.15 fit the ball perfectly as shown in the bottom image when playtesting a piece of track. The is able to roll nicely down the middle with barriers either side to avoid the player falling out on most pieces. The collision made also allows the ball to move smoothly without error.

Issac's Created Asset Testing: This clip shows me playtesting the actors made so far by Issac. When making the actor, Issac and I split the asset creation in two to even the workload. Issac so far has managed to make a fan, spring pad, Breakable Glass & a Danger Zone as well as the ball controlled by the player. These are great asset creations that I can now work off of and begin making my end of the assets. In terms of improvements, The Spring Pad could maybe have different angles so the ball can be directed to more than one place.

Risk Assessment: This is a risk assessment table. It covers everything that could go wrong in terms of slowing down our development time. With all of the types of risk listed in the image below, we all decided the likelihood, impact, priority etc..

Team Meeting Week 3:

Art/Visual Theming:

The selection of themes: 

Toy (Voted by Isaac & Finley) 

Arcade (Voted by Isaac, Finley & Adam) 

Adventure 

Space (Voted by Finley & Adam) 

Endless Sky 

The chosen theme with the most votes was “Arcade”.

One thing that we did once assigning roles was make what is called a project board. This keeps track of what needed to be completed for our game idea. In the image below, there are three sections of To Do, Doing & Done. Each of these have lists of what each of us are focusing on with our names being highlighted on each design.

Team Meeting Week 2:

One Page Design

Gameplay 

The player controls a moveable ball which can be manipulated via gravity, momentum and movement controls. Movement of the ball isn’t directly controlled by the player but rather manipulated by them with standard movement controls. 

Mechanics 

Increasing Momentum – The ball can be affected by an increase in momentum to achieve jumps in levels. If the momentum is too high, the ball can become harder to control. 

Collision – With enough momentum the ball can be used to destroy walls or objects to progress through a level. 

Ice – The ball can lose grip on certain surfaces which would affect how well it can be controlled. 

Wind – Wind can push against the ball to make it harder to reach certain areas in the level. 

Different/Inverted Gravity – Certain areas on the map can have different or inverted gravity which would alter the way the ball’s movement behaved. 

Objective 

Complete levels by reaching end and / or collecting items. After beating a level, the player progresses to the next level with the same / similar objectives. 

Visual Design 

3D with the camera is in an isometric plane and follows the player ball. The game features a minimalist art style, taking inspiration from the marble run toys while also making it easier for the player to see different mechanics and where their ball is. 

Sound / Music 

Basic sound effects for UI and ball (clicking, rolling, crashing, etc). The levels will not include any backing music. 

Levels / Environment 

Levels belong in chapters, each one having a different theme. These levels are detailed with appropriate objects and structures according to its theme. 

Chapters will introduce new mechanics in their levels. 

Management Strategy 

Team Meeting Week 1: 

Moving ball 

Simple premise can be expanded very far into a full game. Potential for level modifiers such as different gravity, inverted gravity. Easy to develop maps for. 

Burning house 

Simple concept that would be easy to develop, the map design in a topdown format would be easy. Would encourage the player to play and replay levels due to a scoring system. 

Unicycle 

More complex initial mechanic, although it can’t be developed so far as map design would have to be fairly simple. Finley already has experience in a similar game idea. 

Initial Ideas 

Adam’s 

Burning house, steal items 

Fire spread mechanic 

Timer for how long you have 

Oxygen metre 

Large items reduce movement but are more valuable 

2D Top down, potentially 3D 

Parkour game, explode if you go slow  

Timer starts once below a certain speed/velocity 

Standard parkour layout 

First person 

Trade controls for abilities 

Start with basic controls 

After certain number of waves, option to swap keybind for an ability 

After a boss fight, you can gain an additional keybind option 

First person 

Finley’s 

Moving ball, physics 

Player controls a ball with WASD, which can make it roll 

Potentially, grab ball with mouse to move it 

Physics based and gravity determines the way it moves, with enough momentum you can’t stop it 

Break walls with momentum 

Different gravity modifiers on maps 

Horror game where you can’t breathe 

Microphone listening to breathing 

If you are too loud it gives clues to an AI that could find you 

Certain puzzles require noise 

Isaac’s 

Unicycle, balance with mouse 

WASD controls movement 

Going round corners means you start tilting 

Use mouse controls to counteract tilting 

Could be an endless runner 

If you fall over then its game over 

Bird flight game 

3D flappy bird 

The final Idea: The idea that we all decided on was the moving ball game. We felt that this could be expanded on the best and built in the time given. We were also able to allocate 3 roles:

Issac: Coding

Finley: Level Design and Structure