Proper Player Vs Object Coding
BlitzMax Forums/BlitzMax Programming/Proper Player Vs Object Coding
| ||
| Hello, I have been working on a serious program for the last few weeks with a group of people I know, and I have been programming the Player logic. My question is or maybe request for help is; I'm trying to figure out what would be the proper way (recommended way) to do interactions of player class, and other objects in the game. The first thing I did was separate Classes for each the player, and say health piece and found the code to be very back and forth having to make sure that the player object test to see if the object was: a) with in the correct distance of the player b) which object he was on in the list c) collect the object d) remove it from the list Like I said this was very redundant and I was hoping for a suggestion to better this concept. My next approach was going to be a primary GameObject class and then making sure that objects in the game (player, mobs, object, platforms, etc..) were extended from this primary GameObject class. Then I realized this also created the same problem above having to check a list, and make sure that you were not searching the player, but then you would need to make sure that object was a health object, and etc. Can someone please help me with a better way or am I heading in the right direction with this? Thanks, |
| ||
| ...what have these two concepts got to do with one another? Whether world items are kept in a list doesn't have ...anything, as far as I can see... to do with whether they share a common base class with the player. (Don't use a common GameObject class. There's rarely any good reason to do this. Shared subtypes are for when things are actually subtypes, and might have to operate in the same situations. This is pretty rare for game objects, so they're usually not helpful.) You haven't been entirely specific about what you're doing with lists, but in general an associative structure like e.g. a TMap is good for this. When your player detects a mesh in the 3D scene or a sprite in the 2D scene using collision or the like, you can put it into a map keyed by meshes or sprites to retrieve the health piece object represented by that visual world component. If you haven't heard of entity-component systems, take a look at this and this. They might pre-emptively answer some questions about object structure and show you why it's important to avoid the temptation to subclass GameObject. There are many ways to implement such a thing in Max, so it depends what you're doing. Linking components via a multimap is probably easiest (a multimap is a multi-way version of a map: instead of key-> value, you have obj1 or obj2 or obj3 ... -> {obj1, obj2, obj3}. Implement it by wrapping a whole bunch of maps together, each one keyed on one of the "columns"). Components are important because they let you link a player to a character model and a world position, and a health kit to a potion model and a world position, without suggesting the utterly absurd relationship that because players and potions both exist in space, they must be basically the same thing (which is what deriving both from GameObject would suggest, and why that generally ends up being a mess because the shared properties are totally arbitrary). It also lets you avoid the idea that a player's mesh/sprite, or position, is actually part of a player, when it isn't. |
| ||
| @ Yasha : Thanks for the wise words that you provided me, I have been researching the component approach for the last few days, and its amazing how much more you can do with it. I'm not fully aware of the best way to go about it, but I have been looking at multiple other examples. From what I have seen so far its about not inheriting from multiple types, and just assigning components to the Entities Types inheriting from the base TEntity Type. I had a look at AlexO approach to this as well, and it seems to be very solid approach, but I added in my own things to better it for my programming. |
   |