How to Code Level Collision for 2D Games (Sega Genesis & Mega Drive) - Beginners Game Dev Tutorials

[@PigsysRetroGameDevTutorials]

This is the most requested topic for a tutorial, so I hope everyone enjoys it. I had initially planned to do this next year due to it's difficulty, but everyone kept asking so here it is! It's the biggest one yet at over an hour, but the next one on jumping/gravity should be a lot shorter as it builds on everything we cover here. The programming and concepts are the most complex of any of the tutorials so far, so it will take some time and effort to work through, but once complete you will have a collision model in place for your game.

[@frankmabo3940]

hey, would you consider doing something for SNES platform?

[@denraimei32]

While it's great you manage to get this finished, it's becoming apparent that your subscribers should know patience is a virtue.

[@PigsysRetroGameDevTutorials]

@@frankmabo3940 I'm focussed on Mega Drive for now and will probably do some Saturn/Dreamcast stuff after that, so I don't think I'll ever get around to working on SNES stuff (if I were to do any Nintendo stuff it would probably be GBA)

[@PigsysRetroGameDevTutorials]

@@denraimei32 I think everyone's been great on the whole. In an ideal world I would be able to do this full time with tutorials and updates on SotN/GGS every week, but in reality I have to try and balance things so that I can continue with all this into the long term. Thanks for the support!

[@benjibrogames2795]

You are the GOAT!!! (greatest of all time)

[@stephenwhite506]

As an optimization, you can track the edge needed to be tested based on velocity (one for X and one for Y). Then XOR the current position with the desired position for each axis (ie the current position plus the velocity). These positions can still be in fixed point. You can then test a single bit in the result to see if they are different. This will indicate that the edge has stepped into a new tile. If not, you don't need to do any more expensive tests. However, this only works is you limit the velocity so you cannot cross more than one tile per frame.

[@PigsysRetroGameDevTutorials]

That's a good idea, thanks. I will introduce a terminal velocity in the next lesson (although skipping through tiles isn't too much a problem when using 16*16 tiles

[@GimblyGFR]

Excellent tutorial. Very clear and really detailed. I was eagerly waiting this one, and I was not disappointed. Thank you very much for your work on this series, and for taking the time to move this one up on the schedule.

[@PigsysRetroGameDevTutorials]

You're welcome! This was something that was holding a lot of people back from making the projects they wanted to, so I was glad to be able to get it done.

[@Hwi1son]

I've never looked at the SDK but I'm absolutely going to start using it. ( I used another tool that looks very similar to this, and i was getting decent) Awesome work as always.

[@PigsysRetroGameDevTutorials]

Thanks and good luck with it!

[@Nikku4211]

I followed along with this tutorial, and though it was meant for the Mega Drive, I've been able to use the information I learned from this tutorial to implement collision on Game Boy through GBDK.

[@PigsysRetroGameDevTutorials]

That's good to hear! Since this is written in C I always assumed that it would work fine with other consoles too (most homebrew kits for GB, GBA, Saturn, Dreamcast etc have decent C compilers), but it's nice to get confirmation. The GB CPU is much weaker than the MD's mighty Motorola 68k of course, so you might want to optimise the code in the future if you experience any slowdown (if you have lots of enemies also using the collision code for example). However, if things are running fine then you may as well just keep the code as it is. Keep me updated!

[@Nikku4211]

@@PigsysRetroGameDevTutorials Yeah I don't know how to optimise lol.

[@zabustifu]

1:00: Considering there are only 3 plants in this scene, sprites are indeed a fine option here. But if you need to optimize sprite count, you could use the other background plane for that (e.g: main scene on plane A, top of objects on plane B as high priority tiles). Of course, a third and very cheap option could also be to make those plants completely rectangular, as if they've been cut this way, if you can pull off this art style.

[@PigsysRetroGameDevTutorials]

I think for this type of game the other BG layer is reserved for text and menus. The best thing to do would probably be to just make all elements neatly rectangular as you said

[@zabustifu]

@@PigsysRetroGameDevTutorials For dialogue boxes, wouldn't it be possible to dynamically change map tiles to dialogue box tiles temporarily, then revert those changes? Assuming no scrolling happens when the dialogue box is up. It may not be very fast, but that could be acceptable for this kind of game.

[@PigsysRetroGameDevTutorials]

@@zabustifu Come to think of it, I believe Centy uses the other BG layer for parallax scrolling at some points, so it probably is using the method you described

[@Matrix803]

Great tutorial! I was able to get it working for my game. :) I think I also figured out how multiple levels can be achieved! The trick is to initialize your MAP_COLLISION array like this in the beginning of your main code: MAP_COLLISION[number of levels in your game][length of array] = { { 0, 1, 0, 1, etc.}, {1, 0, 1, 0, etc.}, {1, 1, 1, 1, etc.}, {0, 0, 0, 0, etc.} } So, you are essentially setting up the collisions for all your levels in sub-arrays within the same array. Next, you set up a "level" variable of some sort to specify what the current level being played is, along with a function for loading the current level (which would get ran when you either start a new game or switch from one level to another). This function would also assist in changing tile maps, player x and y starting points, palettes, etc. Then in the actual physics code, you adjust all the MAP_COLLISION references from this tutorial so they're set up with the new [level] expression. So for example: "tile_collision_type_bottomleft = MAP_COLLISION[level][array_index_bottomleft_colbox];" One caveat with this method is, I think you might have to make all your levels either the same size, or make all your collision arrays the size of your largest level. I'm not sure if this is the most optimized way to do it, but it worked for me. Hope this helps! ^^

