• Add Review
  • Subscribe
  • Nominate
  • Submit Media
  • RSS

The Evolution of TheInfinite's RPG Maker Action Games.

  • Infinite
  • 09/06/2017 10:10 PM

Rissa is my latest Rpg Maker game. It's probably my last Rpg Maker game. It's a project I started while still finishing Ascending Dreams. My goal for Rissa was to utilize the things I learned while making Ascending Dreams, without driving myself crazy by creating original art assets. I wanted to optimize the speed of an Rpg Maker action game, and develop modular systems for streamlined iteration.

RPG maker is not known for action games, if anything, it's known for bad action games. We probably shouldn't bother trying to make action games in an engine like RPG maker, but for a long time, it's the only engine I knew how to use. I found Rm2k when I was 12 years old(I'm 30 now). I had come across some kind of Pokemon fan game. When I saw how easy it was to get a game started, I kind of became obsessed. I immediately tried to make a Super Mario game. It was your average side scroller Rpg maker platformer. Press enter, and Mario and Luigi would move 2 grid-spaces up, one grid-space to the right, and 2 grid-spaces back down. I spent the rest of my teenage years trying to make Rpg Maker action games. If you see the games I have uploaded here on RMN, you'll see every major project I've released is some kind of action game.

My first real RPG Maker game is Demon Dreams. Of course there are countless projects which came before Demon Dreams, unfortunately they're lost in time. It's a project I'm proud of because of how good it feels as an Rm2k3 action game. The tile based movement makes for some clunky feeling experiences, but the hit-detection is pretty good, and the overall design is pretty good for an Rm2k3 game too! It comes from my teenage years, when I had nothing better to do than make games, and play games, all day every day between sleeping and eating. It's the only project I kept saved on an external hard drive.

