Response to Gigantic Do It All System

[Nestharus]

Actually, i was going to say something else, but I saying what I did was more fun ^_^.


Now for the real message ; ).

Developing an interface for a large system that can handle all relationships and all types is very difficult, and when you develop it about the only way to develop it is by taking the same kind of approach Lisp took, that is, making people define all of their types.

For example, in Spawn you had to define every single object. It had no objects of its own, everything was abstract. In this way, you could handle pseudo dynamic memory, or memory of any type of any size. This code could have pseudo dynamic relationships, or relationships of any type of any size.

What this means is that you can create your own objects and plug them into this arching framework and have it work, and from there you can generate anything with it at any point, whether you are writing it out or doing it during gameplay ^_^.


That is about the only way I could figure out to create a system like that. Maybe we could start a contest to design one of these huge systems for use in Speed Maps = ).


Maybe the categories should be-
Flexibility (where it can be used, hopefully everywhere)

Maintainability (does code written with it have to be change when types or relationships change, or not? Do you have to write new code for different types/relationships, or can you use the same piece of code for all of it)

Production Speed (how fast you can use it)

Learning Curve (interface)

The required features and the categories should be discussed before finalizing anything, but the resource that is produced from the contest would be really beneficial for speed maps and it'd allow people to get more rep if they want it or w/e ; o.


So, my reasoning for why these huge systems can't really be used in actual maps should be pretty apparent ^_^. All of the trigger evaluations involved between types, the linked lists between all the relationships (all hashtable linked lists btw), and all the extra operations involved with each function (let's say your framework does archiving of relationship changes like mine did?) just bogs everything down ; ). If you really need all of that (your map better have 100+ types and use every feature as well as have 100% dynamic changing types in-game), then the system is actually useful o-o.


This actually brings me to something I've been pondering for awhile ; ). Humans traditionally react slower than animals do. The reason is instinct. As a trade off, humans can respond to any given situation whereas animals can only respond in a number of ways. Sometimes, animals also respond more slowly, that is when they stop to think about it.

Instinct comes from the programming within our bodies. Hardcore programming in our bodies reacts instantly to a given situation. When we do a given task over and over again, or when we inherit something from genetics, those tasks become easy for our bodies and we don't even have to think about those tasks to accomplish them. The keyword here is think, for when we start using our mind, that is the thing that allows us to respond dynamically to any given situation, we have to process it. Typed data is always faster than untyped data. Our mind has to go through loads of conditions and reasoning and so on to finally get to the problem at hand (identify the problem), and then has to solve the problem. This is the reason why fighters try to build up their instincts or w/e for matches because programming the body (while it may be time consuming and hard) results in instant reaction time (you could pretty much have your eyes closed and mind blank and your body would respond).

In fact, many animals don't have the capacity for reasoning and what not as they really don't need it. Their bodies compensate for what they don't have. It's like making a good program, that is, making something for a specific situation. Look at humans, sort of a jack of all trades. As a result, we are slower ; ). What about our reasoning? Isn't that fast? Not really. Look at computers, they handle specific types so they are much faster. We have loads of extra operations that we have to constantly handle, so it just bogs everything down. Perfect in that it can handle any situation, but imperfect as it can't handle any situation perfectly. However, we can make up for that by programming our bodies forcefully ;p. We can also meditate to increase concentration, thus relieving some of the processing so we can allocate it to the given situation ; ).


So, let's move on.

Perhaps the task at hand is to script something that is very similar to how humans are in their environment. Yes, it'll be much slower, but it'll handle any situation. I hope my speech can help people to understand why these systems can't be used for regular map making (that is to the person who still says it's usable). I also hope they know where I got my estimate speed differences from = ). This idea would only be for speed mapping.

Now, if people are interested, don't forget that i do have design diagrams for a system like this from back when I was working with this stuff. I also have a lot of code that handles stuff like this. Now, I personally don't enjoy speed maps, but I find the idea of quickly making little mini-games and what not for fun intriguing, and then taking some of those maps and really making them something special. It's like, hey, I want to play a new game today, work 30 minutes on it and it's done ;o.


Any thoughts on my big speech up there? : P

1. Thoughts on such a script
2. Thoughts on what the interface might be like
3. Thoughts on the idea of a contest to develop this (sort of like developing the wiper blades for a car)

 

[Jesus4Lyf]

>Any thoughts on my big speech up there? : P
It has a terrible interface, so I didn't bother reading it.
Too long.

