I love that you are thinking about what dropping items on the ground looks like. I was thinking about this in my game. I decided that all items I would be dropping would be placed in a container. For example, I will be spawning guns in a gun crate and when you pick a gun up, the old gun will go into the crate. The gun has a pick up timer(when you drop it in the crate) and gun crate will never spawn as long as the timer and the spawn position is true. I also have the ability to raycast easily in my engine, determining the exact placement was generally easy. I was originally going to drop them at my feet but the thought of guns stacked as high as the timer is true just seemed like something I did not want.
Interesting! In the final version I do end up dropping items on the floor. And yeah, it's a headache. In my version I decided against stacking items on one space so picking up doesn't require a dedicated UI. Like you I try not to drop items at one's feet just so they are visible on the map and picking them up is a deliberate choice. Also I wanted to avoid an awkward "look at what's on the ground" menu command. I ended up simplifying the inventory a lot which helped.
Damn... for some reason I hadn't ever considered using modulo for wrapping around. I usually carry around a wrap() function, and that simplifies it. I don't know if it works for any min/max values, but I'll be trying it out: *function wrap(val, min, max)* *return (val-min)%max+min* _-- my previous algorithm:_ _-- return val>max and min or val
that function actually only works for 1 to 6, the correct function is ugly as hell though and wasteful function wrap(val, a, b) return (val-a)%(b-a+1)+a end
19:39 - Wouldn't a better way to do this state change would be something similar to how you do the game state? As in, you'd have each window object hold an Update function and have the CURWIND pointer execute its Update function. No need for the messy ELSEIF block and you could have as many windows you want without having to code explicitly for each. Another possibility (though probably overkill for this application) is having each window keep a list of child windows, thus allowing you to kill all children by closing the parent (making sure no windows like the use window stick around) and making layout a bit easier. 24:13 - There isn't any equivalent of an ENUM? 31:40 - Another option: make "SEP" another item "type" that won't trigger any action. That way you can use separators in different spots in different windows and they'll always be ignored. Added bonus: you can check for if an item is a SEP and, if so, have the cursor just skip that line.
Window update functions would be a good idea. So is the children thing although I we don't have such a big window structure here anway. No, there are no Enums. You can use variables but that costs tokens. Making a seperator an item type is an intriguing idea! In this case the window is filled with items from multiple tables anyway. So we can't get around the if statements.
yea i think having a item dropping pickup system is not necessary for a roguelike game. Too complicated to implement with maybe not much functionality in reality
The "local" keyword is free so declaring a variable is the same cost no matter what scope it has. It would be really bad if you had to make all variables global just to save tokens!
I love that you are thinking about what dropping items on the ground looks like. I was thinking about this in my game. I decided that all items I would be dropping would be placed in a container. For example, I will be spawning guns in a gun crate and when you pick a gun up, the old gun will go into the crate. The gun has a pick up timer(when you drop it in the crate) and gun crate will never spawn as long as the timer and the spawn position is true. I also have the ability to raycast easily in my engine, determining the exact placement was generally easy. I was originally going to drop them at my feet but the thought of guns stacked as high as the timer is true just seemed like something I did not want.
Interesting! In the final version I do end up dropping items on the floor. And yeah, it's a headache. In my version I decided against stacking items on one space so picking up doesn't require a dedicated UI. Like you I try not to drop items at one's feet just so they are visible on the map and picking them up is a deliberate choice. Also I wanted to avoid an awkward "look at what's on the ground" menu command. I ended up simplifying the inventory a lot which helped.
Damn... for some reason I hadn't ever considered using modulo for wrapping around. I usually carry around a wrap() function, and that simplifies it. I don't know if it works for any min/max values, but I'll be trying it out:
*function wrap(val, min, max)*
*return (val-min)%max+min*
_-- my previous algorithm:_
_-- return val>max and min or val
Modulo is used a lot for wrapping and I started using it more often after this series. Your wrap function looks good!
that function actually only works for 1 to 6, the correct function is ugly as hell though and wasteful
function wrap(val, a, b)
return (val-a)%(b-a+1)+a
end
@@Kulpo yea I ended up giving up on it. It didn't work, and I didn't figure out how to make it work. :)
19:39 - Wouldn't a better way to do this state change would be something similar to how you do the game state? As in, you'd have each window object hold an Update function and have the CURWIND pointer execute its Update function. No need for the messy ELSEIF block and you could have as many windows you want without having to code explicitly for each.
Another possibility (though probably overkill for this application) is having each window keep a list of child windows, thus allowing you to kill all children by closing the parent (making sure no windows like the use window stick around) and making layout a bit easier.
24:13 - There isn't any equivalent of an ENUM?
31:40 - Another option: make "SEP" another item "type" that won't trigger any action. That way you can use separators in different spots in different windows and they'll always be ignored. Added bonus: you can check for if an item is a SEP and, if so, have the cursor just skip that line.
Window update functions would be a good idea. So is the children thing although I we don't have such a big window structure here anway.
No, there are no Enums. You can use variables but that costs tokens.
Making a seperator an item type is an intriguing idea! In this case the window is filled with items from multiple tables anyway. So we can't get around the if statements.
yea i think having a item dropping pickup system is not necessary for a roguelike game. Too complicated to implement with maybe not much functionality in reality
Ironically, I ended up writing one in the release version. I think it depends on the kind of item management you want in your game.
@@LazyDevs lol
The "local" keyword is free so declaring a variable is the same cost no matter what scope it has. It would be really bad if you had to make all variables global just to save tokens!
I mean there is already plenty of bad habits you pick up when saving tokens anway. 😏
But thanks for clearing this up! That's super good to know.
Definitely true... But luckily this means that polluting the global namespace is not one of them!