( maybe someone can figure out how to bypass/hack the game folder on my old website http://foreverproductions.free.fr/games/ which is miraculously still live after all these years!)

Lasting Dreams is a kind of follow up to Demon Dreams. It's a side scrolling adventure made with Rm2k3, which used RTP graphics in a kind of innovative way. It's probably the most "complete" game I've ever made. Featuring many dungeons, items, and bosses. It piggybacks off the ideas and things I learned from the other action RPG maker games I've made. It's a game that brought me back into game dev after years of living an adult life. I happened to be looking through old e-mails one day and found this unfinished project I had sent to a friend. Many of the game's systems were built by my teenage self. All the adult-me had to do, was build the world, distribute the items, and tell some kind of story. It was an okay attempt at an action adventure for an Rm2k3 game.

Ascending Dreams is my first RPG maker VX ace game. It transformed many times along its development. My original systems worked the only way I knew how make them, using many of the same ideas and systems I would have used in an Rm2k3 game. It wasn't until late in its development that I learned how to better utilize Ruby coding. It was that learning process that allowed for Rissa to be what it is!

Awesome Ruby plugins like Quasi's pixel movement meant I no longer had to fight the clumsiness of Rpg Maker's grid based movement. Pixel movement supplemented by "Perfect Pixel Collision System" by Cidiomar R. Dias Júnior, kind of speaks for itself. We're off the grid!

My Rm2k3 projects were not very modular. There were many limitations. I started these games by working with 1 map. I designated the first 5 events to enemy events, each of them would get a set of variables. Their x & y coordinates, health, and attack power. The next 5 events would be the items they drop. So if you killed enemy 1, it would drop item 1 at enemy 1's location. There would be 1 "brain" event, which activated when you arrived on a map, and that would set the variables for each enemy. There was another event for the hero's weapon, which would be the sword, or the arrow the play can fire. These events needed to be the same for every new map, because the "common event" would always look for event 1, 2, 3, 4, or 5 when trying to find see if they're being hit by a sword or arrow.

Once the all the systems were built, I could copy and paste my master map. This meant I would often have to reprogram the "brain" event on every map, and make sure each enemy has the right HP and attack power for the enemy type. If I wanted to change an enemy on a map, a lot of times I had to reprogram them from scratch. Click on the event, change the character graphic, reprogram its movement and speed, update the brain so it has the right hp and ap. If I was lazy, I would copy an enemy from an earlier map, and paste it into my new map. As long as I replaced Enemy 1 from map A, with Enemy 1 from map B, I wouldn't have to go in and and swap all the associated variables like Enemy 1 Hp becomes Enemy 2 Hp, and so on. This discouraged iteration. I couldn't just change the attack power of green slime game-wide, because I'd have to go into every map green slime appeared, and change the brain events to the new stats for green slime.

By better utilizing Ruby, Rissa's systems solves almost all these problems.
Clone Events v1.0 by Shaz was a game changer.

It allowed me to program an enemy 1 time, then clone that event any time I wanted the player to face that enemy. This allowed for a new level of iteration. Should the Bat fly faster? Should the Skeleton move this way or that way. If I wanted to change something, I only had to do it once. I tried implementing this plugin into Ascending Dreams later in development, but it probably didn't agree with some of the other plugins I was using, it just didn't work with everything I already had built, or would require major reconstruction. It wasn't until I started a fresh project with this plugin as the central feature, that I could see which plugins it would cooperate with.

So Map 1 of my game project was home to the enemies. Using the "Game_Event class" I would assign each event's stats based on whatever the name of the event was.


The Game_Event class can also be used to program more advanced types of enemy AI systems. The code below just shows some examples of clocks that determined when an enemy would fire a bullet, while the game's event would control its movement through basic "move routes".


I still used a "brain" event on each map, but this time all I had to do was tell it which enemies to spawn, and where to spawn them(at a specific location, or a random spot within a region).

Another huge step for Rissa was the usage of Sprites as bullets. Using "Perfect Pixel Collision System" by Cidiomar R. Dias Júnior, I was able apply collision to generated bullet sprites! Ascending Dreams used this pixel collision system too, but it wasn't until late in development when I learned how to generate collision detecting for any instantiated sprite. I was originally using Rpg Maker's built-in picture system as bullets. So the player would thrust their spear, and the game would ask itself if picture 1 was colliding with enemy any of the 5 enemy events.

This made for some overly convoluted programing.

This is a piece of the code for enemy 1. This code would have to be repeated for enemy 2, 3, 4, and 5. Changing each of the variables associated with each of the 5 enemy events. It's very tedious to do, and it was stifling iteration.

Early on for Ascending Dreams, each enemy slime was assigned 3 pictures to shoot at the player. Lets say enemy 1 would have pictures 1, 2, and 3, then enemy 2 would have 4, 5, and 6, etc. Each bullet had a specific set of variables it used to determine the trajectory it would take toward the player. I spent a lot of time on this system, it was cool to get it working, but again, it was very limiting. If I wanted the red slime to shoot slower or faster bullets, I would have to go into every map that had red slime, and change each of their events to reflect the change of their bullets.

By using Ruby's sprite class to generate a bullet, which could used Cidiomar's collision detection, I could ask the bullet to see if it collided with any event that could be damaged. It wasn't 1 specific picture sprite trying to find 5 specific events. It was any sprite I generated trying to find any event that was designated as damageable. The only limitation was keeping the number of enemies and bullets low enough prevent to frame rate issues. This allowed me to spawn 20 Jellyfish that shoot out 8 bullets every few seconds. The player could shoot multiple arrows, place as many bombs as they wanted, that would interact with any of the 20 Jellyfish.


"for i in 0..$game_map.events.count" means do this for every event on the map!

Rissa is probably my last RPG Maker game. I had abandoned it at one to point to learn Unity. Since then I've release a mobile Unity game called Super Bomb Jump. You can find it in the Google Play store for Android phones (you may have to search "Super Bomb Jump by Ismael Rodriguez" to find it, because I'm terrible at marketing and have fallen down in the search results, even if you search "Super Bomb Jump" verbatim). I'm currently working(sometimes) on another mobile Unity game which uses assets I created for Ascending Dreams. I decided to go back to "finish" Rissa so the community could see the progress I've made on RPG maker action games. I hope it will be helpful for future Rpg Makers to see some of the ideas I used in Rissa, and maybe apply it in their own games.