Active TopicsActive Topics  Display List of Forum MembersMemberlist  Search The ForumSearch  HelpHelp
  RegisterRegister  LoginLogin
Developers
 Brain Games Forums : Developers
Subject Topic: Game engine design Post ReplyPost New Topic
Author
Message << Prev Topic | Next Topic >>
Iamweasel
Senior Member
Senior Member
Avatar

Joined: 19 August 2003
Location: Brazil
Posts: 539
Posted: 07 April 2004 at 15:27 | IP Logged Quote Iamweasel

Hi, this question is for Santi and all people who develops games.

I'm writing a game engine. I wrote all the usual classes, like Sprite and background. The main control of the game is done with the usual State classes (RunningState, MenuState, etc). My question is, in the RunningState class (in my engine, it's where all the action when the game is started happens), should I use another class to keep scores, lives, hiscore, etc, or it can stay just here. I know it sounds like a silly question, but I just don't want to write too many classes as well. About the sprites classes, I tried to put almost everything I could in the generic Sprite classes, and only use subclasses when it was strictly need (e.g, enemies that need to know where the player is). Can you explain how did you wrote your engine classes ? It would help to know how you did yours, I believe I made my sprite class too heavy. How did you implement animations in your sprite ? With a new class (eg. animation) or just store the images in your sprite class ? Well, there are other questions, but I'll stop now. :-)

Thanks,

 



__________________
[]s

Mauricio.
Back to Top View Iamweasel's Profile Search for other posts by Iamweasel Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 07 April 2004 at 23:35 | IP Logged Quote Popolon

Actually, the "basic" class structure of the engine of MoG2/Magical Tree is the following: (there are many minor classes, here are depicted only the main ones)



Notice that all the classes are "doubled", e.g. for the maps, there is the MAP class and the ActiveMAP class. I hope that the picture is self explanatory. Just ask me if you have some doubts.

For your specific question about the scores, lives, etc. In my engine it's solved like this:
- There is a TOP class called APPLICATION (that isn't represented in the picture above, I should update that picture since it's some months old... ): this class keeps the hiscore
- The APPLICATION class has instances of the MENU and GAME classes (ActiveINTERFACE and ActiveMOG2 in the picture). The scores, lives, etc. in my engine are stored locally in the PLAYER class (ActiveOBJECT), since in multiplayer games, each player has its own score, lives, etc. The APPLICATION class is continuosly cheking if there is a PLAYER that has a score higher than the current hiscore, to update the value.

I hopt this helps
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
Iamweasel
Senior Member
Senior Member
Avatar

Joined: 19 August 2003
Location: Brazil
Posts: 539
Posted: 08 April 2004 at 23:51 | IP Logged Quote Iamweasel

Well, it is indeed quite different from my design, what is good, because we can talk about it and learn new ideas to improve our own view of what is good/necessary to a game engine. But I'm curious, where do you keep information about 2 sprites that share common info ? E.g. , if the player can only throw 2 knifes at a time, and he will only be able to throw another one when one of those knifes dies, where this information is kept ? In your Mog classes, together with all the other info (score, etc) ?

__________________
[]s

Mauricio.
Back to Top View Iamweasel's Profile Search for other posts by Iamweasel Send Private Message Add to Buddy List
 
valerian
Groupie
Groupie
Avatar

Joined: 05 October 2003
Location: France
Posts: 65
Posted: 09 April 2004 at 00:44 | IP Logged Quote valerian

Hello all!

Well just started programming some c++ 2 month ago and just want  to say that the pic your show for Mog2 classes is good to look at for learning  but still a bit hard to understand yet of course for me !

but i want to ask Popolon if you have a such pic for the class of road fighter and mog1 ?(to learn and understand)

i have also download the source of mog just too see how it work: conclusion : it's a huge work!!!!so there is a long way......Also want to say that i have learn a lot when reading on this forum about a guy who ask how make video game it was a very interesting topics!

 finally keep up the good work and give us soon a wonderful mog2!  

See you!

ps:sry for my poor english!

 

Back to Top View valerian's Profile Search for other posts by valerian Visit valerian's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 09 April 2004 at 13:51 | IP Logged Quote Popolon

