Developer Interview: Walfrido Abejón – “NOAH & The Poohloudies”

SHIRO!: “Let’s start at the beginning… Can you tell us how you originally got into game design?”

RNC: “I always wanted to make games, I guess… But I was born in the 80s, and at least in my country of Spain, there weren’t many studies oriented for that. So one day I saw a tutorial on SDL (Simple DirectMedia Layer – a 2D graphics library), and I coded a Pacman game where the ghosts would patrol specific areas, instead of wandering around randomly. Pacman could “stick” to the walls and move alongside them, sneaking behind them as if he were Solid Snake. A few other projects came after that, but I never dedicated my full time or focus to make money from it. I just kept reading about and practicing making small games in my free time…”

SHIRO!: “What developers and games would you say have had the most impact on you and your work?”

RNC: “Mostly Japanese devs… Pretty much any Nintendo game is a master class in game design. Some of the Fumito Ueda games are also fresh and innovative in so many ways. Also, Kojima before the PS3 creations 😆”

SHIRO: “Can you tell us a little bit about Rainy Night Creations?”

RNC: “Yeah, one day my girlfriend decided that she wanted to study abroad, and it got me thinking, ‘what if I take this opportunity to quit my boring job and try doing something I actually enjoy?’ That’s basically how Rainy Night Creations got started. We didn’t move (abroad) right away, (that was more than a year later), but during that time, I started working on my first game project after getting home from work each day, all while saving up money so I could eventually quit my job.”

SHIRO!: “What is your favorite project that you’ve worked on under Rainy Night Creations?”

RNC: “I’ve only released two games so far… FreezeME (a 3D platformer) and Vaccine (a survival horror roguelike). I’m very proud of both projects, but neither of them is exactly what I had envisioned at first…

FreezeME was my first project using Unity, Blender and programming in C#. So every other week I was scrapping everything I had done before and starting from scratch, until I reached a point where it was clear that I was going to run out of money and time. So I just decided to move forward with whatever I had and only rework things if I had no other choice… I reached the last month of development with a half-baked game and just enough money to survive the following month… FreezeME was released at the end of 2015 on Steam and later on Wii U, Xbox One and PS4 to mixed reviews.

Fortunately, when you work alone, you don’t need a massive hit to make enough money for your next project… So before moving on to my new project entirely, I wanted to take some time to consolidate what I had learned and see if it was enough to avoid scrapping a project every other week. To quickly test myself, I set out to create a game from a prototype stage and do a full release in five months (six months including the console certification process). I could not spend more time than that, as it would affect the bigger project I had in the pipeline for when this was done.

I had two prototypes for this test, one was Vaccine and the other one was Noah and the Poohloudies. For reasons I’ll explain later, I went with Vaccine… 6 months later, the game was released for Wii U, Steam, PS4, Xbox one and later on for Switch, again to mixed reviews.

I could have easily spent two years on Vaccine, but that’s one of the biggest takeaways and differences with homebrew development… Deadlines and budget drive the entire development process. The funny thing is that Vaccine made almost twice as much money as FreezeME did, and Vaccine took only six months, while FreezeME took 3 years..!

Currently I’m working on Innocence Island set to release (hopefully) in 2022.”

SHIRO!: “What game design philosophies are most important to you and your games?”

RNC: “Basically, the opposite of repetitive gameplay… The games I have most fun with are those that constantly ask me to do different things, vary the gameplay and offer new challenges. Good game design can impose challenges by introducing new platforms or enemies (take a Mario game for example) or by giving the player more tools to resolve problems in different ways (a Zelda game would be a good example).”

SHIRO!: “Can you tell us the story behind NATP? What inspired it?”

RNC: “As mentioned before, NATP was a project I discarded when moving on to Vaccine. NATP was supposed to have a single-player story mode and then an online-multiplayer, where people would battle on User-Generated Maps (using an in-game map editor) to collect a number of things before their opponents.

Online connectivity and UGC increases the budget and developing time significantly, and unfortunately, it wasn’t feasible to do it in 6 months, so the project went to the back burner… Also, in the original prototype, the ‘merging’ mechanic wasn’t implemented.

One day, I saw someone on reddit post a basic tutorial on how to display a sprite and move it around on PlayStation. Even though I love old consoles and their games, it never occurred to me to develop a game for them… I followed that tutorial and kept adding more and more features, until I reached a point where I thought it would be fun to have Noah running around a 3D level, and that’s basically how it got started.

I hadn’t developed much of the story mode (for the PC version) before scrapping the project. I mostly worked on the editor and the online features, so other than the main idea and character model, everything for the old consoles was created from scratch.”

SHIRO!: “What type of game do you intend it to be? Are there any existing games that you might compare it to?”

