Droid Engineer Archive

I'm curious about the work effort involved in making the changes we want to see in droids.

I'm wondering if this is more complicated than we imagine because the Devs used the same or duplicated subroutines for a single "pet" system that they figured would work for both Droids and Creatures - an obvious "let's save some$ and re-use as much code as possible" manouver.

The similarities between storage and training are undeniable so I'm assuming that this is the case.

So now I'm curious as to whether they duplicated the "pet" subroutines over (making for easier individual tweaks/bugfixes/etc to the systems for each easier) or whether it's only one set of "pet" subroutines where a check is done and droid pets are flagged differently than creature pets (much bigger mess when trying to fix/add things for one class of pets vs another).

I wasn't around for Beta so I don't have knowledge of just how similar/close the droid/ch systems were in the early stages and how much each has customized out over time.

Knowing this might help gain some appreciation for how long we can expect changes to take and how buggy things may get overtime with customization and changes along each different "pet" type (droid vs. creature).

IMHO I don't think they should have used the same subroutines at all since I don't consider droids a "pet" but whatever we are in the situation we are in (*sigh*)

A more accurate and modern way of describing this would be to say that its likely that CH Pets and Droids are both forms of the same "class". Modern programming is generally whats called object-oriented programming, meaning that every element of information in the program is treated as an "object" which has specific methods that can act on it, specific values associated with it etc. Classes can be extensions of other classes, meaning the extended one can have additional methods and values that are not present in the "base" or original class that they extend. I won't bother going into more detail than that

So, we most likely have a "pet" class, with specific programmed details (like what menu entries can show up and under what cirumstances etc, although those are more likely part of a menu class that is independant of the pet class). Pets will have attributes like Health, Action, Mind etc that have methods that allow those attributes to be increased, decreased etc.

Now the class thing is a generic object. Each actuall object in the game, each pet, will be an "instatiation" of that class - an object that is defined as having the characteristics of that class. So when i make a droid in game, a new instatiation of the droid class is created and will persist until something occurs to destroy it. Its not the class itself, but rather an object made from that class definition.

Now, as I said, classes can be based on other classes. I suspect that the Droid class (such as it may be) is an extension of the generic Pet class. IF this is so, then it shares all the characteristics of the pet class, and may have some additional ones added on. Essentiallyl this means that a change to pets will affect a change in droids, but a change in the droids class will not affect pets.

If this is true its actually bad coding in my opinion because of the link between the two things Pets (living) and Droids (mechanical) which while they may behave in the game the same way are not the same thing conceptually to me at least. Now, if they were smarter than I am supposing (based only on my own suppositions) - and they are professional programmers so they are probably smarter than I am speculating here - there is the generic pet class alright, but it only defines the very basic pet object, and animal pets would be an extension of that pet class in one direction, droids in another, faction pets in yet another etc. That is the way it would certainly have been the smartest to approach this. it is probably what they did.

However i keep getting the impression that making changesto CH Pets somehow impactsdroids which is kind of odd. That might imply Droids are an extension of CH Pets rather than a more basic "pet" class. If so, bad design, if not then curious...

The point of classes and object-oriented programming is simply to make the reuse of code more prevalent, make for stronger code (because the same thing is not programmed in several locations but rather once then reused where needed). There is no other way to effectively program something this size at this time - at least that I know of. Its very bad design to simply make a copy of a class and change its name by this reasoning - if they did that then again bad design, although it would allow them greater freedom in making CH pets and Droids operate differently.

It does seem to me that they spend far more time working on CH pets than they do on Droid pets at the very least. Changes to droids seem willynillly, made without any clear thought or design. If we see a change to something that is clearly an animal-only facet of pets than then impact droids in a direct way, we can assume the design is bad. As it is, its more likely that they have defined many aspects of pets in the generic Pet class that should have been defined in the extended Animalpetsand Droid classes. Now it may be too late to redo it. This would explain why you have to teach a droid its name, rather than simply tell it - the method for learning names is defined in the generic pet class and at ahigher level in the AnimalPet and Droid classes - which could then have different methods of learning a name (teaching for Animalpets and simply assigning one for Droids). It seems possible that no method for relearning a new name has been implemented, so once your pet learns its name, thats it, it won't ever change - because a method for learning has been written that assigns that name value to the pet object, but no method for changing or updating that name has been implemented so its simply not possible (at least I can't make it happen and have read of others who said the same).

