Scripters got a heart too

Yesterday, a guy from a forum annoyed me. I had the impudence of posting a little word about how it made me feel. Then someone commented on that, saying I just wanted to "prove my intellectual superiority", and "make the others feel poorly about themselves". As rude and tactless as I might be, I'm also an honest person, so I honestly asked myself:: why do I even bother posting contents and helping people in the first place? Maybe I actually do want to show off, after all.

For you to get a better understanding of my insight regarding this issue, let me tell you about this blog's history. I've written scripts for RMXP for several years now. My Ruby skills have improved a lot in the process (and still is), so there are some of them I've simply abandoned, others I've not completed yet. At first I just wanted to use them for my own projects. I believed sharing them would only result in people downloading them and not even saying thank you. Then I subscribed to a French game-making board thinking: why not just discuss this hobby of mine and share thoughts about it? And that changed my mind, because I realized discussing scripts and helping people with their issues gave me the courage to write even more scripts and excel myself. I realized that the day I wrote the Animated Custom Menu System's very first version - because this was the first time I had written a full system for someone else.

So I started to consider sharing my other works. I must admit I was pretty reluctant. What if people stole them and claimed them as their own? What if people didn't like them or otherwise didn't give a damn? And most importantly, since the point was for me to keep encouraged in exchange for the time and energy I'd spent, what if people just grabbed what they could and never provide any feedback? Well, I wasn't quite wrong about that last point, since virtually nobody has ever commented on my works unless they had something to request - and the bigger the request, the more praise they felt they had to provide. Anyways, I decided to do it, and here we are.

Now you know why my works are free and why my help is free - you actually give me something in return, in the form of positive human energy, which keeps me going and allows me to provide even more quality contents. In short, the price for a work of mine is a "thank you" - and most people don't even bother to pay that.

So it really does hurt when I'm told I think too highly of myself and I just want to make people feel bad. This was the kind of issues I wished to avoid at the time I didn't want to go on the Internet. Maybe I should just tell people who ask for support they should learn Ruby just like I did, after all no one's ever helped me in the process but online documentation. Maybe I should retire, maybe writing scripts for RMXP, even more than sharing them, is a waste of time.

So, as a conclusion, I still don't know what will become of this blog, and of my involvement with game-making communities. My only certainty is that I'm feeling very bad about it right now.

Animated Custom Menu System updated! (again, v2.00)

Rejoice, ye ACMS lovers, for a brand new version has been born!

I've been asked for new features here and there, and since I also had my own plans for it, I thought it was about time I did something. I first came up with a draft for a v1.12, then thought of further improvement for an hypothetical v1.13. Then, I thought to myself, since I'm there, why not do everything I have in mind at the same time. It took me long enough, but here's the result, and I doubt you'll be disappointed with it.

So, here comes v2.00, with TONS of new features and fixes, and also a forth theme - the three older ones still need to be updated to work with v2.00, so please be a little patient. See the main post for more information. Ane please leave a nice comment if you like what you see. :)

A Closer Look at the Scene_Base Architecture

Some people have been asking me how to write new scenes using my Scene_Base architecture. Here's an overview of how it works, and how different it is from standard RMXP's scenes.

RMXP's Standard Architecture

---

Here's a pseudocode template of a standard RMXP scene.

class My_Scene
  def main
    create windows and sprites
    process transition
    begin loop
      update frame
      call update
      check if another scene was created, and if so, abort loop to end current scene
    end loop
    erase windows and sprites (dispose)
    prepare for next scene's transition
  end def

  def update
    update each window/sprite
    check for inputs and do the appropriate stuff for each key
  end
end class

Seems perfectly fine as is, now doesn't it? However, when you think about it, several issues can arise with that simple, straightforward architecture:

1. If you want to add a new window to the scene, you are forced to rewrite its main method entirely, because it's in a single piece. Thus you cannot use two scripts at the same time, which modify the same scene, because the latter will systematically override the former one.
2. All RMXP scenes rely on this same architecture, thus the same lines are written over and over again, which is unnecessary repeating.
3. Because of 2., if you'd like to tweak all scenes at once (for example modify the transition at the beginning for all scenes), then you have to rewrite all of them one after one.

Of course, as long as you're not dealing with editing scenes/making new scenes, you have little concerne for such issues. But since I've had the occasion to make some heavy on scenes, I thought it was about time to do something about it, and that's how I came to write the Scene_Base class.

Moonpearl's Scene_Base architecture

---

The Scene_Base class was written to address the previously stated issues. It was meant to:

1. Provide easier writing for new scenes since you don't have to rewrite all the base code.
2. Handle scenes in a more modular fashion to allow easier editing.
3. Make it possible to tweak all scenes at once

Here's an overview of how the Scene_Base class works.

class Scene_Base
  def main
    call setup
    begin loop
      frame update
      call update
    end loop
    call terminate
  end def

  def setup
    create windows/sprites and list all of them in @sprites
  end def

  def update
    update all windows/sprites listed in @sprites
  end def

  def terminate
    erase all windows/sprites listed in @sprites (dispose)
  end def