RNC: “If you had to define NATP using already existing projects, I would say Super Mario 64 meets Pokemon meets Tamagochi… 😆.

You take on the roll of Noah, a rescue robot with the ability to merge with other robots and gain new abilities. Noah has been assigned with the mission to rescue the Poohloudies, several robot inhabitants of a galaxy that is on the verge of being wiped out by a meteorite.

The meteorite’s proximity causes the Poohloudies to malfunction and attack you, so the robots that you are supposed to save are also your enemies in the game, but you cannot hurt them. Instead, you must jump on them to ‘catch’ them in your backpack and gain special abilities.

While in your backpack, they might need food and water to survive, or medicine if they get sick. If that happens, you won’t be able to utilize them, or worst case, they will die and you will have to restart the level.

There’s also the main collectable, which serves as your ‘fuel’, so you’ll need to collect a specific amount in order to travel to other planets.”

SHIRO!: “What types of game play mechanics do you plan to incorporate?”

RNC: “The gameplay will basically be driven by the new abilities acquired after merging with a Poohloudi.

There will be some ‘original’ abilities implemented, but I also want to call on the ‘nostalgia-factor’ a bit… For example, you will find Poohloudi with spiky blue hair and red shoes (imagine Sonic), and when you merge with it, you will be able to travel fast enough to clear a door that would previously close shut in your face because you were too slow. You can also merge with an orange Poohloudi wearing blue jeans (imagine Crash), and destroy several crates that previously blocked your path…

There’s always a time limit for each level (before the next meteorite strike) so time is of the essence in the game. You’re allowed to have 3 merging robots at a one time in your backpack’s ‘robot slots’. You can assign these robots (abilities) to specific slots before entering each planet. If you want to assign new robots to them after you have landed, you will suffer a time penalty, so you’ll have to plan out your slot assignments carefully before going to a new planet. New robots collected will occupy any free slot, if available.”

SHIRO: “You mentioned first porting NATP to PlayStation years ago…
Do you intend to finish that version, and what inspired the move over to the Saturn?”

RNC: “I actually spent a great deal of time working on the PlayStation version, but it’s been about a year now since I’ve even touched the PSX version… Last year I actually started working again on the PC port, to help me in debugging non-graphical things quickly. I also wanted to use OpenGL 1.1 (an old graphics library), as there is an existing port of this library for Dreamcast (and other platforms like Nintendo DS and GameCube). When I completed the PC port, I was supposed to start work on a Dreamcast port (which should be fairly quick after having ported it to OpenGL), but since the game was already running fine on a 32-bit machine (PSX), a Dreamcast port felt more like ‘busy work’ than a challenging project… So that’s why I decided to move the project over to the Saturn.

The idea is (assuming the Saturn port ever reaches a stable 30fps 😆) to merge the optimizations I created for the PC and Saturn versions back into the PlayStation port, consolidate the assets pipeline and then finally work on a Dreamcast port.

(Also, at some point it was running on N64 using Nintendo’s official libraries, but I’ve decided to stay away from that…)“

SHIRO!: “A lot of things have been said over the years regarding Saturn game development. Everything from ‘complicated architecture’ to ‘poor documentation & tools’ to ‘loads of untapped power and potential’… From your personal perspective, what can you tell us about game development on the Saturn?”

RNC: “Regarding the architecture and it’s ‘untapped potential’, I think there is a bit of a mix of facts and urban legend… When you have a look at the Saturn’s main competitors (PSX and N64), although they’re different, they shared a common basic structure: A versatile main CPU, a coprocessor that is able to perform a variety of heavy calculations magnitudes faster than the main CPU (PSX has the GTE and N64 has the RSP) and then a GPU (VDP1 in Saturn’s case). While the Saturn doesn’t have a coprocessor like PSX & N64, it does have a second main CPU (Hitachi SH-2) and a DSP (however, neither of them are magnitudes faster, and they all happen to share the same bus). On top of all that, it adds an extra GPU (VDP2) to spice things up… 😆

I guess a lot of people think of these five elements (SH-2 + SH-2 + DSP + VDP1 + VDP2) as separate entities that can (in theory) all work together in harmony, not only putting Saturn’s power on par with it’s competitors, but even surpassing them. However, the problem is that (in practice) these five elements don’t work in harmony… They are, in fact, constantly fighting with each other for resources…

Here’s an analogy: It’s like having three meals to share between five people. If you only feed two, they won’t be able to eat it all, and if you attempt to feed all five, there won’t be enough food to feed them all… If you try to feed three of them, that won’t be perfect either, because one of them will often be hungrier and will eat some of the others’ food...

So, the reality is that it’s impossible to fully utilize all of them at the same time. Depending on the specific game and/or genre, you might be able to squeeze them in a better way and perhaps surpass what is possible on other consoles, but there is no way this can be generalized and applied for all games. Even the idea that Sega could have come up with an SDK enabling all games to outperform PSX & N64 equivalents is just wishful thinking…

