Naming in Wuu Shyng

I am not embarrassed in saying that my project, Wuu Shyng, is directly inspired from and is meant to be a spiritual successor to Pokémon.

What embarrasses me is that I have yet to make names that are distinct from their inspiration.

Some things are different from the inspiration: there are no Gyms, badges, or villainous teams in Wuu Shyng. Also, while there are some combination of the Kahunas and the Elite Four (which are even called The Four Heavenly Kings in the original Japanese), the inspiration of those is actually The Four Symbols. In fact, the game proper does not have any Trainers; the only “trainer” is you.

Despite these variations, in the end, my game uses not-Pokémon that have not-Abilities that you can look up in the not-Pokédex, then you use not-items and give not-Berries. Before your hunt, though, you go through a not-Mart and a not-Center which has a not-Wireless-Club or even use a not-Global-Terminal. The play even gets a not-starter not-Pokémon. Even the name “Wuu Shyng”, which is just the name of the philosophy behind the game, is provisional.

The only thing that does not embarrass me is that the not-Pokémon use moves. Because Wuu Shyng does not exactly correspond to elements, but rather movement. In fact, the “Shyng” of “Wuu Shyng” means “movement”. The term “moves” is too fitting.

This is embarrassing because I do not want my game to be a mere copy  of Pokémon.

The main reason why I am writing this, though, is because I want to alert you that I may use some Pokémon terms when writing about Wuu Shyng by virtue of Wuu Shyng being a spiritual successor of Pokémon.


(Maybe I can call my not-Pokémon “Agents”…)




ChaiLove or Game Boy Advance

Summarizing part of my pathway in game development, I was initially excited in developing games in LÖVE and the pico-8. However, I hit into the deficiencies of Lua… mainly how Lua does not have support of classes. Because of this, I spent my time searching for alternatives. Two platforms ended up fitting my needs: ChaiLove and the Nintendo Game Boy Advance.

To me, ChaiLove is LÖVE without the problems. More specifically, ChaiLove retains LÖVE’s ease of programming (and, in fact, is modeled after LÖVE’s API), flexibility in programming, abstraction of lower-level requirements (rendering graphics being the big one), and freedom from compilation while adding the benefits of C++/ChaiScript (actual classes!), taking advantage of Libretro, and meaningful active development. In fact, the Libretro blog post explicitly mentions potential portability to other consoles because ChaiLove targets Libretro!

Before ChaiLove appeared, though, I seriously considered using a more indirect approach in trying to write a “universal” game. In this case, instead of trying to code from scratch a game that works in every platform that RetroArch supports, I could simply look for a game system that every version of RetroArch can emulate, then write a game that targets that system. This approach also provides (theoretically) infinite forward-compatibility. Though I initially considered this approach because ChaiLove did not yet exist, the fact that ChaiLove depends on ChaiScript, which depends on C++14, motivated me towards considering the indirect approach again. After all, Visual Studio 2003, which is the latest compiler that can generate binaries that work with Windows 95 and the original Xbox OG console (the one before the XBOX 360), does not support even C++11… or C11, in that matter.

After currently comparing the systems that Windows 95, the Nintendo 3DS, and the PlayStation Portable can play, I decided that the best system was the Game Boy Advance. My reasoning was that:

  • I should avoid any emulators that prohibit commercial use (an issue that plagues Libretro and its contributors to no end)…
  • …or anything that requires an official BIOS.
  • My theoretical game Wuu Shyng is based on the mainline Pokémon series, which is played in the handheld GameBoy and DS product lines. A result of these game being played on handheld systems is that the contents of two different save files interact with each other; home systems that use save files usually rely on the contents of only one save file, instead.
  • My games are based on a maximum of 3 action buttons and 1 menu button. A lot of the systems that Windows 95, the Nintendo 3DS, and the PlayStation Portable can play use 2 action buttons and 2 menu buttons, instead.
  • While I could target the original Game Boy or the Game Boy Color systems, I read, repeatedly, that games that target those systems needs to be written in Z80 Assembly language, even when C compilers exist.
  • The Game Boy Advance has a lot of strength. Mario Pinball Land used 3D graphics. The Game Boy Advance Video series used full-motion videos.
  • The games I want to make are essentially Super Nintendo/Game Boy Advance games, anyways.