end class

Now let's see how we could write an entirely new scene using this architecture.

class My_Scene under superclass Scene_Base
  # No need to redefine main method

  def setup
    create windows/sprites and list all of them in @sprites
  end def

  def update
    call superclass's method
    check for inputs and do the appropriate stuff for each key
  end def

  # No need to redefine terminate method
end class

One can easily see the first benefit, which is a substantial saving of code, which in turns means a substantial saving of time and energy. But that's not all. Suppose we further want to edit our new scene as an independant script, while not rewriting everything from scratch. Here's how to add a new window/sprite:

class My_Scene under superclass Scene_Base
  # No need to redefine main method

  def setup
    call former code
    create a new window/sprite and add it to @sprites
  end def

  # No need to redefine update method

  # No need to redefine terminate method
end class

This is just enough since our new window/sprite is listed in the @sprites Array, which means both update and terminate will handle it as any other previously created window/sprite. Likewise, suppose we now want to ass new functions to our scene, for example make it able to respond to a new key.

class My_Scene under superclass Scene_Base
  # No need to redefine main method

  # No need to redefine setup method

  def update
    call former code
    check for the new input and act accordingly
  end def

  # No need to redefine terminate method
end class

As you can see, we stick each time only to the necessary edits. Furthermore, this allows several edits of the same scene to coexist, because we do never rewrite a part of the code, we only expand it with new features, always calling the older version.

As an example of how powerful this architecture can be, you can have a look at my Scene_Menu_Base class, from the Animated Custom Menu System. This allows all menu scenes to exhibit common features (namely, a background image and a scrolling overlay). Basically, it's written that way:

class Scene_Menu_Base under superclass Scene_Base
  # No need to redefine main method

  def setup
    create background image and add it to @sprites
    create overlay and add it to @sprites
  end def

  def update
    call superclass's code
    move overlay
  end def

  # No need to redefine terminate method
end class

Now we just have to write new scenes listed as subclasses of Scene_Menu_Base, and since we'll keep on calling formerly written code, the background/overlay will automatically show, and the overlay will automatically scroll, with no need to state those explicilty in our new scenes.

Conclusion

---

I hope this quick overview could persuade you how the Scene_Base architecture can be useful and handy. If you were trying to write your own scenes with it, I encourage you to do so, and I also hope it did clear things out for you.

Why I hate RPGs

You might think this is funny from someone whose hobby is to write scripts to enhance a RPG maker engine. But it's actually for that very reason I do this, and it's a fact - I can't stand the RPG genre. To make this statement a little less blunt and some more interesting, let me explain you why...

History

---

I'm sort of a dinosaur in the world of video games. I was born in the 80's, and I spent a very long time without a gaming console, nor even a PC - just old computers, with old video games (and when I say old, I mean older than pretty much anything you'd have in mind), and RPG came only very late in my life. At the time, there were no real genres - since the games were lacking on the multimedia side, they had to be interesting, and quite unique, if they were to catch your eye. Rather, they were roughly categorized into action/arcade, puzzle, strategy and "adventure". This last category could have held RPGs as we know them today, if there was only any chance that they could have developed at that time. The "adventure" category was further roughly divided into two styles - humourous, puzzle-like adventure games (think LucasArts's Monkey Island), and serious role-playing video games (which should be the ones to deserve the title of RPG, but which I refer to as "RPG-ancestors" to avoid confusion).

So, it all started with those "RPG-ancestors". Historically, they would be videogame adaptations of classical "pen-and-paper" role-playing games (think Dungeons & Dragons), and as such, would present the player with incredibly rich and detailed worlds, and countless possibilities. Just like a PnP role-player, you were thrown into a full-scaled universe with lots of place to visit and lots of people to talk to - and more importantly, no one sticking out to tell you what to do, or stop you if you would try and go somewhere while that was not the time yet. Though appreciated by fans, this extreme freedom would sadly overwhelm the newcomer, and make these very complex games, which required weeks of experimentation before they could be enjoyed to their fullest. For this reason, "RPG-ancestors" were particularily geeky games.

Then, one day, there was Final Fantasy.

Upon its release, Final Fantasy was kind of a UFO among "adventure games". It was neither puzzle-like, nor hardcore-roleplaying-game-like. Actually, there was pretty much nothing to do other than follow NPC's instructions who told you where to go and what to do, just a few battles here and there to keep the player interested. For the first time in videogame history, you could enjoy an epic adventure without even thinking about it. So you can only imagine how it soon became a hit.

And thus, Final Fantasy started a long-lasting tradition of brainless adventures, where you just have to sit and enjoy, and occasionally bash a few buttons to take down overpowered enemies. This is what we call RPG nowadays, and this is what I've come to dislike more than any other kind of videogames.

RPGs have you do anything but roleplay

---

