Kid Tripp Nintendo Switch Development Blog

Phase 6

The end is in sight

Phase 6 appears to be relatively simple now, the game is running without audio but for some reason saved data does not seem to be working despite me having written the Switch implementation of the nagFile object already and had it pass all the tests. I decide to sort this out before looking at the audio.

Time to learn about Test Coverage. This is a measurement of how much of your code your tests actually cover. Some development environments offer code to actually calculate this for you as a percentage to help encourage you to increase your coverage. Some people would say that 100% coverage is your goal, others would say that there is always some code that there is no point covering. In nagEngine, it would have helped me if I'd actually covered the writing to files in my tests. I had not, and it turns out that the Switch libraries don't handle opening files for writing in the same way as other systems. It didn't take too long to fix, but I'm going to have to change the way all versions of the engine deal with save data just for the one platform, something you usually want to avoid.

Audio

Using my Sherlock Holmes like skills of detection, I find some sample demo code with names that start with "Audio" and set to looking for one which provides the functionality I need - playing music which may or may not loop and playing multiple sound effects at arbitrary lines - then mess about with it a little to understand how it works with a view to then pulling the required lines of code into the engine. It'll look a little messy and the code formatting and naming conventions won't match the rest of the engine, but I can always change them later when it is fully working and I'm happy with it.

Only it turns out this code is quite huge and not very understandable. This is going to be a problem. I might be able to get it working, but if I don't really understand it, I can't be sure that I'm using it correctly, for example am I shutting things down correctly when I've finished with them? Is the code leaking memory somewhere without my knowledge? Memory leaks are when you allocate memory from a buffer and never say that you are finished with it. Eventually the buffer will shrink to nothing and future allocations will fail causing a crash. I want to be confident that there are no hidden bugs in the code that will show up under odd circumstances. I've now spent 2 hours on this attempt and I'm not happy with it. Time is running out if I want to hit the target of completing this in a week.

Audio attempt 2

I decide to shelve the work I've done so far. This is a nice feature of the repository (database) in which the code is stored. One of many nice features. It lets me restore the code to an earlier state, but keep the changes safe so that if I decide to go back to them, I can do easily. When I downloaded the Switch libraries from Nintendo, I remember seeing a helper library with the same name as the Nintendo 3DS helper library that I use for playing the audio in nagEngine already, but I haven't seen this library anywhere in the installed development environment and searching for it by name in the documentation doesn't yield any results. I resort to opening up the zip files in the download cache that have the matching names to see what they contain. It soon becomes apparent that they have multiple new names on the Switch and I determine that they are installed and even better, they have their own samples that don't start with "Audio".

It soon becomes very apparent that the sample code works exactly the same way as the previous 3DS sample did although there were a couple of processes that the 3DS code handled that the sample didn't use which were necessary to get the Switch version running. The end result was that I now have audio in the Switch version of Kid Tripp! Here's another video in a tweet sent out after I got it working. This attempt only took 1h 30m, so I was very happy with that.

Final conclusions

I initially set out to see if the claims that existing games could be ported to Switch in a single week were valid, but also to provide a little context to the amount of work involved and the number of people doing that work. I put a total of just under 34 hours in to the task which is under my lowest ever contracted working week of 35 hours, so it is fair to say that it is possible to port an existing game to Switch in a week.

My attempt was certainly made easier by the fact that the engine required to run Kid Tripp doesn't have to do a whole lot of complicated stuff, and it was already in a reasonable state for the conversion. It was made more difficult by the fact there was just one person working on the task. I see these two factors cancelling out somewhat. A more complicated engine is likely to have been developed by more people and therefore have more people available for the conversion. My work could have been about 6 hours faster if the engine had been in a perfect state ready for the conversion so it should be possible to convert an engine with a few more features within the space of a week.

One final thought. Other developers have already stated that the Switch is a dream to develop for. I totally agree with this. The development tools and environment are really good and I've only scratched the surface so far. Nintendo have done a cracking job putting this together.

Thanks for reading this, I hope you've enjoyed it. If you have any questions or feedback, feel free to use the contact form on this site. If your question is about the release date for Kid Tripp on the Switch, I can answer that now: I have no idea. When I know for certain, I'll announce it.

Conversion Time

Time in this Phase: 3h 35m

Total Time: 33h 40m

Total Technical Debt Time: 6h 05m

More Pages

Overview
Phase 1
Phase 2
Phase 3
Phase 4
Phase 5