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.
Well... my main question is, has there been anything done to this in the past few months?? I would really like to see what you can get this to do. Or make a game out of it...
Speaking of slayers... when will the downloads section be ready so I can get Slayers from you guys?? My 92+ needs a good game or two put on it..
The archives. Right now, I'm looking for a file repository similar to RW Download without the money involvement. I wish the E-blah guys still worked on E-Dir. All it really needed was some file management utils and it would be good enough.
Anyway, the last couple of months I've been working mainly on the site, so not really. I do play around with it once in awile, and this was the result. It first shows the Grayscale Picture using the grayscale task, then it runs a task that specifically does the grayscale and text manipulation. Just to show off it's modular nature, all I had to do is create task 20, and make the data file to use it, so no editing of the core app was done to create the above. Also the image in my sig is an example of what temporal grayscaling looks like.
Actually, it wouldn't be far fetched to make a Phoenix Wright game. It pretty much is just a storyline you pace through, and the Slayers Engine box control could do that easily, although I don't know if I would do it full grayscale since it would be huge. All of the images are out on the net to download, and I have the game to reference the storyline from. Although I wouldn't do the entire game since I don't want capcom suing the heck out of me.
Just for the interested, A new Slayers series has recently been released. So far it's the same as the last three but looks a lot better since it actually has a budget behind it.
If your still curious how the Slayers Engine Fighting Spec was handled, pay attention to the fights. Only two episodes were out when I posted this, and the fight in Episode 2 between Lina and Pokota (The Weird looking Pokemon thing) pretty much lays it out right there. It has Highlevels, Spell Vs Spell Cancellation and even weapon damage handling (More like Highlevel Vs Highlevel, but Still). The only thing I didn't see was an Intercept, and so far there hasn't been one in the series. This also shows why I don't think Ti-basic can truly handle the AI this engine would need, as this fight is pretty complicated and would end instantly in the players favor or be next to impossible to beat with a simple AI.
You can also find episodes of Slayers Revolution and Evolution R on YouTube, but don't expect them to be there for too long.
As it pertains to the Slayers Engine Fighting Spec, (or SEFS for short) Season 1 is dead on. Next, Try, Revolution and Evolution R have things that would add some complexity to SEFS, but not much. They follow the Spec pretty close up until they fight big stuff like Zanaffar, Hellmaster Fribrizo, Darkstar and Shabranigdo.
Now why would the AI be a pain to code for SEFS? well for one is the complexity of SEFS. For example, SEFS classifies spells based on the way they fire. Lowlevel Spells are instant, noncounterable, and usually do no damage such as levitation, MidLevel are your Non-Lethal, counterable common spells, like fireballs. The Fun begins with HighLevel spells, which are basically instant death spells that can only be countered by other highlevel spells, like your DragonSlaves. For balance purposes, Highlevels are hard as heck to cast, and virtually drain you of your power.
Now for the sake of argument, lets bring the First Shabranigdo Fight (Click Here) into Perspective, and why the AI would be a real pain for this.
You would have Lina, Zelgadis and Gourry in your party. Zel can take a ton of Damage due to his Deflection ratio (which is how much damage his armor reflects back to attacks and swords. Episode 6 has a great example of this). Gourry is basically screwed without the Sword of Light (which is his highlevel).
The mission would be to basically cast the Giga Slave without screwing it up. Casting anything else at Shabranigdo is useless.
To cast the Giga Slave, you would need to cast Two HighLevels, The Sword of Light and The Giga Slave itself.
To begin, everyone (or at least Lina and Gourry) would have to get their power bars up to highlevel firing range. Best case sceneario for this is 10 rounds, and that's if they never have to dodge.
keep in mind that Shab is basically firing powerful spells at the crew the whole time draining their power bars as they dodge the pretty much lethal attacks, and he's doing this each round. This extends the rounds it takes to get their power bars in highlevel firing range, and gives shab more shots at the players.
Zel is going to have to intercept a ton of very painful incoming spells so that Lina and Gourry can charge. if Zel falls you either heal him or start over, cause you would be pretty screwed.
Once the power bars are ready, Gourry has to fire the Sword of light, which is a round, then pass the sword to Lina, which is also a round and leaves Gourry completely defenseless. On her turn, she would then cast the Giga Slave.
During the Giga Slave cast, Lina cannot take a hit. Not one. Any damage she takes will screw up the spell and basically blow the world up ending the game. (Actually in the game, there would have been only two places you could actually safely cast the thing. (The other being when you fight copy Rezo and he taunts you into doing it. Even then, Sylphiel puts a stop to it in storyline.) If you were stupid enough to cast it outside of those two places, it had a 99% chance to fail and game over.)
The Giga slave has a WaitState of 2. That means for two rounds, Lina is standing wide open for attack. In the show, Shab just stares at her casting one of his spells, but the AI would immediately lock on and start attacking Lina with every round he's got.
in order to stop the world from going boom, Zel (who's got to be nearly dead by now from the intercepting fun he's been enduring for roughly 13 rounds) and Gourry (who IS dead if he intercepts anything without the Sword of Light) need to intercept any attack Shab makes on Lina during the Giga Slave cast. If they're out of commission at this point, it's pretty much world goes boom time.
If all above conditions are met, the Giga Slave is successfully cast, it hits shab, which crumbles to dust, and Lina sports a white hairdo.
Now. Code an AI in Ti89 basic that can handle the above conditions and doesn't make it mind numbing easy or mind blowing impossible, or takes forever thinking up it's next move...
Just to add to this, I've officially renamed the Slayers engine to the Landel engine, since Legend of Landel will most likely be the first game to incorporate the engine.
At some point, you might see the projects page on http://fryedsoft.bluecrimson.com/ reflect that change, but since I don't update that page anymore and pretty much keep in around for historicial purposes, I might just keep it that way. Not to mention that the site is already out of date vs what the engine can do today.
My job has been really taking a ton of time this past 6 months so I haven't worked on it for awhile, but I've been thinking about where I need to move next on it. Unfortunately It's probably going to take vacation time for me to get the time to work on it.
Home
Calendar
Search
Register
Login
Print Thread
Report to Moderator
Logged
Site
Private message
Or make a game out of it... 
YIM
WLM