Answering to Iamweasel:

ActiveOBJECT is quite a complex class. Objects can have "CHILDREN". That are objects that are tied to a father object (for instance, the SWORD, or the ARROWS are children of the main character). If the father objects disappears, all the children object do the same. The behavior of the objects is specified in SCRIPTs. The script to fire an arrow can be the following one (very simplified):

IF KEYPRESS(SPACE) AND
   COUNTCHILDREN(ARROW)<2 THEN CREATECHILDOBJECT(ARROW)

These scripts are specified in the OBJECT instances. The ActiveOBJECT instances just execute the scripts.

There is an instance of the OBJECT class for each different type of object (i.e. one instance for the player, one instance for each kind of enemy, for each item, etc.)
Then, there are as many instances of ActiveOBJECT as objects are in the game. I.e. if in one room there are two skeletons, there will be a single OBJECT instance containing all the scripts for the skeletons, and two ActiveOBJECT insances executing the scripts for each one of the two skeletons.

I'd like to see your class graph also. It'd be interesting to see another approach. I actually used this approach because of the editor. Using the MoG2EDITOR, you edit the MAP, ROOM, OBJECT, etc. (i.e. the classes on the left part of the image). Then in execution time, the classes on the right part of the image are used.



Answeing to Valerian:

I'll try to draw the same picture for MoG and RF. They will be simpler. I'll post them when finished.
and btw, I do not recommend you to look the MoG source in much detail, it's a complete mess! better look at the road fighter code, it's a bit more organized!
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
Iamweasel
Senior Member
Senior Member
Avatar

Joined: 19 August 2003
Location: Brazil
Posts: 539
Posted: 09 April 2004 at 16:57 | IP Logged Quote Iamweasel

for some reason I  can't use the controls to format the colors and make this text more readable (using IE 5.00 here), but here it goes: (I'll use --- to separate your text from mine).

It is become more interesting than I thought it would be this conversation. :-) Let's keep on.

-----------------------------------------------------------------

ActiveOBJECT is quite a complex class. Objects can have "CHILDREN". That are objects that are tied to a father object (for instance, the SWORD, or the ARROWS are children of the main character). If the father objects disappears, all the children object do the same. The behavior of the objects is specified in SCRIPTs. The script to fire an arrow can be the following one (very simplified):

IF KEYPRESS(SPACE) AND
   COUNTCHILDREN(ARROW)<2 THEN CREATECHILDOBJECT(ARROW)

These scripts are specified in the OBJECT instances. The ActiveOBJECT instances just execute the scripts.
------------------------------------------------------------------

Hmmm, let's see if I get it, the "logic" of the behavior of the caracters in the game all reside in your script files ? Really interesting. But doesn't that make debug a little harder ? I thought about doing that kind of relationship ("father" and "children" ) between sprites you did, as a matter of fact, I did it, but a really simple one, an sprite has only one sprite that should be warned when he dies (the arrow case we talked about), so the warned sprite "knows" he can shoot another one. I didn't want to do it as you did because I want my sprites objects to be independent one from another as much as possible. it's a guideline recommended in OO design if I remember well, But I don't know how long I will be able to keep it. What do you think about that ? Am I being silly ? I really want to hear your opinion about that.

------------------------------------------------------------------

I'd like to see your class graph also. It'd be interesting to see another approach. I actually used this approach because of the editor. Using the MoG2EDITOR, you edit the MAP, ROOM, OBJECT, etc. (i.e. the classes on the left part of the image). Then in execution time, the classes on the right part of the image are used.

------------------------------------------------------------------

I'll draw one for you, just let me finish it. I shouldn't say this, it's a not written rule we use here in #MSX brazil mailing list, we never talk about what we are doing until it's done because it brings bad luck to the project. ;-) I'm writing a remake here that is helping me to refine the game engine. It's 80 % done (the engine) I believe, so it's just a matter of refine it. The game is going well, and (should not say that either... ) IF everythings goes well, in a month or so I should present a beta to people here see.

But since I don't like to let things unanswered, I'll try to explain a little from my design:

