Tip Top Table Tennis
Tip Top Table Tennis

Prepping For Launch

As the title of this particular blog might suggest, the game is now on its way to launch! So now feels like a perfect time to talk about what it took for the team to get the game into a state that is ready to be shipped out onto the Nintendo Eshop and high street stores.

We are just 2 weeks away from Tip Top Table Tennis releasing digitally and we are super excited, nervous and all other kinds of feelings as we get closer and closer.

This was a first experience for the team and it certainly came with a learning curve, but we also had the support of the publishing team and their producers to assist us in getting through the various steps and checks that were required. 

QA
As with any game title, the Quality Assurance process as the game moves towards its gold master submission is where a lot of the development time was spent in the final month or so. Rightfully so as well, the QA process is the double door system that decontaminates your game from all those nasty bugs before letting it enter and mingle with all the other games on the stores.

During development we had been as mindful as possible to ensure that we weren’t creating edge cases and bugs whilst we implemented all the features of the game, but as is almost right of passage in the game dev cycle, you WILL be tormented by some strange game breaking issues that you can’t figure out, but ultimately end up being the simplest and silliest problems to solve.

An example of some of the funky foolery that we had to solve during the final stretch includes, finding that if the ball travelled over the net in a particular spot, it would hit something invisible, obviously ruining that rally. We spent about 3 days trying to sus this one out, there was nothing there in the scene, no hidden collisions, nothing. It ended up being the ball used for replays being teleported to the centre of the table, but remaining invisible. 


The QA process is never just about the bugs though! Having people external to the development team test your game gives a massive amount of insight into how readable your game is, where the fun is and what confuses the testers. Not only were we getting bug reports back from the QA team, but we also received heaps of quality of life suggestions that could improve the user experience. This assisted us in making the experience as seamless as possible and finding areas of confusion in the game that we could clear up.

Overall, we had a relatively smooth QA period and weren’t overwhelmed with too many bugs, which gave us some time to make improvements alongside them.

The Lotchecks

So, our gold submission milestone date was approaching, we had fixed all of the bugs (that we knew of), and the game was ready. Or so we thought! 

Unfortunately and ironically, you aren’t just required to develop the game when you create…your game. There is still quite the process to go through in order to get that game submitted and accepted onto any platform, the Nintendo Switch platform is no exception and is possibly one of the more stringent platforms to submit for. 

Luckily, we had the publisher to assist us with this and guide us through the process, but it started dauntingly with numerous spreadsheets each with at least 20 different specific items that needed consideration. 

As always, I am going to be very vague and nonspecific as to what these things were so as to not upset Nintendo, but these requirements ranged from things like hardware usage and save files all the way through to controller usage and warning screens. 

We had to take a good chunk of time towards the end of development to ensure we had gone through each item on these lists at least twice, checking that we had considered the requirements and implemented something for it if required. 


We had been really quite thorough with this process and we felt cautiously optimistic that we would pass submission. We were warned by Excalibur that the reality is likely to be that we don’t pass the first time. Steve, Excaliburs development director, had said in his experience very little games have passed the first time.

And of course, Steve was right. Submission number one came back about 3 days later having failed and a small list of changes needing to be made.

And of course we made those changes, which spawned more bugs that needed fixes in the second submission, and so the cycle continued until the game was stable and also fulfilled all the lotcheck guidelines.

It took us 4 submissions in the end, but I was pleasantly surprised at how quickly the game was tested and returned by Nintendo. Having the responses back in less than a week made it much faster to find the problems and get changes made in the same week we submitted them.

The Final Build(s)
The final build(s) with the “s” in parentheses because there were multiple “Final” builds.

Very much in relation to the lotcheck process, we went through the cycle of creating a final build for the game a few times. Our process did improve each time we went through creating the build which was good to see. We created a detailed build check list that encompassed everything we needed to do before sending off the zip file. 

This included a long list of in-engine tasks to complete such as, building lighting, setting up the final build settings and setting the build version, among many other things.

On Top of that, something that caught us off guard initially, was that post-build, we then had to use an authoring tool in order to add the legal metadata, icons, and a few other platform related requirements to the final build that were needed for platform submission.

So after a few failed submissions and making all the required changes, we now had our NewFinalFinal_100%Final build that was sent off and after 4 days, it came back successful and we could celebrate the game going GOLD!!

