From: Mikhail K. <me...@cs...> - 2002-06-08 07:14:49
|
> Refactorings that would simplify the system and make conform to best > practices: > 1) Rand - currently, a random number gets set in ScorchApplet.receiveGameSettings. However, it is > passed all over every object with no change. Recommed: static variable in some Util class (or > just ScorchApplet). All other objects requiring this static value would then call > .getCurrentRandom() to get the Random object. Impossible, unfortunately. It can't be static, because it than would be shared by all instances of the game running in the same JVM, which can happen if somebody opens up applet in two windows of the same browser. This would screw up our synchronization based on the same random # sequence. You could make it non-static publically available object in ScorchApplet, or ScorchField, but I think I decided again it because that meant that I would have to pass reference to that containing object everywhere. > 2) Weapon acting as a Weapon base class and a Factory. Recommend: > splitting the effort - create a > separate Factory class to handle the creation of Weapons. However, if > this is done, Item would > also have to be modified to remain consistent since it has the same > issue. (Is it worth the > trouble?) Just that Weapon and Item should not know about the > implementing classes. Wait, the only thing that weapon knows about the extending classes are their names. It's easy to get rid of this: we can use reflection to list all classes in "scorch.weapons" package which extend Weapon. Then call getName() on them etc. I'm not sure it's worth the effort. Factory is a possibility too. If you feel like it, try it. Of course changes to Items should be symmetrical. > 3) ScorchField - knows about specific Weapons and Explosions. This should be refactored so that > it is unware of types. For example, it could call the WeaponFactory > (or just Weapon if we don't > do the Factory) for a randomExplosion() (death explosion) and get back > the appropriate Explosion > class. (just saw you had a TODO in there for this also.) Yes and no. Explosions are not eactly the same as weapons. I guess the right way to do it is to add a flag to each weapon which would say whether it can be used for the death sequence. I need to think more about this, but just moving this to weapon or weapon factory doesn't sound 100% good. Much biggre problems is with Items. ScorchPlayer has a lot of knowledge about specific item classes. > public class LiquidDirt extends Weapon { > protected static int radius = 50; > > public LiquidDirt() { > //to make the design more obvious, the below variables can be obtained > //by creating 2 abstract methods in the Weapon class, and sub-classes > //would then implement them. > type = SandBomb; > price = 5000; > } > > //make parent class abstract > //call our Explosion -- only this weapon needs to know how > public Explosion produceExplosion(Bitmap bitmap) { > //this removes need of argument variable > LiquidDirtExplosion expl = new LiquidDirtExplosion(bitmap, radius); > return (Explosion)expl; > } > } I think I have a better idea. I kind of like the fact that produceExplosion is so generic and that weapon class doesn't have to implement any methods. The solution I have in mind is to make argument an Object isntead of int. For example MIRVExplosion needs really 2 arguments: number of particles and radius. Then the object passed to is as arument would be an array of two ints. This might introduce some weird relation ship between Weapon and Explosion class, but it looks good to me. At least at 3am. Let me know what you think about this idea. |
From: Charles M. <cha...@ya...> - 2002-06-09 03:32:19
|
comments below... --- Mikhail Kruk <me...@cs...> wrote: > > Refactorings that would simplify the system and make conform to best > > practices: > > 1) Rand - currently, a random number gets set in ScorchApplet.receiveGameSettings. However, > it is > > passed all over every object with no change. Recommed: static variable in some Util class (or > > just ScorchApplet). All other objects requiring this static value would then call > > .getCurrentRandom() to get the Random object. > > Impossible, unfortunately. It can't be static, because it than would be > shared by all instances of the game running in the same JVM, which can > happen if somebody opens up applet in two windows of the same browser. > This would screw up our synchronization based on the same random # > sequence. You could make it non-static publically available object in > ScorchApplet, or ScorchField, but I think I decided again it because that > meant that I would have to pass reference to that containing object > everywhere. > Ah... didn't know applets would do that. I also didn't know it tied some how into your synchronization. I thought it was more for just getting a random number. If you don't mind me asking, at which class(es) does the synch issues come up for this Random number? > > 2) Weapon acting as a Weapon base class and a Factory. Recommend: > > splitting the effort - create a > > separate Factory class to handle the creation of Weapons. However, if > > this is done, Item would > > also have to be modified to remain consistent since it has the same > > issue. (Is it worth the > > trouble?) Just that Weapon and Item should not know about the > > implementing classes. > > Wait, the only thing that weapon knows about the extending classes are > their names. It's easy to get rid of this: we can use reflection to list > all classes in "scorch.weapons" package which extend Weapon. Then call > getName() on them etc. I'm not sure it's worth the effort. Factory is a > possibility too. If you feel like it, try it. Of course changes to Items > should be symmetrical. > Interesting idea. Might work well. Sort of has a Module plug-n-play feel. > > 3) ScorchField - knows about specific Weapons and Explosions. This should be refactored so > that > > it is unware of types. For example, it could call the WeaponFactory > > (or just Weapon if we don't > > do the Factory) for a randomExplosion() (death explosion) and get back > > the appropriate Explosion > > class. (just saw you had a TODO in there for this also.) > > Yes and no. Explosions are not eactly the same as weapons. I guess the > right way to do it is to add a flag to each weapon which would say whether > it can be used for the death sequence. I need to think more about this, > but just moving this to weapon or weapon factory doesn't sound 100% good. > Much biggre problems is with Items. ScorchPlayer has a lot of knowledge > about specific item classes. > I like the idea of having each weapon know if it can be used in a death sequence. I guess I need to look at the Items and ScorchPlayer ties more closely. > > public class LiquidDirt extends Weapon { > > protected static int radius = 50; > > > > public LiquidDirt() { > > //to make the design more obvious, the below variables can be obtained > > //by creating 2 abstract methods in the Weapon class, and sub-classes > > //would then implement them. > > type = SandBomb; > > price = 5000; > > } > > > > //make parent class abstract > > //call our Explosion -- only this weapon needs to know how > > public Explosion produceExplosion(Bitmap bitmap) { > > //this removes need of argument variable > > LiquidDirtExplosion expl = new LiquidDirtExplosion(bitmap, radius); > > return (Explosion)expl; > > } > > } > > I think I have a better idea. I kind of like the fact that > produceExplosion is so generic and that weapon class doesn't have to > implement any methods. The solution I have in mind is to make argument an > Object isntead of int. For example MIRVExplosion needs really 2 arguments: > number of particles and radius. Then the object passed to is as arument > would be an array of two ints. This might introduce some weird relation > ship between Weapon and Explosion class, but it looks good to me. At least > at 3am. Let me know what you think about this idea. > Yes... I was thinking of changing the single attribute int to a array or hashmap. If it was a hashmap, you could do a name value pair. In either case, I still wasn't sure if there was a need to hide the Explosion class. Here's the benifits/tradeoffs that I see: 1) current way - requires less code, increased complexity in the explosion class being called 2) using abstracts - forces developer to implement the child class correctly, more obvious what is going on No real big wins or loses either solution. It is probably slightly faster (runtime) to create an Explosion class directly than to instantiate from the name. It's up to you on how you'd like to move forward on this. I personally like to make things more readable in the code. When I first looked at the specific weapon classes, I was amazed at how little was in them -- but was also confused. The README.Weapon helped a lot though. I just look at the abstract methods as a built in readme that is also validated during compile time. :) Ok. let me know what you decide and what things you'd like me to do. I'll be working on the LiquidDirt until then. Thanks. -Charles __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
From: Mikhail K. <me...@cs...> - 2002-06-09 05:36:09
|
> > Impossible, unfortunately. It can't be static, because it than would be > > shared by all instances of the game running in the same JVM, which can > > happen if somebody opens up applet in two windows of the same browser. > > This would screw up our synchronization based on the same random # > > sequence. You could make it non-static publically available object in > > ScorchApplet, or ScorchField, but I think I decided again it because that > > meant that I would have to pass reference to that containing object > > everywhere. > > > > Ah... didn't know applets would do that. I also didn't know it tied > some how into your > synchronization. I thought it was more for just getting a random > number. If you don't mind me > asking, at which class(es) does the synch issues come up for this > Random number? It's not synchronization in the sense of synchronized (rand) { ... } What happens is that when games starts, server generates a seed. It sends it to all clients and they initialize random number generators with this seed. Then it is important that every client generates exactly the same number of random numbers in exactly the same order. That's how we make sure that all clients have the same terrain generated etc. > > Wait, the only thing that weapon knows about the extending classes are > > their names. It's easy to get rid of this: we can use reflection to list > > all classes in "scorch.weapons" package which extend Weapon. Then call > > getName() on them etc. I'm not sure it's worth the effort. Factory is a > > possibility too. If you feel like it, try it. Of course changes to Items > > should be symmetrical. > > > > Interesting idea. Might work well. Sort of has a Module plug-n-play feel. It might work, might not. There are some issues in Netscape Communicator with security and reflection. I don't want to break NC support just for that. But if it works it would be quite cute feature -- add weapons without recompiling. Useless, of course, in an open source project. But on the other hand you will be able to *remove* weapons without recompiling. > > Yes and no. Explosions are not eactly the same as weapons. I guess the > > right way to do it is to add a flag to each weapon which would say whether > > it can be used for the death sequence. I need to think more about this, > > but just moving this to weapon or weapon factory doesn't sound 100% good. > > Much biggre problems is with Items. ScorchPlayer has a lot of knowledge > > about specific item classes. > > > > I like the idea of having each weapon know if it can be used in a death > sequence. Please don't call it weapon, it's explosion. Otherwise it's confusing. There might be some problem lurking in there. Ah, I know. All the explosion classes take slightly different arguments so to generalize that will have to path a bunch of useless arguments to some explosions. For example only FireExplosion needs height of tank, only Fire and Laser need width of tank and only FunkyExplosion needs rand object. > I guess I need > to look at the Items and ScorchPlayer ties more closely. I though about that a lot. I don't think this tie can be easily broken, because unlike weapons, items influence things in environment a lot. Things like tracers, parachutes, auto defense can not be self-contained. This is a case when design and incapsulation must clearly be sacrificed for practicality. > > I think I have a better idea. I kind of like the fact that > > produceExplosion is so generic and that weapon class doesn't have to > > implement any methods. The solution I have in mind is to make argument an > > Object isntead of int. For example MIRVExplosion needs really 2 arguments: > > number of particles and radius. Then the object passed to is as arument > > would be an array of two ints. This might introduce some weird relation > > ship between Weapon and Explosion class, but it looks good to me. At least > > at 3am. Let me know what you think about this idea. > > > > Yes... I was thinking of changing the single attribute int to a array > or hashmap. If it was a hashmap, you could do a name value pair. In > either case, I still wasn't sure if there was a need > to hide the Explosion class. Here's the benifits/tradeoffs that I see: > 1) current way - requires less code, increased complexity in the > explosion class being called There is one more benefit: I was thinking of completely getting rid of Weapons classes and just turning them into a text file with weapon properties. This way people would be able to tweak weapons without recompiling. With the current scheme this change is more or less trivial. > 2) using abstracts - forces developer to implement the child class > correctly, more obvious what is > going on I'd prefer to stick with 1) really. I think it will look much better if we change arg into an Object and stick arrays into it when possible. I don't want it to be a Hashtable because in most cases there will be just one argument, sometimes two. Hashtable seems to be an overkill, even though the idea of having names does sound good. I just think that changing stuff which is not broken is almost always a bad idea. It's ok to do when the benefit for design/readabilitiy is obvious, but when in doubt, leave the lying dogs lie. > Ok. let me know what you decide and what things you'd like me to do. > I'll be working on the > LiquidDirt until then. I don't know yet. Maybe I'll ask you to finish implementing the boot player command. When we have that, we can make a new release. |
From: Charles M. <cha...@ya...> - 2002-06-11 12:36:31
|
CVS updated last night. Added 2 Classes - DirtBall and DirtBallExplosion. Modified 2 Classes - Weapon and PlasmaExplosion. Thanks. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
From: Charles M. <cha...@ya...> - 2002-06-12 02:19:57
|
I've noticed a couple of times where the colors of the board and the ground made it difficult to play. For example, the sand was black and so was the night sky. Also, There was one where the color of the red/yellow tanks were near impossible to see on the background color. Not sure this was on the list to fix, but just wanted to mention it. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
From: Charles M. <cha...@ya...> - 2002-06-12 12:35:41
|
I got the liquid dirt to work with a few tweaks to the NapalmExplosion. (By the way... I still don't know 1/2 of how things are working in the class. There are a lot of things in the base APIs that when I go to them via code they don't explain what they are or used for.... which leads to more digging and looking to try to understand. However, I understand enought to create this new class.) Anyway, I started going down the path of handling more than 1 argument... public void setArguments(Object args[]) The negative with this is that each class will pass in a varying amount of arguments, all of different types. It makes it more difficult for the developer when they are coding to understand what is being used. This also requires us to case a int to a Integer and then back to a int. If you don't mind these shortcomings, then I'll continue to move forward. At a minimum, each explosion class that implements this method should describe the input expected as the API. > > > > I think I have a better idea. I kind of like the fact that > > > produceExplosion is so generic and that weapon class doesn't have to > > > implement any methods. The solution I have in mind is to make argument an > > > Object isntead of int. For example MIRVExplosion needs really 2 arguments: > > > number of particles and radius. Then the object passed to is as arument > > > would be an array of two ints. This might introduce some weird relation > > > ship between Weapon and Explosion class, but it looks good to me. At least > > > at 3am. Let me know what you think about this idea. > > > __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
From: Mikhail K. <me...@cs...> - 2002-06-12 13:19:47
|
You are probably right. It's a bit ugly. I see two ways to work around this. Either go with your suggestion and path Properties object or Hashtable object (of Properties are not in jdk1.1) or create a new bstract class WeaponProperties. Abstract class won't have any methods. Implementation will have methods like getRadius(), getBlah(), everything inside will be read only and initialized by constructor. Then weapon class itself will create an instance of that WeaponProperties class and pass it to the setOptions() methods of Weapon (setArgument is gone then). What do you think? > I got the liquid dirt to work with a few tweaks to the NapalmExplosion. (By the way... I still > don't know 1/2 of how things are working in the class. There are a lot of things in the base APIs > that when I go to them via code they don't explain what they are or used for.... which leads to > more digging and looking to try to understand. However, I understand enought to create this new > class.) > > Anyway, I started going down the path of handling more than 1 argument... > public void setArguments(Object args[]) > The negative with this is that each class will pass in a varying amount of arguments, all of > different types. It makes it more difficult for the developer when they are coding to understand > what is being used. This also requires us to case a int to a Integer and then back to a int. If > you don't mind these shortcomings, then I'll continue to move forward. At a minimum, each > explosion class that implements this method should describe the input expected as the API. > > > > > > > I think I have a better idea. I kind of like the fact that > > > > produceExplosion is so generic and that weapon class doesn't have to > > > > implement any methods. The solution I have in mind is to make argument an > > > > Object isntead of int. For example MIRVExplosion needs really 2 arguments: > > > > number of particles and radius. Then the object passed to is as arument > > > > would be an array of two ints. This might introduce some weird relation > > > > ship between Weapon and Explosion class, but it looks good to me. At least > > > > at 3am. Let me know what you think about this idea. > > > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > _______________________________________________________________ > > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > _______________________________________________ > Scorch-devel mailing list > Sco...@li... > https://lists.sourceforge.net/lists/listinfo/scorch-devel > |
From: Charles M. <cha...@ya...> - 2002-06-13 02:55:18
|
Good alternative. However, wouldn't this generate more classes and code writing than overriding performExplosion. A Hashmap still requires the conversion from objects, but removes the dependancy to get all the args in the right order. I don't know. They all work as solutions. I still fancy the performExplosion (for those that need it), but I'll implement whichever one you want. --- Mikhail Kruk <me...@cs...> wrote: > You are probably right. It's a bit ugly. I see two ways to work around > this. Either go with your suggestion and path Properties object or > Hashtable object (of Properties are not in jdk1.1) or create a new bstract > class WeaponProperties. Abstract class won't have any methods. > Implementation will have methods like getRadius(), getBlah(), everything > inside will be read only and initialized by constructor. Then weapon class > itself will create an instance of that WeaponProperties class and pass it > to the setOptions() methods of Weapon (setArgument is gone then). > What do you think? > > > I got the liquid dirt to work with a few tweaks to the NapalmExplosion. (By the way... I still > > don't know 1/2 of how things are working in the class. There are a lot of things in the base > APIs > > that when I go to them via code they don't explain what they are or used for.... which leads > to > > more digging and looking to try to understand. However, I understand enought to create this > new > > class.) > > > > Anyway, I started going down the path of handling more than 1 argument... > > public void setArguments(Object args[]) > > The negative with this is that each class will pass in a varying amount of arguments, all of > > different types. It makes it more difficult for the developer when they are coding to > understand > > what is being used. This also requires us to case a int to a Integer and then back to a int. > If > > you don't mind these shortcomings, then I'll continue to move forward. At a minimum, each > > explosion class that implements this method should describe the input expected as the API. > > > > > > > > > > I think I have a better idea. I kind of like the fact that > > > > > produceExplosion is so generic and that weapon class doesn't have to > > > > > implement any methods. The solution I have in mind is to make argument an > > > > > Object isntead of int. For example MIRVExplosion needs really 2 arguments: > > > > > number of particles and radius. Then the object passed to is as arument > > > > > would be an array of two ints. This might introduce some weird relation > > > > > ship between Weapon and Explosion class, but it looks good to me. At least > > > > > at 3am. Let me know what you think about this idea. > > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! - Official partner of 2002 FIFA World Cup > > http://fifaworldcup.yahoo.com > > > > _______________________________________________________________ > > > > Sponsored by: > > ThinkGeek at http://www.ThinkGeek.com/ > > _______________________________________________ > > Scorch-devel mailing list > > Sco...@li... > > https://lists.sourceforge.net/lists/listinfo/scorch-devel > > > > > _______________________________________________________________ > > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > _______________________________________________ > Scorch-devel mailing list > Sco...@li... > https://lists.sourceforge.net/lists/listinfo/scorch-devel __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
From: Mikhail K. <me...@cs...> - 2002-06-13 04:46:58
|
Well, I definitely hate the name "performExplosion". Produce or Create sounds better. Let's not hurry with this though. I need more time to think. BTW, Alex, I'd love to hear your opinion on this. With all due disrespect to your design abilities... you are the smarter one now :) > Good alternative. However, wouldn't this generate more classes and code writing than overriding > performExplosion. A Hashmap still requires the conversion from objects, but removes the > dependancy to get all the args in the right order. I don't know. They all work as solutions. I > still fancy the performExplosion (for those that need it), but I'll implement whichever one you > want. > > > --- Mikhail Kruk <me...@cs...> wrote: > > You are probably right. It's a bit ugly. I see two ways to work around > > this. Either go with your suggestion and path Properties object or > > Hashtable object (of Properties are not in jdk1.1) or create a new bstract > > class WeaponProperties. Abstract class won't have any methods. > > Implementation will have methods like getRadius(), getBlah(), everything > > inside will be read only and initialized by constructor. Then weapon class > > itself will create an instance of that WeaponProperties class and pass it > > to the setOptions() methods of Weapon (setArgument is gone then). > > What do you think? > > > > > I got the liquid dirt to work with a few tweaks to the NapalmExplosion. (By the way... I still > > > don't know 1/2 of how things are working in the class. There are a lot of things in the base > > APIs > > > that when I go to them via code they don't explain what they are or used for.... which leads > > to > > > more digging and looking to try to understand. However, I understand enought to create this > > new > > > class.) > > > > > > Anyway, I started going down the path of handling more than 1 argument... > > > public void setArguments(Object args[]) > > > The negative with this is that each class will pass in a varying amount of arguments, all of > > > different types. It makes it more difficult for the developer when they are coding to > > understand > > > what is being used. This also requires us to case a int to a Integer and then back to a int. > > If > > > you don't mind these shortcomings, then I'll continue to move forward. At a minimum, each > > > explosion class that implements this method should describe the input expected as the API. > > > > > > > > > > > > > I think I have a better idea. I kind of like the fact that > > > > > > produceExplosion is so generic and that weapon class doesn't have to > > > > > > implement any methods. The solution I have in mind is to make argument an > > > > > > Object isntead of int. For example MIRVExplosion needs really 2 arguments: > > > > > > number of particles and radius. Then the object passed to is as arument > > > > > > would be an array of two ints. This might introduce some weird relation > > > > > > ship between Weapon and Explosion class, but it looks good to me. At least > > > > > > at 3am. Let me know what you think about this idea. > > > > > > > > > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Yahoo! - Official partner of 2002 FIFA World Cup > > > http://fifaworldcup.yahoo.com > > > > > > _______________________________________________________________ > > > > > > Sponsored by: > > > ThinkGeek at http://www.ThinkGeek.com/ > > > _______________________________________________ > > > Scorch-devel mailing list > > > Sco...@li... > > > https://lists.sourceforge.net/lists/listinfo/scorch-devel > > > > > > > > > _______________________________________________________________ > > > > Sponsored by: > > ThinkGeek at http://www.ThinkGeek.com/ > > _______________________________________________ > > Scorch-devel mailing list > > Sco...@li... > > https://lists.sourceforge.net/lists/listinfo/scorch-devel > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > _______________________________________________________________ > > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > _______________________________________________ > Scorch-devel mailing list > Sco...@li... > https://lists.sourceforge.net/lists/listinfo/scorch-devel > |
From: Charles M. <cha...@ya...> - 2002-06-13 04:53:12
|
Yes... let's hear some thoughts Alex! :) and you are right Mikhail. createExplosion is actually more accurate for what the method is doing... I was just referring to the already existing name -- but I mistyped it... it was suppose to be ProduceExplosion. peformExplosion is a bad name (since it is creating an Explosion class). --- Mikhail Kruk <me...@cs...> wrote: > Well, I definitely hate the name "performExplosion". Produce or Create > sounds better. > Let's not hurry with this though. I need more time to think. > BTW, Alex, I'd love to hear your opinion on this. With all due > disrespect to your design abilities... you are the smarter one now :) > > > Good alternative. However, wouldn't this generate more classes and code writing than > overriding > > performExplosion. A Hashmap still requires the conversion from objects, but removes the > > dependancy to get all the args in the right order. I don't know. They all work as solutions. > I > > still fancy the performExplosion (for those that need it), but I'll implement whichever one > you > > want. > > > > > > --- Mikhail Kruk <me...@cs...> wrote: > > > You are probably right. It's a bit ugly. I see two ways to work around > > > this. Either go with your suggestion and path Properties object or > > > Hashtable object (of Properties are not in jdk1.1) or create a new bstract > > > class WeaponProperties. Abstract class won't have any methods. > > > Implementation will have methods like getRadius(), getBlah(), everything > > > inside will be read only and initialized by constructor. Then weapon class > > > itself will create an instance of that WeaponProperties class and pass it > > > to the setOptions() methods of Weapon (setArgument is gone then). > > > What do you think? > > > > > > > I got the liquid dirt to work with a few tweaks to the NapalmExplosion. (By the way... I > still > > > > don't know 1/2 of how things are working in the class. There are a lot of things in the > base > > > APIs > > > > that when I go to them via code they don't explain what they are or used for.... which > leads > > > to > > > > more digging and looking to try to understand. However, I understand enought to create > this > > > new > > > > class.) > > > > > > > > Anyway, I started going down the path of handling more than 1 argument... > > > > public void setArguments(Object args[]) > > > > The negative with this is that each class will pass in a varying amount of arguments, all > of > > > > different types. It makes it more difficult for the developer when they are coding to > > > understand > > > > what is being used. This also requires us to case a int to a Integer and then back to a > int. > > > If > > > > you don't mind these shortcomings, then I'll continue to move forward. At a minimum, each > > > > explosion class that implements this method should describe the input expected as the API. > > > > > > > > > > > > > > > > I think I have a better idea. I kind of like the fact that > > > > > > > produceExplosion is so generic and that weapon class doesn't have to > > > > > > > implement any methods. The solution I have in mind is to make argument an > > > > > > > Object isntead of int. For example MIRVExplosion needs really 2 arguments: > > > > > > > number of particles and radius. Then the object passed to is as arument > > > > > > > would be an array of two ints. This might introduce some weird relation > > > > > > > ship between Weapon and Explosion class, but it looks good to me. At least > > > > > > > at 3am. Let me know what you think about this idea. > > > > > > > > > > > > > > > > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Yahoo! - Official partner of 2002 FIFA World Cup > > > > http://fifaworldcup.yahoo.com > > > > > > > > _______________________________________________________________ > > > > > > > > Sponsored by: > > > > ThinkGeek at http://www.ThinkGeek.com/ > > > > _______________________________________________ > > > > Scorch-devel mailing list > > > > Sco...@li... > > > > https://lists.sourceforge.net/lists/listinfo/scorch-devel > > > > > > > > > > > > > _______________________________________________________________ > > > > > > Sponsored by: > > > ThinkGeek at http://www.ThinkGeek.com/ > > > _______________________________________________ > > > Scorch-devel mailing list > > > Sco...@li... > > > https://lists.sourceforge.net/lists/listinfo/scorch-devel > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! - Official partner of 2002 FIFA World Cup > > http://fifaworldcup.yahoo.com > > > > _______________________________________________________________ > > > > Sponsored by: > > ThinkGeek at http://www.ThinkGeek.com/ > > _______________________________________________ > > Scorch-devel mailing list > > Sco...@li... > > https://lists.sourceforge.net/lists/listinfo/scorch-devel > > > > > _______________________________________________________________ > > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > _______________________________________________ > Scorch-devel mailing list > Sco...@li... > https://lists.sourceforge.net/lists/listinfo/scorch-devel __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |