(~9 min read)

  • Prifurin
  • 04/17/2021 10:41 AM

Well actually as it turned out, quite possible, so let’s take a deep dive into origins of such bizarre mashup!

Digital Soul Data RMN gamepage: https://rpgmaker.net/games/12002

The engine I am speaking about today is a little different than standard arsenal of RMN user, yet has a lot of common with RPG Makers – it’s called OHRRPGCE which by the way stands for “Open Hamster Republic RPG Creation Engine”.

*flashbacks to 5 years ago*

Well since the very first time I’ve seen Touhou series I fell in love, honestly. It was incredibly challenging yet so mesmerizing! As many of us indie devs do, among the very first game concepts I was bearing in my mind as a beginner to game-making – was a Touhou fangame idea, the shooter which is not only stuffed with colorful projectiles of all shapes and colors but as well has some story with humane characters different from that of cliche shmup range – warships, space collisions and gruesome interstellar entities which won’t bring a smile at player’s face as they casually dodge waves and waves of spell cards and patterns infused with puns and lore.

courtesy of ZUN, from Touhou 11 Chireiden ~ Subterranean Animism

Although for a complete novice like me back then, with no gam mak skills whatsoever and no idea on how to start the whole thing and make it real, the objective was clearly impossible to reach.

I began with looking into open game engines like Construct and Unity, Godot wasn’t even known as much as today. For a someone with education not even remotely related to math like me it could seem useless to ever try, but luckily enough I’ve stumbled upon one engine, which looked rather like something from DOS era – black&white UI, monospace pixel font, keyboard-only controls(for the editor itself!) – OHRRPGCE.

engine UI

Not known to many, even up to this day, this tool appeared to be both opensource and “no programming knowledge required”-type(or so I thought). It has many limitations(many of which were successfully lifted by bizarrely devoted developers), long history of 20+ years with it’s own rises and falls and overall by it’s capabilities relatively comparable to RPG Maker early installments such as 2000 and 2003. With one groundbreaking feature – it allows users to write their own scripts using large syntax rendering most parts of engine accessible directly(unlike RPG Maker event system which in my personal view is much less flexible and more inconvenient to edit) – it can be thought of as Ruby/js scripting support in newer RPG Makers.

And so the journey began, I had envisioned a beautiful game about underwater palace waking up from 5000-year slumber where main character, the prince, had to escape his own prison he was sent to, before the whole thing collapses as an outcome of magic war… you get it. And how hard I failed!

Even with scripting and tutorials found on the forums dedicated to OHRRPGCE I got quickly bogged down in unsolvable bugs like bullets never disappearing from screen or not being able to move parallax layer below character. It felt terrible and really soul-crushing so I had to essentially give up and try something easier( spoiler: it wasn’t a platformer as it’s equally hard to make these in the engine aimed for creation of RPGs in style of Final Fantasy and Dragon Quest.)

Vikings of Midgard, one of most well-known and typical OHR games

Yet now, five years later during occasional game jam the team I was in agreed upon exploring such an ambitious idea – making a danmaku game with OHR, which meant a lot of default functionality had to be ignored and worked around with custom scripts.
But the most interesting part in my opinion is to explain(briefly) some of the principles that are utilized to render a shooter game playable in RPG Maker-like engine.

Despite what I said above, *a lot* of default functionality was actually extended and built on, like the player character is the default “actor” for hero slot 0 (from 4 in the party caterpillar) and NPC instances are used to create references for enemies and power-ups, converting their in-engine definitions to “slice” arrays(kinda similar to Flash slice trees if anyone is familiar with these) – OOP physical instances which yield variables, foe stats in the engine are used to calculate HP and firing rate, player lives and magnetic range for pulling power-ups are also referring to the hero stats, dialogue window lines are converted into the text to be shown with custom script enabling full bust images and opacity change for inactive speaker… e.g. it was beneficial due to:

a) not writing all these systems completely from scratch
b) allowing easily accessible and tweakable level design and stat essentials like foe placement, stage length, power-up drop rate, HP, damage, you name it – right in the engine.

