Yeah. I've seen too many people flounder about to have it happen anymore.
So, here you go.

Rule 1: If you're a beginner, DO NOT make a Final Fantasy/Pokemon/Borderlands/Ultima/<insert console game here> clone. The sheer amount of content will crush you, your spirits, and your lifespan. This also means don't try to tackle a huge project if you haven't don't enough experience.

Rule 2: Always, always, ALWAYS code the battle engine first. Don't even worry about story right now. Get characters and a couple enemies and make that beast of a battle system now. It will kick you in the face later if you don't do it early.

Rule 3: Make sure your menus/GUI and button configuration are the same throughout.

Rule 4: BALANCE YOUR FORMULAS! Attack, Defense, Speed, Stat Gain, Level Up, EXP... Make it all realistic. I shouldn't be able to kill a LV 10 with an uber-randomed LV 2. Make sure your curves are parabolic but not super steep.

Rule 5: Having Japanese-sounding names in an RPG doesn't make a good game. It's gameplay that does it. Make sure your gameplay is solid.

Rule 6: Immersing the player doesn't involve super-awesome graphics. It's the fusion between storyline and gameplay. Innovation is key on this point.

Rule 7: Draw ALL of your sprites and tiles first!

Rule 8: Have a basis to start on when it comes to stats. Just because you know a Fighter's stats at max level doesn't mean that should be your starting point. Work from the ground up.

Rule 9: Write your story on paper first. It will help organize your thoughts.

Rule 10: Code your program in subroutines. I don't care if you hate them. It will help.

Rule 11: If you are making a pure-BASIC game with limited access to archive memory, make sure that NPC convos are as short as possible, while making sure to not destroy your storyline. DO NOT USE LOWERCASE LETTERS! Otherwise, prepare to run out of memory very fast. Text takes a ridiculous amount of memory.

Rule 12: If you are making an ASM/Axe game (doesn't apply to ASM Flash APPs), make sure that as many things as possible in your RPG is in data form. The NPC/Event text, enemy names/stats, monsters encounters possible in each areas, NPC movement patterns, battle background images, not just the sprites and maps. Data doesn't count towards the 8/16 KB executable code limit in 8xp/8xk executables, respectively. If you just hard-code everything with If blocks, prepare to run out of code space very fast!

Rule 13: Don't artificially lengthen an RPG by making the player level up to a certain amount before advancing. Different difficulty modes are a nice touch, though. If you add them, you can go as crazy as you want with grinding in harder modes. (while making sure it's beatable). Illusiat 6 original only had one difficulty. Later, DJ Omnimaga added an easier mode.

EDIT: A warning if you decide to save memory on enemy formulas by adding an universal level per area, like DJ Omnimaga did in Illusiat 3 through 12 (AKA dynamic enemy stats generation): those are VERY hard to keep balanced. Use at your own risk! Halfway through the game, you may end up having to give the character a magic ring that reduces all magic damage by 80% from now on, like DJ Omnimaga had to do in Illusiat 10 and 12. At that point, no matter how high he was in LV, all magic spells casted by enemies seemed to kill him instantly. Such dynamic enemy stats are good to save space, but the downside is that they're ridiculously hard to balance.

Rule 14: When creating characters and situations, write down your character's personality somewhere. When a character does or says something that goes against what they believe in without any provocation, it detracts from the mood. Nothing is worse that having a selfish thief suddenly give something they took back without a reason.

Rule 15: Do not make an ultimate weapon if you plan to make the game multiplayer or you plan on adding a secret boss.

Rule 16: When coding, get a piece of paper and write down the letters A-Z on one side. Then, put the symbol <theta> on the other. Now, any permanent values you don't want to be overwritten, assign a variable to them and leave them on that side of the paper. When you are completely sure of those values, erase all unused letters and put them on the other side of the paper. There. Now, the variables on the left are GLOBAL variables. Don't touch those. The ones on the left are LOCAL variables. You can use those for your temporary loops, counters, whatever you need. And, if you lack enough local variables, throw all of your globals into a list and save it. Then, run rampant with your local variables.

NOTE: If you are making a subroutine, make sure none of the variables overwrite any of your values.

Rule 17: When programming in BASIC, don't use Y if you're using the graphscreen. Some graph functions overwrite that value.

Rule 18: Optimize as you go. But, make sure that you can figure out what each line of your program does.

Rule 19: Ask for help if you are struggling.

P.S. Please rate me up on this if you like this. My respect is fluctuating.

When you are trying to display a sprite that is bigger than 8x8 and you are reading two bytes at a time, does that mean that the data needs to be reversed or something?

Is it possible to play BGM music in Axe if the following were true:

*If there was an AppVar that acted like a filetype and the bytes for the sound frequencies were stored inside.
*If it was played as frequently as an interrupt.

Comment and tell me what you think.

Is it possible?
I want to display 4 bytes of a 16x24 sprite in a line.
Would I use Pt-On or Pxl-On for this?

Okay.

This has been alluded to before in another topic, but I need to understand.
How exactly would one get external data from another program?

Oh. My. God.

EDIT: A zombie invasion invoked this. Proof.