Edit: Finished the BETA for my do everything sys.

 

[Nestharus]

I wouldn't exactly call that a do everything sys, rather a spell system that can handle all spells ; ).

 

[Jesus4Lyf]

I wouldn't exactly call that a do everything sys, rather a spell system that can handle all spells ; ).

It does unit attachment and event handling, with heavy interfacing to simulate polymorphic properties. It randomly does AoE stuff just for kicks.
(Well, that is part of the scope of making spells... but doesn't totally belong. )

 

[Nestharus]

Actually, I was pondering some more on these larger systems with generic data types and I remembered some stuff I used to do-

Unit unit = Unit.create(player, type, x, y, z, facing)
Item item = Item.morph(unit, type)

Now on morph, unit would actually be emptied and put into item

You could also put them into generic types instead-

Data data= Unit.create(...)
prinf(R2S(data.x)) //gets unit x in the background
data = Item.morph(unit, type)
prinf(R2S(data.x)) //gets item x in the background

Through a clever use of interface delegates (getters/setters), generic typed data is achieved.


This is actually sort of what I was debating on and what my old Spawn specialized in, lol. Actually, it had to specialize in this because all of its handling was with untyped data : o.


Now, the extra stuff (deep clone, mimic, attach objects) is what made my old Spawn so big ><. All that extra stuff enabled it to be used in any environment (like a huge linked list of linked lists that stores all of its stuff in the background).

Setting something like this up would be a serious pain, but once it's set up, it'd actually low dev time because all of the methods (that are needed for the map) are global to each type ><.

But again, the vJASS evaluations kill it, and there are very few cases where something like this would actually be useful in my opinion, lol. I mean, it would be useful for faster dev time (if you already know it or have it set up), but ><.

Spawn also worked off of 3 tiers. Tier 1 was the objects (first code I showed).

The other tiers were like attachments. The middle tier did operations for the lower tier. The low tier was like objects that are produced.

So it went-
Game Interface Object (unit or w/e)
Code Interface Object (middle, handles all memory of all types ><)
Production Objects (spawns)

But yea.. while it worked, all of that ambiguity killed it o-o.

That's kind of why I started this thread in the first place, because I was saying systems of that nature can't really be done : ).

When I looked at your system jesus4lyf, I didn't quite understand how it was a do all system as it seemed to handle spells more.


Also, when I was looking at it, I didn't really see any way to link spells together easily (through the system).


I mean, yea it's good as it runs nice effects for spells, and you can register different things or w/e for the spells to run, but you can't easily move spells between types or w/e ><. Also, you can't easily do production of spells, you leave a lot of that up to the user, which lends makes it more efficient obviously, but takes away from ease of use ; ).

One thing I worked for was OOP on even the equations, lol. I would pass in the x, y coords and all the person would have to do was CreateUnit or w/e the type they did.


I just don't know if there is any really good way to doing this ;\.

 

[Jesus4Lyf]

> didn't really see any way to link spells together easily (through the system).
I'd like you to explain what that means and where it is practical...

>When I looked at your system jesus4lyf, I didn't quite understand how it was a do all system as it seemed to handle spells more.
It's a do-everything system for spell crafting. But take a look again, and you'll see some very neat timer/trigger attachment features with a minuscule interface. It does attaching to timers and triggers and if you call destroy on the struct, it pauses all timers, frees them using TimerUtils or Recycle, destroys all triggers, (but safe to the double free bug with waits), and flushes all data attachment stuff.

 

[Nestharus]

True that

I guess when I look at it, in the background, that's what Spawn was capable of too, I just had 3 layers, lol ; )

It allowed you to run through triggers/events/timers ; D


Now here's a thought, why not split it into different layers for dif types that way we can build dif frameworks that specialize in dif things and use those ambiguous types from the base ; O.

 

[tooltiperror]

Key Timers 2|AIDS|Event|Damage|T32|GTrigger|MoveSpeedX|AgentStats|Expert Spellcrafting Tutorial|Leakless Groups Tutorial|SpellStruct

I think that there will be a do-it-all system within a few years.

 

[Jesus4Lyf]

>I think that there will be a do-it-all system within a few years.
I like modularity.
But SpellStruct loosely covers the abilities of: KT2, AIDS, GTrigger, Leakless Groups.
And goes very nicely with T32, Damage, MoveSpeedX.

 

[kingkingyyk3]

>I think that there will be a do-it-all system within a few years.
The script will as long as Vex's caster system.