I guess... the requirement of not having it announced automatically disqualifies CaDan 83+ ...

Could've easily won a contest with something like that in the works

If an RPG could be qualified as a "platformer" (unsure of what that is), maybe I could try coding something using Celtic III just to push the lib ... >> ... <<

Or... use a "secret" uber version of Celtic III that's not available to the public yet. You know, the one that has a raycasting engine...

Had forgotten to reset the environment while I was spending time developing. The new script engine shows some of its power in the screenshot linked to below this paragraph. Had to turn collision detection for yourself off to demonstrate this.

http://www.mediafire.com/imageview.php?quickkey=kz5z2itz0zy&thumb=4

(...)
@Iambian: what percentage of people have to hear the "No."?

Roughly in the 1 percentile. When I did serious development on-calc, everyone knew I'd go absolutely crazy if anything happened to what I was working on, so they wouldn't ask me more than once if I gave my "traditional" response. Took a little while before those asking knew that was my form of "No. Quit asking."

Your mileage may vary. Truly depends on how you are seen at whatever school you go at.

Me? Won't get into those details.

Didn't check whether or not I said it here, but I may have been jumping the gun when I said that "Replay" would be a standard game option. The way I see it, if it were to work out that way, the game would have some insane system requirements.

If I had it my way, 32 or 48KB of FlashROM would be for my game. ALL YOUR RAM would be needed to keep track of replays, high scores, and the temp file. Currently, the calculated number sits at a cozy 22520 bytes of RAM needed to accommodate all of what I want to keep track of.

Cutting the "Replay" option would remove only 9000 bytes from this calculation. I'll need to recalculate the memory requirements as I find out what I need to do to keep track of the scoring file.

Thankfully, nothing has happened to me as of yet. Since very few of my projects are built on-calc, I haven't had much of a problem with calc corruption. Back in my "earlier" calc programming days, in which I did build stuff on-calc, I've been blessed with a calc to computer link cable for the entire experience, so I've been backing up. Most of what I did "lose" was at most an hour or two worth of work.

In this distant "future", I personally don't miss anything that I've lost in this way. As for my ASM projects, I keep multiple backups where I deem useful. Multiple backups of my entire development environment has been made to several flashdrives and a few computers (some of them date back so long that I'll look over them just for nostalgia purposes).

Currently, CaDan is protected in part by a not-so-recent email to myself with relation to the project. A copy was made to my 16GB flashdrive and an "active" copy is always in my laptop, sitting both in the dev folder and in the SD card. The idea for using the SD card came from a friend in the math lab, who reminded me that laptop harddrives are notoriously flaky. This one hasn't caused problems yet, but I still keep backups of full source on my SD card.

Backups include WinRAR'd "past" versions of the program, with a current version sitting as-is.

Celtic III is, in part, backed up by multiple flashdrives, and the postings on UTI. Retracing my steps through the various versions shouldn't be that hard, in the event the most recent one is lost.

In short, even though you'll hopefully never use them, ensure that your backups have backups in all sorts of medium, including USB flashdrives, SD cards, multiple computer HDD's, email accounts, and if you want open-source, full source posted to the forum(s) of your choice. Especially the forums, since you can pretty much go anywhere and work on your program, with or without your dev environment.

If it's an on-calc thing, ensure that you regularly "group" changes (which saved me many times). If you have a cable, transfer those groups out and onto a computer. Never allow anyone to touch your calculator. If someone wanted to borrow your calculator, the following excuse has usually worked for me : "Can't let you borrow this. It's in development." If that doesn't work a stern "No." works after that.

Can you make it read a appvar, and we can add ourselves/submit those to ticalc or w/e?

That wouldn't exactly work. The RAM usage is pretty hefty and the storage for all the characters would exceed the RAM limit. Reading from archive would suck in the environment I'm running in.

Actually, I'm more concerned about people cheating by putting in buffed up characters with absolutely no storyline content whatsoever. Whatever is decided for the game, the story *must* be stuck to in order to remain coherent.

The profile is pretty much to help me figure out what to put in and how the story should form. Not all the requirements need to be met, but I need *something* useful.

Celtic III doesn't work fine on the Nspire? Does it includes any of the xLIB backward compatible functions? I remember xlib working pretty well on the Nspire

As far as I can remember (I dunno if I fixed it), it would've been xLIB's box drawing routine. Somewhere in the code, it uses undocumented opcodes if you try to draw a box that clipped within the same byte. Otherwise, it would work as "normal". Other than that, Celtic III should work just fine. I just want to discourage use on the Nspire because one may forget about that problem. It's really easy to forget stuff like that.

...
My only gripe right now is that I no longer have a Silver Edition to play the game when it's finished so I am worried about TI-Nspire compatibility (since some ASM doesn't work fine on it) -.-. TI-Nspire is all I got to play SE only games right now

The TI-Nspire will more than likely work for that game, since it's written in BASIC, and I'm (hopefully) sure that TI worked out compatibility for their own OS. I'm also pretty sure that the ASM libs that are there will work since none of them should use any questionable instructions. I know Celtic II does not