Targeting the Game Boy Advance is a very different paradigm, though. I have to code the game in C instead of C++, which uses structures instead of proper classes. The Game Boy Advance does not play actual audio files, but, rather, MIDI-style files that say what sound samples should be played. (I am not good at making full songs, plus there seems to be a lack of freely-licensed music that can be played in the Game Boy Advance.) Sprites have to be converted to bits (which was a big problem when I looking into coding a game from scratch). Homebrew information on the Game Link Cable (a big thing, given Wuu Shyng and its influence from Pokémon) is rare; homebrew information regarding the Wireless Adapter (something that would be very beneficial) is even worse. Of course, I would have to compile, though I would also have to use a toolkit (in this case, devkitARM, a part of devkitPro). Finally, the Game Boy Advance, being a dedicated handheld device, has more programming restrictions… a lot of them.

However, from what I see, targeting the Game Boy Advance is within my skill set. I mean, the Tonc guide and devkitARM’s libgba libraries seem to make the Game Boy Advance accessible. I have the 1st edition of The C Programming Language, a book that is not only enjoyable and digestible but also would definitely produce C that is compatible with Windows 95. Use of C also means that I, in theory, could use plenty of the C libraries out there that would help my game development. I would not have to worry about different display resolutions because I would only have to focus on keeping things 240 * 160. Implementing multiplayer through either the Game Link Cable or the Wireless Adapter bypasses Libretro’s current netplay system which is opposed to the way I want to make multiplayer, which is based on handheld game systems, anyways. (I would still have to do something about programming a server because I want to implement a type of Pokémon Communication Center in Wuu Shyng.) Game Boy Advance games (excluding a couple of Game Boy Advance Video cartridges) go up to 32 Megabytes, that is, significantly small by current standards. (Thought the main influence on file size comes from the programmer, getting a maximum file size, especially one that small, is comforting to the downloader.)  There are also more platforms that can play Game Boy Advance games… including the Game Boy Advance SP that I currently have.

Honestly, I am actually getting excited from the possibilities. I am eager in getting Re-Hoard and Reckless Abandon done!

Wrapping up the game package

I think I got together all of the pieces of game-making.

Compilation: From the start, the compiling tool was going to be make, which was simple. (Compiling a Libretro core only needed “make -f Makefile.libretro” or even just “make”!) CMake was too complicated, while Bazel needed the horribly insecure Java. The actual compiler I would use was Clang on top of LLVM. My reason is that LLVM/Clang seems to be compatible with projects that work with GCC, the standard of compilation in C, but brings its own benefits, including keeping closer to the original code in compilation while managing better performance. I am new to makefiles or actually knowing compilers, but I found this tutorial which makes things look actually possible.

Networking: Though Libretro has netplay, there are at least a couple of problems with their current implementation.

  1. The way Libretro’s netlag-hiding works is that, during netplay, Libretro constantly makes savestates. If the savestates of the players are out-of-sync, Libretro loads the last savestate when they were in sync then continues normal gameplay. Notwithstanding that any core I would make would have to support savestates which themselves require serialization, the savestates have to be a certain size, meaning that even Nintendo 64 and Playstation 1 emulators cannot use netplay.
  2. Libretro’s netplay seems to be modeled after a home console (multiple players playing on the same system that runs one game) instead of a handheld (multiple players using their own systems that run their own games and connect each other in some way). Driving home this point is the Libretro crew specifically saying that you cannot trade Pokémon through netplay. This is a problem because one of my games Wuu Shyng, is a spiritual successor of Pokémon. Netplay is, therefore, a big concern with me.

While the FAQ list implies that the Libretro crew is going to make a new form of netplay, I decided that the better option would be to not use on Libretro’s netplay at all and instead use an external library, though I would take cues from Libretro’s implementation of netplay in anticipation of compatibility with any future implementation that may work with me. After browsing the Awesome C(++) list for network tools that use TCP (the protocol that Libretro uses), I decided that Mongoose was the best option due to its small size, ease of implementation, and, most importantly, ease of use.

Cutscenes: I decided from the get-go that the files are going to be .ogg files that use Vorbis audio and Theora video, both of them being open-source standards of lossy audio/video. (I could use lossless formats, but I want to keep my games small, especially when you consider that Retroarch has been ported to the PSP and 3DS.) Actually playing those videos is another matter. While I initially looked into using the libraries themselves, their complication combined with my need to implement subtitles (.srt files, by the way, because they are easily written) and the possibility of me needing to add more features led to my decision to just integrate MPlayer in my game. MPlayer has a “slave mode” (ew) that makes this possible. The controls look great; I think that I can have player control the video through their controlers. The one thing that bothers me here is that there is no way of doing a frame-step backward. After looking into how that mode works, I decided to simulate a frame-step in either direction by telling MPlayer to rewind or fast-forward by a fraction of a second, that is, how long does playing a frame take.

Frames Per Second Seconds of a Single Frame
25 0.04
30 0.033333…
50 0.02
60 0.016666…

