I was wondering if their was any method or technique any developer uses to simplify codes, so they aren't so blotchy.
In other words, any way to help make a code run more smoothly through compile.
Methods for like the for(), and the New().
If you understand well enough to give me an answer on what you think I meant, that would be appreciated, thanks for reading.
ID:151433
 Jan 6 2011, 11:46 am
|
|
You should probably try out lists and switch statements.
| |
Well, by the way I put my codes together. I was never in the neatness league here. So basically "Computational Complexity" and "Complier Complexity" those would be the only two that I would really need help with here. See, I started coding awhile back, and I quit for about 5 months and I'm just trying to get back into the rhythm of coding again. Thanks BTW for the reply.
| |
I know you're talking about the code itself but this is how I like to organize my code :
////////////////////////////////////////////////////////////////////////// It just helps to keep everything separated. | |
Having a hundred code files wouldn't be helping either to be honest. I prefer minimal code files with maximum internal organization. I guess it comes down to preference in the end.
I use the code files : Player : Settings // Systems // Functions Enemy : Settings // Systems // Functions NPC : Settings // Systems // Functions Object : Settings // Systems // Functions Turf : Settings // Systems // Functions That's 5 x 3 (15) files but that's all I will ever need really. Might make a few random files like Quests.dm or something similar but most code will fit under those basic 15 files. | |
That's why you use folders.
player/settings.dm player/systems.dm player/functions.dm This also allows you to easily uninclude pieces of your code without having to rely on commenting it out. Not to mention it lets you split your project into "modules" more easily, allowing you to get help from others without having to give them any of your work, just have them program new modules based on the specifications of your work. ANNNND, it's a lot easier to selectively #include files with preprocessors than it is to deal with selectively compiling sections of code with them. Now, if you intend to keep your project to yourself forever then you should work with your personal preference as much as you want. But if you're ever planning on making resources for other people to use it's best you get used to a more standard method of organizing your work, so people don't have to figure out how you do things just to make use of your resources. | |
I do something similar, however I separate each and then in the code file itself, I make separations by way of comments. It works well for me as I usually only have about 7 files. (I also add a file for world (general code) and hud (I like to keep it separate from player code)
| |
I have what may seem a pretty pretentious view on code, but stick with it:
Good code is graceful code. Graceful code is the kind of thing that were you to come across it, the following happens: You'd understand it with no major issue. Sit back and go "That's a neat way of thinking about it.". You have a think about how it runs, and realise it always works on the smallest amount of data possible, stores complex and re-usable results etc. You go to make a change to it, and your change actually never touches existing code, just extends it. The greatest quality increase you can make actually happens before you have a code file open, it's mindset. Look around you, what do you see? Objects. Your watch, your PC, desk, chair, bedroom, even yourself. BYOND maps those into three types, those that move (mobs), those that don't (objs) and those that make up your environment and scenary (turfs). However, there are more objects still in this world, that either you can't see or don't need to see. Like your CPU, that's an object, but you don't need to see it or know what it looks like for it to work. Or the wind, which clearly exists (it affects us), but has no visible shape. BYOND maps these too, as datums. All of these things have properties (variables) on them, like the wind has a direction, a speed etc. Sometimes the property is another object, your PC has a CPU object in it. This has neat consequences, like your PC doesn't need to know all the details of running a program, it can just ask your CPU to do it. Getting your idea of the "world" of your game and the objects (visible and invisible) that should be in it is fundamental. Getting this right means everything else falls in place 99.9% of the time, and you get computational simple code without even trying. You actually get pretty much all of the points I listed if you get this correct. Not convinced? Here's an example: mob/person Not so bad, right? Imagine that with all your vital organs though, big code file is big and difficult to keep track of. How about: mob/player Any better? Well, now the person object doesn't have to care how a heart works. Similarly, we can extend Heart for special heart conditions, that say cause large drops in heart beat at intervals, and still the person object wouldn't need to care how that works. In the first example, this would need an extra variable for the condition, more code in beat() to check it and act appropriately. As you can imagine, for more and more conditions you add, the first example's beat() proc and variables get bigger and bigger and more difficult to keep correct. In the end you're doing a butt-load of checks for stuff that 90% of the time, won't even apply to the person object. Your computational complexity is up, all because you didn't get that mindset correct. And if the mindset isn't correct, how can you possibly improve on it? Sure, you can profile code and change for loops for other ones over smaller data, maybe cache results of some calculations, improve the order of if statements to improve short-cutting etc. That's a lot to keep in mind and double-check over to maintain your efficiency gains though as you go forward, and it probably doesn't compare to the second example for the 90% of cases, the majority of your players. Not to mention the potential for bugs that affect ALL of your players. Ultimately the problem is still there, the design just wasn't up to the job. Once you have the mindset solidly in place, then we can start talking other ways to simplify computational complexity. Funnily enough a lot of the tricks still meet the mindset, just take BYOND's strength's and weaknesses into account more. Feel free to ask questions, this topic I've touched on may seem simple, but it's actually really subtle and takes some getting used to. Practice makes perfect. | |
Thanks a lot Stephen001. This is very useful. I will bookmark this, as a precaution. In case I forget any of it. Thanks to the others who posted, Kyle, and Nadrew for their brief examples.
| |
Would be cool if we've something to search codes like Qt Creator. Example:
http://files.byondhome.com/OceanKing/FeatureRequest1.png | |
Data Management (how logically the game's data is divided)
Logical Separation (how logically the code is divided)
Computational Complexity (how fast it runs, or how slow [at worst])
Maintainability (How easy is it to read, change later)
Compiler Complexity (How quickly it may be compiled)
The last one being particularly hard to nail, however thankfully works "fast" enough if you get some of the others correct. What are you interested in simplifying?