Milestone Complete

As the title and subtitle of this blog might suggest, we passed a milestone, the first milestone for Tip Top Table Tennis! 

The first milestone was 1 month into development, and the requirements for this milestone were simply “First playable proof of concept”…and that is all. There were some other details, mainly around final decisions on visual style of the game, but the main meat of this checkpoint was the proof of concept playable. 

So this entry in the series is going to talk about just that. The first playable and what was included in that build, how we got there and we will of course give you some behind the scenes on what that actually looked like. 

Also we want to talk a little bit about what we have set up internally and the processes we use in order to deliver these milestones to the publisher. We feel it could be valuable to any other new studios or even those outside of game dev, who are looking for insight on build delivery and other aspects of those pipelines. 

Proving the Concept

Before you continue on a 6-8 month development journey creating a game, you first need to find out whether the game you intend to create is something that works, feels good and can even be done. 

We are in a lucky position as mentioned before, in that our game is already made and the rules determined. So in this instance, we are not validating the concept of Table Tennis as a sporting game, but the implementation of systems that replicate them. 

We already know that table tennis is fun for the right audience, more importantly for us, we need to quickly find out whether table tennis replicated with motion controls on the switch is something that is fun, feels good and engaging, as well as if it is technically possible. 

As we set out and started prototyping after having done some initial experiments, we wanted to focus on 3 main systems for the first milestone which we felt even in a rudimentary state, could provide a solid representation of what the game could be. Those were: Ball Physics(not those balls you naughty nelly), Shot mechanics and Paddle representation.

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.

Bringing it together 

All on their lonesomes, these systems won’t mean much, so we of course had to bring them together into a level where we could test how it all works together. Once all said and done and the set was complete, this is what the proof of concept looked like: 

And that was that, first milestone complete. Now we just have to make the rest of the game…

See you in the next one!

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top