The small, finite numbers, combined with how much less work would manually animating things be, led to my decision to make files at 25 frames per second. That suits me just fine; I actually do think that PAL, the European analog television system and source of the 25 fps standard, is “Peace At Last”!

That being resolved, my only real issue here is how I would get MPlayer to display to either SDL2’s SDL_Surface or Libretro’s video_cb, unless MPlayer already takes care of that. If I resolve that, then I finally have a complete framework from where I can make Libretro games free from Lua.

Banjo Laylee

Recently, Yooka-Laylee got a rolling release.

While the game had a very successful Kixkstarter campaign, a big following, and successful delivery, Yooka-Laylee got some controversy over not only being too far a clone of the original Banjo Kazooie games but also copying the flaws of 3D collection/platformer games.

I am worried that Wuu Shyng would end up the same way.

While I plan on writting a more proper post on this idea, suffice to say that, from Telefang to Mino Monsters, clones of Pokémon did not really connect with audiences and, in fact, had even gotten controversy over this matter. I want Wuu Shyng to be a spiritual successor and a “love letter” of some sorts to Pokémon, but I do not want to blatanty clone the game, especially not its flaws. In fact, part of the reason why I am making Wuu Shying is because I want to fix flaws that the original Pokémon had! If this game does not go right…

The Tinglar Difference: Fan Involvement

Recently, there has been controversy on how Nintendo dealt with the Metroid fangame AM2R and the Pokémon Fangame Pokémon Uranium. This is not a new phenomenon, either; Nintendo has also effectively shut down Pokémon Evoas. Nintendo is not the only one involved, either; Sega shut down the Streets of Rage Remake while Square Enix shut down both Chrono Resurrection and, later, Crimson Echoes. No matter what you think on the morals of both the fangames and the shutdowns, whatever the motivations, the game companies have effectively punished the fan’s loyalty to the games the companies made.

Of course, one way to avoid this issue is making a game that copies or grows the previous gameplay while not actually using anything from the original setting. Freedom Planet grew from Sonic the Hedgehog while Axiom Verge grew from Metroid, yet they even got released on official consoles! (That is right; Nintendo let a sort-of Metroid fangame on one of Nintendo’s consoles!)

Even the official developers, disgruntled by how their companies handle the developer’s games, left their companies and made their own spiritual sequels. A lot of employees left Rare, the publisher of Banjo Kazooie, and are making Yooka-Laylee. Koji Igarashi left Konami, the publisher of Castlevania, and is making Bloodstained: Ritual of the Night. More infamously, Keiji Inafune left Capcom, the publisher of Mega Man, and made the Mighty No. 9 and is making Red Ash.

My game, Wuu Shyng (working title), is based on this principle.

More specifically, Wuu Shyng is supposed to be a spiritual successor to the Pokémon games, though Wuu Shyng not only implements ideas from other games (notably The Legend of Zelda and Zelda 2: the Adventure of Link) but also takes into a different direction the original ideas that became Pokémon. In fact, Wuu Shyng fixes some issues that fretted fans of the original Pokémon games; accuracy and evasion do not exist in Wuu Shyng, if I were to give a quintessential example.

Even so, I had several important reasons on making a spiritual sequel instead of a fangame, even if I did disregard the risk of Nintendo shutting down my game.

  • This was a college project. I would have at least given my college a big embarrassment if I were to make a game that used an official company’s previous assets!
  • Though this is more a reason why I spent so much effort in differentiating Wuu Shyng from Pokémon, a blatant clone would be rightfully be considered a rip-off of Pokémon that misses the point why the original games are popular. (Who cares about all those clones that litter App Stores?) After all, I actually plan on Wuu Shyng eclipsing Pokémon while taking in, and making feel at home, fans that are dissatisfied with the original Pokémon games, lofty that goal may be.
  • I get to avoid any baggage that the original games have. For example, some Pokémon designs were flops, yet a fangame, even if implementing only the best Pokémon designs, would still, by implication, call back to every Pokémon design, not just the good ones. Making my own game would make a clean break.
  • The biggest reason is also the most emotional: a spiritual successor would make the game mine. I would not be bound by the settings of the originals or the mentalities of the makers. I can do whatever I want with my game. I have full freedom. This is important, because…
  • …I would be able to freely license my game. All games by Tinglar are (at the time of writing) licensed by the GPL. That way, fans can add to, remix, or even tribute my games without legal issues that would just hurt everyone. I want to reward the dedication my fans have and, in fact, want to give them my approval. (Of course, the GPL would require fans to make any derivatives under the GPL, but I would rather keep the freedom flowing rather than use a less permissive license.)