shaunjs
patreon
Tile Collisions - Prep Work & Code optimization
🕑 Added 2017-08-29 16:03:06 +0000 UTC Here is some insight for you guys on some of the process behind this week's video and why I've made certain choices about the code we'll be doing. I dunno if talking about this is of interest to you guys, but let me know if it is and I can do it more often!The image here is what I've more or less nailed down as the main chunk of player code I'll be teaching in this week's video. Teaching you how to collide with a tile layer rather than collide with memory/cpu intensive objects! The more advanced among you might be able to break it down yourself now and save some time.
Here's the code on pastebin if you'd like to try.
Be careful though, the code assumes your tiles are 32x32 (You can just change the numbers if needed, I'd recommend using a macro/constant here actually!). You also need to make sure you grab the tilemap id from the layer, I do this in the create event with:
tilemap = layer_tilemap_get_id("Collision");
After doing some research and trying a few methods, I've gone for something different to what is already out there and ditched the bitwise operations many tutorials apply. (&ing your position with ~15 or similar in order to snap to the grid). I did a lot of research on this method and it's a great approach, one I would probably use myself in my own games, but I'm not going to use it in this video.
The reason for this is that although that method is arguably the most efficient and creates some fairly condensed code, it would take up a lot of video time to properly explain and is probably poor value for a video like this. Putting up a wall and a turn off for some that wouldn't be there otherwise. While it teaches something very useful and powerful it really isn't what most would come to a tutorial video like this for. I might do something that covers that method, or bitwise operators as a whole, on another occasion! Doing it this way instead splits it into a couple more jumps but those jumps are far smaller and easier.
I've also left in some elements that ""should"" be variables or constants instead of repeated calculations. I already mentioned using a macro for every mention of "32" (classic case of a "magic number") but also there's things like "hsp > 0" and even "bbox_bottom-y" which are being recalculated more often than they need to be. hsp > 0 could be put into a var before the checks, bbox_bottom - y could be done in the create event and then put into a variable and never calculated again (unless the player changes sprites).
So why have I done this? I do this a lot. I haven't recorded the video and I clearly know how the code can be improved, so why am I teaching "bad habits"?
Well the truth is simply that I believe that a tutorial is more effective and easier to follow, for the widest possible audience, if all of the logic is laid bare. I purposely leave this logic in place so that it can be read by the viewer and understood. By condensing certain elements into variables, their meaning is held at a distance from the reader, which can be very useful and is the whole point of my video on helper scripts many of which do exactly this. But in trying to help a viewer grow their skills keeping this information visible is necessary, and showing the steps to optimise is simply not. Doing this also speeds up the video and cuts out "filler", leaving every line of code as meaningful rather than many simply being optimisations, increasing the amount the viewer needs to understand and recall.
I try to point these occasions out when recording, I definitely don't want to teach bad habits, so I draw attention to areas that can be improved so that the user knows this is imperfect code and that they may wish to later revisit and test themselves by optimising. I think as long as I do this, my approach to "optimisations" is a good balance.
This stuff is all very subjective, but I thought I'd give you some insight on my style, ways I've been trying to improve my videos and why I teach code in the way that I do.
Comments
You can make the player hitbox bigger than a tile but it will create problems with certain shapes in your level. You can avoid these in level design but it's best just to keep your tile size larger than your player hitbox. The art can obviously be whatever. You can still make this method work for larger player hitboxes in all cases by checking more points (such as the "middle" of each edge.)
Raeldor
Looks a lot more complex than object collision but it's nice if its more efficient. The player object can be bigger than a tile though? Also, Would be wise to do 2 types of tile collision, for different sized terrain or different properties?
