In 2001, the Nintendo GameCube launched as a successor to Nintendo’s N64. The system had two goals, one for its users and one for its developers: the first was to deliver a moderately priced console that ran at a moderate speed and the second was to have a console that was easy to develop on and speed up dev times. On this console, many staple franchises debuted, including Luigi’s Mansion, Animal Crossing, and Metroid Prime. The console’s run concluded in 2007 with a total of 651 games for players to choose from.
Or that’s at least what we thought. Tommy, a developer from Japan, has been working to bring this console out of retirement by creating a development kit that lets people build their own games on the system. Today, we’ve brought Tommy on to talk to us about his GameCube SDK!
Hello! Can you tell us who you are and a little about yourself?
Hi! My name is Tommy. I was born in Germany and now live in Japan.
I started programming at the age of 9. At that time, I started with BASIC while slowly changing to C/C++.
Like many other fellow developers, I was obsessed with creating my very own games. I was born in the early 90s, so I grew up during the transition from 2D to 3D games, and that shift had a huge impact on me.
When I was 12, I got into 3dsMax 7, which was still developed by Discreet back then. I remember waking up at 4 in the morning just so I could spend a few hours before school to play around with it. I was like a sponge, trying to absorb as much knowledge as possible. School quickly started to become boring, as I discovered tools like: “UnrealEd” (later UDK, UE4), “HammerEditor,” and most importantly “A7-Engine”. I spent my pocket money to buy train tickets so I could attend various 3D conventions. I still remember that one event in Frankfurt where I won the first prize: a 900$ VRay license, which I’m still using to this day.
School and University felt like the biggest waste of time. I already knew what I wanted to do with my life. I sometimes regret that I hadn’t started my career earlier. But in 2014, while still in university, I finally founded my own company, which deals with the development of game tools and frameworks.
I still have the same curiosity and drive from my childhood. I still collect and read CG papers, and I still try to bring all those ideas in my head to life. Programming and development has never been just a job for me. It is both my hobby and my professional passion.
So you’re developing an SDK for the GameCube, a console from 2001! What made you want to begin this journey?
GCubeSDK is only the tip of the iceberg. Before I started working on it, I had already spent years building smaller tools around the GameCube, like BMDBuddy (a project that is still in progress by the way).
I’m also not building this from nothing. GCubeSDK stands on top of devkitPPC, libogc, and decades of research from the GameCube and Wii homebrew community. Contributors from projects like Dolphin, YAGCD and DevkitPro are the wells I draw from.
I’ve also spent a lot of time rewriting the documentation from the PowerPC Gekko so I could use it as a personal reference. Understanding the hardware and learning about the ideas engineers came up with to deal with limited resources is pretty rewarding.
At some point, I had the idea to put all that research into a framework so I could develop games on my own. It all started with the videos from James Lambert, who is constantly documenting his progress of Portal64 (A clone of Portal for the N64). The Nintendo 64 homebrew community is pretty active and has great toolchains, which are much more user-friendly in general.
The tools that exists for the GameCube though are more suited for small game jams, and tech demos, but I wanted something more modern, but not as bloated as Unity, UE4 and Co. Something that is more similar to the A7/8-Engine.
The framework that I personally use the most is three.js. I really like the class structure! It was actually one of the reasons I decided to design GCubeSDK in C++ instead of plain C. Over time, I became more confident that I could implement a similar structure and scope. I started with Object3d and BufferGeometry and slowly worked my way through the online documentation.
Right now, what has been your biggest challenge so far? I know support for it has been dropped awhile ago, so you’ve been working without official support to make the engine come to life. It’s really impressive.
The biggest challenge so far has definitely been getting skinned meshes from gltf working. There is so much struggle happening behind the scenes that I usually don’t write about in my devlog. But I think that whole animation system gave me the biggest headaches so far. The SkinnedMesh class wouldn’t have made much sense without having a way to somehow import an exported animated model from Blender, Max, or Maya. So, I had to write the GLTFLoader class first before anything else.
For that, all my thanks goes to Johannes Kuhlmann, because I could fork from his project cgltf, even though I had to rewrite it from LittleEndian into BigEndian to make it compatible with the GameCube.
After that, I could finally focus on Bones, Skinning, Animation-Actions, Clips, and Mixer. The actual implementation swallowed so much time. And when I could finally import my first animated GLTF model, I got trouble making it run at 60 FPS.
A lot of time was wasted by performance bottlenecks and hardware limitations. Importing static OBJ files is simply not pretty useful for actual games. That is why I had to spend so much time on making the animation system work. With the animated SkinnedMesh support in place, it felt like the hardest part was behind me.
Now that we’ve talked about challenges, what’s been your favorite part so far of building this engine. I feel like it would be rewarding to see everything working.
One of my favorite parts has actually been the documentation.
I have this very strict habit of keeping my code very clean: vertical alignment, 4-space tab indentation, enough whitespace, and most importantly: inline comment blocks. Those comment blocks will be used to generate the documentation. Having clear and concise documentation is half the rent. At some point, I wrote a small internal tool just to generate the GCubeSDK documentation.
Over time, I have continued to improve this tool and have transformed it into a standalone program, which is now just about to be released.
Since I’m a big fan of the three.js documentation, some people will probably notice some similarity there. I really like how easy it is to browse, how quickly you can jump between classes while keeping a minimalistic style that doesn’t stress your eyes.
I kinda enjoy how GCubeSDK is slowly completing: the code, the examples, the documentation, the structure. That part is the most rewarding to me.
Do you think modern games are becoming too bloated with special features and graphics, and do you think a more retro approach is something the industry needs right now?
My first instinct would be to agree with that. Yes, I get a bit irritated about those big AAA-Studios and Publishers who recycle the same formula. Call of Duty 22, Battlefield 14, but now with slightly better graphics. Maybe it is just my personal perception, but sometimes I wonder whether games are gradually losing their soul.
But if we talk about “modern” games, one has to consider the whole spectrum. And that includes not only AAA Developers and Publishers, but also small indie developers. These days, there are way too many games. You can’t see the forest for the trees! But among them are real hidden gems. But how was it back in the 90s?
If you take a look at the Nintendo 64 catalog, for example, there were only a few hundred games released for the system over the years. And after personally playing every single title for the N64 I can say one thing for certain: a huge part of them were either trash or mediocre at very best. The games that are still remembered today usually got very strong publisher support, clear creative direction, and very talented programmers. A game was a much bigger risk. Physical cartridges had to be manufactured, boxed, shipped, and marketed. Publishers had to be very selective and careful.
The problem lies in perception. Your new favorite game is out there! You haven’t found it yet. Small developers from around the world usually don’t have the budget and expertise to compete in marketing, let’s keep that in mind.
Do you have any plans to develop your own set of games for the console using these tools?
I do actually! To build an actual game alongside the development of the framework is the best proof of concept. All those features need to hold up in a real project, not just in tech demos.
There is already a prototype that I made years ago. And all those assets are ready to be recycled. Skinned and rigged models are slowly collecting dust on my hard drive. I would really like to bring it back to life.
Favorite GameCube game?
I think this is one of the hardest questions to ask any gamer. Giving an answer feels like it would betray all the other titles that I also dearly love. But if I am forced to choose, then it would be “The Legend of Zelda – Twilight Princess”.
For people who already follow my other content, probably won’t be surprised, since I’ve been reverse engineering this game for more than 9 years^^. LordNed’s Winditor gave me the foundation that I needed back then. Since then, a lot has happened.
I think what I like the most about “Twilight Princess” and also about “Ocarina of Time” is the Tolkien-inspired world. This mix of Norse and Japanese mythology is what got people subconsciously hooked, I think.
What’s some advice you would give people about making games and engines?
Keep it simple, Keep it small!
Setting the right scope without falling into the feature creep pit is one of the hardest challenges in designing any kind of software. I know that you might feel the urge to create that next “OpenWorldSurvivalMMORPG”, but instead of eating the whole pie, just take a tiny slice. The last 10% of a polished Project is where the real struggle begins.
Reduce the scope until it almost feels too small. Cut away all non-core features. Give yourself a month or two at most to build a usable prototype that demonstrates the essence of that project. From there, it is polishing only! make it stable, make it presentable, let internal people try it, and use their feedback to improve it.
Keeping your code extremely clean and provide a documentation, not only for other people, but for your future self. You should be able to revisit a project after a long time and continue where you left off with no problem. Even if you have forgotten 90% of the details, the structure, naming, and documentation should help you to get right back at work.
Connect Today!
Tommy has chosen a great time to launch this SDK as we approach the 20th anniversary of the GameCube’s final title, launched in 2007. I myself have been looking forward to seeing how this kit works and am already thinking about trying a few new games on my Retroid device. You can keep an eye on Tommy’s development on the GCubeSDK website or on his X!
Leave a Reply