System Spawn

[Nestharus]

What Previous Versions Had-
Spawn 1.0-
The ability to make any object mimic any other object, including units mimicing items
The ability to lend and borrow bases and spawns up to any degree
Easily trade spawns, etc
Spawn at the handle's x and y coordinates

Spawn 2.0
API Improvements and many performance enhancements

Spawn 3.0
Relative Spawning (spawn relative to x, y, and facing of handle and base spawn slot)
More performance improvements
Improved mimicing

Advanced Data Attachment
-Attachment Archiving
-Multi Data Attachment
-3 Levels of Data Attachment All With Multiple Attachments

Extensibility-
It uses a combination of interfaces and structs so that any type of variable or set of data can be used-

library MyHandle
    globals
        private unit array u
    endglobals

    public struct Unit extends Handle
        //sets up u and makes the getters and sets of the handle point to the unit array
        //and use unit getters/setters (SetUnitX and GetUnitX for example)
    endstruct
endlibrary

Flexibility-
Contains many delegates so that pieces of objects can be put together to create a full object. These pieces can all be changed at a whim!

Just to name a few-
Base- modifiers, custom method injections
Spawn- modifiers, algorithms, custom method injections, creation

Advanced Data Manipulation-
Cloning, Mimicing, trading between large sets of data, and so forth all with very simple calls!

Custom Data Attachment On Top Of Spawn's Architecture-
All Handles, Bases, and Spawns may be used as ids for attaching data in an array-
myArray[handle] = myData

For validation, all handles, bases, and spawns include an id that stays unique for the entire game. They also include a mimicId that stays unique for
entire game. The reason for the id is because struct ids get recycled-

if handle.id == myId[handle] then //make sure it's the same handle and that it's still in its state
    set myData[handle] = data
endif

The mimic id can be used if you only wanted to attach data to something for a specific instance of a mimic

Advanced Data Production so that Produced Data can be relative to any other piece of data up the tree-
Spawn Objects can produce any data you want. They use everything you plugged into them and then pass all of the data into a method you
write yourself.

Parameters: spawn, player, typeId, x, y, z, facing

The Spawn calls your function multiple times, so all you have to worry about is making the type, Spawn does the rest =).

local unit u = CreateUnit(player, typeId, x, y, facing)
call SetUnitFlyHeight(u, z, z*10)

JASS Description

Design Upgrades-
onBaseAdd/onBaseRemove
onSpawnAdd/onSpawnRemove
Modifier Object

UML Guide
Eclipse

ERD Guide Part 1
ERD Guide Part 2
MySQL Workbench

Progress-
1. Use Chart
2. Initial Class Chart
3. Sequence Diagram and map out the API
4. Write Spawn 4.0
5. Write out manual using the charts and API (very technical and in-depth) (for designers)
6. Release 4.0 as a beta and get feedback
7. Work on 4.1 if any features are requested or any bugs are found
8. Write a guide (for users)

MySQL Workbench File

 

[Nestharus]

Placeholder

 

[Nestharus]

Example Section

 

[Tyrande_ma3x]

I seriously can't understand ANYTHING in this system... except something about data attaching. You totally lost me.

 

[Nestharus]

Tyrande.. there's no real way to put it into simple terms because spawn has no set defined types... it handles fully ambiguous data ><. What this means is that the data can be whatever the user desires...

I guess I'll try my hand at coming up with a good description in following posts and we can just pick the best = ).

Description:
What does a lamp produce? A lamp produces light. Imagine that the lamp and the light are separated. The lamp is by itself in the dark and the light is by itself in the light. Now, we want to add the light to the lamp, and so we do, and the lamp goes back to producing light.

Now imagine a lamp with hundreds of different colored light bulbs. Each light bulb produces a different color of light. The lamp has one switch for each light bulb so that you can turn them on or off individually and one main switch for turning them all on or off. Now you detach all the many light bulbs from the lamp so they are on the floor and all the light bulbs shine out with their lights. Let's say that the light bulbs must have a lamp to shine out their light, otherwise they don't know where to shine.