Post-Submission Blues
While we did take stock of the moment as a team, and we will certainly be getting together for launch to celebrate more, the submission of the final build and it being accepted was actually a mixed bag of feelings.

The game we’d poured so much effort into over the last 6 months was now done and ready to be shipped, which was an amazing feeling! We were, and still are, really proud of the achievement, our first commercial release as a team and first Nintendo Switch game! 

At the same time, it felt like there was a bit of a void in our work lives, something was missing. It’s not to say we didn’t have anything else happening, because we certainly had other clients and bits of work to crack on with, but it felt almost like the festival or holiday blues when you are heading home or just getting back. 

We had massively enjoyed the journey this amazing little game took us on, from start to finish it has been a real experience of problem solving, first times, design problems to solve and so many other encounters that have lead to heaps and heaps of learning for the whole team. So to see it come to an end from the development perspective was actually bitter sweet. 

Looking forward to launch, however, is a completely different box of frogs! We are excited, anxious and all inbetween to see our game out in the wild and hear what people think of it. 

2 Weeks to go! 24th May. The Countdown begins!
Tip Top Table Tennis

Your Paddle, Your Way

The Paddle Editor

Early on in the project, we decided that we wanted the game to have a sense of customisation, as well as a way to reward players for progressing through the game. We found a solution to both of these requirements with the idea of adding a paddle editor into the game.

Players will be able to edit their paddle by changing its colour, shape  and texture while also adding stickers to the paddle from an unlockable selection of stickers that can be unlocked through completing some achievements.

While we loved this idea, we quickly realised that allowing players to change the shape and texture of the paddle would take too long for us to achieve within our tight release schedule, so we ended up simplifying the system into just using the stickers and selecting the paddle’s colour from a preset list.

Editor Concept

The paddle editor’s design didn’t change much from the original design. Due to us removing the texture and model selection feature, we could simplify the UI further. We additionally decided the menu felt too crowded with both sides being on screen at once, so we added a button to flip the paddle.

So without too much more dilly dallying, here is a little video showing off the kind of customisation you can make to your paddle with the paddle editor!

The Stickers

From the beginning we wanted a wide range of stickers with a large variety of art styles. We started by searching through the Unreal Engine asset store, and while we found some that initially looked perfect, upon closer inspection they turned out to be AI generated.

We obviously didn’t want anything AI generated in our game, so we continued searching. We explored options on a range of platforms with sticker packs available, but nothing really felt like it was a direct match for the game or was up to scratch for what we wanted to do.

We briefly tried making our own pack from stickers from stock photo sites, but we were unable to find a good range of stickers in varying art styles. In the end, we decided we’d have a much better final product if we paid some cool local artists to make the stickers instead.

The Local Artists…

Part of our mission as a studio is to provide local talented individuals with opportunities to get involved with industry work wherever possible. This was no different, so when Excalibur suggested outsourcing the stickers for the work, we asked to get some artists from the Cornwall area and Falmouth University graduates to get involved. 

Excalibur were accommodating and allowed for us to choose which artist we would like to work with so we had some internal discussion and suggested some artists we all know of that we wanted to give an opportunity to.

Eventually we settled on working with the Ludophoria team and another Falmouth graduate, Jesse Hooson. 

The Ludoophoria team are an epic bunch, working on their own 2D co-operative platformer Arm of Satan. They boast a solid 2D art team who we knew we could tap into for these stickers. Jesse is a graduate artist who was warmly recommended to us through our network and had a portfolio to back it up.

Both Ludophoria and Jesse did amazing work with the stickers and we are so excited for everyone to see them all in game. 

We are getting very close to the Tip Top Table Tennis launching on the Nintendo Estore, so it’s all very exciting. Our next blog will be talking about the run up to release, and what it took to get the game passed gold master submission. See you dreckly!
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 🙂

OfficeOutroCinematic - frame at 0m2s
HighresScreenshot00004
HighresScreenshot00000
HighresScreenshot00027
HighresScreenshot00025
Previous
Next

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!
Tip Top Table Tennis

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!
Tip Top Table Tennis

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!
Tip Top Table Tennis

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.

Timeframe
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!

THE ARCHIVE

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!
Tip Top Table Tennis

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

It is pronounced “Three-Sixteen”

Site

Contact

All Rights Reserved. Designed & Developed by Studio 316

Scroll to top