All graphics are tiles or sprites. Everything that interacts with you or each other is a sprite (duh?). Enemy objects are descendents of the sprite class (called Garejo, I'll explain that in other message), so you have a blue Garejo, a gray Garejo, and so on). The player is a descendent of sprite class named player (really ? ) and so on. these sprites are kept in a linked list that is kept in a map class. This map class has the responsability of keeping the tiles and sprites, and draw then on screen. the idea of the game is that we have state class, that have the responsability of in each state (let's say the RunningState class, where the game goes), to iterate through the sprites list, calling on each the update's method. In update's method of each sprite there is code to update it's position , animation, and check if it reachs the bounds of the screen). this sprite can return sprites's action to inform the RunningGame class that something has to be done (the sprite has to die, the sprite wants to add another one (he shoot an arrow, for instance), and so on. If an action has to be made, the RunningClass call's a method in the same sprite in order that he can say what he wants to do (is each sprite responsability to know what sprite should be created, what to do when he dies, etc). That way, I believe I can keep the code distributed by each class responsability, making it more maintanable ( I hope). After the update of the sprite and checking if he returned an action to be done, is checked the colision between this sprite and other sprites on the list. Again, each sprite has to say what should happen when he collides with another one.

So, to keep it short, we have the sprite classes (objects of the game), the map (that keeps the sprite and draw to the list), a state game class to command the show in each state (menu, demo, game, end),  a resource manager class to read the resources (sounds, images), a inputManager to read keyboard strokes, a soundManager to play sounds (each sound is a separated thread) and I believe most of it is described now. :-)

If there's anything you didn't understand, just ask, it is nice to talk about game development. :-)

 



__________________
[]s

Mauricio.
Back to Top View Iamweasel's Profile Search for other posts by Iamweasel Send Private Message Add to Buddy List
 
Iamweasel
Senior Member
Senior Member
Avatar

Joined: 19 August 2003
Location: Brazil
Posts: 539
Posted: 09 April 2004 at 17:00 | IP Logged Quote Iamweasel

I forgot to say, of course there are private classes inside those I mentioned, but these are only to do small jobs, the main classes are those I mentioned. I want to make more classes, such as classes for score, network, whatever, I want to make the design as clean and elegant as possible.

__________________
[]s

Mauricio.
Back to Top View Iamweasel's Profile Search for other posts by Iamweasel Send Private Message Add to Buddy List
 
valerian
Groupie
Groupie
Avatar

Joined: 05 October 2003
Location: France
Posts: 65
Posted: 09 April 2004 at 18:41 | IP Logged Quote valerian

Hi Santi and the others!

thanks for reply but dont waste time to do that if you haven't got it!yes you are right very difficult to understand mog especially that i am a noob!Must work on my knowlegde and it's hard but i will try !!! Want to make something like a game someday so i run on and on.

thank you anyway! see you soon!

Ludo the french noob coder!!

Back to Top View valerian's Profile Search for other posts by valerian Visit valerian's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 10 April 2004 at 14:03 | IP Logged Quote Popolon

Well, about RoadFighter, I can let you see this document: 68F67_rf-design.zip
I wrote it previous to create the game, and the real implementation is a little different, but It somehow summarizes the main idea of the game.

And about MoG2:

- actually, having the behavior of the objects in scripts made debugging very difficult at the beginning as you say. But I implemented a SCRIPT DEBUGGER, in which you can execute the game stepping cycle by cycle and see the state of each script.

- About the father-child relationship. As you say it is better to leave all the objects as independent as possible. But I implemented in having in mind to create really complex obejcts such as final demons, where the body of the demon is the main object, and the legs, arms, or other parts are children objects of the main object. Each one can have a different behavior. Actually that idea of yours of passing messages between objects (when an object dies notifying the father) is an interesting one, It could allow quite interesting coordination among objects. However, I think that what you should do is to allow generic messages among objects, and not only a "I've died" message. That would allow a very generic coordination mechanism! I think that that is missing in my engine. I should definitively implement a way in which objects can communicate. I do not need it in MoG, but may be in some other game...

