Garthor wrote:
The trouble comes when you forget what exactly you're looking for... That's why you name the verb/proc/whatever with a name that reflects what it is. mob/verb/Blacksmith_Item() Then it is not a hassle to find. :) | |
Heh, being that I have seen some of your code Garthor, I recommend you split the stuff up to different files. In my 'Solus GMUD System', I have the source split up like this...
area.dm - All the games areas, convientiently located in one (small) file client_basics.dm - All client proceedures, variables, and anything else mobile_saving.dm - Whatever I use for saving code mobile_basic.dm - All of my re-definitions of existing procs (Stat, Login, Logout, etc.), for 'class' based games, this is where I stick the starting form for each class (values of their variables, icons, etc.) mobile_implementor_verbs.dm - Anything and everything dealing with being an implementor, except Login() changes, which are located in mobile_basic.dm mobile_procs.dm - All of my freshly created mob procs mobile_variables.dm - Variable definitions, I _try_ to keep them all here mobile_verbs.dm - Umm. Duh. object_equipping.dm - May not even be relevent, but given that my object equipping has to be very long (it can edit pratically any stat, and each piece can have up to 9 different stat increases/decreases on it) object_variables.dm - Hum de dum. All my object variables, normally a pretty short file turf.dm - All of the turfs in the game Note: I played NeoHaxor's game Evolution, and he taught me something. Using areas to declare density rather than turfs allows for lots more versitility in your games (non-dense walls, secret passages, use your head) world_basics.dm - Pretty much dealing with global variables, and world/hub, name, New() proc, any global loops (ticker, repopper) Now, if you use lots of different map files, I recommend segregating them in a different folder, along with a code file for each map, declaring the objects found on the map, and the mobiles. I mostly use this technique in TTS however, so it may be of no relevence. Also, using areas or whatnot for warp locations makes it much, much cleaner than using coordinates, especially if you change the size of the map, and scoot things around as much as I do. Polatrite | |
turf.dm - All of the turfs in the game Yeah, but which is kind of STUPID...he names all of his areas no_pass passable so all ya gotta do is point your mouse over it.... :P | |
Polatrite wrote:
[snip] turf.dm - All of the turfs in the game[snip] Uhmn, you can edit the density of objects in the map editor. | |
Actually, that's correct. Everything in the computer becomes procedural, but they're different at the lower levels.
OOP languages are generally compiled or interperated in such a way that in asm you might have: xor ax, ax jne __MyProc __MyProc: **DO STUFF** I don't want to get into that, but basically it's a bit-wise comparison between the ax register. If it ends up not being equal, it jumps to MyProc. In Serial languages it would look more like: **DO STUFF** Without the test, which makes it LOOK Faster, but it's not. When you think that the stuff in **DO STUFF** section MAY not need to be done, but are done anyways, you realize it's less efficient. In fact, a couple OO Operating System's I've used are insanely faster than their Serial-Based Counter-Parts ( Same OS concepts & stuff, different code-base ( C vs C++ )). But this is very abstract and usually not really worth a damn unless you're designing for raw speed, which most BYOND users seem to care little about. The reasons I REALLY promote OOP is that it generally causes fewer problems. Because of the nature of it, you can have easier-to-write raw code. And it's maintainable, which any of you who have had a 1000+ line program in QBASIC know it's REALLY HARD to add anything to the game. Even the smallest matters are huge deals. | |
Sure you can, but that takes a while, especially when your workspace is older than your little sister. Well, not quite that bad, only 4 years. But either way, thats more of a hassle, plus is has to make more turf states at compile-time (I believe, not totally sure, and I won't even pretend to know, just assumptions). With an area, a simple click and the turf is either dense or not dense.
| |
I agree with the redundancy, as my friend can attest, I've probably rewritten my project about 3 or 4 times because I learn something new or realize I have bad or redundant code in there!
Loops are bad in an online game because they require over-use of the system. When it goes down to the computer level, which is already slowed down cuz BYOND is an interperator with a compiler to move it down to a more raw language, we get two structures like this: **DONE WITH A LOOP** LOOP DECISION IF TRUE - DO THE STUFF IT NEEDS TO DO IF FALSE - EXIT LOOP CHECK LOOP AGAIN IF EXIT LOOP REMOVE LOOP OVERHEAD AND CLEAN-UP LOOP STRUCTURE PROCEED **DONE WITH A NON-LOOP APPROACH** IF DECISION IF TRUE DO THE STUFF THAT IT NEEDS TO DO IF FALSE DO THE OTHER STUFF IT NEEDS TO DO REMOVE IF OVERHEAD AND CLEAN-UP IF STRUCTURE PROCEED You see, the loop structure actually requires two decisions to be made: Whether the loop can proceed and whether the system is in a loop at all. This is the way almost any programming language works. AANNNDD, if you have a problem with GOTO statements, it's non-existant because ASM relies heavily on jumps ( which are almost like GOTO, but a little more efficient ). So if you need to loop, it's almost better to force a GOTO and use an IF statement. Not to mention, you can do more at once because you can start doing stuff in the FALSE section, whereas in a LOOP you cannot. | |
ShadowWolf wrote:
which any of you who have had a 1000+ line program in QBASIC know it's REALLY HARD to add anything to the game. Even the smallest matters are huge deals. I've written numerous qb programs with over 1000 lines, and I think it really depends on how efficient your code is. Hmm, if I hadn't of found BYOND, I would have still been working on that tile-based qb RPG. >:) (Ugh, it was funky too ;)) - Malver | |
Well, speaking on the realm of code organization, here's how I'm doing my latest project:
MRPGMain.dm -- Start of everything, it's more the world stuff, but there are a few init's in there too. MRPGPlayerCharacters.dm -- PC stuff MRPGMonsters.dm -- Enemies and Creature stuff MRPG[TownArea] -- Basically, like MainTownAreas and stuff like that MRPGMagic -- Magic system MRPGGuilds -- Guilds and Guild-Related stuff, including Levels MRPG[ItemType] -- Basically just holds all instances of one item type. MRPGCOMMENTS -- Just a comment file so I can remember stuff :-) But I think I might like Polartrite's method better. Mine's getting disorganized now... | |
But I think I might like Polartrite's method better. Mine's getting disorganized now... I don't know about better, but I did look at a couple DB games code. Oh god, I was scared. They had mobile variables defined at like 40 places through multiple files... I could never operate in an enviroment like that. Speaking of variables... say I have... mob/var hp = 5 maxhp = 7 mp = 2 maxmp = 3 str dex gold exp If the variable is still null, does it consume memory, or... I don't really understand alot about the super-internal computer workings. Variables, garbage collection, etc. Just a basic rundown on the whole shabang would be nice. | |
It really depends on how the Language defines null. In some environments, null is literally no memory, or basically a 'black hole' of the system. In others, null is just defined by "" and 0 and what-not, but in DM I know for a fact that "" and 0 are NOT the same as null, which leads me to believe that they have a black-hole part of the system.
I, personally, always cast my variables as a type on creation ONLY if they are going to be used immediately. Otherwise, it's a waste of space to code '0' and all that stuff, so don't bother. But memory wise, I believe, it makes no difference since memory is not taken up until you use the variables. One thing I pretty much am sure of is that variables are controlled at run-time. So when you start using your variable hp, it assigns 5 to it. Until you do, however, hp doesn't exist anyways, so don't worry about it. Basically, in an overlycomplicated way, I've stated you can do it either way because DM's variables are controlled at run-time and not compile-time. | |
Assigning things to 0 has its uses. For example, say you want to give someone starting a game out with no 'Computers' skill in the game.
If you left it as null, you would see in the statpanels: "Computers: %" But if you initialised it as 0, you would see: "Computers: 0%" One little-known fact of BYOND is that it doesn't track individual variables of any object until those variables change from the default. That is, if there are 15 objects of the same type in memory, then all of the variables of the default are tracked and take up memory, but the only variables of the objects that are tracked are their x, y, z, and loc values, assuming they're different, as well as their internal ID numbers. If there is only one object, then it will actually be less efficient, since it's loading a template and then loading an object based off of that template, which is forced to have its own x, y, z, and loc variables. That's four additional variables. But as more and more objects are defined, the savings becomes astronomical. Savefiles are similar -- any variables that don't contain values equal to the initial values are stored; otherwise, the object will simply gain the initial values when it is reloaded. (This actually caused confusion on my part, once, but I remembered this fact and thus didn't falsely report it as a bug.) Anyway, I'm not exactly sure how BYOND handles null itself, but I would presume that it's just a blank (but crash-protected) memory address. | |
heheeh Well, our teacher has (had, he retired att he end of this semester) this thing with short and to the point comments, so that you wouldnt get distracted by them when you read the code..
I got bored one lab test, and wrote all my comments in haiku just to bug him >:P On Form_Load this fires It adds the fields to ListBox Hopefully this is right ^_~ Elorien | |
True, they shouldnt have said -avoid- loops, it should have been avoid -poorly writen or unnessicary- loops ^_~
Youd be surprised how much code you can get ridda, and how much faster the program runs sometimes if you just find another way to do it then a loop @.@ Elorien | |
All loops are inefficient compared to non-loop counterparts. You should avoid them like the plague if possible.
If you DO use a loop, make sure it doesn't last very long. | |
That's the most hillarious programming-related thing I've ever heard. Sorry, but I feel like I need to rip that off because I know my C++ professor would appreciate that :-)
By the way, one time I left a 35 line note on how pointers were far better than what we wanted us to use, and it was unrealistic to expect us to recode the same thing 8 times each being 50 lines of code. He gave me full credit cuz he knew I was right :-) | |
True, I wasnt saying that you shouldnt avoid loops, I was just saying that dont avoid them all-together ^_~ thats why theres 3 different flow structures in programming, you -need- them all to solve any problem you come across, you just have to know how to pick them properly.
El | |
ShadowWolf wrote:
Loops are bad in an online game because they require over-use of the system. Loops are an integral part of any program that actually does anything useful. They're unavoidable. The trick is to know how to use them. When it goes down to the computer level, which is already slowed down cuz BYOND is an interperator with a compiler to move it down to a more raw language, we get two structures like this: As far as I know there's not a whole lot of "loop overhead" in most languages. In DM I know there's a temporary list created if you use a for(N in M) syntax, but cleaning up that list would happen regardless. Cleaning up overhead is also a minor operation, when it needs to be done at all, if you're doing it for a comparatively large loop. I also think you've woefully misrepresented the if-else structure of a loop. It looks more like this (for a while() loop): LOOP DECISION IF TRUE - DO THE STUFF IT NEEDS TO DO CHECK LOOP AGAIN I left out cleanup because, well, there isn't any to speak of. **DONE WITH A NON-LOOP APPROACH** I don't see how the above can be translated to this. Either you need to do something in a loop or you don't; the two situations are entirely different. And whereas it might be arguable that some loops use "structures" that need cleanup, if() does not. This would strictly be a jump instruction in the bytecode. You see, the loop structure actually requires two decisions to be made: I don't follow what you mean here. If you're in a loop, you know exactly what's in the loop and what's not. A loop has only one key condition, although you can add others to break out early or skip ahead. This is the way almost any programming language works. AANNNDD, if you have a problem with GOTO statements, it's non-existant because ASM relies heavily on jumps ( which are almost like GOTO, but a little more efficient ). A jump is exactly like GOTO. The GOTO instruction basically showed up in early programming languages because it's directly analagous to a machine-language jump. In the case of an interpreted language like BASIC or Java or DM, there's still a jump instruction but it's in bytecode. So if you need to loop, it's almost better to force a GOTO and use an IF statement. No. Not to mention, you can do more at once because you can start doing stuff in the FALSE section, whereas in a LOOP you cannot. But as I said, a loop and an if-else are completely different situations. Either you're iterating over a bunch of things, or you're doing a one-time decision. Lummox JR | |
ShadowWolf wrote:
Actually, that's correct. Everything in the computer becomes procedural, but they're different at the lower levels. Actually jmp is the instruction of choice for a hard jump, but that's only in compiled languages. In an interpreted language, an internal program counter and probably some pointers are changed. I don't want to get into that, but basically it's a bit-wise comparison between the ax register. If it ends up not being equal, it jumps to MyProc. The instruction "xor ax,ax" performs an XOR on the ax register with itself, forcing it to 0; this is marginally faster than mov ax,0. It's not a comparison at all; however it does set the Z flag, indicating a zero result, which would allow an instruction like je or jne to make a decision. Incidentally, the ASM code you posted would do nothing except reset ax to 0, because jne is the same as jnz, meaning no jump will happen if the Z flag is set. I think it's possible you meant "or ax,ax", which would indeed behave like more of a test, by resetting flags without changing ax. If that's the case, then the instruction is equivalent to: if(_AX) goto _MyProc; In Serial languages it would look more like: The way a loop is constructed is a programmer's own decision, and whether redundant things are done depends on that. Otherwise I'm not sure what you're getting at. Two things I can tell you, though: If a jump is intended, it's simply done, so I'm not sure where you're getting the idea that a test is done. The other thing is that serial languages and object-oriented languages are basically the same thing; both execute code in order. The only significant difference is that an object-oriented language tends to run on some kind of event loop, with a manager function or thread determining which functions to call. "Oh, there's input waiting in the queue, so I'll call HandleInput() next." At the function level there's no difference between these language types, which means loops and everything else work the same way. The only difference is the entry point of the program, which in object-oriented languages is usually just implied. (C++ is really more of a strictly serial language than object-oriented, since it preserves a main() function that's really non-negotiable except in things like DLLs. Java, on the other hand, uses main() on a much more limited basis, and pretty much always concerns itself with handling various objects; things like applets can be compiled without using a serial-style entry point at all.) In fact, a couple OO Operating System's I've used are insanely faster than their Serial-Based Counter-Parts ( Same OS concepts & stuff, different code-base ( C vs C++ )). C and C++ are basically identical except in syntax. They both compile to machine code. C++'s object approach can actually be slower, though, because polymorphism (the concept behind multiple inheritance) means that function pointers may have to be looked up from a table at runtime, not compiled directly in. This is called "late binding" and occurs with any C++ member function declared as virtual. Basically what's happening here is that C++ has a sort of transparent way of managing and using function pointers, but you could do the exact same thing in C and see no difference in the machine code output. But this is very abstract and usually not really worth a damn unless you're designing for raw speed, which most BYOND users seem to care little about. Raw speed really comes from programming at a very low level, something that gets right down to machine code. You get the best speed by hyper-optimizing the machine code, which requires programming in assembly (or assembly inlined into a language like C). The reasons I REALLY promote OOP is that it generally causes fewer problems. Because of the nature of it, you can have easier-to-write raw code. And it's maintainable, which any of you who have had a 1000+ line program in QBASIC know it's REALLY HARD to add anything to the game. Even the smallest matters are huge deals. BASIC is not a language that's easy to change programs in, it's true. I worked with it for years before I learned C. C, however, is vastly different because of its top-down function model, so it's apples and oranges. But you don't really get to object-oriented programs until you work with something like Visual Basic or DM, which have event managers and a lot of internal structure that basically acts like a pre-written keystone to your program. Lummox JR | |
"now where is that blacksmithing code..."