Tip Top Table Tennis

Tip Top Visuals

For Tip Top Table Tennis, we wanted Tip Top Visuals…so lets talk about what we have done to get Tip Top looking Tip Top 

Settling on art style
From the outset, we had some guidance from the publisher on what they wanted the title to look like, which was leaning more towards a realistic art style. At first, we were on the other side of the fence, feeling like the game could look great utilising a playful stylized art style referencing the classic wii sports resort.

In the end, we realised that the decision was somewhat out of our hands, because with the time constraints and budget of the title, we were required to use asset packs to create the environments. Which means we are now at the mercy of the availability of assets on the store that match the style we wanted to aim for.

With that in mind, the main thing for us was consistency. We wanted to ensure we could create multiple levels that all match in art style, preferably these environments would also be created by the same studio, and so we got to searching the asset store.

After a solid few days deliberating and searching for the right packs, we settled on a studio called Dekogon, who have an expansive library of environments all matching in quality and style, perfect for what we need and so the decision was made for us. Realistic art style it is! 

From a technical perspective, these packs were also very well put together and even for going onto switch they required very little work to be performance compatible at 60fps, so props go to the Dekogon team for creating these awesome packs. 

Since we are getting closer to release, and i’m sure you are all just itching to get a sneaky peek at what the game is going to look like, here are some nice in game screenshots for you 🙂

With great visuals, comes great expectation

Visuals instead of power, expectation instead of responsibility. And yet the responsibility is still on us to make sure that, alongside the high fidelity graphics of the title, we provide gameplay that is also representative of that. 

Possibly more significant for sports games but with the realistic environments and art style of the game, a perception is made by the user, potentially even unconsciously that the gameplay would also be a realistic representation of the sport.

So what we have done by choosing to implement this realistic art style, is restricted the gameplay somewhat to being something that matches somewhat with the realism of those graphics. So this is something that we needed to consider carefully as we moved forwards with the title.

Something about UI

For our game’s UI style, we wanted something that included elements of table tennis iconography. At first, we considered achieving this by having all of our menus rendered in world space on top of table tennis tables and paddles. While we felt like this style had a lot of potential, we ultimately decided against doing this due to how long it would take to implement new menus and elements. We were also concerned with the readability and localisation problems that this could cause, since it’d be harder to fit potentially longer text in boxes and ensure that it’s readable.

Even though we couldn’t use our original idea of using a world space UI system, we still wanted to include table tennis iconography. In the end, we decided we wanted to incorporate a halftone effect reminiscent of the pip pattern on table tennis paddles

With this in mind, we went back to the drawing board (literally) and made several mockups for UI designs that could utilise this pattern in some way.

While bringing these mockups to life, we took inspiration from the family friendly vibe of the Wii Sports series, and experimented with a style full of bright colours, round edges and shiny buttons.

We enjoyed the overall aesthetic that the designs were conveying, but we felt like it looked too childish, so we ended up adding diagonal lines to the buttons and adding grey to the colour scheme, as well as changing the font to a more geometric one. We also ended up replacing the shiny effect with the halftone effect that we wanted to add.

So that concludes this little blog about how we went about some of our design processes for the visuals and interfaces for the game. The next entry we plan to talk about taking the game into BETA and what the iterative process to get their looked like.

See you dreckly!

The First Playable

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!

Jostling with Joy-Cons

Now, we have to be careful about how much we share with you in these blogs, as we don’t want the heavy forehand swing of Nintendo spanking us across our backside, but we will be doing our best to let you in on as much of the development as we can. Starting with our first experiments…the Joycons. 

Joycons, Gyros and Accelerometers…
The obvious main feature of the game, is the use of the Joycons as your paddle, utilising motions control in the form of Gyros + Accelerometers in order to replicate as close as possible, the real life action of swinging a table tennis paddle around. 

So our first stop along this development journey was to Joycon town, where we took a look at getting an on screen Joycon, to move in the same way you move it in your hand in real life.

