Help me organize this idea.
BlitzMax Forums/BlitzMax Beginners Area/Help me organize this idea.
| ||
| Ok for my current project I plan to have randomly generated bosses. Each boss ship will be made of parts that attach to each other in a way similar to the freeware PC game "Warning Forever". Could anyone provide a good way to create and store the parts so when one is destroyed all the parts attached to it are destroyed aswell? Initially I thought of making each part object have a list that would hold attached parts. When the object is updated, it updates all it's local parts from the local part list. I assume that when the part object is destroyed all the attached parts get destroyed too by default. Is this a good idea? It seems to be getting a bit complex due to a function to add parts that looks alot like the create function to hold base parts in the global "parts_list". Here is "Warning Forever" honestly one of the best Shmups ever-freeware or not. http://www18.big.or.jp/~hikoza/Prod/index_e.html |
| ||
| I think that would be a good way to handle it, yeah.. Make a "Boss" type which holds a list of "parts" and their coordinates (relative to the boss' center (imaginary) coordinates). Loop through and update each part in a "boss" update method and check if one of the parts have died, you can take action accordingly.. (like kill the rest of the parts, or the boss might continue fighting without that part etc. etc.) |
| ||
| Oh, I never thought of havig a special "boss" type to hold the parts. I just had parts holding parts which lacks a basic main type. |
| ||
| Don't make a separate "parts list." Make all of your parts of say Type TPart - even the "base part" that holds all other parts. You don't want to differentiate your base part from the other parts. Instead, store the base part in a type, say - TBoss. So the basic hierarchy of this when all is said and done is a type TBoss which holds a tree of TParts. i.e.
TBoss
|
Part1-------------\
/ \
Part2----Part3 Part4
/ \ \ \
Part5 Part7 Part8 Part9
etc. Since it is a tree, if any part is removed you can simply remove it and all of it's child parts will be removed as well. |
| ||
| Ryan, I'm using a similar technique for my sprite engine. Basically, each sprite object has the following: Type Sprite relX#, relY#, relRot# absX#, absY#, absRot# ' lots more stuff to it, but this gives you the idea ParentSprite:Sprite childSprites:Sprite[] That is, a sprite can have a single parent (null if there's no parent) and multiple children. When you call methods, simply be sure to loop through each child sprite and call all the way down the row, passing position information as you go. I give each sprite object a "relative" coordinate set and an "absolute" coordinate set. The "relative" coordinates are the position of the sprite compared to the parent sprite; the "absolute" coordinates are where the sprite object actually rests in the game's coordinate system (on-screen.) All you need to watch out for is cyclical references. |
| ||
| This is cool, I'm working on this for my next game as well. Talk about coincidence :) |
   |