Quote:
Originally Posted by kikems
Our plan is:
1- Update GRAC 2 to GRAC 2.5, fixing small bugs and add some new options but with compatibility with old projects, you can load your old game into the new GRAC 2.5 and save as improved version. In addition we include an external app for extract text files for help to recreate the game in different languages.
(Now finished at 99% , we need check documentation, test it intensive and make a new better tutorial)
2- GRAC 3, will include all improvements of GRAC 2.5 and add graphic inventory, native multi-language for games , new format for read and write files faster , new question and answers engine, options menu for save and load states, maybe a new music .mod engine and some other things.
(At now new file format, graphic inventory and multi-language is ready)
3- GRAC 3.5 , the idea is maintain the same GRAC 3 editor and rewrite a new player engine in Blitzbasic for OCS and AGA adventures.
4- GRAC 4 ( Not more GRAC source code dependency ), when GRAC 3.5 finished Birra want rewrite all from scratch for make and adventure engine capable to build games for Amiga OCS, Amiga AGA, Amiga RTG and Amiga NG, all in the same tool.
Of course all this things need time, time, and more time. GRAC 2.5 and GRAC 3 they are in progress, GRAC 3.5 and GRAC 4 they are just an idea, for now.
|
@Kikems
I started writing an adventure engine in AmigaE once. I didn't make it very far due to the bugs in the E compiler but I know of some ways to improve execution speed even in AmosPro to help get to the later stages of development sooner.
Here are some examples:
Use a bitset to store inventories. It doesn't matter if it's a room inventory or a character inventory, inventories can be stored in a single integer variable by using the BSET, BCLR, AND and OR commands in AmosPro. The limitation is that only 32 items can be stored in such an inventory, one per bit in the integer. The way this works is that you assign a binary place value for each item in the inventory and mask bits on and off to indicate adding and removing items from the inventory. The main advantage is that, by creating a mask, multiple items can be tested for absence or presence in a simple use of bit twiddling.
Compile walk-zones into a 2D matrix (array). Path finding algorithms usually use a recursive heuristic to determine the path to walk between when using the "walk to" action. By setting the rows of the array as zone numbers of where the character currently is and the columns to be the waypoints and destinations of the walk operation, it's possible to do a travel using a while loop instead of recursion. By reserving zone 0 as the character being in the position requested already, you can know the terminating condition of the while loop also. (As an aside, this is the same algorithm used to tokenize variable length strings in a compiler using GNU Flex.)
If these algorithms interest you, I'll discuss it with you either privately or in the AmosPro programming forum here on EAB. If you think that it needs a better compiler than AmosPro, Bebbo's GCC 6.5b will outdo Blitz.