ID:155433
Jul 8 2011, 6:43 pm
|
|
My first project is finally starting to move forward. I'm still a bit uncomfortable about how to use the client and mob variables. For instance, what I have right (roughly) puts all gameplay related variables and procs under mob, while any variables and procs related to display and the interface (such as the flag that indicates whether we are in a menu) go under the client. It doesn't seem to matter, though, which variables go where except for organizational purposes. Does it matter? Am I going to get halfway through the project and find that I made a major design error?
|
In response to Ill Im
|
|
Thanks a lot. As the complexity of the project grows, I am thinking more about how to organize all of the interface data, and so that is a good idea.
|
Use datums. Spells, HUDs, movement systems, all of those things should be handled by datums. The only variables you need on the mob and client should be references to those datums.
|
In response to SuperAntx
|
|
I did exactly that. As a long time C++ programmer, I am only now starting to appreciate how BYOND differs from C++. It does indeed work much better now.
|
There are probably some rare cases where it matters. In most games the player controls a single mob, so you rarely bother to ask yourself "is this a property of the mob, or of the client?". In the rare case that a player switches to control a different mob, there may be some things you had assigned to the client that may belong on the mob, or vice versa.
But generally this doesn't matter, it's purely for organization. If you did declare extra vars on the mob when they could have been defined for the client, BYOND won't use extra memory unless a mob modifies those vars. You can also declare vars as tmp vars so it won't affect how mobs are saved. |
You could probably handle everything under datums for better organization (i.e: an /interfaceHandler datum attatched to all client's that handles the interface)