There enough geekspeak to fill most anyone's day

This is somthing I had pondered about as well ..

And it makes sense that they would use a pet class to define all pet objects... However, the behaviour and functionality between driods and creatures is very differant.. But its not imposible to to add additional functions to the droid sub-class, the code is there it just needs to implemented... Which is why I say the driods are not finished, and tossing them into the creature pet class (ok another droid sub-class that has limited functionality)was the easiest fix given teh time constraints.

Yeah, and there is lot more I didn't mention to all this of course. You can "override" methods and things like that, so its possible to correct aspects of an extended class if their methods are wonky seeming, but it makes it seem to me like the defined a base pet class, then made the CH pets class that extends it, then developed pets further making changes to both classes as required. Once they had the basic design down, they then created the new pet classes like Droid, but because the design was based on the CH pets and shaped around that design, some aspects of the newly extended Droid class make them act more like CH pets.

A test of this might be to check the only other mechanical like class that I can think of and that is the ATST pets. Do they have any characteristics to them that really seem more "living pet" oriented? I doubt you can teach them a name or anything obvious but is there another aspect of them that might indicate they were made later (and that the base class they were designed on hadn't really taken their future existance into consideration when it was created)?

True - and probably pointless - speculation of course. I am not that much of an object-oriented programmer myself - although probably more than most here at a guess. Perhaps someone more knowledgable will speak up

---

Sneev wrote:

A more accurate and modern way of describing this would be to say that its likely that CH Pets and Droids are both forms of the same "class". Modern programming is generally whats called object-oriented programming, meaning that every element of information in the program is treated as an "object" which has specific methods that can act on it, specific values associated with it etc.

---

Thanks Sneev!

Uh-oh guess my gray hairs are showing... been a long long time since I coded anything (*blush*). OOP was just coming in when I stopped sticking my hands into it. I recall some basics (thanks for the reminder) but obviously strayed back in time when formulating the question. LOL.

Some great thoughts there.

Yah I definately get the impression that droids are an extension (sub-class) ofcreature pet, not an extension(sub-class) of a larger more generic"pet" class.

There are certainly large hints that the creature class was finished first, then the droid extension added later and modified somewhat.

yeah, what sneev said

I was wondering though, about the concept of the "base pet" class. It would seem to me, being a DE and having a nonCH pet as well, that perhaps there is a basic pet class, animal pet class, and mechanical pet class, but some important distinctions that would separate them weren't separated. Example being, naming droids and naming pets. perhaps the intention was that to save some time and trouble they bundled the naming mechanism into the basic class, instead of making different naming sequences for the different pets. That being my suspicion, I have to wonder how many entity-defining characteristics have been made standard for all pets instead of being different for different kinds of pets.

Perhaps that also has to do with why our droids all do pretty much the same thing. since you'd need to have a basic pet class, a mechanical class, then subclasses of that: medical droid, combat droid, item storage droid, repair droid, etc. Using the modules to define the droid asopposed to the droids defining themselves would have been a huge timesaver in the code department. That way, all droids behave the same, and you simply call up whatever module routine you need for the droid in question to perform a task. Efficient, but pretty lame.

Anyway, thinking about this is about to make my head explode, so I'll stop now

Problem is, they got a lot of the attributes and methods mixed up between the Droid and Creature classes. Examples are:

m_iMinHealth
m_iMaxHealth
m_iMinDamage
m_iMaxDamage
m_iNumPetsAllowedInStorage
m_iNumPetsAllowedInWorld
m_HealPet()