- I see several parallelisms between your engine and mine: you have TILES and SPRITES, and I have TILES and OBJECTS (for me an OBJECT is an entity with a set of TILES associated and a set of behavior SCRIPTS). Your MAP class is like my ROOM class (actually my MAP class is a container of ROOMs). Your STATE class is somehow like my Active* classes. I think that the main difference is that you specify the behavior of the SPRITES by specifying a new SPRITE class and I specify the behavior by specifying SCRIPTS in the generic OBJECT class. I actually used your approach in RoadFighter, where I have an OBJECT class, and a CarOBJECT subclass, then PlayerCarOBJECT and EnemyCarOBJECT firther specialize CarOBJECT.

I think that both approaches have advantages and disadvantages and there's no one better than the other. Your approach is more efficient (since you code the bahavior directly in C), and my approach allows me to specify the behavior using my external editor. I'm actually impementing a general 3D engine for a project in my lab, and I'm using your approach of specializing the OBJECT class (Called AW_Agent in my 3D engine) to specify new behaviors.



Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
Iamweasel
Senior Member
Senior Member
Avatar

Joined: 19 August 2003
Location: Brazil
Posts: 539
Posted: 10 April 2004 at 15:11 | IP Logged Quote Iamweasel

------------------------------------------------------------------

- About the father-child relationship. As you say it is better to leave all the objects as independent as possible. But I implemented in having in mind to create really complex obejcts such as final demons, where the body of the demon is the main object, and the legs, arms, or other parts are children objects of the main object. Each one can have a different behavior.

------------------------------------------------------------------

Indeed, in this case, a sprite independent approach would be harder to coordinate.

------------------------------------------------------------------

Actually that idea of yours of passing messages between objects (when an object dies notifying the father) is an interesting one, It could allow quite interesting coordination among objects. However, I think that what you should do is to allow generic messages among objects, and not only a "I've died" message. That would allow a very generic coordination mechanism! I think that that is missing in my engine. I should definitively implement a way in which objects can communicate. I do not need it in MoG, but may be in some other game...

------------------------------------------------------------------

Well, the messages are generic. There are only 3 kinds of message: SA_KILL, SA_RESTOREPOS, SA_ADDSPRITE (SA stands for Sprite Actions) . When those messages are received, control is returned to the sprite because it's his responsability to tell what should do now (in the last case, he must tell what sprite should be created, in the first case, he should notify any other sprite that something has happened to him (in this case, the only thing it's being used is the case of his death). If I need more types of message, I'll create them as soon as it is needed, but for now, it is good enough those 3. :-)

------------------------------------------------------------------ 

- I see several parallelisms between your engine and mine: you have TILES and SPRITES, and I have TILES and OBJECTS (for me an OBJECT is an entity with a set of TILES associated and a set of behavior SCRIPTS). Your MAP class is like my ROOM class (actually my MAP class is a container of ROOMs). Your STATE class is somehow like my Active* classes. I think that the main difference is that you specify the behavior of the SPRITES by specifying a new SPRITE class and I specify the behavior by specifying SCRIPTS in the generic OBJECT class. I actually used your approach in RoadFighter, where I have an OBJECT class, and a CarOBJECT subclass, then PlayerCarOBJECT and EnemyCarOBJECT firther specialize CarOBJECT.

-------------------------------------------------------------------

Yes, there are similar things, and it had to be this way, we both are coding action games, and the ideas behind the implementation like actors (or sprites, objects), stages (maps, rooms), were defined years ago. Thinking about now, I see that there's another thing similar, I'm using the "model" sprites too, my resourceManager class creates all the sprites needed, and they are cloned and put in the game as needed, exactly as you're doing.

-------------------------------------------------------------------

I think that both approaches have advantages and disadvantages and there's no one better than the other. Your approach is more efficient (since you code the bahavior directly in C), and my approach allows me to specify the behavior using my external editor. I'm actually impementing a general 3D engine for a project in my lab, and I'm using your approach of specializing the OBJECT class (Called AW_Agent in my 3D engine) to specify new behaviors.

-------------------------------------------------------------------

I don't believe in right or wrong. What matters is if the code works or not. Your code works fine for me. I'm trying to make my code to work as good as yours, and just like you, I'm trying to do it the more reusable that I can. Of course, the more reusable a code is, the slower it will be, so I need to find the balance point. As I said, it is always good to talk about it, after all, you are an experienced game developer, and I can always learn from your experience. :-) Another thing I would like to ask you, in your code, things like AI (path finding algorithms, etc) your enemy objects use, are all coded in each object's script or are you using generic classes to do it ?

 



