Jump to content

  • Log In with Google      Sign In   
  • Create Account





Title?!? What Title?!?!? A Few (Brief) Thoughts.

Posted by Gregory Cheyney, in Alternative RPG Maker 13 August 2014 · 291 views

ARPGM alternative rpg maker screenshot thinking speculation
Title?!? What Title?!?!? A Few (Brief) Thoughts. Just a general question to begin; how often are screenshots desired, and what is a decent number of images per screenshot post, before the viewer starts to get sensory-overload? I'm considering adding the occasional screenshot, with the proviso that "features may change before release". In my opinion, I'd try to give a screenshot or two, at least every third or fourth post, more when necessary, with a likely cap of four screenshots per post, max. But, on to other matters; a bit more of a description of some of the things I intend for my ARPGM.

First, the most noticeable of the competition is that game-creation seems to be a solitary act -- Enterbrain's makers are fairly good at presuming it's just one person making a game; however, I know from reading the English rpg-maker forums that it's somewhat of an economy of asking for project help, and recruiting for the project. I am hoping to include some form of versioning for project data, for those who wish to split development to specific persons on a project. So, it will no longer be so solitary. Also, support for I18N/L10N (allowing a game-maker, et al, to provide for game accessibility and translation to additional language-speaking players).

Second, is the fact that I do want to support larger screen dimensions than Enterbrain's products; although to make it make sense, it will be a per-project setting where the game-maker can specify minimum, maximum, and default resolution ranges, so that it makes sense from the developer's point-of-view. One game-maker (herein abbreviated GM) might make a project title screen for a 800x600 resolution, while another might go for the 1280x1024 -- and I need to keep track of that on a per-project level. As well, in multi-GM projects, settings for testing fullscreen versus windowed is important, as well as various other editor state-remembering factors.

Third, adding new aspects from a particular "Suggestions for the next RPG Maker" forum thread-listing. To me, it does make a little bit of sense to also include a Database tab for specifying Races and Genders, so that further specifics of Character creation and eventing can be implemented. I know that some GMs wish they could make certain classes dependent upon certain races or genders, or even inaccessible to certain others. It would also be nice to be able to check in the Events whether a target character is Male, Female, or even Neuter -- like Final Fantasy Tactics, seducing enemy NPC with "Vixen's Whisper" or other skill....

Fourth, some aspects of an RPG Maker will remain similar to what people are "used to using"; but some things will by necessity be different, due to how I may implement my ideas for such. The items list, for one; I want armor, weapons, and consumables to all be in one Database tabbed hierarchy, but I also want it to make sense, in the implementation. Armors can be sub-typed, and weapons are most definitely categorizable by manner of use or form. As well, I also am planning to allow for a default implementation of Item Crafting to be included -- with item ingredients, recipes, tools or utensils, et cetera.

Fifth, Eventing and Scripting. Yes, I want to provide both, but I am still figuring this out. Events are a must; I have several ideas on that end. Scripting is desired as well, but this needs a little more thinking -- along the lines of which scripting language would better go with a Java-based application, and therefore either be natively supported in Java or have a class-library to implement these features. Then, figure out how it works on the editor side and engine side. Actually, I do have a decent idea that will work in the editor part, of how to store and write the scripts, but since the engine part is behind in percent-completion, it'll be a while until I can test it.

In conclusion, I have more ideas than this; I just wanted to start with a few aspects, to keep in touch with people following this journal, as well as allow for input where you have ideas or questions for me. The image included is of the main editor UI, using FXML with CSS for styling.




Just a general question to begin; how often are screenshots desired, and what is a decent number of images per screenshot post, before the viewer starts to get sensory-overload? I'm considering adding the occasional screenshot, with the proviso that "features may change before release". In my opinion, I'd try to give a screenshot or two, at least every third or fourth post, more when necessary, with a likely cap of four screenshots per post

 

That sounds pretty reasonable.  I've noticed that members who share screenshots seem to draw more attention -- even to their entries that don't actually contain images -- I guess maybe a screenshot is an easy way to get people interested and encourage them to actually read the text.

 

 

Versioning to allow easier/better collaboration sounds like a fantastic addition!

 

Just a general question to begin; how often are screenshots desired, and what is a decent number of images per screenshot post, before the viewer starts to get sensory-overload? I'm considering adding the occasional screenshot, with the proviso that "features may change before release". In my opinion, I'd try to give a screenshot or two, at least every third or fourth post, more when necessary, with a likely cap of four screenshots per post

 

That sounds pretty reasonable.  I've noticed that members who share screenshots seem to draw more attention -- even to their entries that don't actually contain images -- I guess maybe a screenshot is an easy way to get people interested and encourage them to actually read the text.

 

 

Versioning to allow easier/better collaboration sounds like a fantastic addition!

 

Yes, fantastic -- although, a bit nerve-wracking for me, as I've never worked with developing a versioning-system before. My assumption is that I would use an existing class library, and just add the UI for project-versioning on top of it. If it's at all more involved than that ... I'll be befuddled and addled.

 

Though I also suspect collaboration means more than just version control, but for the most part it is regarding communication (I assume each project participant would have their own chat clients, email, and document-sharing solution).

 

That said, thanks for the feedback on screenshots.

Latest Visitors

PARTNERS