Spawn works in much the same way as the lamp and the hundreds of light bulbs, except that Spawn has thousands of possible lamps of all different shapes and sizes and thousands of different light bulbs of different colors. The light bulbs can move from lamp to lamp in masses as well.

Spawn's primary data, the lamp, can be any data type. This means that the data might be a unit, an item, an integer, or even a completely custom user defined type like a struct or a full blown system. It's primary data is called a Handle.

The next data type is called the Base. The base would be the lamp head with all the sockets on it for holding the light bulbs. Like a normal lamp, a handle can only have one base at a time.

The final data type is called the Spawn. The Spawn would be all the many light bulbs that fit into the lamp head. Just like that, Spawns get attached to Bases, but unlike the lamp head, bases can hold unlimited Spawns.

So, the relationship between the 3 objects are like this-
lamp <-> lamp head <-> light bulb
handle <-> base <-> spawn

lamps can touch the lamp head and the lamp head can touch the lamp.
The lamp head can touch the light bulb and the light bulb can tough the lamp head.
The light bulb cannot touch the lamp because the lamp head is in between them.

It's the same idea with handles, bases, and spawns.

So, like a light bulb can produce an effect, so can a spawn. Spawns, like the colors of the light bulbs, can produce any effect the user can imagine. Unlike the light bulbs, the effects can run whenever the user wants, whether it be off of a trigger event or a timer expiration. Like the light bulbs, the spawns can be turned on and off.

Everything that extends from a Spawn object inherits all of its traits, meaning that all things that extend from it automatically work with all the colors of the rainbow, or all possible data types.

So, where might Spawn be used?
Spawns might produce units for the handles that they are attached to in games like Footmen Wars.

Spawns might produce spells in spell systems

Spawns might produce attacks for specific items that are equipped on units.

Spawns might produce inventories when a player clicks an inventory button

Spawn allows for the ultimate in extensible and maintainable code as all types work and users can plug in whatever they like.

Spawn is split up into 3 parts that are not constructed for you. It's like a lamp being split into the moldings for lamps and bulbs. Spawn was made to create lamps and bulbs, or rather handles and spawns. It's the system designers duty to create the handles and spawns for Spawn to run. The user pieces together the handles and spawns created by the designer any way they want. Lamp heads, or bases, don't have to be constructed, but they can be (the mold is there for them to).

The objects that system designers will primarily be using are the SpawnObject and the Handle. Why don't system designers use a Spawn directly? So that the Spawn can change its type, or so that the light bulb can change its color.

The other 2 objects that weren't mentioned are the SpawnMethod and BaseMethod objects. They allow for custom methods to be inserted into spawns and bases to produce new and wild effects. Let's say you want to add a tint to your yellow light bulb.

 

[garion992]

can you explain to me what you did in the demo code? It's because i don't understand JASS very well (your system looks very usefull btw)

 

[Sevion]

OK, here's what it does in a nutshell:

He creates a spawn. [Peasants]

Creates a base (The object that spawns the whatevers) [Paladin]

Attatces the spawn to the base. (So the spawns spawn at the base)

 

[garion992]

So in the demo script he spawns a peasant at the paladin every 3 secs? and why won't you use a GUI timer trigger in this case? (I'm just being a critic, no offense)

 

[Sevion]

This is just a very basic demo.

Spawn can do a lot more. For example, creating a spell's projectiles at the caster then you can... I dunno... Do something with them ;o But you can do pretty much anything with this

 

[Larcenist]

So it's an utterly over-complicated spawning system?

 

[Nestharus]

It was designed to handle all data types including full systems. A simple spawning system cannot do that =). It also has various inject methods for custom method implementation and what not.

There's just a lot : ). I described it in the description : p.
Handles = anything
Spawns = anything

I just didn't want to type out a full system for a small demo ^_^.

The fact is you can run many things with the same lines of code : d.

More maintainable and extensible =).

And it's complexity lies from the fact that it can do all of this ^_^.

 

[Jesus4Lyf]

So it's an utterly over-complicated spawning system?