__________________
[]s

Mauricio.
Back to Top View Iamweasel's Profile Search for other posts by Iamweasel Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 11 April 2004 at 15:18 | IP Logged Quote Popolon

AI is one of the things that I still don't have decided how to definitively include in the engine. Currently, all the AI of the enemies is coded in the scripts. But of course, if I need pathfinding, what I will do is to implement a generic pathfinding algorithm in C, and add some script commands to manage it.
However, the AI needed for the enemies in MoG is _REALLY_ simple, they use very mechanical behaviors, and some "IF the character is near THEN fire a bullet". I think that complex AI is more suited for games such as Nether Earth.

I'm curious about your "resource manager" and "input manager" classes. What do they do? I can imagine that the resource manager loads images/sounds from disk. Does it has some policy to delete tiles from memory that are not in use any more or something like that?
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
Iamweasel
Senior Member
Senior Member
Avatar

Joined: 19 August 2003
Location: Brazil
Posts: 539
Posted: 11 April 2004 at 19:26 | IP Logged Quote Iamweasel

Well, ResourceManager indeed load images, sounds, maps from txt files and creates "models" for all sprites used in the game. this is done before the game is started, in a separated thread, of course. When a sprite is needed , all I have to do is create a new sprite by cloning the desired sprite from the resourceManager. InputManager manages all input from the user, it uses a class called GameAction to each command the user can do (fire, up, down, etc), and it allows me, among other things, to redefine keys on the fly, associate more then a key / mouse button to a command, control the behavior of the key (continuous press, initial press only). Currently there's no policy to delete tiles, and all memory management is left to garbage collection present in java, although I'm planning to do something about that too. 

__________________
[]s

Mauricio.
Back to Top View Iamweasel's Profile Search for other posts by Iamweasel Send Private Message Add to Buddy List
 
Iamweasel
Senior Member
Senior Member
Avatar

Joined: 19 August 2003
Location: Brazil
Posts: 539
Posted: 13 April 2004 at 19:54 | IP Logged Quote Iamweasel

Just to see if I get it. In your design, all the objects (arrow, coins, rocks, etc) are of OBJECT type (you don't subclass it for special behaviour) and their behavior are located in the script files ?

__________________
[]s

Mauricio.
Back to Top View Iamweasel's Profile Search for other posts by Iamweasel Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 14 April 2004 at 09:17 | IP Logged Quote Popolon

exactly.

The OBJECT / ActiveOBJECT class is the most specific object class. There are no subclasses. They have generic draw and behavior functions that work for any kind of object.

and btw, I like very much your InputManager idea! Maybe I copy that... If you allow me of course
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
Iamweasel
Senior Member
Senior Member
Avatar

Joined: 19 August 2003
Location: Brazil
Posts: 539
Posted: 14 April 2004 at 13:25 | IP Logged Quote Iamweasel

-----------------------------------------------------------------

exactly.

The OBJECT / ActiveOBJECT class is the most specific object class. There are no subclasses. They have generic draw and behavior functions that work for any kind of object.
-----------------------------------------------------------------

Hmmm, it sounds great to me, because it allows you to have fewer classes and to make the code clean. :-)

---------------------------------------------------------------


and btw, I like very much your InputManager idea! Maybe I copy that... If you allow me of course

--------------------------------------------------------------

Sure, I'm glad you liked it. Feel free to make your InputManager class, I don't have any patents on it (and I didn't invent the concept, that's for sure). :-) If you want to know more about how it is implemented, just ask. But since you brought this subject, I heard there's a strange patent law being discussed in europe about software ideas and algorithms, did you know that ? What's exactly they are trying to do ?

 



__________________
[]s

Mauricio.
Back to Top View Iamweasel's Profile Search for other posts by Iamweasel Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 14 April 2004 at 15:34 | IP Logged Quote Popolon

About the generic OBJECT/ActiveOBJECT classes, the greates benefit that I've seen from them is that it is very difficult that those classes have a single bug. Since there are hundreds of objects in the game using the same code. They are masively tested. If an object does not behave as hoped, it is definitely because the action script has nnot been specified properly.


