LÖVE

nyenye wrote:Okay I have two different questions. First of all say that it's a Top-Down view kind of game.

The first one is about "collisions" and the second one deals with Jumper and STI.

• Collisions - I am using Hardon Collider, and till now very pleased, but right now I am dealing with collisions between two 'dynamic' entities and I get a not expected behaviour. The 'enemy' pushes the 'player'. Is this normal? Attached a video.

  Code: Select all

  function CollisionManager:resolveCollisions()
    -- For every dynamic collider do
    for _, dyn in ipairs(self.dynamics) do
      -- Check if active. If not active then it doesn't collide
      if dyn.is_active then -- if active then
        -- HardonCollider returns all collisions with the current dynamic collider (dyn)
        local collisions = self.hc:collisions(dyn)
        -- For each collision...
        for other, sv in pairs(collisions) do
        	-- If other active...
          if other.is_active
            and ( dyn.mask[other.group] or dyn.mask[Globals.MASK_ALL]) then -- mask filters collisions. Player and Enemy always collide
            if other.mode == Globals.COLLIDER_DYNAMIC then -- If other is dynamic too...
              CollisionManager.resolveDynVsDyn(dyn, other, sv) -- resolve collision for dynamic objects.
            else
              CollisionManager.resolveDynVsOther(dyn, other, sv)
            end
          end
        end
      end
    end
  end
  

  In this code below 'shape_a' is always the one colliding, and the one which should be separated.

  Code: Select all

  function CollisionManager.resolveDynVsDyn(shape_a, shape_b, sv)
    local entity_a = shape_a.entity
    local entity_b = shape_b.entity
    -- In the original code I had more things but it didn't work, so I simplified 
    --   to the minimum (more or less like a dynamic vs static collision)
    entity_a:move(sv.x, sv.y)
  end
  

  Maybe what happens is that the collision is checked two times? One for the player against enemy and second enemy against player. But I don't think it should because when it's resolved one time, its resolved for the two, right?
• Jumper / STI - Has anyone dealt with Jumper and STI? Is there a standard way to do it? Or do you have to make a matrix map with walkable tiles each time you change a map on Tiled? Or does anyone have a trick to make it more or less dynamic?

Thanks in advance.
PD: game.love is attached

Collision between two dynamic entities will always push the other, since they are both dynamic. Its physics stuff in love2d

Thanks a lot for the insight. I was really frustrated because I didn't see it normal.

About the STI/Jumper problem it's been more or less solved for now. Don't quite like the solution, because it's not very dynamic, but at least I solve it with the Tiled editor, and not with hardcode.

Thanks again!

yetneverdone wrote:Collision between two dynamic entities will always push the other, since they are both dynamic. Its physics stuff in love2d

Last i checked, HardonCollider doesn't use love.physics (Box2D).
http://hc.readthedocs.io/en/latest/Main ... collisions
According to that link above, the order with which you iterate over objects matters, so if you think that "the 'enemy' pushes the 'player'" is wrong, then you're simply doing collision detection from the enemy's perspective. (And you do write that only one of the shapes get moved, only it's the "wrong" one.) I might be wrong, but this would be my guess. Try putting an if into your resolver, to only do things if shape_a is the player or something.

Hmmm, you where right, I was moving the player instead of the enemy. As I see I'll have to check if entity_a or entity_b is is the one moving toward the collision, and choose what to do. If the two of them are moving against each other, I'll move them both by half of the separating vector, and it should work. Thanks again!

Can't figure out how love.math.random works,

I need to get a random number between two limits:
where RandomBounceLimit can be just about anything, but mostly between about 100 and 200.

But every time I make the ball bounce, it bounces to exactly the same place, or in other words, the random generator gives the same number back every time. I found out about the randomseed, and set that one to os.time as that would probably be different every time.

still, the number does not change, even if I put a print after setting the new seed the second random number is still the same, being 118.

How do I generate a random number that is different every time?

EDIT: I was using the love random gen, and not the love one, thanks for the help!

By changing math.random to love.math.random.

Also, don't call love.math.setRandomSeed, it only needs to happen once and LÖVE already does it for you. You only need to set the seed if you want to do something like minecraft, where you can enter the seed to get a specific world.

Robin wrote:Also, don't call love.math.setRandomSeed, it only needs to happen once and LÖVE already does it for you. You only need to set the seed if you want to do something like minecraft, where you can enter the seed to get a specific world.

Even then i'd create a new (dedicated) PRNG object for that, with [wiki]love.math.newRandomGenerator[/wiki]

Quick question:

I would like to know what is the best approach (either in general or in love2d game dev) in creating data/variables for a certain entity. What is the more favorable approach? Is it: or Or is this more of an it depends thing?

It should be the second approach, most of the time.

I mean, table access is just a tiny bit slower than directly accessing variables (not to mention them being locals), but unless you're doing thousands of calculations per frame with them, i wouldn't worry; also, the B approach does give you "encapsulation", so that's nice.

(Also also, my thousands example works more for many entities with similar properities and not in lua, but in c or similar languages, where you do need to worry about cache misses and whatnot; there, using structs of arrays instead of arrays of structs can speed things up tremendously, given that the code used with them goes over properities in order; but yeah, not that important for lua, unless you're using the FFI to use C like arrays instead of lua tables...)