Menu
▾
▴
[Xenocide-programming] Fwd: RE: Xenocide
|
From: <red...@pr...> - 2003-11-08 16:36:52
|
Third email...
----- Forwarded message from mamutas <ma...@pr...> -----
Date: Sun, 2 Nov 2003 21:40:11 -0600
From: mamutas <ma...@pr...>
Reply-To: mamutas <ma...@pr...>
Subject: RE: Xenocide
To: red...@pr...
Hi guys,
See my comments inserted below.
Regards,
Vlad
> -----Original Message-----
> From: red...@pr...
> [mailto:red...@pr...]
> Sent: Thursday, October 30, 2003 5:50 PM
> To: ma...@pr...
> Cc: ex...@li...
> Subject: Xenocide
>
>
>
> Hi Vlad,
>
> >>Do you think I will not recognize you if you will send email from
> >>another address to me? LOL!
>
> I didnt remember if I had already send you a mail from my
> other account, I am
> receiving like 50 spam mails per day so I am sure that
> sometimes I delete
> important mails because of it (Computer Games writer came to my mind).
:) The email had your name written all other it. I really doubt I know
another Federico Louis.
>
> >>I have reviewed the archives you sent to me and my comments
> are below.
> >>I also attached the very first implemetation of UI
> framework together
> >>with its project file, so you can compile it if you will. Please
> >>review it and send to me your comments. Then, I will post it to the
> >>list as well. Pay attention to hierarchy, class and package names,
> >>please.
>
>
> >>I pretty much guessed your hierarcy, but my 'ui' directory is
> >>immediately under 'xenocide' where you have it under
> >>'xenocide/client'. I guess you are thinking to have more
> than just UI
> >>there, like network communication for example. I can move 'ui'
> >>directory under the 'client' and adjust package names to include
> >>Client in there too.
> You guess it almost flawlessly, I had separated client
> because we already have
> a server directory, so a client one was the better approach
> to get something
> uniform.
Ok. So I update my UI implementation by adding a Client directory and
namespace there. Oh, I just noticed that you already did that for me. :)
Thanks!
>
>
> >>Datainterfaces and its subdirectories.
> >>I notice that namespace for all interfaces is
> Xenocide::Interfaces. It
> >>could be fine not to separate them by behavior or object,
> but I think
> >>we should make a namespace Xenocide::DataInterfaces to distinguish
> >>from other
> >>(network???) kind.
> Noted and modified I think that is a very interesting idea to
> separate them,
> from other type of interfaces.
>
>
> >>Content of datainterfaces\behavior.
> >>I don't think that behavioral interfaces should have any
> data members.
> >>For example, size is not a property for IStorable object. All data
> >>attributes must belong to Object-kind interfaces. Also, I
> am not sure
> >>whether there should be any productID members, as these are
> attributes
> >>of object, but not behavior.
> About behaivioral interfaces (in general, IStorable
> excluded), I dont see a
> reason to impose that big constrain on behaivioral
> interfaces, cause most of
> the times you can use certain data methods to define the
> semantics of the
> class. That is something that you cant do in Java, Eiffel
> have the best method
> to do it via assertions, preconditions, postconditions and
> class invariants.
Java uses abstract classes for that. There is an interface usually, which
defines methods, but if your class mostly needs base functionality of it,
there is an abstract class made of the interface, which has either very
basic implementation or empty methods.
So, I think similar approach will work for us as well, but we do not need to
have interface and abstract class separately, but can combine them. My
concern is that if interface defines a behaviour, it should be stateles,
i.e. no member variables. But that is theory, in reality we could deviate
from it.
> C++ do not offer that kind of facilities, so partial
> implementation via
> C++ static
> methods calling virtual internal methods is the less invasive
> approach (You can
> see the NetworkLib's Connection object for an example) to fix
> the semantics.
> However for that approach to work you still need the data
> members defined. About the IStorable object, it is an old
> interface (I made it even before Alpha
> 1) I had just retrofited it and didnt revisited it (yet) I
> wanted to know
> exactly what you think about it. My reason at the time was to
Well, now you know what I think about it. ;)
> define a simple
> interface for every storable object. If you have to look for
> certain object you
> need its ID or something to know what it is. Because that
I agree, but that ID should not be a member variable of Istorable. There
should be method getID(), but ID must be stored in the implementor. The
reason is that some other interfaces must have getID() methods, but all of
such method would return an ID stored in the implementor class itself.
> interface was
> supposed to be the first in the inheritance tree for objects.
> Maybe a solution
> could be to put it a better name and move it to objects directory.
No, I think name and its location is fine.
>
> >>IStore is not a behaviour, but rather ability. It probably
> should be
> >>put in separate directory, where other similar interface would go
> >>(ILabaratory, IWorkshop perhaps).
> I like the idea of separating between
> objects/abilities/behaivior, and
> definitly IStore is an ability. You can store products or you
> dont. Better name
> for it or is it OK???
How about IStorer? It is a noun which describes the profession sort of. So,
labs would have IResearcher, workshops - IManufacturer, etc. Huh?
>
> >>Next, I do not think that interface should inherit from
> each other. In
> >>your example, IWearable is a child of IStorable. Again,
> interfaces in
> >>this case describe behavior. Thing, you can wear is not necessarily
> >>could be stored (although, it is not true in UFO probably). The
> >>implementing object must inherit from both interfaces if it exposes
> >>behavior of both.
> Certainly we will need to find a better name for the
> IStorable case or a better
> class hierarchy... About the inheritance with interfaces, I
> do not see any
> reason why we couldnt describe similar (or extended)
> behaiviors with interface
> inheritance... For instance you can do it in Java too, and if
> we keep the same
> kind of style like NEVER mix interface inheritance with
> implementation
> inheritance there shouldnt be any problem.
>
> I can think of a very interesting example... For instance in
> UFO you have
> Elerium, Laser Pistols, etc. All of them can be stored in a
> Storage room, be it
> an Aircraft, General Stores, etc. And for instance some of
> them can be STORED
> in the players backpacks. But to avoid the common pitfall of
> UFO (have a lot of
> useless items when arming your soldiers in a base attack),
> you create a sub
> interface that is descendant from the one that define
> storable objects that can
> be carriable by the soldier (the most correct solution). If
> not you can have
> non storable objects that can be carriable, something that is
> absurd in every
> simulation game.
>
I said 'should', not 'must'. I agree that there could be situation where we
want it, but I don't like it about IStorable and IWearable.
As for your example, there are object in UFO game which are carriable, but
not storable. Those are corpses of Xcom units. ;P
Looking forward we might have some missions (like those in WC3) where pieces
of some certain item needs to be gathered from different places. But, that
is absolutely out of V1 scope. It just a thought.
> >>IAircraft seemed OK to me. I only want to suggest to add
> another set
> >>of methods to get/receive the number of HWP the aircraft
> can carry, as
> >>those are different from units.
> Yes you are right, but we will have to think how to
> accomplish that cause the
> more I think about transport aircraft the most I think the
> interface is not
> quite right, for instance how do you check you have enough
> space. Do we impose
> a limit on HWP carry or we use the weight/size/units space
> combination? There
> are lots of important interface decitions to make there that
> are quite gameplay
> oriented. What do you think?
For that example, I think that canCarry() method could be very complex, but
I do not think we need that. I imagine aircraft are powerful enough to lift
off even if they are stuffed with the most heaviest items. So, I would just
take item/unit sizes and the empty space in the craft. Basically, exactly as
UFO had.
>
>
> >>As for the Soldier issue you mentioned there, then
> >>I am not quite sure about the problem. Could you explain it further?
>
> Soldier inheritance tree originally was like this:
>
> Personnel was the base X-Corp class
> Soldier inherits from Personnel
> Scientist inherits from Personnel
> Engenieer inherits from Personnel
>
> However if we want the aircraft to be used by both Aliens and
> Humans then we
> must modify the inheritance tree and find a new better
> abstraction. That's why
> I took it out from the code I sent you.
Your example is about aircrafts, but inheritance is about personnel? Still
did not get it. Sorry.
>
> >>IWeapon. I think that there is very little difference between
> >>isValidWeaponAmmunition() and acceptAmmunition() methods. Do you?
> There is a very subtle but important difference between them,
> If I would have
> implemented the class you would have seen it without a problem.
> isValidWeaponAmmunition() is an static linked method (note,
> not dynamic) that
> states the semantics of the validation method, which means
> make sure that the
> ammunition clip is valid for the weapon. On the other side,
> acceptAmmunition is
> the only method you override to cause the
> isValidWeaponAmmunition know of
> subclasses, and with the added value that you have the check
> needed to for the
> loadAmmunitionClip method too. It is exactly the same as the
> internalMethods
> from the NetworkLib connection.
>
> --------- (SORT OF) ACTUAL CODE ----------
>
> class HeavyPlasma
> {
>
> protected:
> virtual Bool acceptAmmunition (IAmmunitionClip* ammunition)
> {
> if (dynamic_cast<HeavyPlasmaClip*> (ammunition) != NULL)
> return true;
> else
> return false;
> };
> };
>
>
> class RocketLauncher
> {
>
> protected:
> virtual Bool acceptAmmunition (IAmmunitionClip* ammunition)
> {
>
> if (dynamic_cast<SmallRocket*> (ammunition) != NULL)
> return true;
> else if (dynamic_cast<LargeRocket*> (ammunition) != NULL)
> return true;
> else if (dynamic_cast<IncendiaryRocket*> (ammunition) != NULL)
> return true;
> else
> return false;
> };
> }
>
> OR
>
> class RocketLauncher
> {
>
> protected:
> virtual Bool acceptAmmunition (IAmmunitionClip* ammunition)
> {
> if (dynamic_cast<IRocket*> (ammunition) != NULL)
> return true;
> else
> return false;
> };
> }
>
> ------------------------------------------
> Then you delegate the actual decition whether the ammo clip
> is valid to that
> method.
>
> With the plus that you can have for instance and
> AdvanceRocketLauncher that
> shoots only EMPRockets or all type of available rockets
> (using either the first
> of second version).
Umm, Ok. I think I get it.
>
>
> >>Also, I would not use IWeapon for all kind of weapons. I
> think, that
> >>there
> should be
> >>an interface like IFireable for all weapons which can fire. In this
> >>case there would be any problems with non-fireable weapons
> like stun
> >>rod, etc. IAmmunitionClip. No comments on that one.
> I had though about it in the past, however if you think it
> this way: A Stunt
> Rod is indeed a fireable weapon, just only that is a Zero
> Range weapon. After
> all you have to trigger a button to fire the electric charge
> :D ... In that way
> we have two solutions either have IFireable, IRangeFireable
> (that inherit from
> IFireable) or we put the hierarchy upside down and make the
> range an attribute.
> I had found that the second way gives you a better design
> (not as flexible but
> easier to understand and implement) after explaining to a
> friend how to model a
> tanks simulator for his OOP class.
>
> For instance you have Tanks, and some tanks have only radio
> equipment but
> others have fixed turrets (assault tank)... Then an advance
> tank have a movable
> turret (heavy assault tank). Then the property of movable
> should be via
> inheritance or fixed turrets are not more than a specialized
> class of turret
> with a harder constrain (responding I cannot move in that
> direction, if we
> wanna aim we have to move the tank :D ).
Then we need to think about all possible items/weapons the soldier will use
in the battle. I guess grenades will get their own interface, but what about
Medikit, Motion Detector, etc.? Are those going to be a weapon? Perhaps not.
>
> >>IMountableWeapon. Again, I don't think we should inherit an
> interface
> >>from interface. Especially here: Mountable is description
> of behavior
> >>and Weapon is an object. I suggest another interface Imountable.
> Wrong name, changed to IAircraftWeapon and added
> IVehicleWeapon for HWP.
You did not change the file name though. Not a big deal, anyway.
>
> >>In general, this is all great. It finally start to feel
> like there is
> >>some gameplay present. And this is what I love!
> I do like this part too as we can feel nearer of a playable
> game, but the
> infrastructure work is as important as this if we want to make a
> mantenible/extendable game. On the other hand, it is cool we
> can make a
> windowed (not graphic) client to test all this :D ... like
> see what is in the
> stores and all that...
>
> BTW as we are getting a little more involved in the design
> (that I didnt expect
> that with the first mail) I will be sending this to Ermete
> too, and I will send
> him your mail too so we add their comments on this before
> release it to the
> mailing list.
Well, only 3 of us post in that mailing list, so you could send it there as
well - the same audience will be covered. :)
Ok. Now, you have sent me your code + my modified code. None of these files
are in CVS yet. Very quickly it could be hard to track changes in the files.
I suggest we pick a branch or two in possible hierarchy and finalize the
interfaces there. How about everything about aircrafts (weapons, storage,
speed, etc.) and bases?
Ok. That is it so far.
>
> Greetings
> Federico
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.525 / Virus Database: 322 - Release Date: 2003/10/09
>
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.525 / Virus Database: 322 - Release Date: 2003/10/09
----- End forwarded message -----
|