This is an interesting read - RPG creation tips
Miscellaneous Forums/General Discussion/This is an interesting read - RPG creation tips You know. You've been on this RPG trip forever. Media, code tech, and otherwise going on and on about em. Are you planning something?
3) Remarks should be plentiful.
Wrong. Code should be written in such a way that it is readable and self documenting - the more remarks you need to understand what the code does, the more sloppy it is. 4) Use functions instead of sub-routines (gosub/return). Then main reason is for stability. A game is likely to have deeply embedded functionality. Failure to return properly from a gosub will cause a memory leak that may not crash the game for a while. Failure to close a function will cause the code not to compile properly, so the error is caught up front, as opposed to during beta testing.
While this is technically true, it is not the only reason one should use functions over gotos. Nor is it the most important one. 5) Use arrays instead of global variables. Arrays can be declared inside of functions and are global. Global variables need to be declared outside of functions to be global. This also makes it easy to separate and identify ‘global’ variables from local variables.
That is without a doubt the most absurd thing I've ever heard. Seriously. This must be because of some obscure flaw in DarkBasic. 7) Pay close attention to optimization along the way. There are many tips and tricks to optimizing code and making it run as fast as possible. I recommend researching optimization techniques before writing the first line of code.
Yes. The most important one is "Use a language with an optimizing compiler, so you don't have to waste your time doing it manually".My eyes bleed. If you really need to read this, you shouldn't be making an RPG in the first place. And oh the irony of someone using DB not knowing what scripting is.
I did say it was interesting.
:)
:)
RPG = relational database with knobs on.
7) Pay close attention to optimization along the way. There are many tips and tricks to optimizing code and making it run as fast as possible. I recommend researching optimization techniques before writing the first line of code.
And some wise words from Donald Knuth:
"Premature optimization is the root of all evil (or at least most of it) in programming. "
It's true. Get it working and then, *if needed* optimize only the code that executes in your bottlenecks. Anything else is a waste of time and will not likely lead to a faster program (the time spent optimizing code that takes .001% of exectution time is wasted time. That time would be much better spent say, refactoring and/or changing a key algorithm or two that are slowing things down.)
I'd agree with that to a point, but whilst Knuth's advice holds true for most software, I would suggest that optimisation is rather important when we're talking about (for example) 3d game development.
When I worked in the game industry (albeit as a lowly tester), programmers often said "We'll optimise it later". Usually this resulted in no optimisation at all, because, as milestones were missed and new deadlines loomed, they inevitably changed their tune to "it's too late to change it now!"
When I worked in the game industry (albeit as a lowly tester), programmers often said "We'll optimise it later". Usually this resulted in no optimisation at all, because, as milestones were missed and new deadlines loomed, they inevitably changed their tune to "it's too late to change it now!"
I guess the best way is to make optimised code in the first place because you are familiar with how to do it :-)
Wrong. Code should be written in such a way that it is readable and self documenting - the more remarks you need to understand what the code does, the more sloppy it is.
"Self documenting code" is the tagline thrown about by lazy coders who don't want to write comments. Do both. Be a professional.
> "Self documenting code" is the tagline thrown about by lazy coders who don't want to write comments.
partially true. I don't write many comments - only for particularly dense sections of code. I also don't read them, I've been burnt by invalid comments far too many times.
partially true. I don't write many comments - only for particularly dense sections of code. I also don't read them, I've been burnt by invalid comments far too many times.
Comments explain the intention of the code and what it's accomplishing in the larger picture. The code itself should be easily readable as far as what it's doing at a discrete level.
You need both. That's all I'm saying.
You need both. That's all I'm saying.
Comments explain the intention of the code and what it's accomplishing in the larger picture.
No. That's what the SDD does. Comments are for swearing at your co-developers, writting memos and listing any todos. 3) Remarks should be plentiful.
Wrong. Code should be written in such a way that it is readable and self documenting - the more remarks you need to understand what the code does, the more sloppy it is.
Wrong. Code should be written in such a way that it is readable and self documenting - the more remarks you need to understand what the code does, the more sloppy it is.
I tend to agree with this, mostly because there is no restriction to field or method nameing, I find that if anythng needs reming, its because it wasnt written properly. Thats not to say I dont comment, but normaly thats in the second optimizing stage, where I will comment why Im not useing an alternative method.
No. That's what the SDD does. Comments are for swearing at your co-developers, writting memos and listing any todos.
Wrong.