Nestharus
o-o
- Reaction score
- 84
Yea, I know, back to Spawn ; O, but this time it's a very interesting design. Bringing it up here to see if anyone has some other ideas besides the ones I'm currently doing = ). This is being written in vJASS and is 100% OO.
Again, if you see any features listed here that you are thinking might be a bad idea, let me know. If you think of some features that aren't listed here that you think might rock, let me know : D. If you know some better designs than some of the ones that I am using, that too would be nice = ).
Quicko Description
For those who don't know, Spawn is used to create things. Think of a Cartesian graph with an origin and dots. The origin is what the handle references and the dots are what the origin references (origin = owner and dots = spawns like barracks on footmen wars spawning footmen).
Storage
Spawn runs off of a couple of hashtables and *0* interfaces. Nodes on the hashtables are all matrix style, meaning each node instance is derived from the instances that are linked up by it (like a database). For example, if an origin was instance 40 and a spawn was 30, it'd be 40, 30 as the node.
Origin System
Spawn 2.0 only supports locations, items, and units. It does not support regular coordinates!
Recursive Ownership
Origins have recursive ownership: they can be owned by origins and those origins can in turn be owned by origins. Owned origins get their player/coordinate information from their owner. For example, let's say there is an item with a spawn on it. The item is placed into a backpack. The backpack is the current owner: wherever the backpack is, the item is, and whichever player owns the backpack owns the item. The backpack is picked up by a unit, meaning that the backpack's location is the unit's location and the player that owns the unit owns the backpack.
item -> backpack -> unit
Origin is always the root origin.
Furthermore, each origin can have multiple root origins, so like if you have a base that has multiple spawn points, that base can be owned by all of those points (0 spawn at the spot itself!)
Multiple Origins
I'll also have a value for origins to determine how much of the spawn they get. Anything above 1 means that they get a relative portion of the spawn. For example, total spawn count of 9 with 3 origins would give the specific origin 3 spawns. 0 means it gets nothing. The numbers are rounded down =).
Edit- Multiple Origins removed
Edit- Share spawns added
Origin Charges
Origins get a bonus on spawns based on the charge they have. Items automatically retrieve the charge on the item.
Origins for Items
Whenever an item gets picked up or dropped by a unit, the origin is automatically transferred to the unit.
Item Stacking?
Item Stacking won't be supported and I don't suggest it be supported as each specific item can have its own spawns, meaning you'll have to merge the spawns and then somehow split them up >.<...
Origin Garbage Collector
Keeping track of which handles may have spawns and which may not have spawns and running deallocation and so on can be a major hassle. The system does it for you with a timer that runs 5 times per second (not much overhead). The timer itself just runs through a linked list. Everything is handled perfectly. Furthermore, origins are updated.
Example-
item -> backpack -> unit
backpack is deallocated
item -> unit
Spawns
Still designing some of this part, but I plan for relative spawn coords, hard spawn coods, placement algorithms, and so on. Not sure how to do this without interfaces, but I will use 0 interfaces for this (I'm very determined o-o). It's possible that I'll just have a trigger that you add your condition to and just have you code your own spawn, that way you can do w/e you want.
Multiple origins for Spawns
Spawn Counts
Archival Support
Archival Support is like undo/redo for spawns. This happens when an origin lends a spawn to another origin.
Spawn Operations:
Revert(steps)- sends the spawn back x steps
Root- sends the spawn to root owner
Origin Operations:
Revert(steps)- sends all borrowed spawns back x steps
Root- sends all borrowed spawns back to origin owners
What happens when an origin is destroyed?
All spawns the origin is borrowing revert
All spawns the origin is lending are destroyed
All origins referencing this origin reference this origin's origin
All spawns the origin has are destroyed
The origin's instance is recycled
How does an origin get destroyed?
When the origin no longer exists (unit decayed or w/e) or the destroy method is called.
When are an origin's spawns disabled?
While the origin is dead (units only as items go out of scope when they die)
What happens if I try to create more than 1 origin from the same handle?
the handle's origin instance is returned. Just use create() whenever you want to access a handle's origin instance as that'll either make a new one or return the one that's already made : P.
Why can't I make more than one origin instance per handle?
That's idiotic... add new spawns to the origin >.<...
I want to spawn at the handle and other origins all with the same spawn, but adding new origins to the original origin would make spawns stop spawning at that original origin
Uh huh... try adding the spawn to multiple origins then =).
How complicated is this system?
Not nearly as complicated as Spawn 1.0 : P.
Why are you not supporting regular coordinates yet you support locations?
Locations can be referenced by multiple things... coordinates require syncing : (.
Again, if you see any features listed here that you are thinking might be a bad idea, let me know. If you think of some features that aren't listed here that you think might rock, let me know : D. If you know some better designs than some of the ones that I am using, that too would be nice = ).
Quicko Description
For those who don't know, Spawn is used to create things. Think of a Cartesian graph with an origin and dots. The origin is what the handle references and the dots are what the origin references (origin = owner and dots = spawns like barracks on footmen wars spawning footmen).
Storage
Spawn runs off of a couple of hashtables and *0* interfaces. Nodes on the hashtables are all matrix style, meaning each node instance is derived from the instances that are linked up by it (like a database). For example, if an origin was instance 40 and a spawn was 30, it'd be 40, 30 as the node.
Origin System
Spawn 2.0 only supports locations, items, and units. It does not support regular coordinates!
Recursive Ownership
Origins have recursive ownership: they can be owned by origins and those origins can in turn be owned by origins. Owned origins get their player/coordinate information from their owner. For example, let's say there is an item with a spawn on it. The item is placed into a backpack. The backpack is the current owner: wherever the backpack is, the item is, and whichever player owns the backpack owns the item. The backpack is picked up by a unit, meaning that the backpack's location is the unit's location and the player that owns the unit owns the backpack.
item -> backpack -> unit
Origin is always the root origin.
Furthermore, each origin can have multiple root origins, so like if you have a base that has multiple spawn points, that base can be owned by all of those points (0 spawn at the spot itself!)
Multiple Origins
I'll also have a value for origins to determine how much of the spawn they get. Anything above 1 means that they get a relative portion of the spawn. For example, total spawn count of 9 with 3 origins would give the specific origin 3 spawns. 0 means it gets nothing. The numbers are rounded down =).
Edit- Multiple Origins removed
Edit- Share spawns added
Origin Charges
Origins get a bonus on spawns based on the charge they have. Items automatically retrieve the charge on the item.
Origins for Items
Whenever an item gets picked up or dropped by a unit, the origin is automatically transferred to the unit.
Item Stacking?
Item Stacking won't be supported and I don't suggest it be supported as each specific item can have its own spawns, meaning you'll have to merge the spawns and then somehow split them up >.<...
Origin Garbage Collector
Keeping track of which handles may have spawns and which may not have spawns and running deallocation and so on can be a major hassle. The system does it for you with a timer that runs 5 times per second (not much overhead). The timer itself just runs through a linked list. Everything is handled perfectly. Furthermore, origins are updated.
Example-
item -> backpack -> unit
backpack is deallocated
item -> unit
Spawns
Still designing some of this part, but I plan for relative spawn coords, hard spawn coods, placement algorithms, and so on. Not sure how to do this without interfaces, but I will use 0 interfaces for this (I'm very determined o-o). It's possible that I'll just have a trigger that you add your condition to and just have you code your own spawn, that way you can do w/e you want.
Multiple origins for Spawns
Spawn Counts
Archival Support
Archival Support is like undo/redo for spawns. This happens when an origin lends a spawn to another origin.
Spawn Operations:
Revert(steps)- sends the spawn back x steps
Root- sends the spawn to root owner
Origin Operations:
Revert(steps)- sends all borrowed spawns back x steps
Root- sends all borrowed spawns back to origin owners
What happens when an origin is destroyed?
All spawns the origin is borrowing revert
All spawns the origin is lending are destroyed
All origins referencing this origin reference this origin's origin
All spawns the origin has are destroyed
The origin's instance is recycled
How does an origin get destroyed?
When the origin no longer exists (unit decayed or w/e) or the destroy method is called.
When are an origin's spawns disabled?
While the origin is dead (units only as items go out of scope when they die)
What happens if I try to create more than 1 origin from the same handle?
the handle's origin instance is returned. Just use create() whenever you want to access a handle's origin instance as that'll either make a new one or return the one that's already made : P.
Why can't I make more than one origin instance per handle?
That's idiotic... add new spawns to the origin >.<...
I want to spawn at the handle and other origins all with the same spawn, but adding new origins to the original origin would make spawns stop spawning at that original origin
Uh huh... try adding the spawn to multiple origins then =).
How complicated is this system?
Not nearly as complicated as Spawn 1.0 : P.
Why are you not supporting regular coordinates yet you support locations?
Locations can be referenced by multiple things... coordinates require syncing : (.