Jamie was taking a stab at this to start with, exposing the data we get from the internals of the controller and starting to implement solutions for using that data to transform the position and rotations of the on screen controller.

That looked a little bit like this to start with…

(apologies for poor video quality, recording from the dev kit isnt always smooth)

For our first go at this, we were quite excited to see this all working, albeit with some hitches and improvements to make. Eventually, we go on to get rotation on all axis’ working nicely and although there are some inherent bugs that we have to deal with like the values flipping to their opposites at certain points in rotation, we managed to get this transferred onto a paddle quite nicely! 

As we soon came to learn though, it is actually VERY tough to get this iterated into a position where you can actually swing your Joy-Con around and replicate that exactly in game space. There are all sorts of complexities with quaternions, controller states (there is 9 of them!) and a bunch of other niche technicals that go right over my head, but not the head of our head programmer Ashley.

We also started looking at how we can determine when a user has swung so we can hit the ball across the table. The initial obvious solution was to have a threshold, which when the accelerometer reads a value above, the user has swung and the ball is hit.

This worked well for an initial experiment of firing balls around a debug level.

Obviously this isn’t quite up to scratch for even a prototype of a game, so over a few iterations, we managed to get a nice simple prototype working where two users could bat a ball at each other.

Even though quite rudimentary, just being able to play a little prototype of our little table tennis game, built out onto the dev kits, using motion controls to hit the ball. It was all very cool indeed. After such a rocky start getting the project set up, it was nice to get a first proto together so quickly.

Interacting with Dev Kits
I don’t intend to share too many details around this, but it’s worth a small section to talk about what our first experience was like working with the tech.

The Dev kits are great, and it’s been quite cool seeing our work get built out and played on the console. The set up with them is quite simple so unlike our project set up, this was much easier to get going.

We have been dealing with an issue where the Joycons won’t connect to Unreal, so we can’t actually test with Joycons in the engine editor play windows. We’ve had to build out the dev kit each time we wanted to test. So that has slowed us down a bit, but generally we’ve had a good first experience working with the Nintendo Switch dev kits. 

The level of debug information available is also amazing, we’ve been able to easily see where our game sits in a performance capacity as well as getting logs for all the nasty bugs and crashes.

That’s all you funky folks get today, we have more on the first playable for you next time round!

Reality Checks

Starting Our Development Engines

As with most game projects, we started with some planning. We got together in person, sat around a table, and started talking. Now, we do plan to go into a bit more detail on our planning process throughout this series, but for now this will be a short piece that covers some of the main points we had to consider during our kick off planning.

Officially, the project commenced in early September and with the Gold Master milestone being in April 2024, we realistically only had about 6 months to take this game from words on paper, to a fully functional release candidate that is ready to be boxed up. Scary stuff!

This timeframe has and continues to dictate every decision made about anything that is going into the game and contributing to its scope. 

Core Mechanics
We understood that for this table tennis game to work and be fun, it needs to feel like you’re playing table tennis. It needs to feel satisfying with a strong sense of control over direction, letting the user play with intent.

A big challenge for us was experimenting initially and finding ways of using the Joycon motion controls to replicate the action of playing table tennis in a way that feels genuine.

Our primary focus as we started the project were just milestones 1 and 2. Which were simply, the initial Proof of Concept and a Second Playable. No bells, no whistles, just hitting a ball back and forth across a table using the joycons. 

This way, we gave ourselves a nice chunk of time in which to experiment with how the joycons work, how we can utilise the motion data and iteratively develop those core systems that represent the act of playing table tennis. More on this in a later blog!

Everything Else
The rules of our game are predetermined which makes it slightly easier for us and we know that we are using the Joycons as motion controllers to play the game.

We were in a position where we had to decide how we wanted our game to look, function and behave around those rules. We still have a level of creative freedom here, game modes, visual style, progression, customisation, UI… The list goes on. So while the rules are determined, there is still lots for us to consider and design for.