I also feel it’s this architecture that made it really difficult for Sega to create a decent all-purpose library, whereas for Sony and N64, if you wanted (for example) to create a polygon for the floor, you could create a function for the library that would send the vertex to the coprocessor, convert them to screen coordinates and send them to the GPU.

But what could Sega do for their library? Force people to transform the vertex on the master SH-2, on the slave or the DSP? And what if you wanted that polygon on the floor to be displayed by VDP2? There isn’t a common solution that optimal for most cases. I could see Sega having a hard time deciding on the best approach here, because they all seem to create issues at for programmers at different stages of development that probably showed in the final results.”

Last, but not least, it’s rarely mentioned just how fast (at the time of their release) Hitachi’s SH-2s could perform multiply and accumulate operations! So the Saturn does have some benefits over PlayStation (and vice versa). The same goes for the assembly language they both use. If you want to squeeze them, each has its own cool features that the other doesn’t. That said, the PlayStation’s GTE coprocessor makes it much easier to push a huge amount of polygons, but the Saturn’s lightning fast CPU multiplication gets it pretty close to PSX in the end…

The Saturn’s official documentation and tools are something I haven’t used much other than reading the SH-2 and VDP1 Assembly manuals (apparently there are some typos/corrections in the VDP1 manual, but nothing I would consider major). I basically use Yaul and ponèSound (open-source libraries), and I’ve created all the tools for exporting assets myself, but it is true that when I see people discussing specifics of the hardware, such as the DSP, there’s usually not much of a consensus, because apparently the information provided by SEGA is often unreliable and/or scarce.

While the Saturn’s architecture may seem a bit messy, I like to make it a ‘well-thought architecture’ by simply ignoring certain parts of the hardware… Take the DSP or VDP2 for example… I don’t use them at all, and if everything goes according to plan, I never will. 😆 Without them, it’s fairly similar to PSX development. The use of quads and the lack of UVs is an annoyance, but it’s just a bit more initial work for the exporters on the art side of things…

Also, by using my own custom renderer that doesn’t wait for VDP2 to sync on every frame, I can achieve some performance gains, albeit at the expense of being able to create some of the more advanced lighting and effects, similar to what XL2 implements in HellSlave, for example…

SHIRO!: “What do you consider your greatest challenges in working on this game and on this hardware?”

RNC: “For the game itself, I would say TIME! 😆. Working on homebrew games is always time consuming, because everything is bare bones to start with. In most cases, you have to create many of your own tools from scratch, and when you encounter issues, it’s not as simple as doing a quick Google search for the answer or to see if someone else has run into a similar issue. (Much of the time, the issues you encounter will be proprietary to your project).

Also, as a self-employed individual who makes games for a living, any time spent working on homebrew projects (after normal working hours) almost feels like stealing time from my main job and income. It is a strange feeling, even though I do consider it a hobby…

On the hardware side of things, the challenge mostly lies in finding ways to better optimize the cache. It’s always better to keep as much code and data in cache as possible, but in the case of Saturn, this becomes even more crucial, as there are many bus contention issues, so the less you have to resort to the bus, the better. That means, in my case, organizing the data in memory as contiguous as possible and avoiding unnecessary branching.

I’m still working mostly with emulators and occasionally burning a CD to check the game using a PseudoKai Cart. Emulators provide a good overall picture, but when you get down to the nitty gritty details (such as cache), they aren’t that reliable… And burning CDs every time you change a line of code (to see if there’s an improvement) is not great either. I’m hoping that Fenrir has an update in the pipeline to finally utilize its WIFI module to transfer builds to the Saturn quickly and efficiently. I’ll be first in line to snatch such an update as soon as implemented. With that, I could test cache optimizations in a proper way and finally move on to utilizing the second SH-2 processor…

I still need to implement some missing features, and the game remains at about 17-18 FPS on real hardware while running on a single processor, so it’s not really playable yet… Using both CPUs, however, it ought to reach 30 FPS, and once I have everything implemented that is present in the PlayStation version and optimize it a bit more, it should be ready for a demo release to SegaXtreme.”

SHIRO!: “What are your thoughts regarding the current Saturn homebrew scene and the future of homebrew development on Saturn?”

RNC: “I lurk most of the homebrew console discords & forums, and the Saturn community seems to be one of the healthier and more welcoming communities out there. There are a lot of knowledgeable people willing to help, such as XL2, Ponut, Mrkotfw, Fafling, etc.., and it’s the only homebrew community were Vbt is present. 😉

In addition to that, the emulators are getting more accurate, and there are several SDKs to chose from and a plethora of hardware to help you run homebrew projects easily. So I think is only going to get better moving forward… 😊“