"Role-playing games" is an usurped title for this generation of videogames. A game would be called "role-playing" provided the roleplaying aspect makes any difference, wouldn't it? Roleplaying means speaking in place of the character, it means taking decisions for him, and that implies being given the opportunity to do so. Where in a classical RPG do you take any decisions, even regarding what to say to NPCs? And by that, I mean real decisions, some which have an influence, make any difference in the game's unfolding - dummy choices are just a joke, you could program some in Pong and it wouldn't make it a RPG, now would it? The "roleplaying" part is limited to moving the main character and make choices about his equipment, and whether he should attack or drink a potion in battle. If this is enough for a role-playing game, then it makes Doom a RPG (and a much more thrilling one, by the way).

Non-interactive storylines

---

Considering you don't do anything except fight endlessly, it's only natural that whatever you may do has no influence whatsoever on the way the storyline is going to unfold. A few RPGs offer multiple endings (and by multiple I mean just 2 or 3), but it's often not even about important choices in the storyline's perspective - rather, you get another ending because you've chosen this character to join your party over that one, or because you haven't completed some obscure sidequest. The very word "storyline" says it all - we don't even start to think about making scenari something else than a dull, flat line. I'm struck by how we have incredibly sophisticated ways of rendering stunning graphics, and how much passion and energy is put into putting together breathtaking music that matches the game's atmosphere perfectly, whereas we still stick to prehistoric, extremely linear scenari. Even "choose your adventure" books offer the player more interactivity than modern RPGs, whereas their concept is half a century old. I shall discuss leads regarding how to create really interactive storylines in later posts.

It's all about battles

---

Remove battles from a RPG, and it's not even a game anymore. No battles means no equipment, no treasure hunt, no leveling-up, no random encounter and thus no purpose in wandering around to ultimately get and advance the storyline. Without battles, RPGs are mere movies. Refering to my previous statement, a better title for RPGs would be "battling games", since all you really do as a sentient being, able to make decisions is battle. Now, some RPGs do have interesting batttle systems, but most of them are just about attacking absent-mindedly. Take the RPG Maker series, which is supposed to be representative of what your standard RPG would be. Honestly, the standard battle systems they feature are so dumb they make me wonder why I quit playing Soulcalibur.

It's just a matter of optimization

---

Battle could be interesting, and "role-playing-like" if there were even multiple strategies to be developped. For instance, I took some interest in Pokémon for the fact that you can choose your style in some extent (even though it all boils down to dealing the most damage in the end). But most of the time, as for the storyline, there's one and only way to go. When you get the latest weapons in the game, you have to equip them since they're more powerful than the previous ones, there's no considering them a option, you would be stupid not to equip them. Once again, you're not given a real choice, even regarding as basic an option as what kind of items to equip. Regarding how your characters progress, it's just the same - they can only level up, they won't lose abilities they don't use out of lack of training. And since they have classes that prevent them for learning abilities or using weapons that are not meant for them, there's nothing to be pondered, just go and gain XP and money.

Conclusion

---

I think most people enjoy RPGs for their inherent simplicity. As stated above, Final Fantasy met success because it was so simple compared to what existed at the time. I can understand that games which require much thinking and involvement can be a hassle, and to be honest I easily get tired with them as well - however, I think there's a happy medium between being required to manage tons of environmental variables at once, and being given no option at all. I make my best to give RPG Maker XP new dimensions with my scripts. I try to cross-breed RPGs with old-school adventure games, allow them to exhibit a puzzle-like aspect, and in a general manner, give the player's choices more consideration. I hope someday I can make a heavily decision-based game which is easy and entertaining to play, but difficult to get to the best end, to demonstrate my point. And then, I'll consider classical RPGs finally outdated, in a gameplay perspective.

Miscellaneous Scripts

This is a collection of small tweaks I use for RPG Maker XP. Bundles for the Script Manager are distributed separately, but there's a single demo for all of them. Just add/remove the appropriate entries from the Script Manager.ini file to test them individually.

---

Moonpearl's Confirm Decisions

---

This allows the game to prompt the user for confirmation when performing important actions, such as exit the game or overwrite a previously saved game.

Download MP Confirm Decisions (1 KB)

---

Moonpearl's Improved File Menus

---

This replaces the minimalist, slow Load and Save menus with a more powerful interface, which allows you to load savegames by calling the save menu in-game, and also delete savegames you have no longer use for.

Download MP Improved File Menus (5 KB)

---

Moonpearl's Skip Title

---

Pretty self-explanatory, this tiny script skips the title scene and calls the first map directly in a clean, minimalist way. Ideal for testing projects with a long intro.

Download MP Skip Title (1 KB)

---

Moonpearl's New Game Plus

---

Enables a "New Game +" option on the title screen when at least one savegame is flagged as completed. The number of times the game has been completed in a row is stored into a game variable, which allows you to program events to behave differently based on whether you're in Plus mode, and also how many times the game was completed.

Download MP New Game+ (2 KB)

---

Demo

---

Click the following link to download this script. Terms of use and instructions are provided within. Please credit me if you use it in your own project. A nice comment is always appreciated. 

Download Miscellaneous Demo (204 KB)