Envision, Create, Share

Welcome to HBGames, a leading amateur game development forum and Discord server. All are welcome, and amongst our ranks you will find experts in their field from all aspects of video game design and development.

[XP/VX/ACE][WIP] avarisc's RGSS [Cancelled]

avarisc's RGSS
By: avarisc

Introduction

Clockwork RGSS is a replacement script package for RPG Maker (XP, VX, or VX Ace). As it does not depend on any specific RGSS, it is designed to work with any of the three editors.

It's features are, primarily, related to making RGSS more expandable. It also adds a few core pieces, such as mouse, keyboard, gamepad, and network support, to better support RPG Maker's target platforms, as well as polishing certain aspects of RPG Maker.

Enterbrain is very slow to update the official RGSS, often reserving these for new paid releases, such as new editors or DLC. As this is released separately from the editor, updates are far more manageable. In addition, this replacement engine features an API- that is, an interface between the engine and scripts, so that changes can be made to the engine [hopefully] without impacting the operability of scripts.

Features

Pending.

Screenshots

The engine will look and feel quite close to the original, so at this time screenshots are rather unneccessary.

Download

The engine is currently distributed via RPG Maker XP "Scripts.rxdata". I can provide other formats upon request. Major milestones will be released in variety of formats for each RPG Maker.

This is an incomplete project, and is intended to be used for review or critique purposes. Download here:
https://www.mediafire.com/?8t3zeumbn3qpz8a

Script

This is an entire replacement for RGSS, broken cleanly into many separate "scripts". As such, posting them individually here would be impractical.

Instructions

Pending.

FAQ

Q: Why start this thread during the pre-release phase?
A: Simply put, self-motivation and critique. Community involvement is all I have to justify my efforts here to myself, and as this is a "Script for Scripters", I need to know what fellow scripters think of the project, and monitor their input while shaping this engine to be the best that I can provide.

Compatibility

Simply put, there won't be any with scripts that weren't designed for Clockwork. That said, it's an expensive, but worthwhile tradeoff, as scripts written to support Clockwork will be more capable, more compact, and more compatible.

Credits and Thanks

I'd like to take this opportunity to thank you, the reader, for posting your feedback below- good, bad, indifferent, or just a "Hi", every post gets me more excited to work on this project.

Author's Notes

Sorry for all the "Pending" content here - the purpose of this thread, as well as its placement in Script Support, is because, simply put, the project is not yet finished. But I don't want to have to head for the finish line without community involvement - I needed a place to discuss my progress, my methods, and rather than start a new thread when it's finished, I went ahead and adopted the "Released" thread template for this, so that I can simply request it be moved. So for now, the purpose of this thread is mostly discussion and C&C, rather than distribution. But the pending content will be filled in within a relatively short timeframe as progress continues.

Change Log

Code:
 

# v0.01 - Lighthouse

#

# Added the Service_Locator, along with a Provider_Base template.  The service

# locator will be the most centrally used class in the entire project, as it

# provides a nuetral and extendable way for the entire engine to communicate.

#

# Added Provider_Scene, a basic implementation of a scene stack.  Also added a

# Scene_Title.  Title is quite obviously nowhere near completely implemented,

# it's more of a shell to test the locator and provider system with at this

# point.

#

# Refactored RGSS slightly - rewrote main, split some features into "initialize"

# and added RGSS.dispose - this method is now called to exit the game.

#

# Some people are not used to a scene stack - by itself, it changes nothing.

# Simply pop the scene you are leaving, and push a new scene during the same

# game loop.  Should you not provide a new scene, the game will end.  However

# the scene stack allows an interesting expandability - that is, you can now

# have subscenes.  For example, if there is a real-time countdown happening, it

# can easily carry over across multiple scenes by being designed as a subscene

# and pushed onto the stack as an additional layer. Do remember to dispose the 

# scene before removing it, if appropriate.

#

# Added priority macro to scenes.  As a "true" stack would be hard to manage

# with an extension system in play, scenes have been instead given priority,

# updating in order from priority: LOWEST to priority: HIGHEST.

#

# Also added RGSS.set_initial_scene and RGSS.get_initial_scene.  Simple getter

# and setter methods for the scene that the engine will start with. Can be used

# to, for example, start with a splash scene instead of a title.

#

# Removed the terribly hackish Environment script.  Still a one-line hack at

# the end of the RGSS script to inject the main callback, which I will hopefully

# come to a better workaround for.

#

# Added Input.update and Graphics.update to the main RGSS loop - these are not

# scene dependant any longer.  This will make multiple-scene scenarios easier,

# as well as being more reliable as these will always be updated - it's not a 

