Good game and program design is actually a very simple thing, but it has to be done carefully to be successful.

Game design

• Come up with a good idea that you would want tp play. If you don't want to play your own game, then chances are few other people will either.
• The least followed rule of game design is to check if your game exists. Get on Google or ticalc.org and look for similar games. If a similar game exists, don't make your own unless it will be substantially different from all previous attempts. Making yet another WFRNG is unnecessary. Porting one to a new device is useful.
• Plan it out. Too many games require major overhauls because the author realizes halfway through the project that their original idea isn't good enough. This is especially true if you're writing a story based game like an RPG.
• Be realistic. You're not going to get Modern warfare 2 running on your TI-83+ or Crysis on your Prizm.
• Speed, speed, speed. Keep your game as fast as is reasonably possible within the constraints of the language, even if it means that you have to delete that fancy HUD that takes a full second to render. There's nothing like 1 frame per minute graphics to make you want to immediately delete a game.
• Keep it light, within practicality. The vast majority of calc games don't require more than a few kilobytes of memory. Making them into an app just wastes user space and introduces some incompatibilities with older calcs. That said, there are definitely exceptions to this rule, such as when that space is effectively used to enhance a game. For example, Illusiat 13 uses the memory it takes to create an absolutely massive world.
• Keep the User Interface clean and simple. A crowded UI is confusing and makes games difficult to use.
• Include documentation. The end users can't read your mind. Give them a simple readme.txt file (written in English!) to answer a few basic questions about the controls, the storyline, the game itself and so on.
• Use standard keyboard mappings. I can't speak for everyone, but I'm liable to get very annoyed at a program that uses the Clear button as the Enter button or something equally ridiculous. Also, let me repeat myself: include the controls in the documentation, even if they're entirely standard.
• Debug, debug, debug, debug, debug, and debug again. There is NO reason not to debug if you do not have a deadline. Far too many games fail to debug properly and are thus rendered inoperable by many users.
• Include all of the necessary files to run your program. This might sound silly, but you'd be surprised how many people forget to include that one subprogram that contains the entire game engine.
• Keep it widely compatible. Don't write the game so it only works with one version of an obscure, unreleased shell written in 1998.
• Handle errors effectively. Don't let a text based game crash because the user entered a number rather than a letter.

Program design:

• All of the rules in the previous list apply here as well. Read them.
• Don't reinvent OS functions in slower, less accurate ways.
• If you're writing any sort of quadratic solver, give up, go home, and please don't release it. Your users will be perfectly content picking from among the other 3000 quadratic solvers. Now, Nth degree polynomial solvers that can find complex roots are another matter...
• Keep the download size small, please. A good rule of thumb is that if your documentation takes up more space than your program, your program is one of three things: Too complex to ever be used effectively, too brilliant for a coder of your caliber to be reading this, or the documentation is too large. Chances are, it's the third option. There's no need for multi-MB documents to explain your 2 KB quadratic solver.
• Write the documentation in a known language, preferably English. Most of your users will not understand that obscure language spoken in a South American village deep in the Amazon.
• Don't knock off proprietary commercial software like Windows and port it to your calc in BASIC.

Please. FnOff, then FnOn when you quit the game. (In BASIC)

Oh yeah I despise that. It especially sucks when you got no internet at home and are in a hurry to download stuff at school...

Sadly, sometimes it's impossible due to copyrights, though.

Yeah that's what I meant. If you can include the file, then do so. Please read the license first, though. With Omnicalc, for example, the entire source must be included. If you can't include the file, then warn in your description at the very beginning that this require an extra file and put the link to it.

Otherwise I hate when I download a software somewhere or even a game, only to be greeted with a "This program could not be ran because something.dll is missing from my computer"

What about Axe? I know I am ethically obligated to say "This is an Axe Program" and give all due credit to Quigibo, but do I have to include the Axe App/link to it as well?

Nah, you don't, it's actually the Assembly program you distribute.

But you can credit him for creating the language, if you want too, but then again, nobody credits Texas for making TI-Basic.

Edited in.

I noticed that in the past year or so, many calc games have ridiculously high difficulty levels. Games must not be too easy, otherwise it gets boring for a lot of people, but the opposite is also true for a lot of people. I understand that many people here got a lot of inspiration from Donut Quest and love this game, but I think people in general, especially puzzle game fans, are going way too overkill on difficulty. You may be extremly good at solving puzzles and have good dexterity and reflexes to play games that requires extremly precise timing, but it doesn't mean it'S the case for everyone. In fact, you may be singling out many more players than you think, and they might even recommend their school friends against downloading your game if they found it unreasonably hard.

I think games must start somewhat easy (not necessarily super easy, but at least medium difficulty. For 1st levels difficulty, you should base yourself on the level difficulty in Super Mario Bros world 1 through 4 or something like that. Then later, increase the difficulty. If it's a puzzle game it's good that the last few levels are extremly hard too.

To sum up, even though you may be able to beat Kaizo Mario hacks easily, it doesn't mean everyone can. So please try to not take Kaizo difficulty as inspiration for your calc games.

As for RPGs, don't start with extremly hard enemies either. I remember playing Lunar for the Playstation 1 and I died 6 times in the first enemy encounter. Don't make it so you have to fight an enemy, go all the way back to the town to buy potions, then back to the dungeon to fight one enemy, hoping you survive, then go back to the town, repeating the process 30 times to level up. Some people like to grind but too much of it can be boring, so it's good to keep the RPG difficulty curve not too steep and not start it too high. Don't make leveling up too fast either, because I remember somebody spent 8 hours leveling up in Chapter 2 of Illusiat 11 once and managed to reach LV 99 there. He had a 15 MHz calc, though.

WHo knows, maybe he'll port Crysis for real one day.