Hello Guest, please login or register.
Did you miss your activation email?
Login with username, password and session length.

Pages: [1]   Go Down

Author Topic: Tile-Based Collisions and Leveling  (Read 6745 times)

0 Members and 1 Guest are viewing this topic.
Tile-Based Collisions and Leveling
« on: November 19, 2010, 12:33:09 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
In response to something that Xfixium said regarding collision systems running into problems when they have a large number of wall instances I have created a system that uses tile for simple collisions. I think this gives the overall appearance that the complexity of the code has increased a bunch, but in practice I think that it will still have equal performance in small rooms and better performance in large rooms. Essentially the key to this is that doing collision checks for the parObstacle object search through all of its instances in a given room - i.e., if there are less instances to process through, not as many checks will have to be done. Furthermore, with things like environmental effects on a playable map, Link will have to always be checking if he is over something - i.e., the previous way of doing this required large empty instances too.

The code isn't too perfect though, I had been working on updating corner-cutting so that it fit; I had it working with the exception of it sometimes setting my othr_o variable to 0 for a reason I couldn't determine. I figured I would just remove that stuff so I could post what I have done instead of making it look like I was just talking out of my ass. I didn't fully comment this one, but am open to comments about what I made and would be willing to answer any questions that anyone has. I should also note that in lue of making everything integrated for the GM Minish Cap Engine which takes time, I am just going to put out my ideas without expecting them to be fully perfect.

The GMK (for GM8) contains a room with just one object (Link) and how he can interact with tiles. There is a hole that he can only fall in if the hole is one level beneath him. The background files for Level1, Level2... were created sequentially; this might not be strictly necessary in that a lower level need not always be 1 less than a higher level, but meh. There is probably not that many levels in the actual Minish Cap as ledge jumping and some stairs are really just manipulations done on one level. Also in terms of leveling, the layer 0 I created when used for collisions means that regardless of level there will be a collision (useful for bridge ends), but when used for the layer which is for environmental effects, it is just another level.

Screens:


Download:
see attachment
« Last Edit: November 19, 2010, 12:35:52 am by 4Sword »
Logged

Dark-Hylian

Silence
Re: Tile-Based Collisions and Leveling
« Reply #1 on: November 19, 2010, 03:35:27 am »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 370
If I might make a request, and this may not be the place, but could you kind of... airlock the code? It's probably not the best way to put it, but I've been coding a lot based off of your engine, and while it's not majorly effecting the code done on Link himself, it's quite drastically effecting the scripts he uses, and even making some of his code into a completely new script to be called upon. I guess what I'm saying, is, if you add, I don't know, pushing, could you consider doing it as an almost completely seperate entity to the base code, as opposed to me having to go and either re-write my code on top of what you guys have done, or trying to add your changes to what I have so far? I love the work you guys have put into it, and if I ever do anything that is useful to this project I will definitely see if you guys can use it, and in no way want to be judgemental, but I'v done this probably 5 times now xD

With each new rearrangement of your code, I feel like I have to re-write my(mixed with your) code just to add the one new feature you've installed, which is a pain in the ass xD

Also: Related to this post!

I've actually begun to program this in my own way, which is, now I see, not as efficient as yours, with level changing collisions at the end of each bridge etc, which let you jump off stairs, or projectiles collide with the right walls. I see how you do it, and I like it, and am eager to see how you implement stuff like ledge jumping with these levels, or projectiles and collisions.

Sincerely, and thanks again,
Dark
Logged
  • Dawning Hour
Re: Tile-Based Collisions and Leveling
« Reply #2 on: November 19, 2010, 11:13:40 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
I understand your frustrations with having to rewrite your code and having to sift through features to add what you want into your project. I have mostly been working with the movement code which ends up being an influential base to the rest of the code - so when it gets rewritten, it affects a lot. With this stuff though, it isn't complete and I was trying to work it in as a fix to the Primary Object Collision method.

I am not sure exactly how this stuff will affect ledge jumping either. When I was looking through the Minish Cap game I noticed that near the house where you start off, you can ledge jump but for all intensive purposes your level would not really appear to change - or like one could code that to just be one level. Like, even if you fired an arrow on the top or bottom of that hill it would get stuck. Also there are some bridges the game has over water, but I realized you can't swim under them like I thought you could. The only two places I ran into (there are probably more) where leveling was much of an issue was the bridge in Hyrule Castle Town and the ice bridge in that one dungeon.

Overall this method makes coding dungeons a little less instance packed. If I ever add enemies too I am not sure how I am going to have them run the collision checking code though.

