Over the last few days, I've discovered I retained just about all my knowledge of how to program in DM... remarkable for a fellow who has taken a vacation from coding for weeks and months. Not only that, I seem to have become better at it.
I guess the incubation has been good for me, as by separating myself from my code for awhile, it provided the necessary mental distance to critically assess what I've been doing and make improvements to it.
Here's a few things I picked up just recently:
If I could summarize all the above in one sentence, it would be this: Do not work for your code, make your code work for you. When you start coding a new language, you will be doing the former. However, as you continue to practice coding, you can perpetually invent new ways to turn the tables. The only catch: progress will be slower unless you're actively trying to do this.I guess the incubation has been good for me, as by separating myself from my code for awhile, it provided the necessary mental distance to critically assess what I've been doing and make improvements to it.
Here's a few things I picked up just recently:
- Never stop trying to make your code more self-contained/modular.
This largely entails thinking very much in object oriented terms and separating code into files named not for something like their path (as I did before recently) but rather files related to a specific feature being added. Even though I might have a mob, client, and special datum definitions all in the same file, if this block of code has no references outside if it, that's self-contained code.
In a best case scenario, if the code is well-modularized enough, I can just yank one file and have the whole functionality I need with little-to-no modification needed. This would be particularly useful for using test beds that tweak the desired performance of the related code.
Remember: it's much easier to modularize your code while it's still fresh on your mind because what's obvious to you today will some day need to be almost completely relearned. So don't wait until it's time to create a library, start thinking about how you might be able to do it now, while you're coding it.
You probably won't be able to do it right away, while the code is still being conceptualized, but a solution is likely to occur as long as you keep in mind your intention to make the code self-contained. - Don't be afraid to code things that are completely disconnected to your existing code.
I often describe building an epic project as building a skyscraper one board at a time. However, there's a problem with this analogy: it assumes that your structure has to deal with gravity. As a programmer, you can ignore gravity while constructing and reap the benefits of not having to worry about holding anything up until it's done.
I've found it's better to just code an independent entity as though it has nothing to do with anything else, and worry about connecting it to the rest of your code later. If I've got a pretty good idea about how to build a penthouse suite, but I don't know how build the building underneath it, no problem. Just code that penthouse suite and the rest will come in time.
Perhaps the number way I stumped myself while coding is by asking myself a simple question, "now, where was I?" That's a really hard question to answer yourself when you're staring at several dozen files of code. Turns out that question was a fool's errand: it's not about where I was, but where I'm going. When it longer matters how I'm going to add it, when I'm adding it now and worrying about how it's going to fit later, being stumped does not exist as long as there's one thing I'd like to add to my game.
You'd think this would burn down your code by creating a bunch of garbage that you can't connect to the rest of your code. On the contrary, if you've been working with your code recently at all, you'll probably recall what you need to know about connecting the code while you're writing it. You may even need to code some new interfaces, or set about improving your existing code (as this is a great opportunity opportunity to reassess if that code is self-contained enough - see #1, above). - It's better to overload an existing proc to exhibit more intelligent behavior than it is to create a brand new proc to handle a special case.
For many game concepts, for the overwhelming majority of what your game does BYOND already has procs related to it. Enter() determines if you can enter something. Entered() determines what happens when you have. Move() determines how you move somewhere. And so on.
You don't have to abandon those procs, you just need to re-educate them with the special behavior that applies to your game. For example, step_towards currently can't take into account multiple maps in your project because there's no unified method of joining maps. A simple override, and suddenly your step_towards knows how to step between your maps. You could even include true AStar pathing functionality.
Why is this better? Many reasons. Because Dantom had a pretty good idea about the flow of an online environment when he built those procs, and keeping your game in line with that will help its form. Because adding more procs that do the same thing just makes that many more procs to remember later. Because, when all your code operates under the same parameters, you'll encounter less conflict later.
In a little more complex of an example, I have planets that use Lummox JR's swapmap to generate plots of turfs that the players can visit. I initially created some special procs that created the swapmap, located the swapmap, found a place to enter that swapmap, then moved the player to the swapmap. Very awkward to remember later. The revised code simply overrides the plot object's Enter() and Entered() code to run all the necessary procs automatically. Now, all I have to do is tell movable atom to Move() into a plot object, and the rest is handled automatically.
One caveat, though: if you're going to override core procs, code with efficiency in mind. If you have to run several thousand lines of code every time a mob moves, your game will probably slow to a crawl after the first 20 mobs. Code in mind of the program flow going through as few lines as possible in the greater majority of cases.
Of course, these suggestions may not be the best for everyone. Every programmer has their style and experience. Perhaps this advice is too hard to follow. Perhaps this advice is trivial and you've moved on to better things. In the end, the best thing to do is to practice and, if you're working with other programmers, make sure your code is well commented and you're all following the same standards of format.
Code just isn't the same. You have an infinite supply of for loops and you don't need cranes and trucks to move them around. People still have a sense of permanence about code though. Once they put an idea into code they feel obligated to stick with that code or only make slight modifications. Part of this is because people tend to stick with their initial ideas, part is that their code isn't modular and they're afraid that drastic changes might break other things. If your code is set up decently it shouldn't be a problem to rewrite something.
If you find yourself working on a project and think "I should just start over" then you probably did something wrong early on and were afraid to change it. Try to figure out what that mistake was otherwise you'll just do it again.