Supporting continuing development for Empyrean Challenge / Cluster Wars
You are not logged in.
Now mobile friendly!
Will need an algorithm to figure factors that will lead to POP becoming malcontents and eventually rebels. SAG probably worked like the old Group B SPYs and if you had enough you could suppress any rebels even if you paid no CNGD.
POLice are a new element which I believe battled the REBels with the aid of SAG.
Any ideas for algorithms to model this - since we have to reinvent them with put any source code? I suppose they would depend on SOL and adequate FOOD, etc. It would seem malcontents could become content again with an SOL > 1.0. Do you think that should move REBels back to malcontents too?
Death Rate goes as low as 0.0625% when all is well. Lack of LFS and inadequate FOOD push it up. Any sense from reviewing old turns how this worked?
Also, birth rate seems to depend on SOL and how close POP is to planetary maximum. Probably some function of excess LFS with an OPC having free LFS of hab x 1e7. Likely SOL also figures in. Any suggestions on developing and algorithm?
Needed to generate a random universe to use to test other features (eventually). No thought given yet to play balance as far as equity in starting positions.
For now, can seed a set number of systems randomly in a defined 3-D space, 100 systems in 40 x 40 x 40 seems to work OK
/* 5% 4 stars, 5% 3 stars, 15% 2 stars, 75% 1 star */
/* Inner Orbits 75% Terrestrial (5% Hab), 25% Asteroids */
/* Outer Orbits 20% Asteroids, 50% Gas Giants, 30% Terrestrial */
95% chance of a planet at a given orbit, but if no planet generated rest of system beyond is empty orbits
This works out to about a 60% chance all 10 orbits will be filled with planets and a 5% chance there will be no planets
Asteroids are advantaged for METS/NMTS, disadvantaged for FUEL, Gas Giants are advantaged for FUEL, disadvantaged for METS/NMTS, Terrestrial are average for all resources
To model advantage/average/disadvantaged 2 random numbers are generated - advantaged takes higher, disadvantaged takes lower and average averages them
Amounts are Random 1-9 with 1-8 multiplied by a billion and 9 being unlimited
Percentage Yields are Random 10-99
Please comment on these assumptions for generation of universe and if anyone wants to take a look at a randomly generated universe you can download MAMP (free) to set up a local web server and mySQL database. I can sent you some SQL to build the database and the web server will let you look at it with phpMyAdmin.
Made an update to add comma separators and just saw your new comments. There is a way to have the inputs and lists for ASM, UNA and NON/POP display in a column instead of across on a mobile device and I will try to figure that out next. I appreciate all your insights and testing - progress depends mostly on time and learning more about JavaScript and the React Library.
An S/C Design Page is up. Please check for accuracy and post bugs and requests for more enhancements. It is my goal to have the on line tools eliminate much of the side calculations - for example how much FOOD the FRMs produce or how much FUEL it would take to fire the EWP and how much damage they could do.
I think we will remain reasonably true to the original, but the original was somewhat of a moving target over time. I think LABs are an improvement over building RSCH inFCT with a 9:1 PRO:USK ratio. Individual TL levels for items also an improvement over a global TL for all items. BEM are a bit of a kludge for a cost to avoid the complexity of building more cargo SHPs. With online design programs much of the tedium of calculations can be eliminated.
One issue is that it is likely we will never see Vern's source code to pin down exactly what is "original". We will have to develop algorithms to fill in the voids and design them to our collective best guess of how they did or how they should work. Much of the Combat code was buggy anyway - for example when you were INVaded all your SLD went to combat and no one left the next turn to man the EWP/MSS. They were supposed to be "released" but I don't think that actually happened in CWT2.
I agree.
For a turn-based game I foresee having order validation with immediate feedback on test turns. While it is simple to associate the order with the S/C "source" the "targets" should also see that order. No, not emery S/C you will fire on but when you look at a system audits orbits you should be able to see which S/Cs have orders to probe it this turn. Also, a robust help/calculation system, so you will not need to do any side math.
Now if we go into a real-time format we just opened up the possibility for an iPhone App to send you push notifications when your SHPs are built or at least email you a few hours before a SHP shows up in your Orbit 11, so you can decide to send a diplomatic message or write your PME/PMM orders.
I have the better part of a week off coming up, so I may play around with a prototype of a real-time version as a proof of concept.
The universe generation can be in whatever language you are comfortable and familiar with because it is external to any web interface.
We really need to develop and test algorithms. I will try to get you the original structure of the tables - although in Microsoft Access, it is strongly typed and will translate well to mySQL.
I want to propose a concept of shipyards, which will serve multiple purposes in terms of playability. One gripe I have with EC is that there is really only one path to victory - building the largest and baddest ships to destroy or chase you enemy around the galaxy. There is really little opportunity to pursue a HAB victory with more medium sized ships colonizing and holding HAB throughout the cluster.
Shipyards can be built on any colony and fit in well with my idea of SHP design templates. These design templates will include all the ASM items defining a SHP class. Shipyards will work a bit like FCT groups, but not exactly.
First, you would create a ship template and then setup a SHIPYARD to build that template. The cost to set up that template would be the ASM items that would make up that SHP. Kind of like prototyping and testing. This would discourage producing excessive designs as the resources for the first ship are essentially thrown away. So if you ultimately build only one SHP in the class it will cost twice the amount of ASM components, 2 would cost 3, 3 would cost 4, and so on - representing economy of scale based on using the same design after paying for development. So, a SHIPYARD is created with a certain class it can build.
Once created, a SHIPYARD will take orders to produce its SHP class. SHPYARDs will be staffed with CNW. If you gave an order for one it would need the normal amount of CNW. If you gave an order for more, you would have an economy of scale in that the number of CNW needed would decrease, based on a square root function. In other words, if you ordered 4 SHPs it would need CNW normally needed for 2 SHPs, an order for 9 would require only 3 times the number of CNW. The game visual aids would calculate how many CNW you would need to assign to complete the order in one turn. Once you complete an order the SHIPYARD can stay idle until you give it new orders to build more ship in that class. So, you could set one up and build 9 SHPs - for 10x resources and 1/3 CNW - and later build one for 1x Resources and 1x CNW
In terms of gameplay, as in my comments to eliminate the MRG command, I would like to get away from completely generic ships. Having an upfront cost will make building the biggest and baddest still possible, but more expensive, particularly if you build only one. SHP classes will also produce ships that enemies can recognize and independently name. When the Klingons spot a Constitution-class cruiser they pretty much know what they're dealing with if they encountered one before.
Hochler.com is hosted on go daddy and I also have access to mySQL databases.
Currently I am trying to learn some more JavaScript as well as node JS and using the react library for the views.
OK. Think about what the different SHP hull types might be called and what advantages/disadvantages each one might have. The basic type would simply be the way to ship hulls are currently working. That SHP hull type might have a bunch of exclusive radio buttons for selecting Base, sleek, bulky, etc. and maybe a checkbox for indicating whether the ship was capable of atmospheric landing. If a SHP and could not land it would be unable to dock with the OPCs or ESCs. There might be some other advantage to this giving up this ability.
BEM is a newer addition to the game. In the old days you needed to build cargo SHPs to move everything. I think POP were excluded primarily for gameplay reasons so you could not save them from capture as they are a more limited resource compared to raw materials or produced items. A question for the community to weigh in on
I have a thought to eliminate MRG for ships. This would be because it doesn’t really make sense to be able to join a captured alien SHP to yours and really expected to be able to fly. I would also change the construction of ships to have templates for ship construction and the ship would have to be completed before he could launch. This way when you saw a SHP you can give it a name for the class and when you would see similar ships you would know that they were of similar construction. Ships would no longer be infinitely modifiable and generic. You could of course re-purpose the ship by junking it and then using the components to build a different class of SHP. It would add to strategy because at some point you would have to decide whether to keep making older TL spare parts for existing SHP classes or just abandon them in favor of a new type of SHP class. If we choose to make cargo holds an integral part of the ship design then maybe we can also make the benefit with regard to transport capacity additionally increased.
To summarize, you would create a ship class template for all the assembled items including maybe the size of the cargo hold. Then you would use your standard ADN orders to add the assembled components until the ship was completed which point you could fly. If I ship took damage you would see it on your scans as a certain percentage of the original assembled items. For each ship class each player can independently give it its own name to be able to recognize that the ship design when I saw it.
I agree that covering your SHP with plywood and cheese (i.e. using food to absorb damage) is a bit of a kluge. Not sure how to fix that given the current combat mechanics. The point I was making about using STUN as armor is that ESH primarily guard against EWP and ANM primarily guard against MSS but shields also get activated at 20% to defend against missiles that blowup so then armor can defend only 20% against energy weapons(i.e. they drill thru instead of blunting area impact)
The increased playability issue is that here is a reason to upgrade STUN TL where there is not one. Ow
I agree that it was a strategy to use STN as additional mass or FOOD as a buffer to absorb damage. I would like to give STUN an additional property to be considered armor so that there is some reason to upgrade on the technology tree. It seemed reasonable since ESH are 100% effective against EWP then STUN could be 100% effective against MSS (by some formula) but less effective (20%) against EWP.
You are correct that the star systems all have one orbit 11 and if there were multiple stars they can have up to 10 orbits with up to 10 planets. The gas giants were rich with fuel and the asteroids were rich in metals and nonmetals. The terrestrial planets (which you call Rocky) were the ones that were general purpose that had the possibility for HAB
I believe every home system had exactly the same resources but can offer no guidance on the local clusters. In CWT2 I built a utility for my Mac which integrated all the turn data from all of my viceroys. When Jay gets back to me his turn data from that game I can integrate those scans and surveys as well. By taking the earliest surveys, we can get a pretty good look at exactly how that game was generated. I will forward this information to you as soon as I get A chance to put them into the database. If you have a Mac, I can also send you the utility to look at the data directly in table views
The web interface could help by telling you how much FUEL it would take to fire all ASMed EWP and ESH, how much for SPD and HEN for in system jump or per light year - maybe with a checkbox to indicate whether to include and assume all ASM and ADN orders worked. In other words, all of the side math should be presented to you and something you don’t have to calculate.
The web program can only do so much because too many calculations will cause it to be less responsive. However, I also do some iOS programming which means we can even have an iPhone app for that to do a more enhanced user interface and advanced calculations.
Unfortunately, the best information I have second hand is that John passed away in 2016. He ran he own game called Ad Astra around the same time as EC. I spoke to Vern about Ad Astra because I though it might be a fun project to put up as a game on the web to attract players to Cluster Wars, which was more complex. Vern was kind enough to send me a rule book, but did not feel comfortable sharing the code as he had lost touch with John.
I see your point, but one goal is to try to make the game less complex, so newer players don't fail because of what they would see as "gotchas". For example, military supplies (MTSP) existed in EC which were really cheap to produce but if you forgot them on your SHP a huge invasion force would be stymied - which is why I assume they have have been eliminated.
If one thinks of FRM-2+ as hydroponic farms for ESC/OBC and FRM-6+ as farms the can exist on SHPs (with higher fuel cost) I would have to imagine that the assumption is the atmospheric management is "baked" into them. Need to keep it simple for (hopefully) new players - i.e. LFS keeps POP breathing and FRM have food to feed to keep alive too. As for FOOD wastage we just throw it in the null entropy bins, like in Dune.
Honestly, I would have to focus first on just getting the game (I think) I understand up and running. New features either have to simplify (like BEM to make it easy to move material in system (as opposed to building cargo SHPs) or be compelling to improving gameplay experience in some way.
I think the deal with factories taking 4 turns to actually produce something is a game play mechanism making it problematic when you run away by packing up a COL into a SHP to avoid being destroyed by a bigger enemy SHP. You can re-STP the COL in 2 turns at another system, but if that bigger enemy SHP finds you before 6 turns you have no gain by running because you could not have produced anything useful to help your defense.
On the other side, if you commit enough CNW, TPT you should be able to ASM a huge SHP in one turn if pretty much all your POP is working on that project.
I think, more exactly, you mean it takes a FCT four turns to produce, although any number can be assembled in a turn given enough CNW and UNAssembled FCT.
Primarily I think we will try to replicate the game (#1) and in that process be guided by the community as to the way the undocumented parts could/did/should work. Testing the parts (new additions or old) would not necessarily require setting up a game. For example, to test different damage allocation algorithms I would set up a test web page where you can see how certain amount of damage would be randomly assigned to a ship you design or a colony where you could prioritize the broad groups of items.
As far as #3, we could have a discussion about which elements we like or not. BEaMers, for instance, nicety or easier gameplay or a kludge for the less experienced player?
Had a radical thought about #2 - a redesign as a real-time (albeit slow) strategy game where your CNW are continually working on a queue, factories are regularly spewing out items, etc. When you see a ship approaching you get a email when they will arrive in orbit 11 (i.e. like on 10/15 @ 13:55)
Much appreciated, will see as this project progresses if I can pass off a portion to you which would be of interest. Right now still in design phase trying to work through algorithms for the stuff that was not well documented or exposed. Figure to use mySQL as a database and JavaScript (which I am learning) along with React (part of Node.js). Any experience with these languages or tools?
Also, universe generation was a bit of a black box too. If you want to think about and workup some code to generate a universe it could be done in any language with which you are comfortable.
No real use for STUN in the game beyond what exists at the beginning and no incentive to increase its TL when SLS is already 10 times better (although you have to make it in an OBC).
What if STN had a protective effect like armor? For the cost of carrying around more mass on a SHP the STN would absorb some damage from enemy weapons before it was applied to the SHP. Perhaps the STN would absorb MSS damage in some amount like ESH absorb EWP - but without a FUEL cost. It would seem that EWP can drill through armor, so say it is only 20% as effective against EWP fire, much like ESH provide 20% effect against MSS that reach the S/C and explode. Feels like a balance in the universe sort of thing.
I have also been thinking that structure in general is light and might take disproportionate damage in combat, often leaving a negative space condition. Also, SLS-10 is much lighter than SLS-1 for the same volume it encloses but by definition of enclosing that space is significantly stronger or a per mass basis. To adjust fo this, I would propose all SLS takes damage as if it has the mass of SLS-1 and all STN takes damage as if it had the effective mass of STN-1.
Thoughts?
The docs and Vern never shared much about the allocation of combat damage - although there was a provision to target general categories of items on COL, but not SHPs. There seemed to be an adjustment down with large amounts of damage - that way my observation and it seems Jay confirmed that with Vern.
I propose this basic mechanism:
Imagine a line of boxes each representing 1 MU (or perhaps 1 volume unit) not he target S/C - which would be as long as there are MU to destroy. All the items in the S/C would each have a representation on this line - say a SEN-1 would have 3000 contiguous boxes. When say 1 MSS-1 hit it would randomly land on the line and take out 100 boxes(MU). More MSS or EWP individually land randomly on the line taking out there number of damage units represented as boxes. With many hits the damage would overlap and be diminished somewhat at random - kind of like you can only die once. If say all those 3000 boxes for that SEN-1 were not destroyed there would be a percentage of destruction above which would destroy that SEN all or nothing. Say it was 50% then 1500 of those boxes would have to be hit to destroy that SEN-1. Each type of unit could have a degree of "heartiness", which could be cut in half when specifically targeted in a COL.
What do you think?