# variable thing.  Freezing causes Graphics.update to be ignored.  This does

# prevent "hanging script" from firing under some circumstances - but a proper

# script should not have any chance of infinite loops anyway.

#

# v0.00 - Origin

#

# Removed the "Main" script, for simplicity's sake and so that novices can

# simply drop scripts at the end of the list instead of "...but before Main".

#

# Added the Extension base class, which all extensions (a.k.a. "scripts")

# should extend. This provides registration services, and will later provide

# other useful features for developing your extensions.

#

# Added the Extension_Example, using a layout that follows the Ruby Style Guide

# (thoughbeit somewhat loosely).  It will demonstrate the intended way to

# leverage Clockwork RGSS to create capable extensions.

#

# Created the "RGSS" module.  This will serve to store some basic versioning

# information, as well as taking care of extension registration, and a few

# utility features, such as housing our "main" method.

#

# Created the "hackish" Environment script - this script unfortunately does not

# currently conform to the project standard - in fact, I created this script to

# temporarily house features which I have yet to decide on how to make

# compliant with the project standard.

# 

# Added this readme, containing the license and a verbose changelog.

 

Future Plans

None. It is as you see it here.

Terms and Conditions


This work is licensed under a Creative Commons Attribution 3.0 License.
Attribute to: avarisc (http://www.avarisc.com/)
 
So I'm developing a total replacement for RGSS. Well, honestly, it's more of a reimplementation - it's based almost entirely on the original, only written to follow a much more dynamic model, as well as addressing several of my own nitpicks. Most importantly, I just feel it will be amazing to have an RGSS that can be updated to see new features or improvements released over time.

I've been experimenting, tweaking, and remodelling my Event_Listener setup for days, and have come up with several interesting tricks for RGSS. As converting the entire engine will take time, I'm going to break this into pieces and tackle a few a day, but doing my best to keep the engine operable the entire time. So basically, like doing surgery. ..... ..... ...that analogy made sense in my head.

I'll be going through the scripts list a couple scripts at a time and assimilating them into Clockwork. I can't suggest valiantly using the new API until the entire engine is converted and marked as a release, but at the same time I want critique and feedback on this, and noone is going to read 20,000 lines of code at once, so I figure this makes it more digestible for those interested anyhow.

For the pre-release, I'll be using RPG Maker XP to do my scripting (though I'm cross-referencing all 3 to make sure I don't somehow try to release an inferior RGSS, lol). I'll release the in-progress project as a Scripts.rxdata - if anyone is interested to review my code and does not own RPG Maker XP, or would prefer an .rvdata or .rvdata2, please let me know as I would gladly take a moment to provide these upon request.

The ideas (not plans)(IDEAS NOT PLANS!) I have for the future involve merging this project with my RGSS DLL reimplementation (viewtopic.php?f=6&t=78173). The few rough edges on the DLL would be easily smoothed out if I made edits on the Ruby end of things as well. Not sure if it will go that far or not, but the possibilities for this are limited only by how engaging this project turns out to be for me.
 
v0.00 - Origin

Whew. A couple hours later, here's version 0.00. Note that I have restarted since the Event_Listener progress, as I had decided a couple fundamental changes before proceeding and decided to make them immediately rather than waiting for a major refactor at a later point.

Changelog:

Code:
 

# v0.00 - Origin

#

# Removed the "Main" script, for simplicity's sake and so that novices can

# simply drop scripts at the end of the list instead of "...but before Main".

#

# Added the Extension base class, which all extensions (a.k.a. "scripts")

# should extend. This provides registration services, and will later provide

# other useful features for developing your extensions.

#

# Added the Extension_Example, using a layout that follows the Ruby Style Guide

# (thoughbeit somewhat loosely).  It will demonstrate the intended way to

# leverage Clockwork RGSS to create capable extensions.

#

# Created the "RGSS" module.  This will serve to store some basic versioning

# information, as well as taking care of extension registration, and a few

# utility features, such as housing our "main" method.

#

# Created the "hackish" Environment script - this script unfortunately does not

# currently conform to the project standard - in fact, I created this script to

# temporarily house features which I have yet to decide on how to make

# compliant with the project standard.

# 

# Added this readme, containing the license and a verbose changelog.

 

Download:
As mentioned in the first post, it is distributed as a Scripts.rxdata. If you require another format, please let me know and I will export them upon request.

This is nowhere near a useable product - it is being shared pre-release, for critique and review purposes. Please share your thoughts! :)

It currently has a couple debug prints in there, just so that I could tell the system is functional. Obviously these will be long gone before any formal release.

http://www.mediafire.com/download/u0kjub92noz8wqb/Scripts.rxdata
 
