Hello everyone, once again another little visit and break from my programming.
Im wondering how you created obj.
is it a class?
having troubles with my game design in other languages, and trying to soak up as much information as i can. also trying to make it easier for me so i can create new instances of game items using classes as templates. im just wondering how you did your obj.
btw, i know its written in C++, but in programming, its almost all the same.
thanks,
FIREking
ps. sorry if this is the wrong forum, its been a long time.
ID:137488
Nov 7 2001, 5:37 pm
|
|
In response to Dan
|
|
a data structure?
then how the hell did you do variables as in (vars)? maybe VB is limiting, but i cant figure out how to make variables inside variables. im sure ill get it sometime soon, hopefully. another thing im wondering is how the inventory(contents) was done, because im having the hardest time doing that as well. thanks, FIREking |
In response to FIREking
|
|
FIREking wrote:
a data structure? A data structure is a set of data arranged in a specific pattern. An array is a simple data structure that just linearly stores data one piece after another. But I'm sure BYOND uses some sort of tree structure where each node is a part of the tree like the datum. The node would probably contain some kind of ID(probably the name), an array or some other datastructure containing all of the predefined and user defined variables, an array containing procs/verbs which the object has access to, and links to all the nodes which are inherited from this class. The variable list segment of the tree node would contain an ID, data type, and a pointer to the actual data. The proc/verbs part of the tree node would have an ID and a pointer to the location in the dmb where the proc starts. It would have some other information too in there for parameters but I don't feel like guessing how that works(provided I'm even right up to this point). Even if I'm even close to being right about this, Dantom probably has made it much more complex for the sake of optimization and minimizing data transfer. |
In response to Theodis
|
|
Even if I'm even close to being right about this, Dantom probably has made it much more complex for the sake of optimization and minimizing data transfer. I think references are referred to by ID number, but that's at run-time. Objects at compile-time I'm not too sure about, but it's probably similar. |
In response to Theodis
|
|
In actual fact, all run-time objects are stored in special memory chips in your mouse! We thought we'd take advantage of this underutilized system resource. If you unplug your mouse, it has to quickly download all of the data and copy it into the dynamic rotational memory cells in the system fan, another lesser-known system resource that we like to take advantage of. Otherwise, your guesses about the implementation are right on. --Dan |
In response to Dan
|
|
Dan wrote:
In actual fact, all run-time objects are stored in special memory chips in your mouse! We thought we'd take advantage of this underutilized system resource. If you unplug your mouse, it has to quickly download all of the data and copy it into the dynamic rotational memory cells in the system fan, another lesser-known system resource that we like to take advantage of. Eep my laptop has no mouse, so hopefully if it breaks again those dumb repair people remember to reconnect the fan this time! |
In response to Dan
|
|
Dan wrote:
In actual fact, all run-time objects are stored in special memory chips in your mouse! We thought we'd take advantage of this underutilized system resource. If you unplug your mouse, it has to quickly download all of the data and copy it into the dynamic rotational memory cells in the system fan, another lesser-known system resource that we like to take advantage of. I wrote a program once that stored important variables in a bag of Cheetos that was near my monitor. Surprisingly enough, this turns out to be a bad idea. I found that out when I keep running out of resources. |
It's just a plain old C data structure. Implementation of inheritance in DM does not depend on any sort of inheritance provided by the programming language in which it happens to be written (C++).
So basically, the only interesting thing about DM objects from a programming point of view is DM itself. The internal implementation is just the same nuts and bolts you would find in any modern program.
--Dan