Messages

This is a massive gravedig, but someone messaged me on discord about fixing this script to be compatible with caterpillar ghosts.  I updated the script and put it in it's own thread here: https://forum.chaos-project.com/index.php/topic,16211.0.html

[Simple Player Idle Sprites]

Simple Player Idle Sprites
Authors: winkio
Version: 1.0
Type: Animation System
Key Term: Environment Add-on

Introduction

This script was created from a simple request to have idle animations for player characters in this thread: https://forum.chaos-project.com/index.php/topic,2653.0.html

There are many scripts out there that have more fully featured implementations of idle sprites, but this one is intended to be minimalistic - just a single idle sprite per character.
Script

SIMPLE PLAYER IDLE SPRITES: ShowHide

#==============================================================================
# ** Game_Player
#------------------------------------------------------------------------------
#  With idle sprites.  name the idle sprites the same as their normal ones
#  except with '_idl' on the end (before the extension)
#==============================================================================

class Game_Player < Game_Character
  #--------------------------------------------------------------------------
  # * Public Instance Variables
  #--------------------------------------------------------------------------
  attr_reader   :character_name_org       # original character file name
  attr_reader   :current_sprite           # current sprite suffix
  #--------------------------------------------------------------------------
  # * Object Initialization
  #--------------------------------------------------------------------------
  alias initialize_idlesprites_before initialize
  def initialize
    initialize_idlesprites_before
    # set original character name
    @character_name_org = @character_name
    # set current sprite
    @current_sprite = ""
  end
  #--------------------------------------------------------------------------
  # * Frame Update
  #--------------------------------------------------------------------------
  alias update_idlesprites_before update
  def update
    update_idlesprites_before
    update_idlesprites
  end
  #--------------------------------------------------------------------------
  # * Refresh
  #--------------------------------------------------------------------------
  alias refresh_idlesprites_before refresh
  def refresh
    refresh_idlesprites_before
    update_idlesprites
  end
  #--------------------------------------------------------------------------
  # * update_idlesprites
  # Updates idle sprites of the player
  #--------------------------------------------------------------------------
  def update_idlesprites
    if @character_name != ""
      if moving?
        if @current_sprite != ''
          @step_anime = false
          @character_name = @character_name_org
          @current_sprite = ''
        end
      elsif Input.dir4 == 0
        if @current_sprite != '_idl'
          @character_name_org = @character_name
          @step_anime = true
          @character_name += '_idl'
          @current_sprite = '_idl'
        end
      end
    end
  end
  
end

SIMPLE CATERPILLAR IDLE SPRITES (FOR USE WITH TONS OF ADDONS): ShowHide

#==============================================================================
# ** Game_Member
#------------------------------------------------------------------------------
#  With idle sprites.  name the idle sprites the same as their normal ones
#  except with '_idl' on the end (before the extension)
#==============================================================================

class Game_Member < Game_Character
  #--------------------------------------------------------------------------
  # * Public Instance Variables
  #--------------------------------------------------------------------------
  attr_reader   :character_name_org       # original character file name
  attr_reader   :current_sprite           # current sprite suffix
  #--------------------------------------------------------------------------
  # * Object Initialization
  #--------------------------------------------------------------------------
  alias initialize_idlesprites_before initialize
  def initialize(index)
    initialize_idlesprites_before(index)
    # set original character name
    @character_name_org = @character_name
    # set current sprite
    @current_sprite = ""
  end
  #--------------------------------------------------------------------------
  # * Frame Update
  #--------------------------------------------------------------------------
  alias update_idlesprites_before update
  def update
    update_idlesprites_before
    update_idlesprites
  end
  #--------------------------------------------------------------------------
  # * Refresh
  #--------------------------------------------------------------------------
  alias refresh_idlesprites_before refresh
  def refresh
    refresh_idlesprites_before
    update_idlesprites
  end
  #--------------------------------------------------------------------------
  # * update_idlesprites
  # Updates idle sprites of the party member in the caterpillar
  #--------------------------------------------------------------------------
  def update_idlesprites
    if @character_name != ""
      if moving?
        if @current_sprite != ''
          @step_anime = false
          @character_name = @character_name_org
          @current_sprite = ''
        end
      elsif Input.dir4 == 0 && @buffer.size <= @index && @force_movement <= 0
        if @current_sprite != '_idl' || @character_name[-4, 4] != @current_sprite
          @character_name_org = @character_name
          @step_anime = true
          @character_name += '_idl'
          @current_sprite = '_idl'
        end
      end
    end
  end
  