Enemies are placed through the maps at the tile x y positions, and the map itself actually doesn’t move, but rather enemies are spawned in order they were laid out previously, with a 15-tick (250 ms) step per row. In order to compress enemy placement there are even special “buffer” NPCs which hold time for set amount for frames.

Stage map layout, y-marked tiles on the right are spawn positions for sides of screen

Speaking of which, the engine abides by old hardware issue – the game runs as fast as it updates, e.g. the speed of all events directly depends on framerate, resulting in 60FPS making everything incredibly fast or 18,2 FPS boiling it down to a choppy mess of delay. And for action genre such a shmup is you of course would want to have it going at maximal FPS possible.

To overcome this obstacle(preventing either bullets and enemies from moving at adequate speed or game from being a playable experience) programmers on our team(I was responsible for graphics, audio and organization) decided to implement workaround which early 2D Mario games used, for example, - a variable that represents units of 1/256 of a pixel, that might be incremented by 64 every frame, making the object move one pixel per 4 frames. Though in our case it was 1/1000th of a pixel so movement appears to be extra-smooth for an RPG engine physics, ahaha.

The game does not use save states, but how does it remember your scores? - you will wonder. And there’s an answer for that – OHRRPGCE is able to export global variables accessible across scripts into one of the save file slots instead of an actual game save, and load them from it when the game is run other time – this way it always preserves your high scores in the special ranked table, which by the way has an old-school ASCII color-cycling effect for the 1st place, which was added via commands similar to “Show Picture” in RPG Maker.

Snow Clash reference here

Among many other things I allowed myself to steal some precious development time (we only had slightly more than two weeks) and wrote a e s t h e t i c s “CRT”-effect, which is also easily replicable in RPG Maker in the way it was set up – use an image covering the whole screen area, consisting of alternating black and transparent lines, display it at low opacity above everything on screen and move it up and down by a pixel constantly.

One of easiest vfx ever seen

So, persisting all imaginable difficulties and loopholes such a challenge may impose, I say yes, it is possible to make a fully functional bullet hell shooter game in something like RPG Maker( there must be similar attempts but personally I can’t point at anything precisely inheriting Touhou/Ikaruga mechanics due to my limited knowledge of RMN gamelist, so if you happen to know bullet hell shooters made with RPG Maker series, well in Pixel Game Maker MV of course it would be much more feasible, please feel free to tell about them in the comments! That is a very interesting and unique topic to attend ^^b)

To see it with your own eyes, sure you are welcome to play the game itself, Digital Soul Data(linked above), it’s short, challenging and completely free – “Digital Soul Data is a top-down bullet hell shooter - play as a hacker, Mia, who uses avatar NB4 to blast her way through cyberspace and retrieve her sister's Digital Soul from eternal virtual slavery”

Cheers for all innovative developers who pursuit pushing limits of whatever tool they use and gift us with surprising games, plugins and truly priceless advice about gam mak!


Pages: 1
Great read Prifurin !

Thank you for sharing your experience. I like your description of the sub-pixel workaround. A few years ago, I used 1/10th of pixels to improve Lya's projectiles accuracy, and though it was a naive approach. You convinced me that it was actually a good idea.
How does this game only have 34 downloads???

Also, I like the use of the map for game data rather than map data. Clever.
I saw a Bullet Hell script in the style of Touhou years ago for RPG Maker VX by tomoaky. You were able to use equipment to determine your shottype and many other customizations.
It gave me an idea to create a Game where you can run around in a sort of hub area and solve puzzles to get items, extra lives for the Stage sections and so on.
There aren't many narratively heavy shmups out there, so that idea could be golden.

Unfortunately tomoakys site is down and the download for the script is lost, but I do still have the folder for the demo with all the essentials.
The most beautiful user on RMN!

No Gold for Brigands has a shooting mini game.

It's not a bullet hell, but the mini game could possibly be made into one.

I can't remember what script I used though?????

Pages: 1