Menu
▾
▴
xenocide-programming
|
From: Federico A. L. <fl...@ma...> - 2003-12-30 20:37:23
|
Hi, I am being working on Xenocide Data Code... And I had received some comments about the interface of Storable and Wearable Objects... Storable objects are those that can be put on Stores or Aircrafts. However Wearable objects are those that can be used by aliens/soldiers. I was thinking to change Wearable to Carriable cause you can carry corpses but you cant wear them. The problem is: Is Carriable an Ability or a Behaivioral Interface? (you can check the code to see what are on those directories). I was going to put it in Ability but I am not sure, I am open to suggestions. Greetings Red Knight |
|
From: Mamutas P. <ma...@pr...> - 2003-12-31 03:17:10
|
Here is what I think: We need two interfaces (sorry, but I cannot come up with good names :( ) 1) IsCarryable (the item which can be carried). That is an 'Ability' interface which defines that the object can be carried, for example weapons or corpses. Some objects cannot be carried, like phones, dishes, food items, etc., although they are small enough, but there is no need to carry them. 2) AbleToCarry (an object which can carry objects implemented IsCarryable interfaces). Those could be aircrafts, units, general store facilities, etc. That interface will be 'Behaviour' in my opinion. Regards, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Federico Andres Lois Sent: Tuesday, December 30, 2003 2:37 PM To: xen...@li... Subject: [Xenocide-programming] Carriable Items on Xenocide Hi, I am being working on Xenocide Data Code... And I had received some comments about the interface of Storable and Wearable Objects... Storable objects are those that can be put on Stores or Aircrafts. However Wearable objects are those that can be used by aliens/soldiers. I was thinking to change Wearable to Carriable cause you can carry corpses but you cant wear them. The problem is: Is Carriable an Ability or a Behaivioral Interface? (you can check the code to see what are on those directories). I was going to put it in Ability but I am not sure, I am open to suggestions. Greetings Red Knight ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 |
|
From: <red...@pr...> - 2003-12-31 03:57:16
|
Hi mamutas and all,
How about this. We have ICarriable for objects that can be carried, and ICarrier
for those that can carry. In that way we can make a nice system, suppose this:
class ICarriable
{};
class ICarrier
{};
class Soldier : public ICarrier
{};
class Aircraft : public ICarrier
{};
ICarrier should be able to present a simple but unified view for carrying items.
For instance Aircraft's dont mind the size of the stuff you put on them as long
as the weight do pass over an specified ammount. On the other side Soldiers do
mind the real proportions and the specific place in where you put them. That
makes the interface pretty difficult. One solution is to think that carriers
have containers, and those containers specify the limits on size. However, the
carrier itself specify the limit on weight. You can either enumerate the
containers or give them a symbolic name (like "righthand" or "backpack" ) to be
accesible from a scripting language. So for instance to move the rocket launcher
from the backpack to the hand you do the following.
ICarrierContainer* backpack = this->getCarrierContainer ("backpack");
// Get the object via its code or whatever.
ICarriable* object = backpack->takeoutObject ( ... );
ICarrierContainer* hand = this->getCarrierContainer ("righthand");
if (hand->isEmpty ())
{
// The ... is the parameters to specify how to add them, I must say
// that I dont have a clue how to specify those parameters to unify both
// types of carrier objects.
hand->addObject (object, ... );
}
else // we dont do anything, or rollback the action :D ;
Other solution is to have different type of interfaces and that those use the
same type of ICarriable objects (as we have now), one is IStore (where position
in the store is not relevant, only total size or weight and the other is
ICarrier (used to be called Wearable) where not only size and weight are
relevant but position too.
Any though will be welcomed, cause I am stuck on this.
Greetings
Red Knight
Quoting Mamutas Plaukotas <ma...@pr...>:
> Here is what I think:
>
> We need two interfaces (sorry, but I cannot come up with good names :( )
> 1) IsCarryable (the item which can be carried). That is an 'Ability'
> interface which defines that the object can be carried, for example weapons
> or corpses. Some objects cannot be carried, like phones, dishes, food items,
> etc., although they are small enough, but there is no need to carry them.
> 2) AbleToCarry (an object which can carry objects implemented IsCarryable
> interfaces). Those could be aircrafts, units, general store facilities, etc.
> That interface will be 'Behaviour' in my opinion.
>
> Regards,
> mamutas
|
|
From: Cpt. B. <cpt...@te...> - 2003-12-31 04:19:13
|
Why have the arbitrary distinction between crafts and combat units? An
Intercepter would have two carrierContainers for weapons....just assign them
a size(you could even scale it to match a soldier...a backpack is 4x6 or so,
so a hardpoint would be 8x20), and (for v1,at least) just make sure that all
craft weapons match that size.
That way both versions would function the same way...and it leaves it open
in the future to have limits on what craft weapons fit which craft (similar
to Apocalypse).
-The Captain
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of
red...@pr...
Sent: Tuesday, December 30, 2003 7:57 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
Hi mamutas and all,
How about this. We have ICarriable for objects that can be carried, and
ICarrier
for those that can carry. In that way we can make a nice system, suppose
this:
class ICarriable
{};
class ICarrier
{};
class Soldier : public ICarrier
{};
class Aircraft : public ICarrier
{};
ICarrier should be able to present a simple but unified view for carrying
items.
For instance Aircraft's dont mind the size of the stuff you put on them as
long
as the weight do pass over an specified ammount. On the other side Soldiers
do
mind the real proportions and the specific place in where you put them. That
makes the interface pretty difficult. One solution is to think that carriers
have containers, and those containers specify the limits on size. However,
the
carrier itself specify the limit on weight. You can either enumerate the
containers or give them a symbolic name (like "righthand" or "backpack" ) to
be
accesible from a scripting language. So for instance to move the rocket
launcher
from the backpack to the hand you do the following.
ICarrierContainer* backpack = this->getCarrierContainer ("backpack");
// Get the object via its code or whatever.
ICarriable* object = backpack->takeoutObject ( ... );
ICarrierContainer* hand = this->getCarrierContainer ("righthand");
if (hand->isEmpty ())
{
// The ... is the parameters to specify how to add them, I must say
// that I dont have a clue how to specify those parameters to unify both
// types of carrier objects.
hand->addObject (object, ... );
}
else // we dont do anything, or rollback the action :D ;
Other solution is to have different type of interfaces and that those use
the
same type of ICarriable objects (as we have now), one is IStore (where
position
in the store is not relevant, only total size or weight and the other is
ICarrier (used to be called Wearable) where not only size and weight are
relevant but position too.
Any though will be welcomed, cause I am stuck on this.
Greetings
Red Knight
Quoting Mamutas Plaukotas <ma...@pr...>:
> Here is what I think:
>
> We need two interfaces (sorry, but I cannot come up with good names :( )
> 1) IsCarryable (the item which can be carried). That is an 'Ability'
> interface which defines that the object can be carried, for example
weapons
> or corpses. Some objects cannot be carried, like phones, dishes, food
items,
> etc., although they are small enough, but there is no need to carry them.
> 2) AbleToCarry (an object which can carry objects implemented IsCarryable
> interfaces). Those could be aircrafts, units, general store facilities,
etc.
> That interface will be 'Behaviour' in my opinion.
>
> Regards,
> mamutas
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
|
|
From: <red...@pr...> - 2003-12-31 07:12:08
|
Hi Cpt, basicly the Interceptor Craft is like a soldier, not like a transport.
In the Interceptor you have weapons pods, the distinction is with the transport.
In the transport the object are orderless, unless we give it enough space and
arrange the objects algorithmically... After thinking at it (found out that
while writting :D ), we can think of a transport as a Nx3 container with a big N
based on transport size. In that case even transports look like the same as
soldiers, and interceptors.
If someone has another idea of how to do it, it is welcomed but I think I will
start sketching something on this line if I dont receive any further comment.
Thanks Cpt.
Greetings
Red Knight
Quoting "Cpt. Boxershorts" <cpt...@te...>:
> Why have the arbitrary distinction between crafts and combat units? An
> Intercepter would have two carrierContainers for weapons....just assign them
> a size(you could even scale it to match a soldier...a backpack is 4x6 or so,
> so a hardpoint would be 8x20), and (for v1,at least) just make sure that all
> craft weapons match that size.
>
> That way both versions would function the same way...and it leaves it open
> in the future to have limits on what craft weapons fit which craft (similar
> to Apocalypse).
>
> -The Captain
>
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...]On Behalf Of
> red...@pr...
> Sent: Tuesday, December 30, 2003 7:57 PM
> To: xen...@li...
> Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
>
>
> Hi mamutas and all,
>
> How about this. We have ICarriable for objects that can be carried, and
> ICarrier
> for those that can carry. In that way we can make a nice system, suppose
> this:
>
> class ICarriable
> {};
>
> class ICarrier
> {};
>
> class Soldier : public ICarrier
> {};
>
> class Aircraft : public ICarrier
> {};
>
> ICarrier should be able to present a simple but unified view for carrying
> items.
> For instance Aircraft's dont mind the size of the stuff you put on them as
> long
> as the weight do pass over an specified ammount. On the other side Soldiers
> do
> mind the real proportions and the specific place in where you put them. That
> makes the interface pretty difficult. One solution is to think that carriers
> have containers, and those containers specify the limits on size. However,
> the
> carrier itself specify the limit on weight. You can either enumerate the
> containers or give them a symbolic name (like "righthand" or "backpack" ) to
> be
> accesible from a scripting language. So for instance to move the rocket
> launcher
> from the backpack to the hand you do the following.
>
> ICarrierContainer* backpack = this->getCarrierContainer ("backpack");
>
> // Get the object via its code or whatever.
> ICarriable* object = backpack->takeoutObject ( ... );
>
> ICarrierContainer* hand = this->getCarrierContainer ("righthand");
> if (hand->isEmpty ())
> {
> // The ... is the parameters to specify how to add them, I must say
> // that I dont have a clue how to specify those parameters to unify both
> // types of carrier objects.
> hand->addObject (object, ... );
> }
> else // we dont do anything, or rollback the action :D ;
>
> Other solution is to have different type of interfaces and that those use
> the
> same type of ICarriable objects (as we have now), one is IStore (where
> position
> in the store is not relevant, only total size or weight and the other is
> ICarrier (used to be called Wearable) where not only size and weight are
> relevant but position too.
>
> Any though will be welcomed, cause I am stuck on this.
>
> Greetings
> Red Knight
>
>
> Quoting Mamutas Plaukotas <ma...@pr...>:
>
> > Here is what I think:
> >
> > We need two interfaces (sorry, but I cannot come up with good names :( )
> > 1) IsCarryable (the item which can be carried). That is an 'Ability'
> > interface which defines that the object can be carried, for example
> weapons
> > or corpses. Some objects cannot be carried, like phones, dishes, food
> items,
> > etc., although they are small enough, but there is no need to carry them.
> > 2) AbleToCarry (an object which can carry objects implemented IsCarryable
> > interfaces). Those could be aircrafts, units, general store facilities,
> etc.
> > That interface will be 'Behaviour' in my opinion.
> >
> > Regards,
> > mamutas
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
|
|
From: Mamutas P. <ma...@pr...> - 2004-01-01 18:25:55
|
Hello Xenocide Programmers,
I liked RK's idea about containers. It might complicate things a bit, but
what if ICarrier interface will server the only one purpose - the container
management?
For example, each object which is ICarrier will have number of containers
able to hold ICarriable objects. ICarrier will provide methods to enumerate
the containers as well as to access them by number or name.
So soldiers will have many containers (hands, pockets, backpack, mouth :),
etc.); transports will have one container for all their cargo; armed crafts
will have containers for their weapons.
And here is the point: each container will have an object
ContainerConstraint. This object will describe the containers and will be
responsible to provide yes/no for requests to put the item in the container.
ContainerConstraint will have following variables for example:
- size (width and height, or something more sophisticated if container is
not rectangular);
- max number of items;
- max weight of items;
- type of items (craft weapons only or any handheld weapons only, etc.)
The container itself will keep values of current content, so there are no
such varialbles like current number/weight of items in the
ContainerCOnstraint object.
So, in RK's example below hand->addObject() method would call
ContainerConstraint object to verify that Object is acceptable.
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
red...@pr...
Sent: Tuesday, December 30, 2003 9:57 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
Hi mamutas and all,
How about this. We have ICarriable for objects that can be carried, and
ICarrier
for those that can carry. In that way we can make a nice system, suppose
this:
class ICarriable
{};
class ICarrier
{};
class Soldier : public ICarrier
{};
class Aircraft : public ICarrier
{};
ICarrier should be able to present a simple but unified view for carrying
items.
For instance Aircraft's dont mind the size of the stuff you put on them as
long
as the weight do pass over an specified ammount. On the other side Soldiers
do
mind the real proportions and the specific place in where you put them. That
makes the interface pretty difficult. One solution is to think that carriers
have containers, and those containers specify the limits on size. However,
the
carrier itself specify the limit on weight. You can either enumerate the
containers or give them a symbolic name (like "righthand" or "backpack" ) to
be
accesible from a scripting language. So for instance to move the rocket
launcher
from the backpack to the hand you do the following.
ICarrierContainer* backpack = this->getCarrierContainer ("backpack");
// Get the object via its code or whatever.
ICarriable* object = backpack->takeoutObject ( ... );
ICarrierContainer* hand = this->getCarrierContainer ("righthand");
if (hand->isEmpty ())
{
// The ... is the parameters to specify how to add them, I must say
// that I dont have a clue how to specify those parameters to unify both
// types of carrier objects.
hand->addObject (object, ... );
}
else // we dont do anything, or rollback the action :D ;
Other solution is to have different type of interfaces and that those use
the
same type of ICarriable objects (as we have now), one is IStore (where
position
in the store is not relevant, only total size or weight and the other is
ICarrier (used to be called Wearable) where not only size and weight are
relevant but position too.
Any though will be welcomed, cause I am stuck on this.
Greetings
Red Knight
Quoting Mamutas Plaukotas <ma...@pr...>:
> Here is what I think:
>
> We need two interfaces (sorry, but I cannot come up with good names :( )
> 1) IsCarryable (the item which can be carried). That is an 'Ability'
> interface which defines that the object can be carried, for example
weapons
> or corpses. Some objects cannot be carried, like phones, dishes, food
items,
> etc., although they are small enough, but there is no need to carry them.
> 2) AbleToCarry (an object which can carry objects implemented IsCarryable
> interfaces). Those could be aircrafts, units, general store facilities,
etc.
> That interface will be 'Behaviour' in my opinion.
>
> Regards,
> mamutas
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003
|
|
From: Jeffrey W. <je...@ca...> - 2004-01-03 03:38:23
|
I agree with the idea of containers. However, the exact implementation
of this is a bit unclear to me. I've seen some games that use
dimensions, PlanetSide or MechWarrior for example. A soldier is capable
of carrying 2 units x 4 units. A pistol would be 1u x 1u, and a rifle
1u x 2u. A larger vehicle would be capable of carrying 15u x 10u. A
large object that a soldier cannot carry would have dimensions larger
than a soldier's capacity, 3u x 2u for example. This enforces the
restrictions on who can carry what and also enforces the maximum
capacity of a unit.
How this is implemented is up to the programmers, but that's an idea for
the container system.
-mindstorm
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
ma...@pr...
Sent: Thursday, January 01, 2004 10:26 AM
To: red...@pr...;
xen...@li...
Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
Hello Xenocide Programmers,
I liked RK's idea about containers. It might complicate things a bit,
but
what if ICarrier interface will server the only one purpose - the
container
management?
For example, each object which is ICarrier will have number of
containers
able to hold ICarriable objects. ICarrier will provide methods to
enumerate
the containers as well as to access them by number or name.
So soldiers will have many containers (hands, pockets, backpack, mouth
:),
etc.); transports will have one container for all their cargo; armed
crafts
will have containers for their weapons.
And here is the point: each container will have an object
ContainerConstraint. This object will describe the containers and will
be
responsible to provide yes/no for requests to put the item in the
container.
ContainerConstraint will have following variables for example:
- size (width and height, or something more sophisticated if container
is
not rectangular);
- max number of items;
- max weight of items;
- type of items (craft weapons only or any handheld weapons only, etc.)
The container itself will keep values of current content, so there are
no
such varialbles like current number/weight of items in the
ContainerCOnstraint object.
So, in RK's example below hand->addObject() method would call
ContainerConstraint object to verify that Object is acceptable.
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
red...@pr...
Sent: Tuesday, December 30, 2003 9:57 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
Hi mamutas and all,
How about this. We have ICarriable for objects that can be carried, and
ICarrier
for those that can carry. In that way we can make a nice system, suppose
this:
class ICarriable
{};
class ICarrier
{};
class Soldier : public ICarrier
{};
class Aircraft : public ICarrier
{};
ICarrier should be able to present a simple but unified view for
carrying
items.
For instance Aircraft's dont mind the size of the stuff you put on them
as
long
as the weight do pass over an specified ammount. On the other side
Soldiers
do
mind the real proportions and the specific place in where you put them.
That
makes the interface pretty difficult. One solution is to think that
carriers
have containers, and those containers specify the limits on size.
However,
the
carrier itself specify the limit on weight. You can either enumerate the
containers or give them a symbolic name (like "righthand" or "backpack"
) to
be
accesible from a scripting language. So for instance to move the rocket
launcher
from the backpack to the hand you do the following.
ICarrierContainer* backpack = this->getCarrierContainer ("backpack");
// Get the object via its code or whatever.
ICarriable* object = backpack->takeoutObject ( ... );
ICarrierContainer* hand = this->getCarrierContainer ("righthand");
if (hand->isEmpty ())
{
// The ... is the parameters to specify how to add them, I must say
// that I dont have a clue how to specify those parameters to unify
both
// types of carrier objects.
hand->addObject (object, ... );
}
else // we dont do anything, or rollback the action :D ;
Other solution is to have different type of interfaces and that those
use
the
same type of ICarriable objects (as we have now), one is IStore (where
position
in the store is not relevant, only total size or weight and the other is
ICarrier (used to be called Wearable) where not only size and weight are
relevant but position too.
Any though will be welcomed, cause I am stuck on this.
Greetings
Red Knight
Quoting Mamutas Plaukotas <ma...@pr...>:
> Here is what I think:
>
> We need two interfaces (sorry, but I cannot come up with good names :(
)
> 1) IsCarryable (the item which can be carried). That is an 'Ability'
> interface which defines that the object can be carried, for example
weapons
> or corpses. Some objects cannot be carried, like phones, dishes, food
items,
> etc., although they are small enough, but there is no need to carry
them.
> 2) AbleToCarry (an object which can carry objects implemented
IsCarryable
> interfaces). Those could be aircrafts, units, general store
facilities,
etc.
> That interface will be 'Behaviour' in my opinion.
>
> Regards,
> mamutas
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for
IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for
IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
|
|
From: Mamutas P. <ma...@pr...> - 2004-01-03 04:46:48
|
Let me explain my idea a bit more. It might look similar to adding controls in Java's GridBagLayout, so if you are familiar with that, then you are on the fast track. :) Lets take an soldier as an example. He has following containers (not exactly like in the game, but enough for that example): left pocket, right pocket, backpack, belt. When soldier object is created, it will contain enumeration of those containers. When containers are created, each of them will be created with ContainerConstraint object, permanently attached to container. So, in our example containers might have following constraints: Container name Width Height Max Items Max Weight Type left pocket 1 2 2 10 Handheld right pocket 1 2 2 10 Handheld belt 6 1 6 20 Weapon backpack 3 4 12 100 ICarriable So, in this case if player would try to add an object with size 3x2 in his pocket, that object will not fit and the request to add will be denied. However, such object will fit easily in backpack. And... Wait a minute! Now, it occurred to me that there is a problem with layout: we need to keep track of what cells are occupied already. And we need to provide the interface for player to choose cells explicitly. So, it looks like the best way is to go with sort of table, which would describe each cell in addition to total limitations (weight, type, etc.). Well, in that case we need to assign a grid description to each container. Each cell will keep reference of the object it is storing, but the whole grid will manage weigh/type and other global parameter limitations. Regards, mamutas --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 |
|
From: Federico A. L. <fl...@ma...> - 2004-01-03 21:36:57
|
I2luY2x1ZGUgImljYXJyaWFibGUuaCINCg0KbmFtZXNwYWNlIFhlbm9jaWRlDQp7DQogICAgbmFt ZXNwYWNlIEFiaWxpdHkNCiAgICB7DQoNCiAgICB9DQp9DQoNCg== |
|
From: Mamutas P. <ma...@pr...> - 2004-01-04 02:41:26
|
Everything looks fine to me, except for that complex way of ContainerIterators creation and destruction process. Could you provide more explanation behind those invalid field and invalidate() method? Regards, mamutas --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 |
|
From: Xenocide R. A. <rep...@pr...> - 2004-01-02 02:33:18
|
I agree with the idea of containers. However, the exact implementation
of this is a bit unclear to me. I've seen some games that use
dimensions, PlanetSide or MechWarrior for example. A soldier is capable
of carrying 2 units x 4 units. A pistol would be 1u x 1u, and a rifle
1u x 2u. A larger vehicle would be capable of carrying 15u x 10u. A
large object that a soldier cannot carry would have dimensions larger
than a soldier's capacity, 3u x 2u for example. This enforces the
restrictions on who can carry what and also enforces the maximum
capacity of a unit.
How this is implemented is up to the programmers, but that's an idea for
the container system.
-mindstorm
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
ma...@pr...
Sent: Thursday, January 01, 2004 10:26 AM
To: red...@pr...;
xen...@li...
Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
Hello Xenocide Programmers,
I liked RK's idea about containers. It might complicate things a bit,
but
what if ICarrier interface will server the only one purpose - the
container
management?
For example, each object which is ICarrier will have number of
containers
able to hold ICarriable objects. ICarrier will provide methods to
enumerate
the containers as well as to access them by number or name.
So soldiers will have many containers (hands, pockets, backpack, mouth
:),
etc.); transports will have one container for all their cargo; armed
crafts
will have containers for their weapons.
And here is the point: each container will have an object
ContainerConstraint. This object will describe the containers and will
be
responsible to provide yes/no for requests to put the item in the
container.
ContainerConstraint will have following variables for example:
- size (width and height, or something more sophisticated if container
is
not rectangular);
- max number of items;
- max weight of items;
- type of items (craft weapons only or any handheld weapons only, etc.)
The container itself will keep values of current content, so there are
no
such varialbles like current number/weight of items in the
ContainerCOnstraint object.
So, in RK's example below hand->addObject() method would call
ContainerConstraint object to verify that Object is acceptable.
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
red...@pr...
Sent: Tuesday, December 30, 2003 9:57 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
Hi mamutas and all,
How about this. We have ICarriable for objects that can be carried, and
ICarrier
for those that can carry. In that way we can make a nice system, suppose
this:
class ICarriable
{};
class ICarrier
{};
class Soldier : public ICarrier
{};
class Aircraft : public ICarrier
{};
ICarrier should be able to present a simple but unified view for
carrying
items.
For instance Aircraft's dont mind the size of the stuff you put on them
as
long
as the weight do pass over an specified ammount. On the other side
Soldiers
do
mind the real proportions and the specific place in where you put them.
That
makes the interface pretty difficult. One solution is to think that
carriers
have containers, and those containers specify the limits on size.
However,
the
carrier itself specify the limit on weight. You can either enumerate the
containers or give them a symbolic name (like "righthand" or "backpack"
) to
be
accesible from a scripting language. So for instance to move the rocket
launcher
from the backpack to the hand you do the following.
ICarrierContainer* backpack = this->getCarrierContainer ("backpack");
// Get the object via its code or whatever.
ICarriable* object = backpack->takeoutObject ( ... );
ICarrierContainer* hand = this->getCarrierContainer ("righthand");
if (hand->isEmpty ())
{
// The ... is the parameters to specify how to add them, I must say
// that I dont have a clue how to specify those parameters to unify
both
// types of carrier objects.
hand->addObject (object, ... );
}
else // we dont do anything, or rollback the action :D ;
Other solution is to have different type of interfaces and that those
use
the
same type of ICarriable objects (as we have now), one is IStore (where
position
in the store is not relevant, only total size or weight and the other is
ICarrier (used to be called Wearable) where not only size and weight are
relevant but position too.
Any though will be welcomed, cause I am stuck on this.
Greetings
Red Knight
Quoting Mamutas Plaukotas <ma...@pr...>:
> Here is what I think:
>
> We need two interfaces (sorry, but I cannot come up with good names :(
)
> 1) IsCarryable (the item which can be carried). That is an 'Ability'
> interface which defines that the object can be carried, for example
weapons
> or corpses. Some objects cannot be carried, like phones, dishes, food
items,
> etc., although they are small enough, but there is no need to carry
them.
> 2) AbleToCarry (an object which can carry objects implemented
IsCarryable
> interfaces). Those could be aircrafts, units, general store
facilities,
etc.
> That interface will be 'Behaviour' in my opinion.
>
> Regards,
> mamutas
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for
IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for
IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
|
Thanks for helping keep SourceForge clean.
X