0_0 ...

there is some nice work and all but for the hell of it, just some freindly aid :P ;)

Coding notes for improvement
======================================
* If a substantial operation is repeated use a function (saves you time+repairing is eaiser)
* store relative information (that does not repeat) in the same array 
	keyitems = {
		{"heal","Cures 50hp"},
		{"High Potion","Cures 100hp"},
	}
* If the information repeats itself (a lot) in the same value and changes in correlation with the other values store/index it in different fields
	patient[1] = "Jimmy Learnswell"
	bloodline[patient[1]] = {a=12121,t=12121,g=121212.232,99322}
	stats[patient[1]] = {male,110,bloodline[5]},

* Think of arrays as databases/spreadsheets
* store varibles that are related in an array
	cat = {hieght = 5, width = 6, sex = male}
	do not do cathieght = 5 etc UNLESS they are local indexs...	(they can be cleared easier this way etc)
* do not shorten short variables
* use camelcase (don't capitalise the first letter of the variables name but capitals every letter after that that begins a new word.
	i.e.
		camelCase
		camel.case
		camel.caseIsGood
		camelCaseMakes.itEasierToRemember.casesInLargeProjectsCamelCaseIsAStandard.inProgrammingToday
	no exceptions >__> (underscores are terrible loop_count
* clutter code is bad (unless you are trying to make it that way ;) e.g. data encryption methods) when you break items into functions you can then break them into libraries.
* lua has metatable() support, this allows for an object and a event to be stored together (this is idea for menu programming.
* when a function is just going to be called to get the same value few over and over again use varibles i.e. controls.read() then store their values hence the function only needs to be called once.
* when loading images it takes less processing and memory power (loading and unloading) if those images are stored on the same sheet (e.g. the pointer)
* in luaplayer for psp for some reason it takes more processing to blit to and image then directly to the screen
* code can be designed flexible and made to handle future situwations e.g. fieldmap engine supports mulitcharacter movement at the same time, the maincharacter can be changed to anyone, multiplayer mode could be added with a simple irda function, a character has no more right tomove the an object. the engine just supples the basic laws of gravity (no two objects can occupy the same space). the engine could be used for a futurestic mech game just as easily as mq:btg shhhhhhhhhhhhhhhhh don't tell
* some of the best engines come from ascii starts, design the code first then worry about the interface.
* "0010-0160-05-1-Galaxy Crusher" better stored like so {"0010","0160","05","1","Galaxy Crusher"} save time on processing data
* j is a baddddd name for a global var

How to approach a major coding problem
======================================
step 1) research
	step a) is there another application out there you can use as a reference
step 2) break it down
	step a) start a coding project by viewing the whole picture
	step b) next break that picture down into functions
	step c) figure out those functions
step 3) review (pen and pad)
	step a) test your logic (no code written yet)
	step b) try to make and example that would break your logic; is there any?
	step c) see if there a simpler way that does a equally job
	step d) is your code flexible? 
	step e) is your code direct? 
	step d) does your code get the job done? 
	step f) repair your logic
step 4) write
	step a) write the code that you have already formulated
step 5) debug
step 6) enjoy

Quotes
======================================
"Coding is like cooking; problems that are not solved in the beginning of a project only grow bigger"
"it is all about seeing the big picture and then seeing the little pictures that make it up"

