This looks really nice, but in my opinion, you could make some color changes in the graphics.

For example there is a little bit too much bright yellow in the tree and grass green, you could make it darker, which will make it look not that poison-green and also, in my opinion, the darker the more "mysterious" and "dangerous" it will look.
And for example that sunny, blue sky in the abttle scene looks relaxed and fun, but the situation should be more like tension. Here a dark grey with little blue "stormy" and possibly some lighting could do the job.

So you can really change the mood of the player a lot by simply adjusting the shades a bit.

Maybe try out some online tools, there are quite a few of them out there and they will help a lot.

Edit: And one more example, for the menus. If they had a dark grey background with possibly bloody red text it would look more like "fight" too... While a blue background and green text does not symbolise anything to me.

Thanks for the feedback! The blue sky is mainly because it's the first area, everything's supposed to seem light-hearted and easy there, like you said, but I agree. A darker or paler blue would give a sense of foreshadowing of the struggles to come. DJ Omnimaga also wanted to see a gradient thing like this, so it might look a little better:

Now that I see it, the grass is a little too poison-y, like you said. I can tone it down.
And the battle menu text, I don't think dark blue and blood red would look too good together, but I'll see if I can make anything nicer. Thanks for the suggestions!
(And no, I'm not a yes-man. I genuinely agree with all of these suggestions, pretty much)

How is this project going, 123outerme? I hope you'll give us some updates when you have them, especially if the Thanksgiving weekend allows you some time to work on it. My only complaint about that screenshot with the rainbow is that I don't like the single character from "RAT" and "HP0" overlapping; it looks like an error rather than an intentional design choice to me. Other than that, I don't hate the gradient at the top.

I have an idea! DO you think that instead of using the arrow keys to move, you could make it so that you use the arrow keys to move a curser around on a screen, and then press enter to move to that location? Sort of like in the PC game Bulder's Gate. That way the man could move in a slanted line, and thus faster. You will have to add more advanced collision, though.
I hope you understand what i am trying to say

The rainbow you see is just a series of other samples that DJ Omnimaga created to show off other colors. It will still have one solid color as the sky/background. And I haven't had a lot of time to work on it. School and its various projects that I have to do for "reasons" are kinda eating up my time as of now. But the worst of it is almost done, so I'll try to be back soon.

I'll consider it, but it might be more challenging. The way I've set up drawing, it draws one 8x8 tile to erase the character sprite. The challenge with having off movement is that I would have to draw multiple tiles, and it would be dramatically slower.

Beta version 0.2b is out now! I've updated the original post to contain the download. Here are a list of changes from version 0.1b:
*Minor color changes of grass textures for overworld and battle background/sky
*Speed and size optimizations
*Removed small glitch that made options menu appear a split second before battle ending text displayed
*Added progress bar to the blue "Saving" screen
*Added functionality to armor. Now a usable item that ups HP based on the power of the armor
*Changed Doors CSE icon to more closely resemble the new character sprite made by LD Studios
*Small functionality tweaks

Here's a screenshot:

This game looks amazing so far - so much cooler than other rpgs made for the CSE. I can't wait 'till your finished

Hey, I was just thinking that maybe with you game you could have several sub programs (one for each world maybe?) then run them as archived programs temporarily written to your RAM with Celtic? You could do this kind of like in First Fantasy Mana force so that you wouldn't have to worry so much about running out of memory.

Also to me, the main character looks too much like a bad guy. He's so dark and mean looking... Unless I missed something and he's supposed to be a bad guy.

Anyways this game looks absolutely amazing so far!

Thank you!
I couldn't really split the game programs into worlds. The entire game runs on the same engine. What I'll do, is split the battle code and maybe the map loading code into a different subprogram, then call it when I need to. Those are the two largest parts of the program, and removing the battle code will easily take off at least 5000 or more bytes. Although that's just an estimate, I have yet to count.

EDIT: Yes, 5233 bytes to be exact.

The main character is supposed to be a mysterious character in a robe. His face his hidden, so that you can pretend to be him/her. It seems like a dumb reason, but when you think about it, being the hero is what an RPG is about.

I looked at your code in the beta last night and was thinking about this as well, except I had a different idea for saving the maps I guess. Instead of having the tilemaps actually in the program you can have them all in an appvar (one line for each map), then just do something like:
If M=x:(line number to put in answer)
If M=x2:(line number to put in answer)
etc...
det(0
This should make it so you don't need subprograms, which will just eat up ram.
Also, you could store any long strings you have in appvars as well like your help menu, and the long strings with the sub command that say "Slash Pounce Pound etc."

I guess I could store some stuff into an appvar. In fact, I'll need to because the map data alone will probably be around 10k bytes. I was originally going to put the battle code and map data into its own subprogram, but I like the idea of using an extra appvar instead. Thanks!

Edit:
Also, I uploaded 0.3b with not too many changes. No screenshot this time since none of the changes require one.

*Fixed minor lag in battle background gradient drawing as per @DJ Omnimaga 's request
*Changed method of storage for map data from program (inside the main program) to a separate Appvar. This will allow me to keep the game to one program and allow me to make almost too many maps.

So I played Dragonslid on my CE. Will this work on my CE as well?

Thanks for downloading Dragonsglid! I'll be the first to admit it could've been better. That said, it's not a total waste of time.
Anyways, unfortunately, not right now. This is written for CSE calculators only using xLIBC and DoorsCSE. When Doors CE arrives, I'll have to check the compatibility.

I've hit another size issue. I just can't have the scope of the game I want. I either have way fewer maps per world or just release it now how it is. I've completed two worlds and their bosses so far. I'll give you the choice. Just know that the quality will be lower and the game will feel more rushed if I have fewer maps, but if I release it as it is now it'll feel as if it was just cut off suddenly. I'm sorry to have to do this but it's the only way. I've even put a ton of the code into a subprogram. I just can't do it all. I'm also thinking about handing it over to someone else, so if you would like to take the reins of this project, just PM me.

EDIT: I have a solution. Basically, I'll have just a 250 byte program loaded into RAM to handle map data, so there are no issues. If you want the long description of how this works, just ask. But this gives me a total of about 20k bytes worth of tilemap data to use now.

EDIT 2:
Since when loading the map data, the Appvar has to be in RAM, unless I have it in its subprogram, it'll crash. 10k bytes of map data (or more) + 14k bytes of the main program = ERR: MEMORY. But up to 20000 bytes of map data + 250 bytes of a subprogram = A-ok.

Is your problem not having enough ram or rom?
I have tried following your problem across the forums but i still dont know much about it

Sorry. I'm running out of RAM so I get ERR: MEMORY. It happens when I load map data, because it has to put the whole Appvar into RAM to load. That means that 10k bytes of the Appvar in RAM + 14k bytes of the main program already loaded = 24k bytes, when RAM is only 21k bytes max. Instead of having those 14k bytes loaded into RAM, I switch over to a subprogram which is only 250 bytes, solving my problem. This means I have a total of about 20k bytes worth of map data to use before I'll get another ERR: MEMORY.

Ahh. You could also use smaller maps, if they are not already the size of the screen
Edit: what i meant is you could subdivide your maps more, so less ram is required at a particular moment.

I see. I might have to split the map Appvar into a few, depending on if I really need to. I'm trying to limit the amount of files that the user has to keep and download, and with 5 already (Main program, map loading subprogram, tileset Appvar, maps Appvar, and save file Appvar) I think it's getting to be on the heavier side.

You do not need to put an appvar into ram for it to be read. This means you can pretty much have unlimited tilemaps. The only RAM that it will take up is the string that holds the tilemap data, which I believe is approximately 900 bytes. This should be a huge fix for your memory problems.

When I call det(0, the Appvar is temporarily loaded into RAM by Doors CSE, and it has to be, as far as I can tell. Otherwise, it is in Archive. It stops when the Appvar is loaded on top of the other 14k+ bytes of the main program. And if I'm wrong about this, someone who knows this for sure, correct me!

hmm... Well I asked KermM in SAX, and he said it was read directly from archive... Also if you look at tifreak's Lib Help program you will see that the appvar for it is over 40kb. I'm not sure how DCSE could load that into ram.
Anyways would be awesome if someone who knows for sure could comment and explain what is true.