By 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!
All Rights Reserved. Designed & Developed by Studio 316