Saturn's Brain Dump

[Saturnity 60]

Hello you lovely people!

 

Soooo, I have a mind that goes in 50 directions at once. I'll be thinking about new eventing systems for my roleplay one second, then how much I love this cookie I'm eating the next (it's delicious by the way, so be jealous, very jealous. <3). If there's one thing I hate about my thought process, though, it's that I'll lose track of what I was thinking about before I went off track and not be able to remember it. I'm going to use this thread to (kind of) store my ideas and concepts as I make them. I'll also be including any current progress and/or roadblocks I've run into in the design process.

Anything I feel is worthy to throw in here is open for critique, suggestions, questions, and open source usage/testing. (Donations in the form of hugs, kisses, and anything delicious are are always welcome though   ) If I post any completed concepts, feel free to ask for a more in-depth explanation, or even a tutorial on how to make the idea/system work properly, and I'll do my best to help. I'll even throw in a free hug if you're really needing a confidence booster <3

By the by, the by, these ideas are almost solely based around eventing. I have no scripting knowledge whatsoever, but if any of these ideas require a script to my knowledge, I will try to include it in the description.

 Theories 

(Any ideas I haven't delved into yet I'll post here. This is where I'm still picking out the ingredients, so to speak.)

 

Dynamic Maps

So essentially, the concept here is to have maps that change drastically based on certain phenomena and events that take place throughout a game. I'm not specifically talking about aesthetic changes or access to certain areas, but rather an overall functional change that can alter the course of gameplay without impeding the character. The changes can range from terrain alterations or illusory 3-D (mapping that gives the feeling that the player is travelling up and down as opposed to the cardinal directions.

 

 

 Works-in-Progress 

(This section is for stuffs currently in development. I have the ingredients, but I still need to come up with the right recipes and put them into practice. )

 

Line of Sight/Stealth System

I have the foundation set for this system already created using my Distance and Direction system, listed under finished products. Basically it's supposed to work by storing player and event locations into distance variables, and direction information into switches, and using those with the terrain and lighting to determine whether or not the event can "detect" the player under those circumstances.

 

Active Battle System

This is another idea that is going to use my Distance and Direction System. It will incorporate the translation of character statistics into variables and changing the actor sprite for each attack/defense/special skill. I'll probably add more features as I go further into developing the system, but the groundwork seems fun!

 Trial Stage 

(This is for ideas that are ready for testing and minor balancing/tweaks. Perfecting the recipe, taste testing, etc. )

 

(None yet, but feel free to check back later for progress updates!)

 Finished Product 

(All completed ideas here. The cookies are hot, right out of the oven, and ready for munching! Just don't forget the milk  )

Distance and Direction System

This is probably my proudest accomplishment in eventing so far. The premise of this system is for events to be able to read the distance between them and the player, and record their direction from the player's position on any given map. There might have been an easier way, but the method I used to achieve this was with the Pythagorean Theorem (yay... math...  ). I won't go into detail about the eventing itself, but it basically takes the x and y distances between the event and player coordinates on the map and uses them to find the actual distance at any given point. Direction is then also obtained, but by determining the player's position relative to the event in question. It was a bit of work, but totally satisfying once it was finished. It's a very versatile system and has a lot of uses with other ideas I have.

 

[Nexofficial 13]

I'm so glad someone else has the same mindset, It took me years to manage putting all my efforts into a single project. That being said, I actually did something that seems similar to your dynamic maps. What I did was using the Common Event Tiles from Yanfly and then changing the tileset to a custom made one (For instance, there was a pond that became poisonous after a certain event in the storyline), allowing new functionnality to the map. Could you explain concretely what does your system look like (the distance and direction), is it a script or a construct of events ?

Edited August 18, 2016 by Nexofficial

[Saturnity 60]

I'm so glad someone else has the same mindset, It took me years to manage putting all my efforts into a single project. That being said, I actually did something that seems similar to your dynamic maps. What I did was using the Common Event Tiles from Yanfly and then changing the tileset to a custom made one (For instance, there was a pond that became poisonous after a certain event in the storyline), allowing new functionnality to the map. Could you explain concretely what does your system look like (the distance and direction), is it a script or a construct of events ?

 

That's definitely an interesting idea with the Common Event Tiles, I might consider looking into that for my dynamic maps! I'm familiar with Yanfly's scripts just from browsing through them (probably many times over at this point...), and the Common Event Tiles script was one of the ones that piqued my interest the most.  That and button common events, which are very useful too.

 

Here's a rundown of my Distance/Direction system:

 

Essentially, a single event can run off of one common event and one set of variables (although multiple events needing the system will require independent variables, since trying to store multiple event's coordinates into the same variables will cause conflicts)

 

The basic equation for the system is based on the Pythagorean Theorem, which seeks to find the length of the long side of a right triangle:

a²+b²=c² or in our case (X_{1 -} X₂)² + (Y₁ - Y₂)² = Z²

In my obsession with organization when it comes to numbers, I decided to make variables for each step of the process, but there are probably ways to shorten the process by reducing the amount of variables.

 

For my version, I created the following variables:

Player X Position - Stores the Player's Current map (not screen) X position

Player Y Position - Stores the Player's Current map Y position

Event X Position - Stores the Event's Current map X position

Event Y Position - Stores the Event's Current map Y position

Player/Event X DIstance - Distance between Player and Event on the X Axis. (This is found by subtracting the lesser of the X values from the greater of the X values.)

Player/Event Y DIstance - DIstance between Player and Event on the Y Axis. (This is found by subtracting the lesser of the Y values from the greater of the Y values.)

Player/Event Z - Sum of Player/Event X and Player/Event Y Distances

Fin Z DIstance - Square Root of Z, this is the actual distance

 

There is a single command that we need to use via script call (which I don't remember off-hand since I'm away from my personal computer at the moment, but it's used to actually find the square root and reach the final product, since there's no way to do that with the base variable system. No actual additional scripts are needed outside the base game scripts.

 

Finding the direction of the event in relation to the player follows a similar process. We need the following variables:

 

Player X Position - Stores the Player's Current map X position

Player Y Position - Stores the Player's Current map Y position

Event X Position - Stores the Event's Current map X position

Event Y Position - Stores the Event's Current map Y position

 

Instead of adding or subtracting values, however, this time we are going to be running conditional branches and switches.

 

The Conditional Branches will look something like this:

If variable Player X Position > Event X Position (If the event is North of [above] the player)

-(and) If variable Player Y Position > Event Y Position (If the event is West

of the player)

--(then) Control Switch "Northwest" = ON

 

From there, if you have any sort of event that wants to check which direction an event is in relation to the player, all you need to do is set a conditional branch for the appropriate switch.

 

It's a fun system, and I think there are a lot of useful ways to implement this in any game.   

 

If you need a more in depth guide, or some tips on fun ways to utilize this system, I'm open to give further instruction anytime   

 

Edited August 19, 2016 by Saturnity