Month: March 2024
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!

It is pronounced “Three-Sixteen”

Site

Contact

All Rights Reserved. Designed & Developed by Studio 316

Scroll to top