Omnimaga
Calculator Community => TI Calculators => General Calculator Help => Topic started by: Raylin on August 02, 2010, 09:29:27 pm
-
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.
-
[Raylin] Rules edited in.
-
[Raylin] Rules edited in.
/me runs
-
You should have this as a PDF release or something...once many replies come in, not many people will see this topc
-
I'll give my point of view on some of the rules, as I also worked on calc RPGs for several years (specifically from 2001 to 2005 and attempted at making new ones in 2007 and 2009)
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.
I agree partially with this, because I saw many newer programmers or programmers who never did a RPG before start with a clone of a copyrighted game. However, if he's making a stripped down clone of it, it can work. If you do the later, you need to make it somewhat good anyway, though, so in the end you end up having to do something medium to big. Another thing I want to add is that it's good to have originality sometimes. When downloading a FF clone, people may expect more than if you make a new game. Making a new original game may lower the pressure on you as well. Regardless of if you make a clone of a game, please do not start too big. If you want examples of RPGs I did in my early days of TI programming, check the first 3 Illusiat games and then give Illusiat 6 a try. It should give you an idea of what I started up with.
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.
I personally think coding the battle engine early in development is a good idea too. You need to setup a base on how will fight occurs in the game. That said, for some reasons, I always prefered to code the in-game menu (starting with most of the stats screen) first, though, then I jumped on the battle system.
Rule 3: Make sure your menus/GUI and button configuration are the same throughout.
Do you mean for example not having some choices selected with 2nd, others with ENTER then suddently require a number input to select something else? I remember FFTOM did that and it was sometimes annoying in long battles. Some of my old games also had this problem, I believe.
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.
On the other hand, make sure that a LV 9 char won't get instantly killed by a LV 10 enemy, then instantly kill that enemy when he reaches LV 10. Either the game difficulty will rise too fast or it will get too easy if you are over-leveled. ANOTHER IMPORTANT THING (IMHO): Make sure the first game enemies are not too hard, or at least if they are, make sure leveling up is fast enough with them! To be honest, if I try a RPG and can't even beat the first few enemies at all, I will be tempted to give up and delete the whole thing.
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.
Well said. Some people think graphics is all it takes to make a good game, but if the story is boring and the game lacking in features or too easy/hard, people won't enjoy it. On the other hand, avoid MUD/text-only (by text I mean words describing the area you are in instead of an actual map) games. People in general prefer to have at least a certain visual representation of what they are exploring. That said, TI-City and the first Potter Quest were quite good for text games, though.
Rule 7: Draw ALL of your sprites and tiles first!
I partially disagree. Sometimes you may get a better sprite or enemy idea later during dev and may want to add some more stuff. However what I do in general is make a bunch of enemy sprites and map tiles that I'll use and I make some more in case I migth want to use them later. That way during dev, I do not need to stop everything to spend hours making new tiles/sprites. When you are on a coding rage, having to do something else instead of coding is enough to kill it.
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.
True, when I make my stats, I try various formulas to make sure the characters starts and end at reasonable stats. Also make sure to not end up with like 50 HP at LV 1, 500 at LV 50, 2000 at LV 75 then have your HP increase by 500 for the last few levels. It makes balancing the game even harder.
Rule 9: Write your story on paper first. It will help organize your thoughts.
Yup. I did not do this for the Illusiat 1 through 12 games, same for Mana Force 1, and you can see that the story was rushed. Making it as you code often leads to strange, undeveloped storylines.
Rule 10: Code your program in subroutines. I don't care if you hate them. It will help.
True, else you end up in lack of RAM issues. In Illusiat 11, I had to split the boss program in half near the end of development because it was too large.
[Raylin] Rules edited in.
-
Maybe I'll sticky this later. :)
-
Very cool. Added it to the Tutorials thread.
-
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.
On the other hand, make sure that a LV 9 char won't get instantly killed by a LV 10 enemy, then instantly kill that enemy when he reaches LV 10. Either the game difficulty will rise too fast or it will get too easy if you are over-leveled. ANOTHER IMPORTANT THING (IMHO): Make sure the first game enemies are not too hard, or at least if they are, make sure leveling up is fast enough with them! To be honest, if I try a RPG and can't even beat the first few enemies at all, I will be tempted to give up and delete the whole thing.
Um, have you played Illusiat 13? I almost gave up in the Dark Cave because I couldn't kill anyone. Luckily, that's a short space and I made it out and into the funnest calc game anywhere. ;D
Excellent rules Raylin. I think it needs to be pinned. :D
-
Done. Keep adding! :D
This only helps people.
-
[Raylin] Rules edited in.
-
Added Rule 15.
-
How about this one? Not sure if everyone would agree with it, but I like it.
- Do not, do not, do not try an RPG as your first program/game. You will fail. Try simpler stuff first. To make a decent RPG requires quite a bit of programming knowledge, planning, time, etc. Get all that from starting low and working your way up.
-
I think that's basically what Rule 1 says.
-
Hm.... well I thought that was more specific toward console game clones, but I do see your point. I've just seen too many beginner RPG's that weren't ports that were awful and they only uploaded them because they actually completed a game.
-
So, so true. T_T
-
you shouldnt program a huge game until youve mastered most of the coding. if you cant code a little simon says game, you arent ready for rpgs
-
Edited Rule 1, so people stop reiterating it.
Added Rule 16, the most useful rule ever.
-
I disagree with MRide and Skuller972. I think it's a bit of a generalization actually. Of course it is not recommended to start with a large RPG project as your first ever program, but it doesn't mean you will fail. If you start small enough, you will succeed. It won't be the best RPG but you can still do something decent to practice. My first calculator project ever was a RPG and it succeeded. It was not that great, but the 3 other calc projects I had were RPGs too (Illusiat 1 through 3). I personally always found it harder to code anything else than RPGs because with RPGs, you don't have to worry as much about speed. In the walking engine, all that moves around is your character. Everything else is turn-based. If you do a real-time game as your first project, good luck getting a decent framerate. Besides me, I also know other people succeeded with RPG/adventure games as their very first project. Krid and tr1p1ea are examples and Krid did a much better job than me at a first BASIC RPG project.
What I would say is that a good RPG project takes a considerable amount of time to work on and lots of memory. So there, I redirect to rule #1
-
I agree with DJ. Small RPG's can succeed.
-
i do #16 for almost every program i write that takes longer than 48 hours, or programs that have very few "global" variables. in my mind i call them important and unimportant. the tags global and local are more professional though. you also may want to add onto that to have a separate section of variables for subroutines. you don't want to have a subroutine storing values to X and Y and then have it call a subroutine which also stores values to X and Y, unless it's part of the code.
-
Added a note saying that.
Good catch, nemo.
-
Also, in regards to Rule 16, if you run out of variables you always have the Finance variables to use, though they are two byte tokens (I believe).
-
Sorry, but the Finance variables to me seem like too much of a hassle for me to use regularly... :(
-
Also, in regards to Rule 16, if you run out of variables you always have the Finance variables to use, though they are two byte tokens (I believe).
Correct. :)Sorry, but the Finance variables to me seem like too much of a hassle for me to use regularly... :(
I really like the finance Vars, because they are really fast, even faster than Ans. ;D
[Raylin] Rules edited in.
-
While we're on the topic of Vars, DO NOT use Y while working on the Graphscreen!
wait.. why not?
-
Some drawing and graphing commands set it to zero.
-
Graph screen functions actually use the Y variable.
*Edit* Ninja'd
-
Because, if I remember this correctly, it is part of the OS's routine for graphing or something and can easily be overwritten by the OS. Or something along those lines.
Edit:
Double ninja'd.
Sorry, but the Finance variables to me seem like too much of a hassle for me to use regularly... :(
Ya, I know. I don't like using them either. I was just saying in case you run out of normal variables then you always have those as back up.
-
Oh, yeah. Another strike against finance Vars is that you can't DelVar them.
If you need yet another Var like A-Z and theta, go to the catalog, press N, and use the little recursive n. I'm not sure if you can delvar it, though. :)
-
Just tested, you can.
-
You can also store large strings or programming sequences in the sequence variables, u, v, and w.
-
Oh, yeah. Another strike against finance Vars is that you can't DelVar them.
Really? That is rather strange. I didn't know that. I wonder why not? That's good to know though. :)
-
Just tested, you can.
You can, but it doesn't set it to zero. It deletes any integer that is inside it looks like because if you try to use it then it will pull an ERR:UNDEFINED.
You can also store large strings or programming sequences in the sequence variables, u, v, and w.
What do you mean?
-
You can also store large strings or programming sequences in the sequence variables, u, v, and w.
What do you mean?
Quick! Run, look at Homescreen Game Pack. ;D
In it I do stuff like this:
"42=abs(Ans-63->u
...
getKey
If u
Then
.You Pressed 2nd or Enter
-
So basically it's like using a string without using expr( to get the answer?
-
So basically it's like using a string without using expr( to get the answer?
Exactly. :)
-
@ Ztrumpet: I could be wrong, but I thought "->" couldn't not be used with the sequence variables, that they could only evaluate expressions.
-
Hmmm, interesting. Thanks.
-
@ Ztrumpet: I could be wrong, but I thought "->" couldn't not be used with the sequence variables, that they could only evaluate expressions.
The -> is storing it to u in the first place. :)
-
You can't use it INSTRING. You can use it to store to it though.
EDIT: Ninja'd.
-
You can't use it INSTRING. You can use it to store to it though.
Completely correct. :)
-
Ok, I wasn't sure what you meant. I just wanted to clarification that it couldn't be used inside the string. =)
-
Actually, ztrumpet.
Your use of that code [42=abs(Ans-63->u] is genius.
Props. :D
-
So I just was messing with u and got some interesting results (was trying to see if maybe could use it to shorten Battle Ship anymore :P)
So I stored "sub(Str1,1,1" to u with "12345" in Str1. When I did u+u I of course got 11 displayed on the left side, signifying it is a string, which made sense. But when I did expr(u+u it displayed 11 on the right side like a integer...but 1+1 isn't 11...any clue what's happening?
Sorry for getting this a bit off-topic, just curious now.
-
since you established u+u = "11" (notice the quotes, it's a string.), what's expr("11")?
edit: if you're looking for the answer two, try this code:
expr(u)+expr(u)
-
Because you concatenated the string, expr( is evaluating the phrase "11" which is the real number 11.
EDIT: Damn, ninja'd again.
-
Hmm, should I split this topic into two topics? :)
Edit:EDIT: Damn, ninja'd again.
While I'm loling again. :P
-
Ooooohhhhh, ok. I get it now. I see what's happening now. Thanks, nemo :)
Ok, now lets get back on topic :P
-
no problem meishe.
EDIT: Damn, ninja'd again.
lol (: sorry about that Raylin
-
No problem. :P
-
I like the rule about writing your variables on paper first. I do it initially but then I forget to update the list and get lost x.x. Always keep track of what each variables do.
-
[Raylin] Rules edited in.
-
I always wondered about that.
Doesn't optimizing as you go create problems if you happen to forget what line of code does what?
-
I always wondered about that.
Doesn't optimizing as you go create problems if you happen to forget what line of code does what?
I see where your coming from, that is true if your working with complicated code, but from my point of view, if you have a hardcopy with notes, it should be fine
-
This is true.
-
To add to rule 18, do not fall into the trap some people did: rewriting the game completly to save space and stuff, then a few months later doing the same thing again, then again, again. It's ok if done once or twice, but otherwise it's an endless loop for most coders and they never get to finish the game, as they spend their entire time rewriting it.
Five references to go.
-
Five references to go.
lolwut?
-
Five references to go.
lolwut?
To add to rule 18, do not fall into the trap some people did: rewriting the game completly to save space and stuff, then a few months later doing the same thing again, then again, again. It's ok if done once or twice, but otherwise it's an endless loop for most coders and they never get to finish the game, as they spend their entire time rewriting it.
Five references to go.
-
Five references to go.
lolwut?
To add to rule 18, do not fall into the trap some people did: rewriting the game completly to save space and stuff, then a few months later doing the same thing again, then again, again. It's ok if done once or twice, but otherwise it's an endless loop for most coders and they never get to finish the game, as they spend their entire time rewriting it.
Five references to go.
Yeah, as two people on #omnimaga are aware of, the amount of posts containing "the game" on the forums have reached 666.
-
Very good tutorial.
Just these rules already explain why some early games of mine failed.
-
Btw even as experienced coder, you should still keep an eye on those rules. If you made many large RPGs, like Illusiat 7, 9, 10 or 11, good, but afterward, be careful to not jump to a ridiculously large one afterward. I did that with the Reign of Legends 4ever in 2004 and gave up due to the ridiculous amount of maps I would have needed to make. I had experience in making 20 hours long RPGs with more than 3 possible party characters and various features not seen in any other calc RPG, but jumping to a 80 hours long RPG was maybe a bit too much, even after 3 years of RPG coding.
-
Greatest RPG advce ever! I mostly program RPG w/ TI-BASIC!
-
BUMP and/or necrobump.
Seemed interesting to bring back up.
-
Thanks for bumping!
-
Those are really good advices. There are exceptions, of course, but I saw so many RPGs in the past where the author gave up due to doing some of those mistakes.