Tile Collisions about cs420-project HOT 32 CLOSED

I already said the level needs to have an interface for the characters to get the x and y boundaries.
On Nov 7, 2014, at 10:00 PM, Jagabel [email protected] wrote:

Once tiles are loaded, the next goal will be to ensure that the characters interact with them as expected (so no walking through them, no falling through them, etc.)

—
Reply to this email directly or view it on GitHub.

from cs420-project.

Just making sure that the issues I'm focusing on are posted to let everyone know about them :)

from cs420-project.

@Jagabel the tester level has an object layer now so you can detect collisions.

from cs420-project.

Okay, I'll look at playing with that. Thanks!

from cs420-project.

She ain't the prettiest girl at the ball, but she'll do.
Next to work: Tile Class, shrinking the tilesheet (running 5Kx4K where about 95% of that is blank space)

Side note, I'll put this up as a separate issue but I'm randomly having Bond's animation not load at all (enemies disabled for this screenshot). Enemies load and run just fine but about 3/10 times Bond just doesn't show up.

from cs420-project.

Did you use the test file I sent as a basis?

from cs420-project.

Yep, I modified it a slight bit so I can work with collisions on the right/left as well as below (thus the random 3 tiles)

from cs420-project.

Cool, let me know when you're ready for me to push out the actual level for you.

from cs420-project.

Thought you guys might get a bit of a kick out of this...Collisions need a bit of tweaking, but they're close.

Once I'm happy with them, I'll need to work with you a bit to get the checks to fit into the Game Manager class, Joe.

from cs420-project.

Sounds good!

from cs420-project.

Collisions are functioning on a usable, but not perfect level. I'll need to show them to you guys so you can understand what I mean, but I think there's a conflict between the animation and collisions that we'll need to figure out.

from cs420-project.

@freegyp do you have an updated version of you code you could upload that @Jagabel could use to test with? Maybe you might have fixed what is causing the problem in your last couple rounds of coding?@enoughredundancy

from cs420-project.

I’m done with the actor, but the rambo and the enemies will be ready soon.
On Nov 8, 2014, at 3:30 PM, Joe Hause [email protected] wrote:

@freegyp do you have an updated version of you code you could upload that @Jagabel could use to test with? Maybe you might have fixed what is causing the problem in your last couple rounds of coding?@enoughredundancy

—
Reply to this email directly or view it on GitHub.

from cs420-project.

I'm looking at Jarrett's code now.

from cs420-project.

Ok, good deal guys.

from cs420-project.

Are the rambo.png and JB.png the textures of the same person?
On Nov 8, 2014, at 3:51 PM, Joe Hause [email protected] wrote:

Ok, good deal guys.

—
Reply to this email directly or view it on GitHub.

from cs420-project.

No, one is our bond the other is when he turns to rambo.

from cs420-project.

In this case, I have do use two different classes for them because they have to load different texture files.
On Nov 8, 2014, at 4:14 PM, enoughredundancy [email protected] wrote:

No, one is our bond the other is when he turns to rambo.

—
Reply to this email directly or view it on GitHub.

from cs420-project.

Why not just run two textures in the same class? Switch the one to sprite
when he's in that form?

On Saturday, November 8, 2014, freegyp [email protected] wrote:

In this case, I have do use two different classes for them because they
have to load different texture files.
On Nov 8, 2014, at 4:14 PM, enoughredundancy <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

No, one is our bond the other is when he turns to rambo.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#14 (comment).

from cs420-project.

I say we should just focus on bond right now, do you agree @Jagabel and @jhawz ?

from cs420-project.

That sounds easiest.

-Joseph Hause

Sent from my Android Device
On Nov 8, 2014 4:24 PM, "Jagabel" [email protected] wrote:

Why not just run two textures in the same class? Switch the one to sprite
when he's in that form?

On Saturday, November 8, 2014, freegyp [email protected] wrote:

In this case, I have do use two different classes for them because they
have to load different texture files.
On Nov 8, 2014, at 4:14 PM, enoughredundancy <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

No, one is our bond the other is when he turns to rambo.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#14 (comment).

—
Reply to this email directly or view it on GitHub
#14 (comment).

from cs420-project.