Oh, and thanks for the support and post!
Logged
Re: Tile-Based Collisions and Leveling
« Reply #3 on: November 19, 2010, 07:22:04 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3725
Nice, 4Sword. I was already pondering that problem, but never got around to actually working on it. Sahittam's engine showed that having many objects in a room just for collision can definitely lag a game. Currently I am working on a combat system although I am still with the enemy unit. It is not that good yet, but I'll PM you what I have got already later. But this is definitely something that will be added to the engine once the cornercutting is figured out. Ledge jumping will come after that. The pushing will probably not change that much. But I have been looking at the code, but I am wondering how it will work with a generic tileset, where there are multiple tiles representing solids, water, pits and ledges. Or are these just masks for an invisible tile layer?

BTW: I noticed that you consider a position where the level of Link changes as a valid save point and store its x and y. Personally I don't have a problem with that but I noticed that MC does not do that. It considers trigger tiles as unsafe and thus not treats it as a return position. I found this out when I was running through the Castor Wilds. I came off a bridge, over a trigger, direct onto the tall grass. Immediately ledge jumped into the swamp and sank. I was set back onto the bridge. Thinking about it that would mean that you need to save the level to return to as well. Hmm, some food for thought.



Dark-Hylian, we won't stop developing the engine to accommodate projects that use the engine but not contribute to it. Especially when it involves a major issue like this, collision and basic movement. It will just need an overhaul. Knowing 4Sword he will keep revising the basic movement, until it is perfect. I will try to add new stuff. However, I have never heard of "airlocking code", but I do have heard of "freezing a checkout". This means that someone or a group is working with code/tool that is still in development by someone else. With each update that the other makes there is a possibility that the someone's code will not work anymore. If this happens often or causes complications at the wrong time, the someone might freeze his checkout of the code/tool and use it as it is with errors and glitches that it has. In other words that someone will ignore any further updates. Thus the choice is all yours. Do you keep updating and possibly revising your own code, or will you ignore any further updates of the engine and figure out extra additions yourself.

I love the work you guys have put into it, and if I ever do anything that is useful to this project I will definitely see if you guys can use it,
The only way it is not usefull if it is not presented here; if you keep it all to yourself. Any code provided is a stronger voice in the development of the engine than just a post telling your opinion. And in all honesty I'm not that picky about new features that the engine does not have yet. I might add some improvements, or I give you some pointers for improvement and maybe later it can get a complete overhaul, but it definitely is not useless.

So like I said, the only way it is NOT useful. Is when you keep it all to yourself.
Logged

Dark-Hylian

Silence
Re: Tile-Based Collisions and Leveling
« Reply #4 on: November 19, 2010, 09:27:48 pm »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 370
What I meant Niek, is that I will follow the engine either way, and use it, but what I've coded isn't grounded in MC. It's custom coding for custom stuff really. Like my keese coding, it's completely different from the ones used in the real MC. I don't know what use you would have for it. If I doo code something useful to the project, (Something actually in MC, which is what this project is, right?) I'll definitely post it here. I don't want you to halt the code, I was suggesting an ease of use method, which you all are free to ignore, and I won't feel bad at all. It's just more work for people who use it, they aren't all working to recreat MC exactly, thus modifications would be made. Anywho, like I said, when I do something generic, like text or something, that fits MC, I'll post it.
Logged
  • Dawning Hour
Re: Tile-Based Collisions and Leveling
« Reply #5 on: November 22, 2010, 07:33:54 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
About the speed of the GM Minish Cap Engine effort, it gets halted all the time due to life and stuff; as well as the reworking of its internal complexities. I should be commenting my code better and releasing it in GM7 for those who prefer that; the code itself doesn't use any exclusive GM8 features I am aware of.

