Graal Forums  

Go Back   Graal Forums > Development Forums > Future Improvements
FAQ Members List Calendar Today's Posts

 
 
Thread Tools Search this Thread Display Modes
Prev Previous Post   Next Post Next
  #1  
Old 05-04-2003, 08:26 AM
Kaimetsu Kaimetsu is offline
Script Monkey
Kaimetsu's Avatar
Join Date: May 2001
Posts: 18,222
Kaimetsu will become famous soon enough
Gani-specific variables and gani sets

Gani sets

Usually a single monster etc needs a few ganis to operate. A hurt gani, an idle gani, a moving gani etc. But having multiple separate files to represent a single creature's representation seems... messy. I propose a feature whereby ganis can be grouped together in sets. Then instead of the gani directory looking like this:

ghost_walk.gani
ghost_hurt.gani
ghost_idle.gani
ghost_attack.gani
snake_walk.gani
snake_hurt.gani
snake_idle.gani
snake_attack.gani

it would look like this:

ghost.gani
snake.gani

choosing which subgani to use would probably involve some kind of reserved character (example: 'setani ghost.walk,;' or 'setani ghost::walk,;'). The implementation would surely be fairly simple? Ganis are just text files, so the different sprite definitions etc could all be held in a single file with an index of sorts at the beginning. Or heck, they could just be bundled into something akin to a zip file.

Gani variables

Today I was thinking about how I would script a ghost whose opacity varied randomly. The obvious problem with the task is that ganis would not mesh together easily. I could code a script gani that drew the ghost and varied the opacity pretty easily, but each script would have its own set of variables - if the ghost changed from ghost_walk (or ghost::walk ) to ghost_idle then the variable holding its current transparency value would be lost and there'd be a visible change in opacity. Not very nice.

And there are other examples. What about a monster that is on fire? Maybe a fire elemental? If its flames are particle effects controlled by a gani script then they will reset themselves every time the gani is changed. In this case we could try using a complimentary gani to get around the problem, but it's not exactly an elegant solution.

I propose a set of variables that are only accessible to ganis (gani.vars would seem like the intuitive option). These variables would be accessible to every gani that runs, and would be preserved between gani changes. Then I can store the ghost's current opacity in gani.ghostOpacity and any of the ghost's ganis can access it, meaning that the transparency will stay smooth and convincing.
__________________
Reply With Quote
 


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:11 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2025, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.