end

Instructions

Place the Simple Player Idle Sprites script below the default scripts, above main, and above any other custom scripts you may be using.

If you are using the Tons of Addons script and want caterpillar heroes to have idle sprites as well, you must also place the Simple Caterpillar Idle Sprites script below Tons of Addons.

Idle sprites should be named after the original sprite with '_idl' at the end, for example if your player sprite is named 'MainGuy.png', then the idle sprite should be named 'MainGuy_idl.png'
Compatibility

Made compatible with Tons of Add-ons, including when Caterpillar option is turned on.
May not be compatible with larger scripts and ABS battle systems.

replacing the method with this one should fix it, but I haven't tested it

    #--------------------------------------------------------------------------
    # wall?
    #  char - the character
    #  x    - x-coordinate
    #  y    - y-coordinate
    #  Checks if between the char and the target is a "wall". Walls prevent
    #  perception.
    #--------------------------------------------------------------------------
    def wall?(char, x, y)
      # abort instantly if not using this option
      return false if Config::WALL_TAGS.size == 0
      # get pixel movement rate
      pix = $BlizzABS.pixel
      # get coordinate difference
      dx, dy = (x-char.x)/pix, (y-char.y)/pix
      # if x difference is not 0 and x difference is greater
      if dx != 0 && dx.abs >= dy.abs
        # return any wall tile between
        return (0..dx.abs).any? {|i| Config::WALL_TAGS.include?($game_map.
            terrain_tag(char.x/pix+dx.sgn*i, char.y/pix+(i.to_f*dy/dx.abs).round))}
      # if y difference is not 0 and y difference is greater
      elsif dy != 0 && dy.abs > dx.abs
        # return any wall tile between
        return (0..dy.abs).any? {|i| Config::WALL_TAGS.include?($game_map.
            terrain_tag(char.x/pix+(i.to_f*dx/dy.abs).round, char.y/pix+dy.sgn*i))}
      end
      # no wall between
      return false
    end

I made the first if block use >= instead of >, and then for the slopes used the absolute value of the denominator so that the signs would match correctly.

The problem is the UMS overrides Interpreter.execute_command without calling the original method.  BlizzABS uses an alias on this method to temporarily set the $game_temp.in_battle flag to false while running commands, but the UMS stops that from happening.  Try moving the UMS above BlizzABS in your script order.

Quick update since I'm logged back on:

I spent about a year unemployed, during which I worked on various projects, goofed off, and sent in literally hundreds of job applications.  Finally found a good software job in North Carolina, of all places.  It's not game or graphics related, but it's with a small company and I get a lot of freedom of what to work on and my work has a sizable impact on the company as a whole.  Honestly it's way more fulfilling than either of the previous software jobs I had.  I'm still super lonely and trying to figure out how I fit in to society, but I'm hanging in there.  I've been working on a Terraria mod in my spare time and still do some game/app development, but haven't completed anything significant.

Good job turning things around Ryex!  Thanks for the birthday shouts everyone.

Hello!  Welcome to the forum.

Welcome back!

You know how this forum is named Chaos Project?  Well check out the game with the same name that Blizzard made: http://forum.chaos-project.com/index.php/topic,31.0.html

Welcome!

Congrats!

[half plane]

Good ideas, it looks like you have a fairly good start on collision.

