Nestharus
o-o
- Reaction score
- 84
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)
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)