{"author_link":"\/users\/wouter52","author_name":"Wouter52","author_uid":"wouter52","comments":[],"epoch":1744234561,"event":"LD57","format":"md","ldjam_node_id":414455,"likes":5,"metadata":{"p_key":"211131","p_author":"Wouter52","p_authorkey":"1214239","p_urlkey":"450932","p_title":"Mom: we've got collision system at home.","p_cat":"LDJam ","p_event":"LD57","p_time":"1744234561","p_likes":"5","p_comments":"0","p_status":"WAYBACK","us_key":"1214239","us_name":"Wouter52","us_username":"wouter52","event_start":"1743811200","event_key":"111","event_name":"Ludum Dare 57"},"node":{"_collation":{"body_sanitizer":"TextUtils::SanitizeHTML via existing importer","event":"LD57","removed_author":false},"_superparent":406845,"_trust":6,"author":214239,"body":"Collision system at home:\n![5.png](\/\/\/raw\/fd4\/43\/z\/6bcd1.png)\n\n____\n\n\nOk ok, I HAD to fix this, because the current collision system had a glaring bug that was mentioned multiple times in the feedback. It was detremental to the games funfactor. Luckily I did not have to rewrite everything. I had to change 3 lines of code to improve it. It is not perfect, but it works now. For transparancy and to share my findings I decided to do a deep dive ~~hehe~~ here. Don't feel obligated to read this if you don't really care.\n\n### How the system should work:\nSo, I wrote this baby myself:\n1. The code starts with setting a 2D array to NULL values (width * height of screen)\n2. Then all the objects that have a collider will be tested in with their special ID, pixel by pixel (every pixel, *remember this* ~~forshaddowing~~. If there is a NULL value at the pixel spot, the collider id will be written into the 2D array. If there already is an ID there, a function will be called that \"reacts\" to the combination of the tested ID and the ID that is already in the 2D array. A reaction could be: playing a sound, resetting player velocity, etc.\n\n(For example: If red is already in the array and blue is being checked, the system will see if blue overlaps red. If blue finds a red square, it will react accordingly. If blue finds an empty (white) square, it will place blue in that spot.)\n\n![1.png](\/\/\/raw\/fd4\/43\/z\/6bcd2.png)\n\nIt is important to know that the order of collision detections is a limitation of my implementation. For me it works, but I have to be creative. For instance, my player object has two colliders, a horizontal one to detect X-axis colissions and a vertical one for the Y-axis. Both react diffrently.\n\n### How peals were bugging stuff out\nWhile creating pickups, I needed a way for the pickups to each find out which one is hit and delete it from the array of pickups. I could have had every pickup to have it's own ID and test them one by one. Instead I opted for another option: in my infinite wisdom I decided to *modify my already tested and perfectly good colission system* and shoehorn some code in that returnes true when it found a colission. All the code would still work that \"reacts\" to the colissions, the only change I made was that the code itself would return true and false when it collided.\n\n(For example: The red and yellow squares are already in the array. When blue is checked and finds ANY square, it returns true and stops checking.)\n\n![2.png](\/\/\/raw\/fd4\/43\/z\/6bcd3.png)\n\nThis caused a problem. It reacted to ANY collision. Remember the code that checks for X and Y axis colissions? And remember how the array is filled with ID's when a NULL value is present at the tested spot? Well.. I've got news for you: When testing for the X axis, the code would write a bunch of values into the 2D array where a null was present. Next it would test for the Y axis. However... it would react to the FIRST colission it encountered, would try to react to it (y axis does not react to the x axis), but it would still return true and stop checking the rest. This was not what I intended, the could should check all of it and then return true if a colission happened. The code checks from left to right, top to bottom. So it only happened in specific ways.\n\n(For example: The red squares are already in the array. The yellow squares are being checked on the X-axis (and since there were white squares in those spots, the system writes them into the array). When checking the Y axis, it finds the X-axis squares and stops. Ideally, it should continue checking further to find the red squares, but it doesn\u2019t.)\n\n![3.png](\/\/\/raw\/fd4\/43\/z\/6bcd4.png)\n\n### How did I fix it?\nI added some extra code that would return true if it found a specific ID that is provided with an parameter. Otherwise it would just keep on checking.\n\nThis little change lets me control WHICH reaction it should return true with. I can also tell it not to return true at all.\n\n![4.png](\/\/\/raw\/fd4\/43\/z\/6bcd5.png)","comments":5,"comments-timestamp":"2025-04-09T22:54:15Z","created":"2025-04-09T21:29:07Z","files":[],"files-timestamp":0,"id":414455,"love":5,"love-timestamp":"2025-04-11T07:24:47Z","meta":[],"modified":"2025-04-11T07:24:47Z","name":"Mom: we've got collision system at home.","node-timestamp":"2025-04-09T21:45:22Z","parent":406851,"parents":[1,5,9,406845,406851],"path":"\/events\/ludum-dare\/57\/the-chronicles-of-mr-marmo\/mom-weve-got-colission-system-at-home","published":"2025-04-09T21:36:01Z","scope":"public","slug":"mom-weve-got-colission-system-at-home","subsubtype":"","subtype":"","type":"post","version":1307608},"node_metadata":{"n_key":"414455","n_urlkey":"450932","n_parent":"406851","n_path":"\/events\/ludum-dare\/57\/the-chronicles-of-mr-marmo\/mom-weve-got-colission-system-at-home","n_slug":"mom-weve-got-colission-system-at","n_type":"post","n_subtype":"","n_subsubtype":"","n_author":"214239","n_created":"1744234147","n_modified":"1744356287","n_version":"1307608","n_status":"WAYBACK"},"source_url":"https:\/\/ldjam.com\/events\/ludum-dare\/57\/the-chronicles-of-mr-marmo\/mom-weve-got-colission-system-at-home","text":"Collision system at home:\n![5.png](\/\/\/raw\/fd4\/43\/z\/6bcd1.png)\n\n____\n\n\nOk ok, I HAD to fix this, because the current collision system had a glaring bug that was mentioned multiple times in the feedback. It was detremental to the games funfactor. Luckily I did not have to rewrite everything. I had to change 3 lines of code to improve it. It is not perfect, but it works now. For transparancy and to share my findings I decided to do a deep dive ~~hehe~~ here. Don't feel obligated to read this if you don't really care.\n\n### How the system should work:\nSo, I wrote this baby myself:\n1. The code starts with setting a 2D array to NULL values (width * height of screen)\n2. Then all the objects that have a collider will be tested in with their special ID, pixel by pixel (every pixel, *remember this* ~~forshaddowing~~. If there is a NULL value at the pixel spot, the collider id will be written into the 2D array. If there already is an ID there, a function will be called that \"reacts\" to the combination of the tested ID and the ID that is already in the 2D array. A reaction could be: playing a sound, resetting player velocity, etc.\n\n(For example: If red is already in the array and blue is being checked, the system will see if blue overlaps red. If blue finds a red square, it will react accordingly. If blue finds an empty (white) square, it will place blue in that spot.)\n\n![1.png](\/\/\/raw\/fd4\/43\/z\/6bcd2.png)\n\nIt is important to know that the order of collision detections is a limitation of my implementation. For me it works, but I have to be creative. For instance, my player object has two colliders, a horizontal one to detect X-axis colissions and a vertical one for the Y-axis. Both react diffrently.\n\n### How peals were bugging stuff out\nWhile creating pickups, I needed a way for the pickups to each find out which one is hit and delete it from the array of pickups. I could have had every pickup to have it's own ID and test them one by one. Instead I opted for another option: in my infinite wisdom I decided to *modify my already tested and perfectly good colission system* and shoehorn some code in that returnes true when it found a colission. All the code would still work that \"reacts\" to the colissions, the only change I made was that the code itself would return true and false when it collided.\n\n(For example: The red and yellow squares are already in the array. When blue is checked and finds ANY square, it returns true and stops checking.)\n\n![2.png](\/\/\/raw\/fd4\/43\/z\/6bcd3.png)\n\nThis caused a problem. It reacted to ANY collision. Remember the code that checks for X and Y axis colissions? And remember how the array is filled with ID's when a NULL value is present at the tested spot? Well.. I've got news for you: When testing for the X axis, the code would write a bunch of values into the 2D array where a null was present. Next it would test for the Y axis. However... it would react to the FIRST colission it encountered, would try to react to it (y axis does not react to the x axis), but it would still return true and stop checking the rest. This was not what I intended, the could should check all of it and then return true if a colission happened. The code checks from left to right, top to bottom. So it only happened in specific ways.\n\n(For example: The red squares are already in the array. The yellow squares are being checked on the X-axis (and since there were white squares in those spots, the system writes them into the array). When checking the Y axis, it finds the X-axis squares and stops. Ideally, it should continue checking further to find the red squares, but it doesn\u2019t.)\n\n![3.png](\/\/\/raw\/fd4\/43\/z\/6bcd4.png)\n\n### How did I fix it?\nI added some extra code that would return true if it found a specific ID that is provided with an parameter. Otherwise it would just keep on checking.\n\nThis little change lets me control WHICH reaction it should return true with. I can also tell it not to return true at all.\n\n![4.png](\/\/\/raw\/fd4\/43\/z\/6bcd5.png)","title":"Mom: we've got collision system at home.","wayback_source":[]}