v0.01 - Lighthouse

Still working on it. Just got back from a very long weekend. Here's the update.

Changelog:

Code:
 

# v0.01 - Lighthouse

#

# Added the Service_Locator, along with a Provider_Base template.  The service

# locator will be the most centrally used class in the entire project, as it

# provides a nuetral and extendable way for the entire engine to communicate.

#

# Added Provider_Scene, a basic implementation of a scene stack.  Also added a

# Scene_Title.  Title is quite obviously nowhere near completely implemented,

# it's more of a shell to test the locator and provider system with at this

# point.

#

# Refactored RGSS slightly - rewrote main, split some features into "initialize"

# and added RGSS.dispose - this method is now called to exit the game.

#

# Some people are not used to a scene stack - by itself, it changes nothing.

# Simply pop the scene you are leaving, and push a new scene during the same

# game loop.  Should you not provide a new scene, the game will end.  However

# the scene stack allows an interesting expandability - that is, you can now

# have subscenes.  For example, if there is a real-time countdown happening, it

# can easily carry over across multiple scenes by being designed as a subscene

# and pushed onto the stack as an additional layer. Do remember to dispose the 

# scene before removing it, if appropriate.

#

# Added priority macro to scenes.  As a "true" stack would be hard to manage

# with an extension system in play, scenes have been instead given priority,

# updating in order from priority: LOWEST to priority: HIGHEST.

#

# Also added RGSS.set_initial_scene and RGSS.get_initial_scene.  Simple getter

# and setter methods for the scene that the engine will start with. Can be used

# to, for example, start with a splash scene instead of a title.

#

# Removed the terribly hackish Environment script.  Still a one-line hack at

# the end of the RGSS script to inject the main callback, which I will hopefully

# come to a better workaround for.

#

# Added Input.update and Graphics.update to the main RGSS loop - these are not

# scene dependant any longer.  This will make multiple-scene scenarios easier,

# as well as being more reliable as these will always be updated - it's not a 

# variable thing.  Freezing causes Graphics.update to be ignored.  This does

# prevent "hanging script" from firing under some circumstances - but a proper

# script should not have any chance of infinite loops anyway.

 

Download:

https://www.mediafire.com/?8t3zeumbn3qpz8a
 
I'm happy to see people still working on fixing up the RGSS so many years later! I'm still debating coming back to the RM scene for some projects I have in mind, but if this takes off I'd be happy to try it out.
 
regi":39jtir38 said:
I'm happy to see people still working on fixing up the RGSS so many years later! I'm still debating coming back to the RM scene for some projects I have in mind, but if this takes off I'd be happy to try it out.

Welcome back-ish! You should come back - RM does have more viability than it seems, and I'm hoping this project will prove just that. I'm currently working on a massive re-basing of the project, which I hope will remove the glass ceiling over the engine.
 
I need some community input here - Which resolution do you like better? RPG Maker XP's 640x480, or VX/ACE's 544x416? Or something else?

I'm trying to design Clockwork RGSS to be adaptable to any resolution, but I want there to be a standard. While Clockwork supports any RPG Maker editor, it will in fact be an entirely different "engine" so to speak. As screen resolution is not directly relevant to which editor you use, I want default resolution to be standardized across versions.

For reasons I'm not ready to mention, I'd also like to consider mobile-friendly resolutions.
 

KGar

Member

So, I decided to take you up on that offer to say Hi. Hello!

Actually, I'm just now getting started with RGSS3 (and RGSS in general), and I wanted you to know that I joined this forum almost exclusively to encourage you in your current endeavor with Clockword RGSS. I was searching for Event Listening capabilities for RMVXA because I could tell that the Alias Stacking method would get unwieldy really fast. One thing led to another, and here I am!

Even to a newcomer like me, it is easy to see that this is a really promising project, and I plan to follow it as it grows. I'll be here to discuss with my very limited knowledge of Ruby and RGSS. But who knows? By the time I'm really on my feet with Ruby, I can help in some way or other.

Best of fortune to you!
 
I appreciate the feedback, thanks!
It's on hold at the moment because I am working on a commercial project that is sapping virtually all of my free time. That said, I'm glad to hear there's interest in this, I do intend to come back to it soon.

Thanks again, your message is very inspiring and will help me prioritize this in with my other obligations.
 

Thank you for viewing

HBGames is a leading amateur video game development forum and Discord server open to all ability levels. Feel free to have a nosey around!

Discord

Join our growing and active Discord server to discuss all aspects of game making in a relaxed environment. Join Us

Content

  • Our Games
  • Games in Development
  • Emoji by Twemoji.
    Top