New account registration is temporarily disabled.

[SCRIPTING] [RMVX ACE] THEOLIZED BATTLE SYSTEM CUSTOMIZATION, WAY TOO MESSY.

Posts

Pages: 1
Hello!

First of all i would like to apologise for this HUGE wall of text, but i am trying to give as much info as possible. I know this is asking for much, but if a kind soul would ever help me fixing it i would be super thankfull. I am looking for help improving my script so it's better to work with and leaves me room to improve in the future. I need help having the right logic for the script, if i need help writing it i will post a reply after. Right now it's super messy and wayyy too long.

I am currently working on a game called Lunar: The last hope. It is a fan game on Lunar. Lunar has an interesting battle system, where it almost feels like its tactical but not really. Here is a video displaying it! Video

I managed to get close and to be honest, it looks decent! Here is a video of my battle system.Video Now there's a few issues with that but i'll come back on that later.

Now... On the inside... Dun... Dun... DUUUUUUUUUUUNNN https://i.gyazo.com/011c8434d6bbcd84ec491669a9e26331.mp4 (apparently gyazo makes mp4 files now?)I can't copy paste it all here, thats how big it is! So i'm remaking it but i don't think i have enough knowledge to get to a working state. I can do half the job but can't finish it.



What i use:

For the battle system i am only using Theolized Basic Module 1.5d and Theolized Implementation 1.4 (and everything that comes with it.)




Number 1: How it works and my attempts.

I found this bit of code that controlls all the movement

module THEO
module Movement
# =========================================================================
# Exclusive class move object. To prevent adding to many instance variable
# in object that implements this module
# -------------------------------------------------------------------------
class Move_Object
attr_reader :obj # Reference object
# -----------------------------------------------------------------------
# *) Initialize
# -----------------------------------------------------------------------
def initialize(obj)
@obj = obj
clear_move_info
end
# -----------------------------------------------------------------------
# *) Clear move info
# -----------------------------------------------------------------------
def clear_move_info
@to_x = -1
@to_y = -1
@real_x = 0.0
@real_y = 0.0
@x_speed = 0.0
@y_speed = 0.0
@jump = 0.0
@jump_interval = 0.0
@offset = 0
@duration = 0
@colided = false
end
# -----------------------------------------------------------------------
# *) Tells the object to move
# -----------------------------------------------------------------------
def move_to(x,y=0,jump=0,duration=0)
# You can also put the coordinate
if x.is_a?(Coordinate)
target = x
move_to(target.x, target.y, y, jump)
return
end
@to_x = x.to_i
@to_y = y.to_i
@real_x = @obj.x.to_f
@real_y = @obj.y.to_f
determine_speed(duration,jump)
end
# -----------------------------------------------------------------------
# *) Determine traveling speed
# -----------------------------------------------------------------------
def determine_speed(duration,jump)
@x_speed = (@to_x - @obj.x) / duration.to_f
@y_speed = (@to_y - @obj.y) / duration.to_f
@jump = jump.to_f
@jump_interval = @jump/(duration/2.0)
@duration = duration
end
# -----------------------------------------------------------------------
# *) Is object currently moving?
# -----------------------------------------------------------------------
def moving?
return false if @to_x == -1 && @to_y == -1
return false if @duration < 0
result = @obj.x != @to_x || @obj.y != @to_y
return result || @duration > 0
end

def collide_with_battlers?(x1, y1,x2,y2)
@obj.battlers_xy(x1, y1,x2,y2).any? do |battler|
#@colided = true
print("hit22")
return true
end
end


# -----------------------------------------------------------------------
# *) Update movement
# -----------------------------------------------------------------------
def update_move
@duration -= 1
@real_x += @x_speed
@real_y += @y_speed
@obj.x = @real_x.round
@obj.y = @real_y.round + @offset.round
@jump -= @jump_interval
@offset -= @jump
clear_move_info unless moving?
end

I can make it so that only Game_Actor and Game_Enemy is affected by it, no problem.

So, here's how it needs to work:
The x and y movement moves at a set ammount of pixel each frames (same for x and y). There is also a range stat. 1 range = 1 frame of movement. If for example i want my character to move 400 X pixel max, i'd make the speed 4 and range 100. When the character arrives at destination, he stops and does the next bit of action. If he doesn't make it before, then the attack is canceled and he loses a turn.

My attempts:

I'm thinking of making 2 "update_move"s, One for X and one for Y and changing it so it takes speed and range along with the destination. But i'm a bit stuck on how i'll get the sequence to wait and stop waiting when the character arrives and how i'll make it know the character is close enough.




Number 2: The Charcter animation

How it works: The character will cycle trought 3 frames of animation (can be more for monsters) Until he stops.

My attempt:

I can ajust the AutoPose command so that it loops infinitely until said to stop. it would probably use the same trigger as the wait for the movement, so i'm stuck here too...



(Not needed but would still love to have it working. Have no clue how to do this...)

Number 3: The collision system / pathfinding.

Yes, Lunar has a collision system in it's battle system along with a pathfinding. I'm assuming this is extremely hard to implement and i doubt it will ever work. Right now i managed to get a collision detection somewhat working but i have absolutely no clue on where to get started for the pathfinding and if it is even possible. I'll leave this as an open subject, if you have an idea on how to make it happen then feel free to tell me!




Current issues:

My current attempt for the battle system would be enemies/actors clumping up together and making a big sprite mess. The obvious way of fixing this would be the collision system or monsters/players having spells that involves going back to cast it. The other issue i have is big monsters, when a character attack, it will always go to 40 pixels in front of it. Since monsters are centered, this makes the players go inside the monster's sprite. I have made conditions in the attack sequence but having multiple monsters doing this, this adds up quickly and makes it unmanagable.

Anyways, i think thats about it... Any insight on this would be helpfull! Thanks!

Marrend
Guardian of the Description Thread
21806
I haven't watched any of the videos (which probably make me a terrible person), but, the thought in my head is that Battlers, in a general sense, probably use the Sprite class for their graphics handlers. So, you might be able to use certain functions there, maybe in the update_move function, for your collision detection. Maybe implement pathfinding too? Not 100% sure on this point!


At any rate, Sprite.x, Sprite.ox, Sprite.y, Sprite.oy, Sprite.width, and Sprite.height might be of particular interest.
Hmmm What would be the diference between Sprite.x and Sprite.ox?
Marrend
Guardian of the Description Thread
21806
I'm looking at the help-file in regards to the explanations about those variables/properties. They sound very similar to me! However, I chanced a look at the Viewport class, and it's explanation of them. It says ox/oy can be manipulated to cause a "shake". The Sprite class can be passed a Viewport in it's initialization method, and, I literally just noticed a "Spriteset_Battle" class with a "create enemies" function. Which, in turn, creates instances of Sprite_Battler, a child-class of Sprite_Base, which is a child-class of Sprite.

I must confess, I'm not particularly confident about where, or how, this information can be used. However, the logic in my head, given the above, is that the x/y functions/properties would be the ones to use. As for ox/oy, I sense ox might be more useful for a Lunar fan-game, if it's used at all.
Pages: 1