For the type of collision algorithm you are wriitng, there is one big idea that I think would give you a lot of insight: Constructive Solid Geometry (https://en.wikipedia.org/wiki/Constructive_solid_geometry)


For example, besides points, you could define only two other basic shapes, and construct all the shapes you defined:

half plane, with the form y - b <= m(x - a).  This is just an inequality of a simple line.  Point slope is generally more useful than slope intercept form, but you can use whichever you prefer.

circle, with the form (x - a) * (x - a) + (y - b) * (y - b) <= r * r.

Using just those two inequalities and the and, or, and not operators, you can construct all the shapes in your original post.  You would also have to use the Separating Axis Theorem to check for collisions between the inequalities (https://en.wikipedia.org/wiki/Hyperplane_separation_theorem)

The payoff is that your collision algorithm is now super straightforward, as you have very few cases to consider.  Additionally, you can define a lot more shapes very easily without having to write new cases for your algorithm.

The drop rate itself does not change by 10% each time.  It is 1/10, then 1/9, then 1/8, etc.  which is 10%, 11.1%, 12.5%, etc.

Also, I was just giving an example for a rate that started at 1/10, you could do the same thing with a rate that started at 1/1000.

I'm not talking about purely making the item easier, but rather capping the amount of grinding.  There will always be some players that are lucky enough to get an item without grinding, and that is not a problem to me.  The problem is the group of players that decides to grind for the item.  Some of them will have to keep at it 2 or 3 or 10 or 100 times as long as the 'average' time to grind, for no other reason than random chance.  Is that good game design?

Idk, in my opinion it's a bad idea even for cosmetics or optional things.  I remember grinding for a Rod of Discord in Terraria, which had a 1/500 drop rate.  Something that usually only takes an hour or two on any given playthrough took 11 hours when I had to kill 1700 Chaos elementals for the drop (Terraria gives you a banner every 50 kills, so it's easy to keep track).  The whole point of these low drop rates is to make players grind for the item, unless they get really lucky.  But it's cruel to force a small percentage of players to grind double or triple the time it takes for everyone else.  Especially when you start looking at games with large player bases like MMOs, it's possible that some players will never get the drop no matter how much they grind.

It's never too late!  Welcome

Also, even if you can't sell your game, you can still show off your progress to everyone here

[P = n * dropRate]

I thought of two more ways to do rare drop rates.

The first way is to drop item components at a common frequency that can be traded or combined to make the rare item.  So instead of a sword dropping with a 1/1000 chance, you drop sword pieces with a 1/4 chance, and give the player the ability to exchange 250 sword pieces for the sword.  Pretty straightforward.



The other way requires no multiplication or exponents, but still increases the drop rate on failure.  This is done by subtracting the drop rate from the total probability for each failure.  So for a 10% starting drop rate, it would be (1/10, then 1/9, then 1/8, etc.)

#Kills  %Players
1       10%
2       20%
3       30%
4       40%
5       50%
6       60%
7       70%
8       80%
9       90%
10      100%

This data is a result that seems very clean and logical to us, although it is not obvious why it occurs.

Let's look at the math:

P = 1 - product(1 - (dropRate / (1 - dropRate * (i - 1))), from i = 1 to i = n)

Looks complicated.  Let's look at the actual terms inside the product for dropRate = 10%

i  product term
1  9/10
2  8/9
3  7/8
4  6/7
5  5/6
6  4/5
7  3/4
8  2/3
9  1/2
10 0/1

What happens as we multiply the terms together?  9/10 * 8/9, the 9s cancel, and we end up with 8/10.  8/10 * 7/8, the 8s cancel and we end up with 7/10.

So we can write the product term as product = 1 - n * dropRate.  Now we get a much simpler equation for P:

P = 1 - (1 - n * dropRate)
P = n * dropRate

And there we have it, the simple result we saw in the table above.

Drop rates are used in two ways in games: common rates, where the player is expected to get numerous drops as they play, and rare rates, where a special item has a small chance of dropping, forcing the player to grind to get the item.

Common rates work well, and they aren't really that interesting mathematically.  If everything I kill in a Zelda game as a 25% chance of dropping a rupee and I kill thousands of things over the course of a game, rupees will drop fairly steadily.

Uncommon rates are tricky.  If I spawn an endless wave of monsters that have a 10% chance to drop a key needed to get to the next room, how many monsters does the player need to kill to get the key?  The answer is not 10.  It's actually pretty complicated.  What we get is a table of a percentage of players that get a key by the time they kill X number of monsters:

#Kills  %Players
1       10%
2       19%
3       27%
4       34%
5       41%
6       47%
7       52%
8       57%
9       61%
10      65%
20      88%
30      96%
40      99%

So we can see that over one third of all players have to kill more than 10 monsters to get the key.  Of course, there are also some that get the key on the first or second monster.

What is the math behind this?  First, total the probability of the player not getting the key N times.  Since there is a 90% chance of not getting a key each drop, it is 90% * 90% * 90% ... n times, or 0.9^n.  But since I want the probability of the player getting a key (or multiple keys), I subtract this value from 1.

P = 1 - (1 - dropRate)^n

Let's take a look at another result.  Let's say you want to have your super secret special item drop with a 1/1000 chance, or 0.1%.

#Kills    %Players
1         0.1%
10        1%
100       10%
1000      63%
2000      86%
3000      95%

There's still 14% of your players that don't get your drop even after killing 2000 monsters.  Clearly this will be frustrating for them.



So what are some alternatives?  There is no easy answer, but this is one solution that I like:

Increase your drop rate every time the drop fails, and reset it once the item drops.  Take a look at the 10% drop rate example, now with an additive 10% increase every time the drop fails (10%, then 20%, then 30%, etc.):

#Kills  %Players
1       10%
2       28%
3       50%
4       70%
5       85%
6       94%
7       98%
8       99.6%
9       99.96%
10      100%

The drop rate is quite aggressive now, but we know that if the player does not get the drop for 9 kills in a row, then 10th kill is guaranteed to drop with a 100% chance.

The math here is slightly more interesting.

P = 1 - product(1 - dropRate * i, from i = 1 to i = n)

For the 10% case, we can write it as:

P = 1 - (9!/(9 - n)!) * 0.1^n

But overall, this is not really what we want.  Half of the players are getting the drop in 3 kills.  Let's try another solution that does away with the 10% rate altogether.



Let's set the drop rate to start at 2^(-9), and double it each time it fails to drop (2^-9, 2^-8, 2^-7, etc.), while still resetting on a successful drop.

#Kills  %Players
1       0.2%
2       0.6%
3       1.4%
4       2.9%
5       5.9%
6       12%
7       23%
8       42%
9       71%
10      100%

Finally, we have something that looks like we want.  Most of our players will not get the drop until the higher number of kills, but there is a hard cap at 10 kills that guarantees every player will get the drop.

What does the math look like?

P = 1 - product(1 - 2^(a - MaxN), from a = 1 to a = N)

in this case, we have maxN = 10, so

P = 1 - product(1 - 2^(a - 10), from a = 1 to a = N)

This can be expensive computationally, but there are some shortcuts.  There might even be a way to simplify the product expression to an exponential term, but I'll have to look at that later.



Hopefully I have imparted a small amount of distrust for low random drop rates to you.  If you have any ideas on other ways to make a good drop rate system, I'd love to hear them.  Otherwise, if you are stuck grinding for something in a game and it feels like it's taking way too long, now you know why >_>

Two Steps From Hell - Bastion

Welcome! 

You better pray to laptop Jesus that your fans stay in good shape, because on my ASUS, my fans got worse and worse until my motherboard overheated, and I ended up spending $200 on repairs and still ended up buying a new laptop.

In terms of the computer itself though, everything was solid, good performance, no driver errors or stupid bloatware.