ID:152304
 Apr 29 2007, 6:17 pm
|
|
I've returned from a 3/4 year nap and forgotten a bunch....Alrighty.. I saw something a while ago on when to use something.. and when not to(as far as ATOM stuff).. if you could link or provide the info, it'd be appreciated.
| |
Funny = I was just on your profile... I have SUMMONED you.... you almost got it... but I wanted to know when one is better to use than the other... sort of like the src/usr debate
| |
That one's mostly a matter of personal preference... Either one would work...
To me, that one would be an obj... However, if your catapult uses a lot of the same vars and procs that your mobs do (like if they both have a "health" var or some such), it'd be simpler to just make it a mob (so it automatically inherits all of the stuff, instead of having to define everything under two types) The above especially applies if you want your catapult to use any of the special pre-defined vars and procs that mobs have... Most of the built-in stuff is included in both mob and obj (they share the same "parent" type within the program), but there are a few things that are mob-only, and if your catapult needs to use any of them, you have to make it a mob... So the choice between obj and mob really boils down to which makes more sense for the way your game is designed... | |
I was talkin more or less about processor, though it wouldn't make much difference... I'd like to know if any... since some things require less power at compile time and run time and stuff... like maps... would the preloaded procs weigh it down as a mob?
| |
I don't know the specifics, but I'd imagine that there's essentially no difference in those aspects between obj and mob in their basic, built-in forms...
Again, though, things change when the designer begins to add more functions to either one... For instance, if you've got a looping stat proc for your mobs, and your catapult doesn't need it, it would be better to make your catapult as an obj, to keep it from running the unnecessary loop (which eats up processing at runtime) | |
Thanks man... another question I have is how would I make an object with more than 1 tile... and not with a proc.. but pre-built... on the map.. without putting every piece on the map... I use .bmp files..
| |
Spiderdude wrote:
Thanks man... another question I have is how would I make an object with more than 1 tile... and not with a proc.. but pre-built... on the map.. without putting every piece on the map... I use .bmp files.. I've done it with an offset overlay. There are some multi-tiled demos out. Check the demos section on the left. | |
SuperSaiyanGokuX wrote:
I don't know the specifics, but I'd imagine that there's essentially no difference in those aspects between obj and mob in their basic, built-in forms... Other than mobs being capable to hold [/]client data, there is almost no difference. The key of all those differences are that mobs are meant to hold players and objs can't; so technically, what follows is that you should use mobs for anything player-controlled (obviously), and objs for anything players won't [directly] control. | |
Area Turf Obj Mob
I'm going to cover them a bit out of order, though:
Turf is used for all of the tiles that make up your environment ("turf" is another name for the ground beneath you... like "astroturf" is the artificial grass in indoor football stadiums) Stuff like grass, sidewalks, floors, walls, etc. are all things that should be a turf...
Mob is used for living beings, basically... The player is a mob, any enemies are mobs, NPCs are mobs...
Obj is used for any objects that your mobs can use... This includes stuff like equipment, switches, etc.
Area is used to define certain areas of your game (imagine that!) For instance, if you've got a section of the game where new players can't be attacked, you can put the entire thing into an area that disables attacking...
Hopefully that answers your question... If not, you'll have to try to be more specific...