The First Playable

Ball Physics

Ball gets hit by a paddle, ball flies to the other side of the table. Simple right?

Whilst down the line, we know we would be implementing some custom physics in order to get as much control over the ball’s flight as possible, initially, we needed just a simple solution to allow players to bat a ball around with at least some semblance of real life. 

Unreal’s built in projectile components provided us with just that, allowing us to quickly create a projectile we could use as the ball, with all the built in physics we needed to start with. 

The projectile system inside Unreal allowed us to use motion controls to hit a ball back and forth in splitscreen fairly quickly, which is great right? Well, sort of. We very quickly found that the projectile system was quite limited.

Jamie, our Art Director and Unreal Engine generalist continued to experiment in Blueprints with the projectile system to see how far we could go with it. On its own the projectile system had no ‘bounce’ function, so you would therefore need to get the last hit location of each projectile calculation and create a new calculation from that hit. You can see how this can get very tedious.

Thankfully ping pong balls can only bounce a maximum of two times, so we did not need to worry about using a for loop on these projectile nodes for the prototype! What was great is that the projectile calculation could tell us where the ball would be at any given time, meaning we could position the paddle in that location to test our late and early shots! There were some more calculations for adjusting velocity and ball curve based on it’s distance from the table and height, however these were not particularly complex.

The built in projectile system had brought us a long way, and allowed us to get something working quickly that was relatively entertaining, but after playing it a few times the novelty had worn off. We needed some sort of control over the ball, both with direction, spin and maybe power. We had to think about shot mechanics…

Shot Mechanics

The lengthiest discussions and experiments for this initial playable were spent answering the questions, “What determines if the user has swung to hit the ball? Is it forehand or backhand? Which way does the ball go and based on what?”

To be honest, at first, we just didn’t have answers to any of these questions, especially during planning phases where we had to guesstimate what features would look like. Given this was our first interaction with the Nintendo Switch and Joycons, all we could do was start getting as much data back from the controllers as possible to see what was happening as we made a swing. 

There was lots of guess work and just trying things to see what they did during this first month period. As is with many other elements of working with the Nintendo Switch, we can’t really go into detail here around the implementation. But we started by tracking the motion of the joycons over a number of frames, using the data to infer what kind of shot the user is making and then determining a position on the opposite side of the table for the ball to hit. 

Accumulating data like this allowed us to create a fuller picture of what the player was doing, we previously had issues where deceleration would trigger a shot as opposed to acceleration within the gyroscope as the user may swing back before swinging forward for a hit, this is standard in any gyro you would find on the market but did present a challenge. Because often a user would swing back quickly but for a shot period of time triggering a hit, to add to this problem, this hit would be the opposite of the desired hit. For example, a forehand would end up being detected as a backhand, and vice versa.

When using accumulation we are able to better flatten these outliers and inconsistencies with the users movement, instead of tracking frame by frame data, we can gather data over many frames to see how the user is swinging and the magnitude of that swing far more accurately.

Throughout the prototyping phase we played with many different values & methods. If you are interested in using motion data in Unreal Engine, the node ‘Get Input Motion State’ is extremely useful, targeting the player controller. Initially we attempted to get the users exact rotation to determine shot trajectory, however this proved quite challenging, as the way players would swing could be quite unpredictable in many ways. Often, players would flick their wrist towards the end of the shot and the rotation is then thrown off.

Another method we tried was gathering data over a given number of frames, then when a shot is triggered, look forwards and backwards a given number of frames and look at the difference between the start and end of a shot. We could then use acceleration to determine if this was a backhand or forehand shot. This gives us a fairly accurate understanding of the direction of both the forehand and backhand shots.

Paddle Representation 

On top of having the ball behave as you’d expect and also having basic motion controlled shot mechanics, we knew that we wanted to have a paddle on screen to represent each user and have this paddle move around with your motion. 

Even in initial playables, it’s important, or at least we feel it is, that the game is readable. So being able to see your paddle and have it replicate your movement was something we felt was key to the first proof of concept. 

We had already done some initial experiments on this kind of thing in the first weeks of development, you can see what that looked like in our previous blog entry, but we needed to expand on that for the first playable.

After some more improvement to those systems we were able to get something together that worked quite well for the first playable.