Scripting discussion (split from Saving Event Positions)

This forum is for off topic posts not related to Open RPG Maker.
Forum rules
There's only two rules for this forum. 1) No spamming of any kind (doing so will result in the deletion of the post, and the permanent banning of your account). 2) No flaming others (doing so will result in your account being banned for 30 days, repeat offenders will be permanently banned).

Scripting discussion (split from Saving Event Positions)

Postby DiggingStraightDown » Fri Jan 24, 2014 6:13 am

I would say, this is really one good instance in which a scripting system is necessary for expected functionality. An eventing system is great, but eventing-turned-scripting would enhance it even more, even if I haven't really delved into the full capability of scriping in the VX Ace program. (Yes, I know, Tuxinator; you aren't wanting to do a Scripting system (at this point in time, anyway); but I'm including some of the reasoning why I think it could help to have it. Compared a bit with how RPG Maker etc might do... Some of my examples might be better as scripts but could do equally well as event code.)

In my case, I would ask for event handling for the maps. I have maps (towns and building internals) where I want to process things in an "almost scripting" manner, regardless of the events themselves. If you don't want outright Scripting, Tuxinator, could you consider allowing for maps to contain prototypical event pages for the following usage-cases?
  • BeforeMapLoad: before the map is loaded/entered. A village might have a basic map used for the first part of the game. If a game is organized by "Chapter", the game would likely have variables for if the village map being entered is razed to the ground by a villain. In such a case, I would use a conditional branch to test for what "chapter" the game state is in, then I'd only need to tell the engine to load a different map when the current game state requires it. A secondary function of this would be for setting up where the events are on the map, their mobility, and even visibility and other states (treasure chests already opened, fixed-objects pushed to new locations, et cetera). Events representing NPCs could be disabled/hidden before the map is loaded, eliminating the possibility of events appearing even for a fraction of a second before disappearing.
  • OnMapLoad: during the map loading/entry. A village, again, would have a few NPCs idly walking around, and their position and mobility might be changed depending upon game chapter. (Conversations/interactions can and should still be a function of the events themselves.) Alternatively, a destroyed village map/site (as mentioned above, that is "destroyed" in one chapter) could have monster encounters on that destroyed map, perhaps even until a later chapter, where the destroyed village could have a minimal re-settlement attempt is begun, with the relevant NPCs hidden until that time.
  • DuringMap: while the map is active. This might be used for the simple usage-case of always determining, via a conditional test of variables, whether the player has moved so that the X or Y position(s) are greater than or less than a specified value. For constraining certain events based upon player location and not
  • BeforeMapUnload: before the map is unloaded/exited. If we need to check for a "special event" to occur before exiting a map, such as ensuring an NPC calls the player or some other linked event state, it could be tested in a conditional branch using the necessary variables, player states, et cetera. I might have a member of the party which has not joined yet, sitting in a bar or idling in the town square; but as soon as the player attempts to leave the map, that event representing the unjoined character would run over and ask to join.
  • OnMapUnload: during the map unloading/exiting. Any variable or boolean condition that hasn't been set yet could be handled here. Basically, this would be like BeforeMapUnload, but it is for after it is determined that we are successfully leaving the map.
Or something similar. I note that RPG Maker VX Ace Lite does not have this eventing system for map entry/exit, such as what I describe; instead, in that case, handling for position, movement, and even visibility are left to being specified in the event's pages themselves (and I assume the same for this project). It would be good if we could "streamline" or optimize the handling of map-based situations, so that -- for example -- a three-block-wide exit path does not have to use three copied transfer events, but one DuringMap event that would check for that. I would say I'm a proponent of eventing and scripting in their proper utilization.

Apologies in advance if this seems like a "too long" post; please "do read". I tend to go into detail when I've got an idea I wanted to share, and I hope my thoughts are worth at least an honest appraisal.
DiggingStraightDown
 
Posts: 38
Joined: Fri Jan 17, 2014 8:17 am