While we discussed and planned for everything that came afterwards, they were high-level discussions, we noted down the ideas that we felt were strongest for the final release candidate and then returned focus towards the proof of concept. We were comfortable leaving those lengthy design discussions till after we knew our position with the core functionality of the game. More is coming on all this design another time!


Dun dun dunnnn…

As I mentioned in the first blog entry in the series, starting to work on a game with a publisher, really cemented the level that the team is now working at. What is expected of us is continuously increasing. This is only further reinforced when we read the details of THE ARCHIVE. *you have to say that imagining a big dark cloud in the sky with thunderous cracks of lighting as a dark, looming voice rings out “the archive”.

Put simply, The Archive is everything about or for the game, ever, in every format it’s ever used in, documented and notarised in a way that allows the publisher to recreate the game from scratch using that Archive if they wanted to.

It certainly has a lot more detail and legal mumbo jumbo in the actual documented agreement, but on a high level, all assets, concepts, documents, code and its comments, system documentation, animations, build process documents, builds…the whole shebang, needs to be included in the archive in all potential formats. This Archive is then submitted with each milestone delivery.

Being this was our first encounter working with a publisher, this is something that took our project management and organisation to a new level and I wanted to share what The Archive is and requires to any other new teams who may not have experienced this or similar yet.

This was a main topic during our kick off meeting for the game, discussing the requirements, how best we can uphold them and what processes we need to put in place to ensure the Archive was kept up to date seamlessly as we work.

We ended up creating a small tool that allowed all of our team to easily add files of any kind so a secure cloud storage as well as view the entire file structure and hierarchy. As we make additions and updates to the game, we also upload all the necessary additions to the archive alongside it.

The Archive sounded pretty scary at first, and to a team with little experience with such a low level organisational process for a game title, we took it incredibly seriously. In reality, if you keep your projects well organised and document everything well, this should be easy enough to keep on top of. 

Let's Talk Tip Top..

We had very little expectation going into working on a Nintendo Switch title for the first time. We knew there would be a learning curve and expected some struggles initially but it really felt like quite the operation in the first two weeks.

It took us about 11 full developer days just to get the unreal engine project set up correctly and ready to start working on first playables. This doesn’t mean to say everyone else will have the same experience. It probably doesn’t help that we are working on a very recent version of Unreal 5, there was plenty of documentation for Unreal 4 but Unreal 5 had just a couple of things that were slightly different and we had to figure those parts out alone.

We spent a good chunk of time using trial and error and using output logs to find the source of issues. Once we had gotten the process sussed out, we created our own detailed documentation to keep the entire team in the loop. We even shared this documentation on the official forums in the restricted Switch Development section. There are plenty of useful posts in there that helped us get going. 

Getting set up with Nintendo Switch development was a bit of a reality check. Already 2 weeks behind where we wanted to be and realising that there will likely be more of these struggles as we continue. We had to take a hard look at project scope and what was viable for us. Set up isn’t the only consideration though and once we had gotten the SDK all set up correctly, we had to turn our attention to the other major requirements for the Switch Platform. Such as Patch size requirements, storage use limits, save data file limits and many more such requirements that need to be met for Nintendo to approve your title. 

There was lots for us to consider as we started the project and we had to learn at a swift pace. This is our first time doing this after all, so we should cut ourselves some slack.

While this was a frustrating start to the process of developing this game, all the exciting stuff comes after we got through this set up, getting playables out onto the dev kits for the first time and testing our first versions of the game! But you’ll have to read the upcoming blogs to hear more about all that 😉 

The next entry in the series has some juicy behind the scenes of some of our first playables and experiments, so we shall see you then!

Many Firsts, The First of Many

Exciting news!

We are buzzing with energy and beside ourselves to be able to announce that we are working with Excalibur Games on an upcoming title for Nintendo Switch called Tip Top Table Tennis!

And yep… you guessed it! It’s a table tennis game!

This is going to be the first of many upcoming blog posts in which we will be discussing the many firsts we’ve encountered on this game development journey. Working with a publisher, developing for Nintendo Switch, releasing a title as co-developers, among many other aspects of developing this title, are firsts for our team, hopefully soon to be the firsts of many.