Which he spent a very long time making.

 

[Larcenist]

Seeing as it handles about everything, it's just as over-complicated but at least a little more useful. Then again, by the time you've learned how to use everything with this system, your map has been finished since long

 

[Sevion]

I don't really see how this is overcomplicted. In fact, I see it as the perfect solution to all spawning problems because you can use this for anything.

 

[quraji]

because you can use this for anything.

+graveyard vote if this doesn't spawn blueberry waffles.

Nesth, I suggest that if you want us to actually see the amazing properties this system has, you make a better demo than just spawning a unit. Because there's no way I'm putting this in a map just to spawn units. I'm also probably not going to actually read the code either (no offense...I'm too lazy to read snippet code usually..).

 

[Sevion]

There's a system he made ;O

It's pretty much SUPOT^SUPOT in like 30 lines.

It's in 3rd post I believe.

Perhaps someone will make more demos soon ;o

 

[quraji]

There's a system he made ;O

It's pretty much SUPOT^SUPOT in like 30 lines.

Not that I know what SUPOT is, but the system is actually 1072 lines (the Spawn system).

 

[Sevion]

The system built off of Spawn is only like 30 lines

 

[Nestharus]

What does my trade spawn demo demonstrate?
You can have multiple types in spawn and trade them all around very simply
You don't have to track spawns, and if you want to access all the spawns on a base and do something with them yourself, you can loop thru them using my loop tip.

Everyone says, I can hard code for the same effects, but can you really? My trade spawn demonstration showed that hard coding does not merit the same results in any way without you having to do a billion things, so why not let Spawn do it for you and save yourself the trouble... Spawn handles anything you want, so it's not like you can say I really need to handle this, and you can inject into it, so you can't really say I need to handle these extra things.

Also, Spawn can handle any type like I said, meaning you could spawn Bases which spawn additional spawns of the spawn. cloneSpawns will clone all spawns on a base and give them to a base.

There's really no comparison to, "hard code this" or "CreateUnit()" or w/e else people have come up with saying this is useless. The fact is Spawn tracks everything for you, automatically links up all your stuff with all the handle objects, and you can pretty much customize every aspect of Spawn without having to modify the system.

A final argument would be, if I need to spawn units, why not just use SUPOT... it's way easier.
What if you want to spawn units at a handle's coordinates... does SUPOT do that? I thought it took specific coords... so you'd have to update the coords every time. Does Spawn take specific coords? Yes, you can overwrite the coordinates in Spawn to be whatever you like.

But, I need to spawn units and just units. You know, there's a small snippet I made that does the exact same thing as SUPOT just as easily but gives you all the power of Spawn. It's 31 lines... it's called SU and it's in post 3. The only reason to use SU I suppose would be for very simple purposes, and then at that point, why would you even bother with a system. If you don't care about your maintainability or extensibility, then you should just hard code it -.-.

Spawn works for any given need, and systems that are built with Spawn like projectile systems will automatically inherit all of Spawns features and tracking like work on all types and lend, borrow, clone, mimic, etc.

My question is, if you are going to make a system or a map and you aren't planning on hard coding everything, then why shouldn't you use Spawn for all your data producing needs??

 

[Darthfett]

Nesth, I suggest that if you want us to actually see the amazing properties this system has, you make a better demo than just spawning a unit. Because there's no way I'm putting this in a map just to spawn units. I'm also probably not going to actually read the code either (no offense.

I have to agree with this. There's easier ways to create units, and a demo that doesn't show your systems capabilities really isn't a very good demo.

If you really want to intrigue people, you're going to have to say more than that your system is very abstract, and that it is very customizable. Instead, explain some very concrete examples of where your system is better than hardcoding, or why it is better/different than it's competitor, SUPOT.

I personally think it is going to take something closer to a demo MAP than simply a demo code to show us why we might use your system.

Have you thought about using spawn for Buffs? You could perhaps have a neat spellsteal ability that changes the 'base' (unit) of the buffs, so that Damage-Over-Time spells could have dynamic targets. Just an idea.