Re: Saving event positions when exiting map

Postby Tuxinator » Fri Jan 24, 2014 6:48 am

Open RPG Maker does in fact have an OnMapLoad event. This takes place after the map is loaded and before it is rendered. Some of the other things you're suggesting could easily be done with minimal eventing.

For example not having a 3 tile wide town exit contain 3 duplicate complex events is simple, instead you have a single event off in the corner of the map with it's trigger set to "Action Key" (although I will be adding the "called from other event" trigger just like the common events have), and the various exit points would simply call that event when the player steps on them.

Next the DuringMap events are the same as a single "Parallel" event placed off in the corner, which sits there and runs it's event code until the player leaves the map, or until it tells the engine to stop (ie. "End Event Processing", or "Erase Event")

The map unload commands can again be placed in the same event that's called when the player steps on any of the exit points to the map.

What you're describing here is essentially before the map even gets loaded by the engine it could have a chance to tell it to in fact load a completely different map (although that's not even necessary here, since you can use the OnLoadEvent and clever usage of layers to have different chapters). As an example here I've been experimenting with re-creating some key concepts from Final Fantasy Mystic Quest since, while not being that great, it did have some interesting, and useful, gameplay elements. One such example is the overworld changing slightly as you complete each of the four major bosses (this is achieved by having multiple layers for the different states and simply hiding the rest and showing the correct one OnMapLoad, which ignores the transition effect and simply turns that layer on/off before the map has been rendered for the first time).

Basically my main stance on the scripting support has always been thus: wait until 100% complete then see what it can do (I really don't appreciate Open RPG Maker getting constantly viewed as just another RPG Maker exactly like exitbrain's). The only real talent they have in this is their art assets, otherwise each one after 2003 has gotten progressively worse, while also making the user basically program their entire game with scripts since the editor/engine are barely capable of even handling a somewhat decent battle system anymore. To that effect there's three major things that really separate them from Open RPG Maker thus far. First off is the multy-layering support (I'm not even sure if XP/VX/VX Ace could even do that without some completely whacked out scripts and painful editing processes). Second is the fully featured Menu Editor (again something not achievable without scripts in the others without scripts and a slow and painful editing process). Third is the Phase Passability, which may not seem like much at the moment, but once the engine has been brought up to speed I will be putting up a demo project that shows off the true power of that system (liking having a pair of boots that, when equipped, allow you to walk on lava, or an item that once obtained allows you to swim in the ocean without needing a boat).

I admit that there are some things that may never be doable in Open RPG Maker without scripting support, but so far the only such things I've encountered only point to the fact that you are far better off learning to program and using a more full featured engine like Unity, Ogre, or some of the others out there, especially since people seem to be fairly well hung up on making non-RPG games using an RPG Maker and are thus complaining because mines better if it only had scripting.

The bottom line is if you would rather have scripting then consider using one that already has it, since I'm not trying to make Open RPG Maker "like all the others" The fact that Open RPG Maker has become so amazingly powerful and complex, while still maintaining a level of simplicity is because I refuse to turn it into just a simple free and open source alternative to the RPG Maker series. It's in that major difference that has lead to some really powerful features being implemented instead of being tossed aside in favor of scripting since hell you can do the same thing yourself if you had scripting.
Tuxinator
Site Admin
 
Posts: 300
Joined: Wed Sep 05, 2012 8:51 am

Re: Saving event positions when exiting map

Postby DiggingStraightDown » Fri Jan 24, 2014 2:54 pm

Using separate layers for separate chapters/ map states? Wow. Interestingly enough, I had not considered using them in such a fashion; it is an ingenious idea.

