More advice? in Off Topic

ID:119961
 
Oct 14 2011, 10:59 am
This is just another blog post from me asking other BYOND developers for some advice. A few weeks ago I made a post asking about how datums are usually used, and I got quite a bit of good response and tips. This time I'm asking developers that have worked with Dream Maker a lot how they would usually organize and structure their games' code.

I have started many projects on BYOND, but most of the time they seem to fall through mainly because of lack of structure and organization. I understand how to do quite a bit with DM, but things can quickly get out of hand for me with my code, so to speak. After working on a fresh DM environment for even just a few hours, it seems that systems start becoming all over the place, the actual definition for atoms are messy, and it quickly gets to the point where I don't even know where to put things.

I make extensive use of multiple code files, trying to split my code up. At the very start I have Interface.dm (where the most of my macro verbs and winset/winget related code is found), Main.dm (where I define the basis for the world and the mob/Login() and mob/Logout() procs), and Variables.dm (where I list out an extensive bunch of variables used by atoms and the world). After setting these up, I would continue to fill them out, and expand into numerous other files as I try to progress my game.

As I've said above, this system is not working out well for me at all. When I start with those three basic files, all seems fine, but it's hard for me to know how I should sort out anything more.

This is why I am asking for advice again. If you develop with Dream Maker a lot, how is your code generally structured? What should I try doing with my code to ensure it doesn't get out of hand? What programming habits have you picked up that are generally useful to you?

Thanks, as always. :)

I suppose I should learn to develop something soon, my membership runs out in 19 days now ...
#1 Oct 14 2011, 11:27 am
I tend to collect things much smaller than that, according to functionality. So folders for certain game mechanics (I don't mean 'AI' or 'Combat' either, more like 'Tutorial', 'Combat Skills', 'Villager', 'Enemy Gangs' etc), and this within that, one DM file per atom / datum (ish). I say ish, because some are rightfully very small and related, some datums use other little datums internally, so it makes sense they are in the same file etc.
#2 Oct 14 2011, 11:29 am
One of the techniques I use is to split up all the different types of things. A typical project will consist of...

Mobs.dm
Objects.dm
Turfs.dm
Battle_Procs.dm
Enemies.dm <-- holds the enemy datum, which works with Mobs.dm
Characters.dm <-- Same as enemies, only for players
STD_Procs <-- Standard Procedures I tend to use a lot

It tends to deviate something like that. I split everything into their types, and then split further so everything is its own thing. This allows for quick customization and modularity.
#3 Oct 14 2011, 3:06 pm
I do exactly what Caution does. Making a separate DM file for everything seems to do the trick. If that's not enough, you could try folders but beyond that I don't know what to tell you. I'm not sure what you're doing that the separate DM file isn't enough to help you stay organized. It's usually useful to try to get specific as possible, for example procedures. You could do WorldProc.DM for all your procedures that are only for the game itself, NPCProc.DM for the procs that only deal with NPCs, and PlayerProcs.DM for the clients. If you piled all that into one .dm file I would imagine it would get hectic.
#4 Oct 14 2011, 6:31 pm
Using many separate files is a start, but what's more important than just putting code in separate files is making sure that the code is truly separate.

You want to be able to put two pieces of code in separate files and know that one doesn't affect the other, at least not too much. Suppose you have your combat code in one file and your movement code in another. In your combat code you spawn some projectiles. If, when you're coding the projectiles, you have to remember all of the details from the movement code to remember what movement procs you changed because these changes affect how projectiles move, this is when things get messy (even though the code is split between files).

Split things up based on function so each file isolates a set of related things (vars, procs, etc.). For example, don't just put all mob procs in the same file because they are all mob procs. Group things related to a common function - put all of the stuff related to NPC interaction in one file, even though this contains the definition of NPCs, the player's command to interact with an NPC, and other related things.

It should never be a hassle to add things to your program. If you spread your code incorrectly across files it can easily become a hassle. For example, to add an on-screen health bar you should only make changes to one or two files, but depending on how you split things up you might have to modify the combat code (to tell the health bar to update when you take damage), the mob code (to define vars needed for the health bar), the interface/HUD code (to manage the actual health bar), and maybe some other places. As soon as you realize that things are becoming difficult to add or change, stop what you're doing and look for a way to reorganize things. It'll pay off in the long run every time.
#5 Oct 15 2011, 8:42 am
Thanks greatly for the responses. I'm definitely going to make better attempts at it.
#6 Oct 15 2011, 12:52 pm
Forum_account wrote:
Using many separate files is a start, but what's more important than just putting code in separate files is making sure that the code is truly separate.