And about software patents:

Yes, about a year ago, the european council reached an agreement on limiting the number of software patents granted in europe. Now, they want to allow any patent (I think). Considering the number of sued companies in the US for violating patents (see the case of SCO that has sued Linux!). Many software developers considere software patents as a menace for the innovation in software. I'm not much into that area, and I really dont't know if software patents are good or evil. But some of my colleagues at the university are actively fighting against sofware patents.

Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
Iamweasel
Senior Member
Senior Member
Avatar

Joined: 19 August 2003
Location: Brazil
Posts: 539
Posted: 14 April 2004 at 18:51 | IP Logged Quote Iamweasel

If I understood it correctly, everything , from design to algorithms, no matter how  simple, could be patented. This forum, for example, would become illegal, unless the patent for a forum site is ours or we came to a agreement with the owner of the patent. This sounds like a joke, but it seems that the law would allow things like this. I think it's something that you europeans should be worried. Otherwise you will have to keep sites like this in servers located in other countries not in europa...

__________________
[]s

Mauricio.
Back to Top View Iamweasel's Profile Search for other posts by Iamweasel Send Private Message Add to Buddy List
 
Iamweasel
Senior Member
Senior Member
Avatar

Joined: 19 August 2003
Location: Brazil
Posts: 539
Posted: 20 April 2004 at 07:31 | IP Logged Quote Iamweasel

Hi Santi,

I'm trying to improve my engine, by making it as organized as possible, and with as few classes as possible, as long as the tasks are divided correctly, of course. I would like to reduce the number of sprites subclasses (if possible, eliminate all). So , I believe it's my turn now of improving my code by "borrowing" your script idea, if you don't mind. :-) Can you tell me more about it, how it works, which tokens did you create in your language, and how the sprites interact using scripts in your games ?

Thanks.

 



__________________
[]s

Mauricio.
Back to Top View Iamweasel's Profile Search for other posts by Iamweasel Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 20 April 2004 at 09:54 | IP Logged Quote Popolon

I'm actually not very happy with the scripting language I'm using. It's enough for the kind of games I'm doing right now, but I plan to change it in the future. Fortunately the scripts are stored in a class named "ActionSCRIPT", and just by changing that class I can change the scripting language.

There are 3 kinds of scripts:

- ActionSCRIPTS: do not return any value
- ValueSCRIPTS: return integer or string values
- ConditionSCRIPTS: return a boolean value

(I know, ConditionSCRIPTS should be a subclass of valusscripts, but I did it this way...)

The scripts are executed by CYCLES. At each frame of the game, a CYCLE is executed. Value and Condition scripts take a single CYCLE to execute, and action scripts may take more than 1 cycle to execute. Moreover, each OBJECT has a list of variables. A variable is a struct with 4 fields: NAME, VALUE_TYPE (integer or string), INTEGER_VALUE, STRING_VALUE.

Each object has a set of STATES. For each STATE, an action script and an AnimationSCRIPT (that is a very simple script specifying the sequence of tiles of an animation for the object in that state) are specified. Moreover, each object has also a set of CONDITIONAL_STATES. A conditional state has two extra parameters than a script: a PRIORITY and a CONDITION. A CONDITONAL_STATE is executed when the CONDITION is true and there are no other conditional states executing with a higher PRIORITY.