Regarding being compared to RPG Maker, in any of its iterations -- I understood everything you wrote about it; I really do. I understand the frustration of "something or someone being compared to something it's not". While I wouldn't say most people think this is "just another RPG Maker" exactly like the competition, I personally don't feel it's so bad to be compared to in terms of what they are (or were, whatever the case). In one sense it could be a chance to "outdo them at their own game", by providing a stable open-sourced alternative; and in another sense it could still be going beyond where they left off (with or without scripting, though I know that will be a pain point for your target audience, anyone familiar with RPG Maker, et al) -- since, as you say, "each one after 2003 has gotten progressively worse".

... I have no words for that....

Anyway; I looked again at the original post of this thread, and the response to your reply. I can see a potential solution whose implementation could be beneficial to that.

In my test RPG Maker VX Ace project (sorry for any comparison, but it's my frame of reference, and how I explain), I could have a series of dungeons or underground tunnels that interconnect; consider a complex pathing issue. Map A could have a Path 1 (entry on the north, exit on the east) as well as a Path 2 (entry on the west, exit on the south); but neither interconnect. A series of surrounding map tunnels could link the two in some nebulous manner. Map B and C could also have similar interconnectivities. Now, what if something pushed or activated on Path 1 could have consequence on Path 2 on the same map -- but only by leaving Map A and traveling through others could the player get back to Path 2? (I remember seing this done in some games I've played in the past.)

The question seemed to be, How to save the states of object or evented positions? (And "without setting up hundreds of dummy events", I guess. Literally? Tell me, how many have you made?) It's not so easy to figure out the most optimized manner (other than that the methodologies I listed in the previous post would be of benefit) to store or retrieve an object's position, state, visibility, etc; some things can only be simplified so far.

