Omnimaga
Calculator Community => TI Calculators => General Calculator Help => Topic started by: AngelFish on March 06, 2011, 02:22:23 am
-
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.
-
Yeah I agree with that. I hated when I downloaded a 60 KB RPG once, only to realize it has 4 rooms.
Also one thing I can't stress enough: Disable the friggin axises! So many games forces me to manually disable them. Or at least, use a GDB or something to re-enable previous settings once exiting the game.
As for documentation, however, I think moderately large readmes can be ok if you want them to look great, like Axe Parser, but yeah, 500 KB max in most cases should be enough. Also, although if you use .doc, include a txt version of your readme too, for people who don't have OpenOffice or Word.
And yeah debugging is important. One thing I want to point out about missing files: Once you finished your game, do one more backup, then delete every variable/list/strings from the calc (that won't come with the game). Then test the game again for dependencies.
To TI-Nspire BASIC programmers: Please include a README with your game. I noticed none of the BASIC games had one. Most people put the readme in the game, but what about people who wants to know what they are gonna install and the controls before playing?
- 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...
But what if it got grayscale? D:
-
Please. FnOff, then FnOn when you quit the game. (In BASIC)
-
* Don't make the user download a required file. If a game requires Xlib, include Xlib. If it requires Celtic III, don't make the user download Celtic III. "Batteries not included" is not a good option.
-
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.
-
* Don't make the user download a required file. If a game requires Xlib, include Xlib. If it requires Celtic III, don't make the user download Celtic III.
This isn't always viable, as Kerm usually doesn't let anyone include DCS in downloads. That said, if you can't include a program, at least provide a direct link, because it makes getting the program so much faster.
-
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?
-
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.
-
*Elegantly handle errors.
-
Edited in.
-
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.
If you distribute the source too, make sure to specify which version of Axe was used to compile it, and don't be approximative. Some people say Around Axe 0.4.8, but might work with other versions too. It's best to just link to the right version on Omni forums.
-
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.
-
Crysis on your Prizm.
Is this a hint at something Qwerty...
Otherwise, nice guide indeed.
-
WHo knows, maybe he'll port Crysis for real one day. O.O
-
Speaking of good design, I'd like to suggest a few things:
* For selecting, use BOTH 2nd and Enter. That way, you don't have any crazy confusion.
* For info screens (like "High score!", etc.) 2nd, Enter, AND Clear. I've ran into games that would seem to use 2nd to continue on, but I end up having to press some other weird button to continue on, almost thinking that I've crashed! :P The same applies to the above suggestion.
* AxesOff and AxesOn is a must, as well as FnOff. For the first part, not everyone turns off their graph axes, nor should you assume that they know how. DO IT! :D For FnOff, no one wants to see a graph of y=x^2 unless you are making a quad solver (in which there are thousands, mind you :P). As for FnOn... beware that it *might* cause a graph to be drawn (if there is one). I'm not too nimble on preventing that, so you're on your own. (You can try my code below though to see if my guessing works!)
For those BASIC programmers out there, here's what I do every time:
ClrHome
FnOff
AxesOff
ClrDraw
"You're done! Have fun coding! :)
"(code goes here)
"OK, time to give the user their graph back!
ClrDraw
AxesOn
ClrHome
FnOn
ClrHome
For FnOn, beware that FnOn turns all of the functions on. You may wish to add "1" to the end of FnOn.
The code snipplet above is designed to (hopefully) prevent the user from seeing the graph, and therefore hiding the fact that you're using that place to draw. ;)
As for Axe programmers - although this doesn't apply to you, I've seen some programs that have forgotten to ClrHome and ClrDraw! Unless you do an interesting homescreen transition (I have done and loved that a LOT, but most of the time if it isn't needed, don't do it), you should ClrHome. Finally, ClrDraw might be "corrupted" - some other program may have made a mess in there, or like some shells, leave the screen in the buffer. Erase it! ClrDraw^r is also a must if you use the backbuffer as well.
* Mental tip: never assume that the user will be like you, nor will they be as smart as you! :) All of the above stuff basically follows this rule! :) If you are deviating from the standard keyset, etc., include help inside the game. Give really simple directions, keymaps like "2nd to jump!" and "Clear to exit!". This will ensure wide acceptance and enjoyability of your game! :D
* Mental tip #2: never assume your environment is the same as your target user's environment! This pretty much encompasses everything above, but I thought to mention it if you already haven't realized it.
If there's anything that I've gotten wrong, feel free to correct me. I haven't done any serious BASIC game dev in quite a while... :P (Especially those involving the graph screen!)
I think this topic should be stickied; it would be very useful to new and existing BASIC/Axe devs. :)
-
WHo knows, maybe he'll port Crysis for real one day. O.O
Better :P
-
About using both 2nd and ENTER the problem is that sometimes the programmer might be running extremly low in the 8 KB code limit (where every byte matters) and in BASIC speed. Every 0.05 seconds lost on an extra instruction/check/command can matter in long terms.
-
Along the lines of users with different environments, also :GridOff. You never know.
-
Yeah true. Personally, if possible, I think it's best, before the game starts, to store the graph settings, then apply appropriate game changes, then once exiting, recall the old settings. The issue with AxeOn is that someone might already have Axe turned OFF so if they're turned ON everytime he quits the game he might be annoyed as much.
-
Another thing is to Delvar all the vars generated by the program. I got so freaked out about the mess my cubic solver left behind I wrote a program that Delvars just about all the user vars as cleanup
-
One suggestion more, if you use the graph vars: StoreGDB0 (the last, is least used) and afterward RecallGDB0
-
Yeah that's the best solution when in need to turn axises off. Else people get annoyed that their settings are changed. X.x
I tend to not do the delvar thing if I'm running out of RAM, though.
-
Wait, I thought Delvar frees up memory. Am I missing something here? Also, for anyone who doesn't know, thanks to a bug in TI-BASIC itself, the following is actually legal code.
:DelVar ADelVar BDelvar C
This can be continued ad infinitum until you run out of memory, a very useful misbug that shaves a net byte off the two byte Delvar. Please note that you're not actually truncating DelVar, but the ommission of a newline/: saves an otherwise inevitable byte.
-
I mean during game execution. Sometimes you can't afford taking an extra 30-40 bytes string of Delvars at your program exit. X.x
-
Oh. But that's why I keep all my DelVars in their own program.
-
I'm not sure what is the difference. ???
-
That way, instead of chewing up my memory 50 times by putting a whole bunch of DelVars at the end of each program, I only chew up my memory once by putting them all in one program and having the other programs call it when they end. I also use it at the beginning of each program to set all the vars to 0.
-
Well I just put them in one program or at the exit myself.
-
The problem with having BASIC programs in multiple files is that if a user accidentally deletes one of the supporting files then the program stops working. It is even worse when BASIC progs require you to download pic variables because those are so easily corrupted by other programs.
-
* For selecting, use BOTH 2nd and Enter. That way, you don't have any crazy confusion.
Use this myself too, seconded ^^
For those BASIC programmers out there, here's what I do every time:
ClrHome
FnOff
AxesOff
ClrDraw
"You're done! Have fun coding! :)
"(code goes here)
"OK, time to give the user their graph back!
ClrDraw
AxesOn
ClrHome
FnOn
ClrHome
You don't have to set things back by hand, TI-basic has a built in function for that, this is what I use:
My own default basic design, ofcourse, edited differently with every program, but usable everywhere:
::"My MOS header
:StoreGDB GDB1 (or any other GDB0-9)
:FnOff
:AxesOff
:ClrHome
:ClrDraw
:ZStandard
:RectGC
:CoordOff
:GridOff
:LabelOff
:ExprOff
:Normal
:Fix 0
:Degree
:Func
:Connected
:Simul
:Real
:Full
:"Your code
:RecallGDB GDB1 (again 0-9)
And this basically reverts all the user's options to the settings that were there before.
Again, not all the options are needed, but some might seriously screw up your game.
-
That's why I keep my programs in groups. That way, if something gets messed up, the user can always restore it, provided, of course, that they didn't delete the group.
-
That's why I keep my programs in groups. That way, if something gets messed up, the user can always restore it, provided, of course, that they didn't delete the group.
The problem with groups though is that they're by far the most easily corrupted, and the least compatible between different linking software. TI-Connect for Windows, TI-Connect for Mac, and TiLP each use a different filetype for a TI group.
So for groups I suggest keeping them grouped while on your calc but releasing them as separate variables.
-
Huh. Why are they so easily corrupted?
-
In certain conditions (such as when some header in the group happens to sit on the border between two pages, the group can't be ungrouped, giving you either ERR:VERSION, ERR:MEMORY, or ERR:BAD ADDRESS (all of which don't apply). Apparently, it's caused by some bad coding mistakes in the operating system, as thepenguin77 found here (http://ourl.ca/3687/120282). Basically, it's TI's fault.
All the major bugs (and some patches courtesy of the penguin) are listed in this thread (http://ourl.ca/3687).
-
Yeah I would advise against using groups. In fact I wonder if some of the typos in my english RPG translations didn't come from group corruption. I remember trying Mana Force 2 years after making it and one of the program gave me an ERR:SYNTAX. In worst cases, you lose an entire program.
Some people use GroupTools, but I heard it wasn't always reliable either. The best thing to do is to backup on a computer.
-
I lost my Splut source once due to group corruption, luckily I had a backup on my pc from about 2 weeks ago ^^
Backups will help you win the game.
-
Damnit I lost. X.x
But yeah, another thing is that group formats are different between TI linking softwares. A group transfered from the calc to the computer using TI-Graph Link will not work fine if sent back with TI-Connect 1.5 or higher.
Even a TI-Connect 1.2 group will not send fine with TI-Connect 1.5.
-
Some people use GroupTools, but I heard it wasn't always reliable either. The best thing to do is to backup on a computer.
Yeah, sometimes the group itself is corrupted, so you lose all your data.