Well, since there's nothing here yet, I figured I'd start posting something.
As anyone should know by now, for almost the past 8 years, I've been working on and off on an RPG engine that we are planning to use currently for Legend of Landel, known currently as the
Slayers engine. I haven't had much to say on what or how it actually works, so I'd figure I'd give some technicals on its functionality and history before I get to the heart of where it stands.
First off, we’ve never released anything using this engine. I would occasionally run into someone who though we already released the engine with Slayers 2.0 for the 92. In Reality, that game was written by Hiryu while I was developing this engine separately. A lot of my engine's core functionality was designed with FF7CQ Directors edition in mind and eventually absorbed a never released Slayers game fighting spec which gave it it's "slayers engine" name. When we decided that FF7CQ was a Cease and desist from Squaresoft waiting to happen and hiryu already had a successful release with Slayers 2.0, it moved to Punisher X-Treme, and when we decided that PXT (actually, the Punisher in general) broke the Mike Wallace rule, it moved to Legend of Landel where it currently stands. The Slayers 2.0 game engine was built with a system specifically designed for slayers 2.0, and was also used for Nene's adventure. One of these days I'm going to have to rename this thing (most likely it will be called the Landel engine), but since its fighting spec was designed with a slayers game in mine, I started calling it the slayers engine and it just sounded good.
Now to what it actually is. The Slayers Engine is a completely modular RPG engine environment. It was designed from the ground up to be totally scalable and adaptable to any situation that would be possibly needed in an RPG. Scalability and Speed are its 2 primary design goals, and it shows throughout the screenshots I've shown over the past couple of years that not only is it fast, but is modular since the project has shifted so many times. Because of its design, it's theoretically possible to create RPG after RPG without looking identical to each other and without changing any code outside of the picture and data files. Although you may have to change a variable here and there in the code, the majority of the code would not need to be rewritten every time. This is a huge advantage over our older engines, in which you would have to do practically a complete rewrite in order to achieve similar results, not to mention the slayers engine is far more efficient than previous engines, especially in it’s runtime footprint. Its code size goal is not to exceed 10000 bytes of memory. So far, it should be able to do that with memory to spare.
The primary code of the engine is the box control. This allows the engine to do many of the scripted tasks you see in the first demo, and is light years ahead of ff7's story engine. This also follows the modular design in that you can add functionality to the control by simply adding a task routine without editing the main box control. This design also keeps runtime memory much lower than in the older ff7 engine. Many of the special effects you've seen in my sig are done by tasks created for this control. Grayscale dialog boxes, scaling, transitions, fading, even temporal grayscaling are handled by the boxctrl tasks.
The other main control is the walk control. This does the mapping and graphics for the walking demo. Again, it's modular and uses a vnum system to track everything in the world. Groups of vnums can also be added easily to the engine without major code rewrites. The engine also can do a form of tile mapping, but it's used more for placing objects around the world so it doesn't look as repetitive, especially in the dungeon scenes which save ram by recycling dungeon scenes.
The Inventory control was also coded, but is not complete unlike the box and walk controls. It follows along the same lines as the walking engine as is vnum based, the actual handling of goods would be handled in a similar way as the walk control handles room and button calls and would be modular like the rest of the engine. All it can do right now is handle the inventory sorting and menus. It could be finished very quickly, since the file formats and such are completed.
The Fighting engine was never coded but the fighting spec was written and checked on paper. The primary reason it's not coded is because I decided that Ti-basic would not be fast enough to handle the AI this game would need for the Fighting spec to work. It would either be fast and a total cakewalk to destroy, or take forever to do a move and actually stand a chance against you. If you want to know how it worked,
Go Here. I suggest staying away from the movies, specials, Next or Try, and focus on the original series, since that’s what it was designed against. It fights exactly like the anime does to the letter (And I mean exactly. Watch the anime, now imagine your playing it as you're watching it. Animation and all. That how Slayers Duel would have looked from it's preliminary design.) with little to no deviation from its fighting concepts.
Now that that's out of the way, now to it's standing. Right now, I've hit a calc limitation that severely limits the expandability of the Slayers engine. Namely, the 2000 file limit. On any Ti-92 series calculator, the OS has a physical limit of 2400 variables; once you get around 2000 variables the calc starts to severely slow down to the point where it's almost unusable. It's starts running into memory errors past 2400 variables and is absolutely unusable at that point to where the calc practically needs a full reset. It doesn't matter where the variable is stored, (ram or archive) the calc's memory, (This happens on an 89ti as well) or if they are in separate folders or even the size of the files. You hit 2000 and bam, calc's needs to take a nap. I've heard that it's worse on older AMS's and can start having problems as low as 800, but I haven't tested it on anything but AMS 2.09 and higher.
Now, when I designed this engine, I had no idea about this, and designed it around the belief that I would most likely run out of memory before I’d run out of variables (I thought the variable limit would be somewhere around 65535 and not 2400). So in order to keep the runtime memory footprint down, (which was my main concern. This is what got FF7 in so many problems after all) I decided to reference everything as a variable or standalone list. For example, a simple room would have minimum 2 files and upwards to 3. 1 for the picture it could possibly share with other rooms, another for the map and a third for map information such as doors, room names, the image names, mob factor, ETC. Each item is a least 1 list with a possible picture. Even simple dialog such as the guy at the bar that just says
"Times are Tough" would require a variable. You can see where this is going.
So basically, what I need to do is consolidate all of the variables into lists and matrices while it's still manageable. That’s actually easier than it sounds because of the modular configuration, but it means more time to figure out how to layout these new files. It also doesn't help that sometime down the process I expanded the vnum blocks from 100 to 1000 then to 10000. It would be easy to switch back to 100, but just about all the maps we currently have would need to be rewritten. It's a good thing I made a room editor I suppose.
Anyway, if anyone’s got a question regarding the Slayers Engine, post the question and I’ll try to post an answer.