This puts us in a unique position to share our experiences with others who, like us, had no clue what to expect when going to work with a publisher on a full release for the first time. We want to use this opportunity to lift the veil somewhat on this process and also let you in one some behind the scenes action of what has gone into the creation of Tip Top Table Tennis. 

During smaller university projects (Pre Studio 316), its was certainly thrown around a lot in team conversations after lectures on the topic and i’d hear team members say “yeah lets iterate on that” or “We can iterate on it later” but it felt for the most part that it was said with somewhat empty meaning.

In part maybe because I didn’t quite understand how to effectively use the principals or even the concept itself fully at this point, but also because we probably just weren’t doing it right.

It was only really going into the final year with the current studio 316 team that I started to get a solid grasp on the iterative process within games and now I feel I am starting to apply those principals outside of games too, like with the studio website.

Getting the Gig

Getting the Gig

Obviously no bit of work comes in without…work, and Tip Top was no different. Admittedly, this was one of our easier work acquisitions and it came about and got greenlighted in a short period of time. So I feel somewhat like one of those “it’s easy to buy a house, just get your rich dad to give you a deposit!” kind of articles.

There was also some amount of Luck involved in bagging the gig, but not the blind luck kind of thing like being born into a 1st world country with a dad rich enough to pay your first house deposit. My perspective on luck is that, it’s opportunities that you create yourself, but I couldn’t create Steve Stopps from Excalibur showing up to lead an incubator we were involved with, so some things just need to align for you like that sometimes.

The truth is that ALL of the work we have done over the last 2 years, is what made this sale for us. All the time spent talking with Steve about our business, showing him our progress, actually making that progress with our client projects and displaying our ability to perform as a development team and ultimately, becoming what i would consider to be friends over that time, put us in a position to capitalise on the luck (opportunity) that came our way.

It is also important to recognise that people often do business with their friends. Building that relationship was just as important as building our client projects to show what we could produce.

The process was really quite simple, Steve mentioned in a meeting for an entirely different topic, that he thinks there might be a spot for a table tennis game on switch, and his boss might be up for it. Gave us a budget and timeline, and asked us to come back if we thought we could do something.

3 days later, we went back to him, with basically no more than “We think we can do that!” and in every other circumstance, i would recommend preparing a proper proposal detailing how you plan to do that but the existing relationship made it easier to get the vote of confidence.

Let's Talk Tip Top..

So, aside from the obvious, let’s talk about Tip Top Table Tennis and what you can all expect from the game.

Tip Top aims to be an engaging local multiplayer table tennis experience for Nintendo Switch, that utilises a physical peripheral and the Joycon motion controls to provide an enjoyable immersive experience. The game will make use of a realistic art style, whilst also exerting playful and stylized undertones for SFX, User Interface and Music. 

The game will feature multiple game modes, some allowing for up to 4 local players to play simultaneously and we intend for Tip Top to be an accurate but fun representation of a classic table sport that most can relate to.

We really cannot wait to share more about the game but that’s all you get for now 🙂

Coming up next…

Right… Now the cat is out of the bag and you’ve heard a bit about how this came to be, we can tell you what to expect from this little dev blog series leading up to the release of our first title, Tip Top Table Tennis.  (Bold coz it’s still hard to believe.)

You can expect a new one of these blogs every couple of weeks, up to and beyond the release of the game, in a very similar format to this first entry. We will be hand picking a few key topics that we have lots to say about for each blog, covering what we’ve experienced, development struggles, surprises, behind the scenes, early iterations of the game and how it progresses to its release.

We hope that everyone who reads these is able to find insight into all of the topics we decide to speak on, our main motivation with this series is to give other small studios and business leaders like us, an insight into what these kind of development processes are like and the experience of developing for consoles for the first time, for a publisher for the first time, for a game that will be a first release with full credits.

See you dreckly

Scroll to top