In my VX Ace project (again, sorry in comparing; I'm trying to explain this all) I see that it has a whole long list of boolean switches, integer variables, player conditions, items and equipment, ad infinitum; and I also see this editor program allows getting/setting/testing of the same. What I would suggest to Rave is to use two variable slots for each object's position (X and Y), update them when the object moved (so it'd be stored and retrievable later), and then figure out some way to get these values when loading the map, and set the object position.

A possible inefficiency, in my humble opinion, seems to be that all these Switches and Variables and States, Oh My! seem to be "global" in nature (are they ever really ever unloaded, until the game session ends?); that is, they will be publically visible to any other map and event currently loaded. Even when on maps that don't use them. Potentially, a waste of memory and computational cycles, when a list of values are in-memory but perhaps only used in a map that a player might only be on in, say, five percent of the time, to give a conservative estimate. An enhancement or extension to this implementation (where Enterbrain left off) would be to design maps as having defined those boolean and integer entries that are used only on that map.

Now, I am not saying that the global list of variables is no longer necessary; I would always see a need for such values. It's just that I might suggest keeping a global list trimmed to only the variables and switches that are truly used in multiple locations; and extract those variables and switches pertaining to just one map, to that map definition. I would imagine, on the engine side, it might take a few more milliseconds to load and process the separate stack of values, but in my case I would prefer that to "variable-bloat" that I see in the VX Ace project I'm working to test out my ideas.

@Rave:
Regarding making a town "feel alive". I guess, I have always just "taken in stride" the fact of people's placement and the design of the random-movement code. But upon further thought, I do have at least one suggestion for that, if Tuxinator would care to take it in consideration. It's based upon setting a new movement-randomization mannerism; the NPC/event could have a "fuzz" factor or offset from the initial starting point; also, a maximum distance from the starting point that it can or should try to stay within (either on the X or Y plane, or for any distance from starting computable via Pythagorean function).

Where you create each event is its starting point; a "fuzz factor" would be one way of artificially inducing a semi-random initial placement, a reasonable constraint to "stay within this distance" on map loading. A maximum range would be an ultimate distance limitation that controls how far from the start point the NPC/event could travel, before being forced to turn ninety degrees perpendicular to the last movement direction, or perhaps even one hundred eighty degrees, in order to move back toward the starting point, the "epicenter". (Which brings forth another question: is random movement really so serious a concern for most cases?)

So, say I have a semi-busy city street mapped, and a small set of event/NPCs set to random movement. The street runs west-east, is five blocks "tall" on the screen, and is perhaps a couple dozen blocks long -- though perhaps a north-south street crosses it nearby. If an NPC is placed in the vertical middle of the road, and given a "fuzz factor" of (oh, let's be generous for the example) five, and a maximum range of twelve ... I could see a decent range of movement, for some considerably decent addition to the editor (and by extension, the engine).

And finally, about the people being "where they were when map was exited" ... depends a lot on an idea of "map scale". By that, I mean, in my own workings I've imagined different maps as being "worth" a different "time scale" (if only because of different distance scales). Moving one square on the world map is "worth" a few hours to a day; moving a square on a city-street/building-exterior map is "worth" a few minutes; and moving one square inside a building is "worth" perhaps a few seconds. So if you exit from a city into the world map, move a few squares, and go back into the city map, it shouldn't be too hard to understand that this "person" is about in the same place as before. In reality, most people do most activities within an almost unbelievably-small radius of where they live. The game maps we make are, after all, simply an abstraction of the "much larger" pseudo-world we are creating for the sake of the game.
DiggingStraightDown
 
Posts: 38
Joined: Fri Jan 17, 2014 8:17 am

Re: Saving event positions when exiting map

Postby Tuxinator » Fri Jan 24, 2014 9:09 pm

The main issue I have is that scripting is by no means necessary, it's just that without it some things simply can't be done (like dynamic 2D lighting) until they've been hard coded into the engine/editor. The comparisons you've been making to the other makers is simply showing an example of how it is usually done in them, and how Open RPG Maker's will hopefully be a lot easier to do. Scripting has simply just become a bit of a sour topic for me, since I've gotten lots of e-mails, and hate mail on other forums regarding the lack of scripting. Of all these only one person gave me a reason why I should implement it, and his only reason was because RPG Maker XP/VX/VX Ace all had it. The comment about them getting progressively worse is relevant to how little you can do without resorting to scripting. As an example use RPG Maker 2003/XP/VX and try and make a complete (somewhat unique) game without touching a single script, and only using the ones that are distributed with the program (no 3rd party scripts). You will then begin to see that the better the scripting system got the worse the rest of it became, to the point where VX Ace is pretty much just a glorified map editor, and that's why still to this day 2003 has had far more user contributed art assets and is still getting a lot of user contributed art assets, even though of 2003 and above it had the worst graphics.

As for the local switches/variables I had already thought about doing something like that, however there's some major problems. When the player leaves the map the map get's completely unloaded (obviously), however if these local variables and switches need to have their states saved then where does it save that information. The player hasn't saved their game yet, so the engine has to keep them in memory anyway. Think of it each map as a separate program with the variables being unsaved data. The player may need to go to program B to do something so they can continue moving forward in program A, however if they don't save the changes made in B, then they have to go back. So where would the changes be saved, because it can't be saved to the actual save files. Having 5,000 switches loaded in memory at all times is still not that much memory (as a comparison 5,000 switches is about 5 kilobytes of data, whereas 1 map is several megabytes depending on how large it is, and 5,000 variables is still only about 20 kilobytes). Computers today typically have at least 2 gigabytes of RAM on the low end, so that extra ~30KB isn't really much and I've yet to see a game that actually had 5,000 switches and variables, but it is possible (I shudder at the thought of managing them, no matter how you slice it). The way I see it is to have all variables/switches loaded at all times and then have some be flagged as local to the map/event. This way when a variable operation occurs it can choose what switches/variables to modify. Programming wise it's rather simple to implement (although designing to interface to be simple and intuitive might take a minute) so it's very easy to do and allows for better organization of variables.

Ultimately if Open RPG Maker does end up being phenomenally better than the other makers that would be awesome (and with it being open source it would be extremely difficult to compete with it after that). However I choose not to design Open RPG Maker based on the others (for the most part, since it was inspired by them). Where it's gotten now has led me to really take off with it and have the chance to make it it's own thing. Keep in mind this feature may get implemented, but it most likely won't be until the engine is up to speed. I think right now I'm going to focus on fixing the current features (almost done with the last step of improving the phase passability system to have individual directional control) and then getting the engine up to speed.
Tuxinator
Site Admin
 
Posts: 300
Joined: Wed Sep 05, 2012 8:51 am

Re: Scripting discussion (split from Saving Event Positions)

Postby Rave » Sun Jan 26, 2014 1:18 pm

I've took liberty to split it since it was generally offtopic, but interesting enough to keep it in the forums.
Image
We are Linux. You will be assimilated. Resistance is futile.
User avatar
Rave
 
Posts: 179
Joined: Fri Sep 21, 2012 9:29 pm

Re: Scripting discussion (split from Saving Event Positions)

Postby redspark » Thu Jan 30, 2014 9:54 am

Personally, myself, the only line of argument that seems valid for scripting is the concept of customization. Scripting gives the user the power to make the game unique and thus stand out from the rest of the games made with the same engine. The problem with games made from an engine that doesn't have a scripting language, is that they all seem very similar. Other than graphics and the story, other portions such as the interface, battle system, rules, etc. are all nearly the same.

For instance, what if I wanted to (and I actually do want to) make a battle system that is governed by the outcome of a match 3 Bejewelled type game or a hand of poker or a tower of defence. This would be impossible without scripting because something like that was never intended by the original author of the engine. The game developer wants to use all of the other features that your engine offers but the lack of scripting would prevent him from being able to make the engine his own. He would have to make the request to have the engine customized to add in the new options that he wants or download the source code and make the changes himself. Generally speaking, a scripting language will also protect the user from platform dependent coding because the engine provides all of the functions needed to interact with the platform through scripting. This means that the same script will work the same on all platforms that the engine compiles on. This would shield inexperienced developers from having to make changes to the game engine.

Thus, the engine itself is not just a map editor. It can focus on cross platform compatibility, optimal data storage/structures and efficient retrieval, editor customization through plug-in expansion, as well as asset management/protection and speedy script execution, plus the base/core script for the standard game. This is the approach used by many game engines that are not in the RPG Maker series (Sphere RPG, Adventure Game Studio, etc.). RPG Maker was not the first to use this approach and probably won't be the last. And, yes, scripting is a Jack-hammer and too many people whip it out at the slightest whim when the editor can be used to do what they want. This is an unfortunately drawback.

I'm not saying that you should do it. I'm just saying that this would be the only line of reasoning that I can think of for a scripting language that can't be solved by a hardcoded engine/editor. If the purpose of Open RPG Maker is to stick closely to the 2003 version, then scripting shouldn't be included. However, you already have plans on adding features that are improvements over the 2003 version.
redspark
 
Posts: 10
Joined: Fri Aug 16, 2013 1:33 pm

Re: Scripting discussion (split from Saving Event Positions)

Postby redspark » Thu Jan 30, 2014 10:53 am

As an example use RPG Maker 2003/XP/VX and try and make a complete (somewhat unique) game without touching a single script, and only using the ones that are distributed with the program (no 3rd party scripts). You will then begin to see that the better the scripting system got the worse the rest of it became, to the point where VX Ace is pretty much just a glorified map editor, and that's why still to this day 2003 has had far more user contributed art assets and is still getting a lot of user contributed art assets, even though of 2003 and above it had the worst graphics.


I think this isn't quite a complete/correct conclusion based on observation. There may be other factors not taken into consideration here. First, the more the engine relied on scripting, the more onus was placed on the end user who may be intimidated by programming and thus stuck to 2003 because it was easier to get their head around. This is not an issue with scripting but an issue with education. We don't stick to using an Ox and Plow because we don't know how to drive a tractor. There is also the nostalgia factor at play. There are always going to be ones who say that the Ox and Plow makes them better farmers and perhaps they are right. But not everyone would agree with them.

Second, the rest of the engine didn't get worse because of scripting. It got worse because of poor choices and feature implementation by its maker. There were some great improvements for productivity in VX's editor but they were overshadowed by VX's feature inadequacies. It wasn't the scripting engine's fault that they reduced the resolution or that they simplified the mapping tools. These both existed in RMXP. RPG Maker XP should have been the basis for VX. They should have improved the resolution (not reduced it), hardware accelerated the graphics with OpenGL, modernized the audio, improved script execution with a good implementation of Ruby 1.9, gone cross platform into OSX and Linux, added mobile runtime engines, added native mouse or touch screen support, developed a multi-threaded, template driven RGSS, added plug-in expansion to the editor and yet stayed backwards compatible where possible. Indies would have drooled over something like that.

However, to conclude VX was a flop based on its scripting feature alone, would be stretching the truth. It may have been a factor but for me, there were other reasons. I don't think I'm alone in them. I still prefer VX. I just wish it were cross-platform with the above features. Even just cross platform with an improved resolution would be far superior to VX.

Adding scripting doesn't mean that you need to reduce the editor to just a barebones contraption. You can improve the map editor with auto-mapping features, more layers, or dynamic tile resolutions or even get into 2D splatting (I think it's called) rather than tiles for making maps. Try a different approach to scripting where the user can expand the editor with plugins that can store data for their own data structures that they created in Ruby. Or how about adding a GUI editor so that you don't have to design your own GUI by code? Or what about other means of graphical code generations? These things can go a long way to making the developer more productive without making the engine overly complex for him to use. The editor focuses a lot on the scripting portion but should allow itself to be expanded also by the scripting too.
redspark
 
Posts: 10
Joined: Fri Aug 16, 2013 1:33 pm

Re: Scripting discussion (split from Saving Event Positions)

Postby Tuxinator » Thu Jan 30, 2014 12:31 pm

See it's that line of reasoning behind your ideas for different battle mechanics that don't really have me convinced of scripting support. The problem is that the features most people are wanting to use that can't without scripting are things beyond the scope of Open RPG Maker. The more generic and less cookie cutter a program gets the less powerful it becomes (powerful in the sense of how much it can do at one time, as opposed to how many different things it can do). Some of the key points that Open RPG Maker has a good balance of to help eliminate that cookie cutter feel 2003 had is the clever enhancements to the event system, as well as a fully featured menu editor. The battle system will be easily customizeable with the ability to adjust the algorithms used for damage calculation as well. Also there's the yet coded screen overlay mechanic, which I have some vague ideas on how I eventually want to do it, but basically it would use the same advanced event system coupled with custom drawing routines that all use the already familiar event system editing style. In essence the event system is far closer to scripting than what the others had, and that's one way it really helps balance the lack of scripting without making everything too cookie cutter. There is also plans for customized stats that you can add and use in the battle calculations (for example a player gains a level there could be a stat that says how many points it gets after each level, and then those points can be spent much like Diablo had, because of the menu editor it becomes an easier thing to accomplish then either writing out a custom script or a very complex event system using the "Show Picture" event like I've seen done (and done myself) in 2003's event system.

The bottom line with regards to scripting is this: Is there a beneficial feature that would be better left to scripting, but still fits within the scope of what Open RPG Maker is designed for.
The short answer is: Yes, but the only reason for doing so is to save time on my development, and instead let users do all the coding for it.

Again a proper argument for scripting support really can't be made until after the program has reached the 100% feature complete status (where there's still features to be added, but you can make and play a full game). The reason for this is that Open RPG Maker is just far too different and more powerful on all other aspects that it's just too difficult to explain or comprehend the power of systems that have yet to be implemented, but are fully fleshed out in my head.
Tuxinator
Site Admin
 
Posts: 300
Joined: Wed Sep 05, 2012 8:51 am


Return to Other Realms

Who is online

Users browsing this forum: No registered users and 1 guest

cron