I have just finished reading a book by Gerry Weinberg and Don Gause (psychologists of programming) called "Are Your Lights On?"
I fear that my lights are off. I have come home a day early (taking Friday off) so I would have three clear days to get the input utility done.
And I left all the source code I had written behind.
Of course what programming project doesn't have slippage...
So I guess I will spend the next three days on other aspects of the system. For example, my XML code uses the the Apache xerces implementation. This is a jar file 1.49Mb long. It won't fit onto a floppy disk. On the other hand, we only use a small part of it, and the source code is available. So I will extract the required part of the source code and incorporate it in the Clash input utility.
Which leads immediately to my next topic. Game save status, individual user configurations, and other aspects of the game could all be stored in XML format. I have tried to write the input and storage classes in a general way. Also, Java streams allow, in a very simple way, any files to be zipped. This makes them smaller (obviously) and also makes them somewhat less easily hacked. Alternatively I can quite easily write a triple DES encryption system to make them completely unhackable. This I see as a possible later addition.
The question of Applications. Here is Richard's comment:
and an earlier quote:
The last entry appears to apply to Applications. However, I am not sure.
Do applications have Requirements? If so, do the requirements have start values?
How do the actual objects (units, buildings, whatever) interact with the corresponding application? Can the application be viewed as "permission to build"?
As an aside, while I and E are in view, I do not think that one should program for futures. That is, if something isn't actually in the model, it should be left out, and added later if necessary. There is an extensive literature (starting with Kent Beck et al in the XP web site) all of which says the programming for something that might be used is counter-productive. I refer you to website at www.xprogramming.org. However, here is a quote from that website:
Now, Civization Activities. This is starting to look more like an interface than an object, though, like all interfaces, they will have objects which implement the interface. One possibility is to use the Observer/Observed interface. If this is used, we then have a TecnologyActivity object which implements the CivilizationActivity interface.
Must go now - the phone is needed.
Cheers
I fear that my lights are off. I have come home a day early (taking Friday off) so I would have three clear days to get the input utility done.
And I left all the source code I had written behind.
Of course what programming project doesn't have slippage...
So I guess I will spend the next three days on other aspects of the system. For example, my XML code uses the the Apache xerces implementation. This is a jar file 1.49Mb long. It won't fit onto a floppy disk. On the other hand, we only use a small part of it, and the source code is available. So I will extract the required part of the source code and incorporate it in the Clash input utility.
Which leads immediately to my next topic. Game save status, individual user configurations, and other aspects of the game could all be stored in XML format. I have tried to write the input and storage classes in a general way. Also, Java streams allow, in a very simple way, any files to be zipped. This makes them smaller (obviously) and also makes them somewhat less easily hacked. Alternatively I can quite easily write a triple DES encryption system to make them completely unhackable. This I see as a possible later addition.
The question of Applications. Here is Richard's comment:
quote: No, applications and technologies are very different things. Applications do not have helpers and they do not process RP's in any way. They do not have tech levels or knowledge associated with them. Their level depends entirely on the level of the technologies they are associated with. They only rise and fall when the associated technologies rise and fall. This is not at all like the effects of helper techs. |
and an earlier quote:
quote: For individual Technologies: m = GrowthRateMultiplier c = UpkeepMultiplier default DR = RPDiminishingReturnsMultiplier Ts = StartLevel O = HelperLevelOffset h = HelperTechEffect I = ExternalGrowthRateMultiplier E = ExternalUpkeepMultiplier L = ApplicationLongevity |
The last entry appears to apply to Applications. However, I am not sure.
Do applications have Requirements? If so, do the requirements have start values?
How do the actual objects (units, buildings, whatever) interact with the corresponding application? Can the application be viewed as "permission to build"?
As an aside, while I and E are in view, I do not think that one should program for futures. That is, if something isn't actually in the model, it should be left out, and added later if necessary. There is an extensive literature (starting with Kent Beck et al in the XP web site) all of which says the programming for something that might be used is counter-productive. I refer you to website at www.xprogramming.org. However, here is a quote from that website:
quote: You’re NOT gonna need it! Often you will be building some class and you’ll hear yourself saying "We’re going to need...". Resist that impulse, every time. Always implement things when you actually need them, never when you just foresee that you need them. Here’s why: Your thoughts have gone off track. You’re thinking about what the class might be, rather than what it must be. You were on a mission when you started building that class. Keep on that mission rather than let yourself be distracted for even a moment. Your time is precious. Hone your sense of progress to focus on the real task, not just on banging out code. You might not need it after all. If that happens, the time you spend implementing the method will be wasted; the time everyone else spends reading it will be wasted; the space it takes up will be wasted. You find that you need a getter for some instance variable. Fine, write it. Don’t write the setter because "we’re going to need it". Don’t write getters for other instance variables because "we’re going to need them". The best way to implement code quickly is to implement less of it. The best way to have fewer bugs is to implement less code. You’re not gonna need it! |
Now, Civization Activities. This is starting to look more like an interface than an object, though, like all interfaces, they will have objects which implement the interface. One possibility is to use the Observer/Observed interface. If this is used, we then have a TecnologyActivity object which implements the CivilizationActivity interface.
Must go now - the phone is needed.
Cheers
Comment