As for adding to the project, feel free to post something as long as you think it is of a good enough quality (note that some of what I post is incomplete, so it isn't like yours has to be a work of perfection). But yeah, with the tile functions I already have a sort of scheme in my head set up to where Link could do that dig into the ground with the Mole Mits. It isn't too difficult to add; even destroying a hill wouldn't be too complicated in terms of movement. And also you are right, the features added don't have to exist in the Minish Cap game, it just has to fit the style. For example, I could create something like a spirit transfer item which makes a Link ghost go into a suit of armor or make an arrow that bounces off of corner objects.
Logged
Re: Tile-Based Collisions and Leveling
« Reply #6 on: November 24, 2010, 09:28:03 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3725
As for adding to the project, feel free to post something as long as you think it is of a good enough quality (note that some of what I post is incomplete, so it isn't like yours has to be a work of perfection). But yeah, with the tile functions I already have a sort of scheme in my head set up to where Link could do that dig into the ground with the Mole Mits. It isn't too difficult to add; even destroying a hill wouldn't be too complicated in terms of movement. And also you are right, the features added don't have to exist in the Minish Cap game, it just has to fit the style. For example, I could create something like a spirit transfer item which makes a Link ghost go into a suit of armor or make an arrow that bounces off of corner objects.
Agreed, some one can make a hookshot for example or the lens of truth, which aren't in the minish cap, but the graphics alone could just make it fit the style. And if it does not fit the style, it will mostly involve minor changes. There are also a great number of features that are the same for every Zelda game, it is only the graphics that are different. Take for example a sign. It is an object that link can only read when he is standing below it and facing up. Then when he reads it a textbox with text pops up and once the player has scrolled to it completely it goes away again. A sign can be picked up and it can be slashed to pieces. This behavior is the same in MC, ALttP, GB and the 3D Zelda's. The only thing that differs are the graphics. The same goes for NPC's, collectible items such as ruppees, arrows and bombs.

And for the engine I am not that much concerned in the specifics of a specific feature, but more about the base design and implementation. Take for example the enemy I made with my combat system. I used an octorok to illustrate the workings of parMC and parDynamicMC and how someone can easily make an enemy of its own. That is what I care about, not how cool my Octorok looks like and how like the MC counterpart he is, because it is not the same AI as its counterpart.
Logged
Tile-Based Collisions and Leveling (Update)
« Reply #7 on: December 27, 2010, 12:31:14 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
Update:

I added in the corner-cutting, dungeon sub-rooms, and platforms. I plan on making more additions to this in the dungeon format. Also, there are two rooms, the first one shows the tiles which make the room look pretty, the second one is gutted showing only the times which are functional. Also I am going to try and showcase my engine updates with YouTube videos instead of just screenshots because seeing it in motion is more helpful. The blue chest can't be opened yet too.
<a href="http://www.youtube.com/watch?v=lN0WHTtlWzU" target="_blank">http://www.youtube.com/watch?v=lN0WHTtlWzU</a>

The download is in the attachments.
Logged
Re: Tile-Based Collisions and Leveling (Swamp De...
« Reply #8 on: January 04, 2011, 03:02:05 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
Update:

I got bored and added a swamp and damage taking. Basically Link's y drawn position increments downward while the height of his drawn image decrements upward, and then it acts like a pit. Since the code I was working with didn't have Link with more than a few states I didn't have it so going over a swamp forces Link to go back to the Normal state unless he's Pegasus Boot dashing or flying with the Roc's Cape. I will probably go into this later and edit the swamp end effect to just go into the Pit state.

I've also been tweaking the environmental tile code so that it checks what is at the level Link is on rather than the level under the current one; Level0 is supposed to represent doing collisions and environmental effects regardless of what Link's level is.

<a href="http://www.youtube.com/watch?v=kO8vMI3qt-g" target="_blank">http://www.youtube.com/watch?v=kO8vMI3qt-g</a>

I'll post the code later after I fix it up to where I want it, or it gets enough interest for it to be posted.
Logged
Re: Tile-Based Collisions and Leveling
« Reply #9 on: January 06, 2011, 09:02:03 am »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3725
Okay, I have been playing with the gmk file attached to two post up. And I found one small issue. When walking over the bridge and then go to the left or the right you get blocked by a solid. However visually Link is not even close to the bridges railing.

I was thinking that we either need to use a tilesize of 8 instead of 16 or that we need to make the bridge railing solid objects and you only collide with them when on the same level. Personally I think the first option would be better. However, there probably is a better solution.

Second I was thinking of the platforms and other objects that make Link move, beside the player. I think that instead of having the platform actually move Link, they should increase/decrease some x_add/y_add value and x_move/y_move would represent movement made by the player. Then when the movement needs to be done just do x_move + x_add to resolve actual movement. But it can be that you have already added that to it, because I am going to print your code now and make comments. To see what I can do with it.
Logged
Re: Tile-Based Collisions and Leveling
« Reply #10 on: January 06, 2011, 09:38:14 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
The aspects where Link is running directly into the bridge railings going up or down, and parts of the bridge are at a depth which draws on top of Link even though it shouldn't - I was lazy when going that, I just wanted to put a bridge in the example which was tiled over to look neat rather than it all just being bare bones.

If you are talking about changing the snap X and snap Y of the room's grid to be 8 x 8 but leaving the tiles in the background files to be 16 x 16, then that could work as you said. The only thing that might go wrong would possibly be some aspect of the corner-cutting code if it assumes the tile it is running into is on a 16 x 16 grid. Not sure if it totally does that, I didn't look at it much after I got it working well. Otherwise though, when I was making sure running into a diagonal parObstacle child object wouldn't put Link through a wall tile, the corner-cutting code could be alright in anticipating non 16 x 16 grid stuff.

lol, yeah you are right about the platform and the x_add/y_add stuff. When I was rewriting the platform code I was too tunnel-visioned on getting the code out of the platform object itself. This was important too because by having it done in objLink I avoid calling the parObstacle check stuff in the platform objects' code and also have the platform's have non-directional specific masks. Because the platform code had to be before the player key pressing, in the player key pressing movement adding part of the code I had it so it wouldn't "reset" the movement value added by the platform. Your way would make more sense and would later help out with something like a wind turbine which blows Link around or stairs which slow Link down but otherwise don't set movement rules any other way.
Logged
Re: Tile-Based Collisions and Leveling
« Reply #11 on: January 06, 2011, 07:49:20 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3725
I tried to just make the snap grid 8 x 8 and that didn't solve it, so I think interaction tiles should be 8x8 as well. However I don't think dungeon tiles need to be 8x8 because they are mostly for decoration. And it is possible to make a double row when setting up tiles for collision, to prevent go through.

I have also seen that you did what I suggested with the platforms. However, you did it by reseting move_x and move_y. I don't know if this will work with the ice movement and bounce slip, although it is only done on a platform. Also if you put variables in parPlatform called move_x and move_y and then you only need to have parPlatform and you don't need to make a distinction between horizontal, vertical and path-following platforms. Just do x_add += plat_o.move_x; y_add += move_y;

I have gone through the movement code and I probably have figured out everything. Except the following lines:
Code: [Select]
if (disp_a && disp_b){
   if (!collision_line(x - 7,y - 3,x + 6,y - 3,parObstacle,1,1))
      disp_a = noone;
   else if (!collision_line(x - 7,y + 3,x + 6,y + 3,parObstacle,1,1))
      disp_b = noone;   
   break;
}
Here I am wondering why you are first searching for obstacles and then discard it again.
and
Code: [Select]
if (disp_a && disp_b)
          x = disp_a - (move_v > 0) * 17 - line_v;


Okay now I will go over the view code.
Logged
Re: Tile-Based Collisions and Leveling
« Reply #12 on: January 06, 2011, 08:11:44 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
I am kind of resistant to make interaction tiles 8 x 8 because that means more of them would have to be placed. Having the grid 8 x 8 still allows for placement of 16 x 16 tiles appropriately though - it is hard to express without showing it, but if the bridge railings where 8 x 8 aligned, the side of the railing Link wasn't hitting would be fine if it was 16 pixels away from hit because the level stuff prevents interactions with that other side when he is there anyway. But yeah, I just tried to put some tiles and the corner-cutting went to !@#$%, I'll probably just go into that and fix it up there.

Yeah, the platforms are a little quirky. The way I programmed them before was to use the built-in direction variable as the delay mechanism and currently platforms have to be placed in the center of their "paths". I'll go through and try to tweak that stuff.

The first block of code you mention is a corner-cutting correction code. When Link horizontally moves into something, if I based what he is running into on the two halves being disp_a and disp_b, with no correction he won't corner cut as much as he does when he moving vertically into something. The correction code checks to see if there is something on Link's top and bottom mask lines, which is to say that if Link is completed blocked he won't corner cut but if he is at least a pixel free he'll try corner cutting. Corner cutting code happens when either disp_a or disp_b is noone, which is why I set disp_a or disp_b to noone.

The second block of code you mention is just reusing the disp_a and disp_b variables again but because no obstacles where found, it is now checking for wall tiles. The get_wall returns either the X or Y position of the tile Link is on with 16 added to it. The reason for this is because I want to treat the get_wall return value as boolean where 0 is false and want to avoid the 0,0 tile position which is a valid one. The code you mention adjusts Link's position to be directly in front of the tile he is going to run into.
Logged
Re: Tile-Based Collisions and Leveling
« Reply #13 on: April 27, 2012, 02:40:34 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
Epic bump but anyway I thought that I would mention an update of sorts. While not covered exactly in this specific topic, I have in others related to this done tile-based collisions with objects representing the diagonals. This always annoyed me somewhat because it made certain aspects of collision detection ugly to code - object collision will always be necessary though because there are objects like enemies and stuff other than Link.

In a few days to a week or so, I will try and post an example I have been working on in which tile-based collisions for "diagonal" tiles can be done. Essentially, there is a tile and you can program it such that it is recognized as not being completed solid. It is a lot of fun with the math it uses and while doing it this way in Game Maker may not be the best or easiest way, I think that it provides a simplification for collision detection that could be used in other languages. I just thought I would mention this to see if anyone was interested in seeing how to do that.
Logged
Re: Tile-Based Collisions and Leveling
« Reply #14 on: April 27, 2012, 05:23:55 pm »
  • *
  • Reputation: +1/-0
  • Offline Offline
  • Gender: Male
  • Posts: 446
Sounds like a very useful reference to have. I use a ton of touchy diagonals in my game, so I'm sure I for one would find it helpful.
Logged
Pages: [1]   Go Up

 


Contact Us | Legal | Advertise Here
2013 © ZFGC, All Rights Reserved



Page created in 0.199 seconds with 67 queries.