So when the class of Bond is created, I’ll just load the configuration of Bond and pack all the xml things inside the class, which means that the Game Manager just needs to pass a file name (actors.xml) to the class.
On Nov 8, 2014, at 4:24 PM, enoughredundancy [email protected] wrote:

I say we should just focus on bond right now, do you agree @Jagabel and @jhawz ?

—
Reply to this email directly or view it on GitHub.

from cs420-project.

When constructing an enemy, it also needs the name of the character like “Jaw” that corresponds to an available name in the configuration file.
On Nov 8, 2014, at 4:31 PM, Joe Hause [email protected] wrote:

That sounds easiest.

-Joseph Hause

---

Sent from my Android Device
On Nov 8, 2014 4:24 PM, "Jagabel" [email protected] wrote:

Why not just run two textures in the same class? Switch the one to sprite
when he's in that form?

On Saturday, November 8, 2014, freegyp [email protected] wrote:

In this case, I have do use two different classes for them because they
have to load different texture files.
On Nov 8, 2014, at 4:14 PM, enoughredundancy <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

No, one is our bond the other is when he turns to rambo.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#14 (comment).

—
Reply to this email directly or view it on GitHub
#14 (comment).

—
Reply to this email directly or view it on GitHub.

from cs420-project.

After working with collisions again and combining the collision code from tiles with the boundary based code that Yupeng has added to the Actor class, I've discovered a potential issue for building collisions; should there be a change in the landscape, i.e. a hole in the ground, I think the current system will result with characters being able to walk over the hole. This is because the change to the boundary currently occurs only when a character is falling; thus if a character is not falling, he/she will not update boundary related information and thus will not fall when walking over holes in the ground if those holes are level with the current tiles the characters are walking upon. This will need to be addressed soon.

from cs420-project.

I've tinkered with collisions again tonight and while they work better now, they're still not quite there...

Bond can run through tiles, but he lands upon them if he falls/jumps (so no more invisible platforms!). Also, Bond can fall through holes now. Not quite sure why he runs through tiles...but a little bit more working with it and it'll work.

I had to make a few changes overall to the structure of the project to pull this off:
VisibleGameObject now has a variable called type, which is set to 0 for Tiles, 1 for Bond and 2 for Enemies. This allows me to completely ignore collision checks on Tiles (since they don't move) and to properly set the boundaries for Bond/Enemies on the map.

I've added a getBoundary() to the Bond class to return the current boundary value to help and smooth out the collisions.

I've added a method to the Game Manager to allow it to check for map-wide boundaries (so no one walks off the side of the map, because that'd trash the collision detection and it hardly seems like a good feature anyway).

More to come.

from cs420-project.

Good job @Jagabel , is there anything that you need the rest of us to do to help? @enoughredundancy @freegyp

from cs420-project.

Not at this point, ima need to draw it out a bit and think.

On Thursday, November 13, 2014, Joe Hause [email protected] wrote:

Good job @Jagabel https://github.com/Jagabel , is there anything that
you need the rest of us to do to help? @enoughredundancy
https://github.com/enoughredundancy @freegyp
https://github.com/freegyp

—
Reply to this email directly or view it on GitHub
#14 (comment).

from cs420-project.

Ok man, just let us know if you do.

from cs420-project.

Yeah man just let me know.

from cs420-project.

Getting annoyed with this. Collisions above not functioning, collisions on left/right fail if the tiles are level with Bond's midsection (i.e. they're 32 pixels 'below' him). I think I have a solution for the latter. Former driving me to drink...

from cs420-project.

Tile based collisions work across the board except for a very specific instance:

Tiles above/below Bond that are on the edge of a row of tiles depending upon which direction Bond is facing. So in a text based example:

I I*

If I is Bond facing the right and jumps, he'll go through the tile. If I* is Bond facing the left and jumps, he'll also go through the tile.

In essence since I'm checking Mod-based tile positions to run the collision checks, what can happen is that Bond will be considered part of the tile either just before or just after the tile he's supposed to hit upon jumping. It's a bit confusing to explain via text and requires pictures to be drawn to portray the issue properly...suffice it to say it's not a terribly difficult issue to fix, but it will take a bit of time and testing to play with Mod values.

I'm putting this one on hold for the time being though until the Level class is up and running. This one won't break the game.

from cs420-project.

That's it, we now properly collide with tiles. issue...CLOSED FINALLY!

from cs420-project.