The main commands of ActionSCRIPTs are:
- SEQ( action1, action2, ... , action3 ): executes action1, then action2, etc. The nº of cycles that SEQ takes to execute is cycles(action1)+cycles(action2)+...+cycles(actionn)
- PAR( action1, action2, ... , actionn): executes all the scripts in parallel. The nº of cycles taken is the maximum among all the scripts
- ATOMIC( action ): executes cmd in a single CYCLE (i.e. ATOMIC( SEQ ( action1 , action2) ) will execute cmd1 and cmd2 in the same cycle
- PAUSE ( value ) : pauses "value" number of cycles
- WHILE ( condition ) { acction } : ...
- DO { action } WHILE (contition) : ...
- IF condition THEN action1 ELSE action2 : ...
- MOVE ( valuex , valuey) : moves an object a specified amount (in hundreths of pixels, i.e. MOVE(100,0) moves 1 pixel to the right)
- TERMINATE : kills an object
- CREATEOBJECT ( name , x , y plane )
- SET variable = value1
- etc. (there are 47 action commands)

The main ActionSCRIPT commands are:
- INGEGER
- STRING
- VARIABLE ( name , environment ) : the environment can be: OBJECT, ROOM, MAP, GAME, APPLICATION or FOREIGN. (I'll later explain what FOREIGN means). It gets the value of a variable named "name" of the right "environment".
- value1 + value2
- value1 - value2
- value1 * value2
- value1 / value2
- CONCATENATE (value1,value2)
- RANDOM (min, max)
- etc. (there are 25 value commands)

The main ConditionSCRIPT commands are:
- TRUE
- FALSE
- condition OR condition
- condition AND condition
- NOT condition
- value1 == value2 (and also !=, >, <, >=, <=)
- INSIDE_ROOM(offsx, offsy): false if the object has the hot spot outside the room after moving offsx, offsy
- COMPLETELY_INSIDE_ROOM(offsx,offsy): false if the object has some pixels out of the room after moving...
- PARTIALLY_INSIDE_ROOM(offsx,offsy): ...
- SENSE_OBJECT (constitution, x,y,w,h): true if an object of constitution "constitution" is sensed in the square defined by x,y,w and h (relative to the object hot_spot) (objects may have different constitution: NONE, WALL, WEAPON, CHARACTER, etc.)
- SENSE_SPECIFIC_OBJECT( name, x,y,w,h) : ...
- COLLISION (offsx,offsy)
- OBJECT_COLLISION( constitution, offsx,offsy, condition): true if the object collides with an object of constitution "constitution" for which the condition "condition" is true. For example: SPECIFIC_OBJECT_COLLISION( WEAPON , 0, 0, VARIABLE("damage_type",OBJECT) == "enemy" ), tests whether the character has collided with an obejct of constitution "weapon", and that that object has the value "enemy" in the variable "damage_type".
- etc. (there are 28 condition commands)

As I said before there's one thing that I do not like ot my scripts. And it's specifically the FOREIGN environment. Imagine that from the script of an object A, I want to access to a variable V from another object B (in C++ you will write B.V), but in my scripts you must do the following:
IF SENSE_SPECIFIC_OBJECT( B , 0 , 0 , 100 , 100 )
   VARIABLE( V , FOREIGN )
   ELSE
   NONE

If the SENSE_SPECIFIC_OBJECT command succeeds, and finds the desired object inside the box of 100x100 pixels, the obejct B will be set as the FOREIGN object. Then, all the references to FOREIGN variables will be variables from B. This is nice for simple scripts, but when you need to access to variables of more than 2 objects in a single scripts, it starts being a problem, since there is a single FOREIGN register (that actually points to an object).

One of my plans for future improvements of the scripts is to add a fourth kind of scripts: ObjectSCRIPTS that return an "object" as the value. For instance, a command called GETPARENT() will return the parent object of a hierarchy. My idea is that you could write things like this: GETPARENT().V to access to variables of that object. In the current implementatino you must to:
GETPARENT()
VARIABLE(V,FOREIGN)

Well. These are my scripts. I know they are not the best scripts you can think of, but they are working for my games! If you think of any improvement, please tell me!!!
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
Iamweasel
Senior Member
Senior Member
Avatar

Joined: 19 August 2003
Location: Brazil
Posts: 539
Posted: 23 April 2004 at 14:12 | IP Logged Quote Iamweasel

sorry for the delay replying to your message. Well, you developed a powerfull scripting scheme, have you thought about writing an paper about that  ? :-)

I read it, and it sure will help when I design my own script scheme. When that happens, I'll comeback to exchange more ideas about that with you. :-)



__________________
[]s

Mauricio.
Back to Top View Iamweasel's Profile Search for other posts by Iamweasel Send Private Message Add to Buddy List
 

Page of 2
  Post ReplyPost New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum

Powered by Web Wiz Forums version 7.01
Copyright ©2001-2003 Web Wiz Guide

This page was generated in 0,3135 seconds.