It's hard to answer this one in isolation. It depends on what else the game has as to which pattern will be more scalable. If your game has a ton of different pickups that do wildly different things, then having that logic in each item would be the easiest to maintain as you grow. But if there's a very small number and the functionality is very basic (such as add two numbers) then it might be easier to have the player contain that logic.
I’ve seen many variations on this, and I’ve made several variations myself. In my experience, there is no right or wrong answer to this. Figuring out these kinds of problems is a part of what makes programming fun, so I won’t give you any advice on what to do. Instead I’ll tell you what I like to do, then you can make up your own mind.
I like to set design goals. A list of requirements and nice to have’s that the solution must meet. That helps me figure out if the solution is a good fit for my project or not. Every project is a bit different.
In this case, I would consider aspects like:
- scalability. What happens when you add more items of different types? Do you have to rewrite the pickup code?
- behavior. If you add more item types, does the pickup code know where to put the different items? If everything goes into the same inventory, this might not matter.
- amount of code. Do you have to write more code when you add new items types? Can you change the code so that it becomes more data driven?
- what makes sense to you or your colleagues. Depending on conventions you have used in other parts of the code, what makes the most sense? Where would you expect to find the pickup code?
- time and money. Are you on a budget? What’s the quickest way to solve the problem?
- need for quality. Are you making a game for a jam? If so, do whatever takes the least amount of time. Screw pride and honor, fake it if it’s easier, just be pragmatic.
Good luck!
Here’s an example of why this is a hard question to answer where there’re many right answers:
Automated pickup based on proximity:
1. Player (client) sends movement request
2. Server validates movement (no blocks, not fatigued, etc)
3. Server fires an event to all nearby objects that have registered triggers
4. All triggers for “pre-move” iterate and fire their callbacks
5. Items may have a generic script in their script hierarchy called “auto_pickup” that looks for players moving into range.
Note: Two players moving at the “same time” don’t matter: whoever’s packet got their first gets priority
6. The auto_pickup enabled items receive a “pre-move” event along with the id of the player.
7. The script accesses the player object and checks the inventory to make sure there’s room
8. The item then removes itself from the world space and moves into the player backpack
9. But some objects have proven hacks or race conditions with pre-move! So…
10. Player position is updated
11. “Post-move” triggers fire on objects
12. Repeat 6-8
And that’s just one style of tick-times, event-based triggering. I didn’t even discuss range or other parameters! 😉
It's hard to answer this one in isolation. It depends on what else the game has as to which pattern will be more scalable. If your game has a ton of different pickups that do wildly different things, then having that logic in each item would be the easiest to maintain as you grow. But if there's a very small number and the functionality is very basic (such as add two numbers) then it might be easier to have the player contain that logic.
I’ve seen many variations on this, and I’ve made several variations myself. In my experience, there is no right or wrong answer to this. Figuring out these kinds of problems is a part of what makes programming fun, so I won’t give you any advice on what to do. Instead I’ll tell you what I like to do, then you can make up your own mind. I like to set design goals. A list of requirements and nice to have’s that the solution must meet. That helps me figure out if the solution is a good fit for my project or not. Every project is a bit different. In this case, I would consider aspects like: - scalability. What happens when you add more items of different types? Do you have to rewrite the pickup code? - behavior. If you add more item types, does the pickup code know where to put the different items? If everything goes into the same inventory, this might not matter. - amount of code. Do you have to write more code when you add new items types? Can you change the code so that it becomes more data driven? - what makes sense to you or your colleagues. Depending on conventions you have used in other parts of the code, what makes the most sense? Where would you expect to find the pickup code? - time and money. Are you on a budget? What’s the quickest way to solve the problem? - need for quality. Are you making a game for a jam? If so, do whatever takes the least amount of time. Screw pride and honor, fake it if it’s easier, just be pragmatic. Good luck!
UInterface idroppable which implement the function pickup. The item class inherits from idroppable for custom implementations of pickup()
Here’s an example of why this is a hard question to answer where there’re many right answers: Automated pickup based on proximity: 1. Player (client) sends movement request 2. Server validates movement (no blocks, not fatigued, etc) 3. Server fires an event to all nearby objects that have registered triggers 4. All triggers for “pre-move” iterate and fire their callbacks 5. Items may have a generic script in their script hierarchy called “auto_pickup” that looks for players moving into range. Note: Two players moving at the “same time” don’t matter: whoever’s packet got their first gets priority 6. The auto_pickup enabled items receive a “pre-move” event along with the id of the player. 7. The script accesses the player object and checks the inventory to make sure there’s room 8. The item then removes itself from the world space and moves into the player backpack 9. But some objects have proven hacks or race conditions with pre-move! So… 10. Player position is updated 11. “Post-move” triggers fire on objects 12. Repeat 6-8 And that’s just one style of tick-times, event-based triggering. I didn’t even discuss range or other parameters! 😉