[@lancelnce]

Over one hour tutorial! Nice.

[@PigsysRetroGameDevTutorials]

Thanks! TBH, when I first had the idea to make tutorials I assumed that they would all be 5-10 minutes each, but some topics just need more time and explanation.

[@flamingwoodz]

This demystifies a lot, thank you!

[@PigsysRetroGameDevTutorials]

That's great to hear. I wanted to explain things step by step so that people would understand everything and be able to make adjustments to suit their own game.

[@ThatOldTV]

You're at a point where most people could almost make a game with your tutorials. You need to still cover music & sound (which is pretty simple), Enemy sprites and level progression. Oh! I guess, you'll need to also tackle enemy patterns and how to attack and how they attack. Still, I think you can do that in just a few videos.

[@PigsysRetroGameDevTutorials]

I think there is already a decent amount to work with, so hopefully we'll see more people begin to come up with some prototypes/demos. There is still so much to cover though!

[@deadmarshal]

Impressive, very nice! 😃

[@PigsysRetroGameDevTutorials]

Thanks!

[@raycastello2532]

nice, my friend

[@PigsysRetroGameDevTutorials]

Thanks for your support mate!

[@timgilbert8497]

Thanks for clarifying that const stay on the ROM, I was wondering what happens with RAM when you fill the code with collision arrays.

[@PigsysRetroGameDevTutorials]

No one told me that before, so I had to learn the hard way (I got some very buggy collision and couldn't work out why)! I hope that I can save everyone else the pain with these tutorials :) We'll be discussing ROM/RAM a lot more once we eventually get to loading in arrays of enemies etc.

[@GreyMatterShades]

Fantastic job as always. Very clear and easy to understand.

[@PigsysRetroGameDevTutorials]

Thanks! Good to hear that everything is clear and easy to follow.

[@golvellius6855]

I love your tutorials! Thank you!!

[@PigsysRetroGameDevTutorials]

You're welcome! Thanks :)

[@nikolaus8115]

How do you change dynamically the collision map when you "teleport" your character to another room ? I tried to override the variable's value but it doesn't work.

[@Matrix803]

Hey there! Not sure if you already figured this out (since you commented 5 months ago as I write this), but I actually made a comment on this video just now detailing how I figured it out on my own.

[@nikolaus8115]

@@Matrix803 Hey ! I just saw your code below thanks, that's exactly what I did, except that I didn't know how to create the level's variable and it's somehow hardcoded in my code, but thanks to you I'll be able to optimize my function and won't need a switch anymore :)

[@Matrix803]

@@nikolaus8115 Nice :D Glad I could help! I actually still have switch rules throughout my code, for like different level loading parameters, depending on what value my "level" variable is. My game isn't really going to be that big anyway, so I'm not too worried about optimizing things (though maybe I _should_ be, lol...). One thing I noticed I had to do with bigger maps in particular is hiding sprites. If you have e.g. a 1024x1024 map, sprites will actually cycle around the screen (sorta like Pacman-style). So, I just used the current_camera_x and current_camera_y values to determine when it's the appropriate time to hide or show them.

[@nikolaus8115]

@@Matrix803 I think he did a tutorial about showing / hiding enemies when scrolling the map but I didn't have time to work on it. I decided to limit the maps to 320x224 so I wouldn't need the camera function and dealing with the color limitations can be really painful when you have a lot of different sprites and the map is big. It's complicated to work on this while having a fulltime job, I wish I had to opportunity to learn how to develop for the megadrive when I was a teen.

[@Matrix803]

@nikolaus8115 Ah yeah, I definitely relate to that. I work full time as a front-end developer. So if im not coding my Genesis game, I'm coding websites, lol. It's especially great when hints of JavaScript sneak into my main.c file for my game, then I wonder why certain things aren't working right, lmao

[@igodreamer7096]

Wonderful! ⭐⭐⭐⭐⭐

[@PigsysRetroGameDevTutorials]

Wow, 5 stars, thanks!

[@mikeadams3719]

Your vids are awesome, thank you very much, if 16 tile is limited and you can’t import a whole sonic level to generate a collision array, what would you use for larger platformer type levels?

[@felipematias3162]

i tried doing an 8x8 collision on 16 tile, so i could be more precise, but the text file came out kinda strange, then i went back and made 16x16, is there a way to make a 8x8 work?

[@TheRealSparkster]

do a tutorial on how to make and play music

[@PigsysRetroGameDevTutorials]

It seems there might be a lot of updates to the music driver part of SGDK in the not too distant future so I've been putting off any music lessons, but I will get to them eventually!

[@fieldingmister]

The print is good, but I'm really missing breakpoints. Did you find any way to debug with the VS Code? Very good job, by the way. Thanks!

[@The-E-Base]

Note to self: the lazt way of importing these maps is completely useless if it consists of more than 2048 tiles. Anyways I've got 16384 tiles in mine.