[edit] Update: I've scrapped angelscript;
All scripting is now done in C# and the runtime is embedded. Updates to follow.
[edit] Update: I've scrapped angelscript;
All scripting is now done in C# and the runtime is embedded. Updates to follow.
Last edited by Gleeok; 12-15-2014 at 10:34 PM.
This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.
This is all greek to me, sadly. Working on the assumption that this will work fairly similar to ZScript, could we maybe have copy/paste functionality in the built in script editor? The one thing that bugs me the most about ZScript is probably the reliance on importing scripts as .z files with a bare minimum script editor built in.
What will be the FFC equivalent of ffc scripts since there probably won't be ffcs in FFC? Will they be split into field and battle scripts and be assigned to specific maps and encounters? Could one attach a script to an inventory item or command similar to an item script in ZC. Am I being too closed minded here? Probably am.
Also kinda curious how scripting would work in a turn based battle system. Would there be some sort of waitturn() command to prevent stuff from happening between turns?
I don't know how that would work since stuff like the battle engine is not done yet, so I can't give you any sort of good answer. There also is no editor yet. You can use any code or text editor available. This is mostly language, basic features for now. Sorry. ..Originally Posted by Moosh
Also I can see why you are confused. Don't think of this as similar to ZC scripting. Think of it more like Game Maker (yuck) scripting (but faster and better times infinity... f**k you GM... cough.. shoot, ..I digressed...).
Why would you need things like item scripts at all anyway if you can create scripts dynamically? ...I suppose there would be at least three ways: events, objects, and through scripts, anyway. ..At the very least you could create any kind of script you wanted through another script. Example:
Events and Map objects have not been designed yet, however.Code:class MyObjectThatCreatesObjects { void run() //runs every logical frame { // NOTE: you do NOT need while true here! wait(60); //wait one second game.create_object("MyObjectThatCreatesObjects"); //create a never ending object creating object!!! :P //note; after so many objects are created the engine throw an exception and close your game so this is a bad idea. } };
The battle engine will probably be real-time with a bool for turn-based. :) The BattleActor class (or whatever) might just implement the ATB system. (since it is arguably 99% real-time anyway.) I don't know for sure though since it doesn't exist.
This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.
I don't have a lot to say. I am very glad you went with language I understand. It makes me very excited about this project. I can't wait to see more. How much of the mechanics of the game are going to be manipulatable through scripting? Without foregoing built in function and working from scratch I mean.
Thank you! (Shhhh it's a secret but you could make any kind of 2d game you wanted from scratch using scripting or in c++ with the code. Don't tell anyone though.) -/_-
I've been looking at what rpg maker does and it seems that almost all of the logic is scripted using a type of function based script callback system. (Ruby is confusing to me though...) I'd like to do something similar (but easier to understand).
This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.
That sounds very interesting. I have been meaning to look into RPG Maker though I know not a bit of Ruby.
Ruby is...different. Yet somehow improved in the VX and VX Ace series. ANYWAY...
I'm curious as to whether or not the Menu System will be customizable through scripting.
You just hit one of the major time-killers of all time right between the eyes didn't you?
...To preempt this I think the ENTIRE menu/inventory system will be scripted (using c++ for actual inventory of course). In order to do this the Gui and widget classes need to be very powerful, easy to use, and flexable. ..not an easy feat but I have some ideas. :)
This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.
This will be a native feature of the editor, because it will be a (standard) Windows* Application. If things have not changed very much, then the zquest editor is an Allegro Application.
*As currently scheduled.
I was just reading through to see if I can get an idea of how much would be pre-built vs. needing to be made with a script. Naturally, my mind first considers the menuing system-- any kind of Final Fantasy game has a main menu and various sub-menus accessible from it-- but the exact layout and contents of the menu would vary based on the specific details of the game. For instance, Final Fantasy IV needs 5 characters to be visible; FF V needs a job menu; FF VI needs a skills menu, etc. My point being that while they are all very similar and can probably be built from the same basic parts, the specific form that you end up with would differ based on the need of the game.
Parallel to that, I think the map would be a fairly universal module across games as well. Maps need a width, height, tileset, and of course the data (including probably at least a couple of layers). Several general things populate the map perhaps as additional layers: NPCs, treasure chests, event triggers, warps, animated tiles, layer-priority shifts, diagonal stairways, etc. It seems me that if you get the map powerful and flexible, and then a menu-subsystem.. that's 2/3 of the work right there (the battle engine being the other 1/3, of course).
There are currently 3 users browsing this thread. (0 members and 3 guests)
Posting Permissions
Reply With Quote
