This is object oriented programing - oop. A lot of people that are just learning to code by using Quest may not be familiar with what that means. And concepts those of us that have been programing for a while take for granted might seem very confusing.
So, as a suggestion, you might want to do some research.
But here's a very simple explination of what we're doing here.
Assume you have a huge box. You call that box GAME. The box is an object and it has several features - length, height, width, color, material and so on.
But GAME isn't just an object, it can have babies. And when it has a baby box, the baby box inherits everything GAME has. That means, the baby starts out with having height, width, length, color, material. Just like mama box.
But you, the programmer don't want a second GAME box (object). So you change the baby boxe's name to ROOM. And you decide that ROOM needs some features mama box doesn't have - description. And you decide it doesn't need some stuff mama does have - color, height, width. So you tweak it a bit. Then you put the now unique object ROOM inside GAME.
Now you want more rooms. But you're lazy. All programmers are lazy. So you make copies of ROOM and you call them things like room1, airport, kitchen. They all inherit everything ROOM has, but sometimes you tweak them and make the more unique, and sometimes you just fill in the blanks - type in a description instead of leaving it blank.
And you put all the baby rooms inside ROOM, because ROOM is their parent.
Then you make a new copy of GAME, but you change it's name to EXIT, tweak it's features, explain to it how to move a player from one baby room to aother, stick it inside ROOM, then make copies of it, tweak the copies slightly, and stuff those baby exits inside the baby rooms.
Getting the idea?
This very clearly describes the confusion new OOP programmers have...
Even someone coming from a different programming style...
(I know Basic, I can do all the magic OOP can do... but differently...)
To me...
My program contains all the code for everything to work...
(like Game)
But, at least to me, it is like the objects run their own bits of code...
(like rooms and objects)
separate from Game...
But... with the help of the ones that have waded through the confusion first...
I'm sure the new ones can get started.
it is like the objects run their own bits of code
Yup, they can. They don't have to, but they can. And they usually do. What they can do is defined in various functions in the program. However GAME knows about every bit of code that exists in your game. It all becomes part of GAME. If you add a script to a room, it might only run in that room, and it might not be part of the master function library that comes with GAME, but GAME still knows about it. ROOM can't run that function unless GAME allows it to.
When you create a room, as an example, the game first looks at the master ROOM object and creates a clone of it for you. It gives you basic things all room objects logically have. But you, the programmer, can write scripts for that room, you can program code into that room which will run only when someone is in that room. This allows you the ability to make every room in your game unique if you choose to. You can make use of the functions it comes with (create exits) or not, as you choose.
Or, you can choose not to write extra scripts, just let the room object run the code that it inherited from ROOM. (the ability to move the player to another room when they type an exit for example).
It's the ultimate way to be lazy when programing. You create the first object (GAME) and give it lots of abilities. Then you create a new object (ROOM) but rather than writing the abilities you want ROOM to have, you just point to (GAME) and say "use this, and that, and that, and... that one. Don't use any of the others." And then every room you make, gets all of the code that ROOM has, and you can go merrily about creating hundreds of rooms just by typing create room, without having to code the ability to move through an exit, or display the description, for every single one of those hundreds of rooms.
Kinda like you had the ultimate soda machine. It has one bottle of SODA in it, with every ingredient you'd need to make every soda in the world all swirling around inside it. When you want a Sprite, it makes a bottle shaped object, changes the color to green, slaps a lable on it that says Sprite. Then it looks at the liquid inside that one bottle of SODA, picks out just the ingredients that make Sprite, and fills the bottle shaped object it made you with them, and hands you a sprite.
OOP/OOD (Object-Oriented Programming / Object-Oriented Design) is a much larger field than just Inheritance/parent-child/containment heirarchy, as there's Data Structures/Management, and whatever else advance stuff I've yet to learn, lol.
Inheritance/parent-child/containment heirarchy isn't that common knowledge for most people to actually use/apply, especially in programming, (even though it's used everywhere and in/with everything in the real world), and while most can understand the concept, implementing it especially programming-wise, isn't simple. Programmers take this stuff for granted, but it takes a long time to get used to and good at doing Inheritance/parent-child/containment heirarchy (at least complex designs, anyways) and training the brain in this mindset/approach of 'top to down' designing, especially the Absract design aspects involved.
the base of Inheritance/parent-child/containment heirarchy, is the concept of 'encapsulation' of OOP/OOD. Basically, encapsulation is the 'physical (conceptually)' manifestation (an 'instantiated OBJECT') of the theoretical/imagined/concept groups (CLASSES), as both the CLASSES and their OBJECTS contain their own Attributes (data and/or actions) within themselves (kinda like being "self-sufficient" --- they have everything that they are and/or need code wise --- you're not jumping all over your entire code looking for the code associated with them). Inheritance/parent-child/containment heirarchy is having GROUPS/CLASSES/OBJECTS (of GROUPS/CLASSES/OBJECTS) of Attributes (data and/or actions).
any thing and every thing you can think of within the real world is a GROUP/CLASS/OBJECT!
think of whatever you want in the real world, and see if you can list anything for it of the #1-4
an example of OBJECTS/GROUPS/CLASSES of OBJECTS/GROUPS/CLASSES (inheritance/parent-child/containment heirarchy):
shape
shape -> 3D
shape -> 3D -> sphere
shape -> 3D -> sphere -> ball
shape -> 3D -> sphere -> ball -> soccer ball
shape -> 3D -> sphere -> ball -> baseball ball
shape -> 3D -> sphere -> ball -> basketball ball
shape -> 3D -> sphere -> ball -> tennis ball
shape -> 3D -> sphere -> ball -> plastic toy ball
shape -> 3D -> sphere -> ball -> super/rubber toy ball
try to list what you can for #1-4, for each of the GROUPS/CLASSES/OBJECTS (shape, 3D, sphere, ball, soccer ball, baseball ball, tennis ball, basket ball, plastic toy ball, super/rubber toy ball)
extended:
shape
shape -> 2D
shape -> 2D -> round (?ellipse?)
shape -> 2D -> round (?ellipse?) -> circle (perfect: static radius)
shape -> 2D -> round (?ellipse?) -> oval (not perfect: dynamic radius)
shape -> 2D -> triangle
shape -> 2D -> triangle -> equilateral
shape -> 2D -> triangle -> scalene
shape -> 2D -> triangle -> right
shape -> 2D -> rectangle
shape -> 2D -> rectangle -> square
shape -> 3D
shape -> 3D -> sphere
shape -> 3D -> sphere -> ball
shape -> 3D -> sphere -> ball -> soccer ball
shape -> 3D -> sphere -> ball -> baseball ball
shape -> 3D -> sphere -> ball -> basketball ball
shape -> 3D -> sphere -> ball -> tennis ball
shape -> 3D -> sphere -> ball -> plastic toy ball
shape -> 3D -> sphere -> ball -> super/rubber toy ball
shape -> 3D -> cylinder
shape -> 3D -> rectangular prism
shape -> 3D -> rectangular prism -> cube
etc etc etc
let's just look at the game maker level of OOP/OOD (getting into quest itself's OOP/OOD is a much more advanced/difficult concept for non-programmers), some examples:
// too much work to fill in all the Attributes (data/actions) for them and to work out the entire design systems... lol, but hopefully you get the idea from it!
<type name="character_type">
<attr name="life" type="string">1/1</attr>
<attr name="current_lifee" type="int">1</attr>
<attr name="maximum_life" type="int">1</attr>
<attr name="life" type="string">0/0</attr>
<attr name="current_mana" type="int">0</attr>
<attr name="maximum_mana" type="int">0</attr>
<attr name="level" type="int">0</attr>
<attr name="experience" type="int">0</attr>
<attr name="cash" type="int">0</attr>
<attr name="strength" type="int">0</attr>
<attr name="endurance" type="int">0</attr>
<attr name="condition" type="string">normal</attr>
</type>
// "pcs" (can join you as party/team members):
<type name="playable_character_type">
<inherit name="character_type" />
<attr name="statusattributes" type="simplestringdictionary">life = Life: !; level = Level: !; cash = Cash: !; strength = Strength: !; endurance = Endurance: !; condition = Condition: !</attr>
</type>
// can NOT join you as party/team members:
<type name="nonplayable_character_type">
<inherit name="character_type" />
</type>
// "monster/animal/creature":
<type name="nonsentient_type">
</type>
// "npc/townsfolk":
<type name="sentient_type">
</type>
<type name="base_item_type">
<attr name="type" type="string">unknown</attr>
</type>
<type name="item_type">
<inherit name="base_item_type" />
<attr name="quantity" type="int">0</attr>
<attr name="weight" type="int">0</attr>
<attr name="volume" type="int">0</attr>
<attr name="take" type="script">
</attr>
<attr name="drop" type="script">
</attr>
<attr name="store" type="script">
</attr>
<attr name="destore" type="script">
</attr>
</type>
<type name="usable_item_type">
<inherit name="item_type" />
<attr name="use" type="script">
</attr>
</type>
<type name="nonusable_item_type">
<inherit name="base_item_type" />
<attr name="take" type="script">
</attr>
</type>
<type name="equipment_type">
<inherit name="item_type" />
<attr name="equip" type="script">
</attr>
<attr name="unequip" type="script">
</attr>
</type>
<type name="weapon_type">
<inherit name="equipment_type" />
<attr name="speed" type="int">0</attr>
<attr name="range" type="int">0</attr>
<attr name="damage" type="int">0</attr>
</type>
<type name="armor_type">
<inherit name="equipment_type" />
<attr name="defense" type="int">0</attr>
</type>
<type name="clothing_type">
<inherit name="equipment_type" />
</type>
<type name="one_handed_type">
</type>
<type name="two_handed_type">
</type>
<type name="nonprojectile_type">
</type>
<type name="projectile_type">
</type>
<type name="sword_type">
<inherit name="weapon_type" />
<inherit name="nonprojectile_type" />
</type>
<type name="katana_type">
<inherit name="sword_type" />
</type>
<type name="claymore_type">
<inherit name="sword_type" />
<inherit name="two_handed_type" />
</type>
<object name="flaming_claymore">
<inherit name="claymore_type" />
<inherit name="fire_type" />
</object>
<type name="axe_type">
<inherit name="weapon_type" />
</type>
<type name="spell_type">
</type>
<type name="healing_type">
<inherit name="spell_type" />
</type>
<type name="curing_type">
<inherit name="spell_type" />
</type>
<type name="offensive_type">
<inherit name="spell_type" />
</type>
<type name="defensive_type">
<inherit name="spell_type" />
</type>
<type name="support_type">
<inherit name="spell_type" />
</type>
<type name="fire_type">
</type>
<object name="fireball">
<inherit name="offensive_type" />
<inherit name="fire_type" />
</object>
<type name="water_type">
</type>
<type name="shop_type">
<attr name="buy" type="script">
</attr>
<attr name="sell" type="script">
</attr>
</type>
for a small/simple game, this is a lot of work than is needed, but for a large/complex game, this actually reduces the amount of work greatly (it's scalable).
Follow us on Facebook
Follow @TextAdv on Twitter