Unfortunately because I made it an app I'd have to pay publishing costs on Google Play and the App Store so for now it's going to be shelved :( In future I'm going to make things for the web because it's more cross platform
Yeah the match statement is not my finest work. Could you clarify what you mean by state lookup matrix? I'm assuming you mean an n dimensional matrix where n is each cell in a row?
@@PatrickModels you have two choices on how you want to handle this case. A. You could move all that logic to a hash table where you just feed it the current state of the row or column, and it spits out corresponding logic. This will run the lookup operations in O(1) runtime, but is harder to implement and maintain. B. You could change how the merging logic is implemented. It goes like this: Filter out zeroes - remove zeroes from the row to simplify the merging process. Merging - Step 1. Initialize an empty accumulator. Step 2. For each tile in the filtered list: * If the accumulator is empty, add the tile to the accumulator. * If the accumulator is not empty and the last tile can merge with the current tile, merge them and replace the last merged element with 0. * If they can't merge, append the last tile to the result and update the accumulator with the current tile. Add zero padding - Add zeros to the end of the array to maintain the original row or column length. Visually, it looks something like this. Let's say you do a left swipe: [] merged-tiles (remove zero?) (concat (repeat (- (count tiles) (count (remove zero? merged-tiles))) 0)) vec))) (defn generate-row-moves [row] (merge-tiles row)) Have fun with that info!
@@PatrickModels I hate youtube comments. I type a long comment and it doesn't register through anyways, you have two choices. A. Create a state lookup matrix or array. You could move all that logic to a table where you just feed it the current state of the row or column, and it spits out corresponding logic. This will run the lookup operations in O(1) runtime, but is harder to implement and maintain. B. You could change how the merging logic is implemented using accumulation. It goes like this: Filter out zeroes - remove zeroes from the row to simplify the merging process. Merging - Step 1. Initialize an empty accumulator. Step 2. For each tile in the filtered list: * If the accumulator is empty, add the tile to the accumulator. * If the accumulator is not empty and the last tile can merge with the current tile, merge them and replace the last merged element with `0`. * If they can't merge, append the last tile to the result and update the accumulator with the current tile. Add zero padding - Add zeros to the end of the array to maintain the original row or column length. Visually, it looks something like: []
Hmm, I'm not sure if doing it like this would fit with the architecture I've made. That said, the fact that my code wouldn't work with the proper merging algorithm is potentially a sign that I took a wrong turn somewhere along the way. My output at the moment isn't actually the next row, it's a list of changes that need to made to the row. A potential solution to the maintainability of the first time would be maybe having the hashmap be generated programmatically? I dunno. Much to consider because I do plan on expanding on more 2048 ideas
Bro said 2048 was too easy and made it easier
FR though actually cool
Maybe too simple would be more accurate haha :)
May this be the start of your ride on the algorithm cuz I'd say you deserve some more views and subs!
I hope so too 🫡
pretty interesting! excited to see what you make in the future
Thank you!
*sniff* *sniff* Why do I smell Clouds...... 1:05
🤫
what if airplanes in the night sky were like shooting stars
i could really use a wish right now wish right now wish right now...
Wait but can we play it?
Nonononononope
Unfortunately because I made it an app I'd have to pay publishing costs on Google Play and the App Store so for now it's going to be shelved :( In future I'm going to make things for the web because it's more cross platform
Am I dumb or are you using AwesomeWM?
Nah I'm using Sway. I used BSPWM for ~6 years but I switched to Wayland and had to leave it behind ~1 year ago
Cool project
Thank you!
Why was 6 afraid of 7? Because 2048...
I'll show myself out.
Btw use a state lookup matrix for the logic. That match statement is horrific.
Yeah the match statement is not my finest work. Could you clarify what you mean by state lookup matrix? I'm assuming you mean an n dimensional matrix where n is each cell in a row?
@@PatrickModels you have two choices on how you want to handle this case.
A. You could move all that logic to a hash table where you just feed it the current state of the row or column, and it spits out corresponding logic. This will run the lookup operations in O(1) runtime, but is harder to implement and maintain.
B. You could change how the merging logic is implemented. It goes like this:
Filter out zeroes - remove zeroes from the row to simplify the merging process.
Merging -
Step 1. Initialize an empty accumulator.
Step 2. For each tile in the filtered list:
* If the accumulator is empty, add the tile to the accumulator.
* If the accumulator is not empty and the last tile can merge with the current tile, merge them and replace the last merged element with 0.
* If they can't merge, append the last tile to the result and update the accumulator with the current tile.
Add zero padding - Add zeros to the end of the array to maintain the original row or column length.
Visually, it looks something like this. Let's say you do a left swipe:
[] merged-tiles
(remove zero?)
(concat (repeat (- (count tiles) (count (remove zero? merged-tiles))) 0))
vec)))
(defn generate-row-moves [row]
(merge-tiles row))
Have fun with that info!
@@PatrickModels I hate youtube comments. I type a long comment and it doesn't register through anyways, you have two choices.
A. Create a state lookup matrix or array. You could move all that logic to a table where you just feed it the current state of the row or column, and it spits out corresponding logic. This will run the lookup operations in O(1) runtime, but is harder to implement and maintain.
B. You could change how the merging logic is implemented using accumulation. It goes like this:
Filter out zeroes - remove zeroes from the row to simplify the merging process.
Merging -
Step 1. Initialize an empty accumulator.
Step 2. For each tile in the filtered list:
* If the accumulator is empty, add the tile to the accumulator.
* If the accumulator is not empty and the last tile can merge with the current tile, merge them and replace the last merged element with `0`.
* If they can't merge, append the last tile to the result and update the accumulator with the current tile.
Add zero padding - Add zeros to the end of the array to maintain the original row or column length.
Visually, it looks something like:
[]
@@PatrickModels here's some sample code for the second logic.
(defn merge-tiles [tiles]
(let [non-zero-tiles (filterv pos? tiles)
merged-tiles (reduce (fn [acc tile]
(let [last-tile (last acc)]
(if (and last-tile (can-merge last-tile tile))
(conj (vec (butlast acc)) (* 2 tile) 0)
(conj acc tile))))
[]
non-zero-tiles)]
(->> merged-tiles
(remove zero?)
(concat (repeat (- (count tiles) (count (remove zero? merged-tiles))) 0))
vec)))
(defn generate-row-moves [row]
(merge-tiles row))
Hmm, I'm not sure if doing it like this would fit with the architecture I've made. That said, the fact that my code wouldn't work with the proper merging algorithm is potentially a sign that I took a wrong turn somewhere along the way. My output at the moment isn't actually the next row, it's a list of changes that need to made to the row.
A potential solution to the maintainability of the first time would be maybe having the hashmap be generated programmatically? I dunno. Much to consider because I do plan on expanding on more 2048 ideas
now make fortnite in 4D fr
I know this comment is a joke but you've got me actually thinking about what a 4D shooting game would be like
@@PatrickModels doom in 4D would be crazy