Over the Reich - Creation Thread

changelog 30 November

Removed dependence of destroyer cost on the number of Allied Military Ports. If desired, we should re-introduce it on a unit that can only be built by the Allies.

That's fine - the German incentive to attack these is to make it more difficult /impossible to offload freight, so we don't need the destroyer cost mechanism any more.


Current French train generation scheme:
Full movement point Schutzen, Panzers, Artillery have their movement spent and contribute to a 'score' as follows:
Schutzen 3 points, Panzers 2 points, Artillery 1 point.
First 150 points don't count for anything. For every 15 points beyond 150, a train is generated, to a maximum of 6 trains.
Trains are generated on the tiles (166,144,0), (198,142,0), (214,134,0), in that order. If more than 3 trains are produced, start at (166,144,0) again for the next 3 trains.

Sounds perfect.

I'm currently taking a tax preparation course that has exams on the 14th and 17th, and a case study before that, so I might not get that much done that week. After that I'm free, so I will almost certainly be able to get the stuff done by the 21st. There turned out to be a dead simple way to destroy the strategic terrain on city capture, so I already have more time to devote to clouds at the moment. The more I think about them, the more convinced I am that they won't be too bad to do. I'll do clouds this weekend, and see where I get to.

Good luck with the test!

Is there something I can start thinking of/preparing? Will I eventually need a list of storm center coordinates? I can start gathering a few for heavy, medium, and light cloud cover. I just need an idea of what I need to gather.

I would figure that if the factory is covered by clouds, then it is on a cloud terrain instead of its regular terrain (since there are no clouds on map 1, this doesn't affect production) and will get the terrain defensive bonus anyway. So we don't have to mess around with changing bomb effectiveness.

That's a very good point.

How should reactive fire depend on clouds? Assuming it is about equally easy to do both versions, do you want a smaller chance of damage, or less damage, but the same chance of damage (e.g. 50% of regular chance of a hit, or 50% of damage from a hit). Is flak different? Should it depend on whether the trigger unit is in clouds, or the reacting unit?

I'd say fighter reactions should be halved, bomber reactions should stay the same, and flak should be halved until an advance is researched (I can get you the exact tech number later). There were advances in radar-assisted targeting and proximity fuses throughout the war. I will probably add a proximity fuse tech (we have plenty of spares).

For my part, I'm not sure how much I really need to do a single player playtest, anyway. It's tough to judge balance against oneself. I will likely spend the time remaining methodically going through the features and events and just looking for mistakes or errors that way. I think we identified a large number of issues between our playtest and some of my research tests and I'm pretty confident I've caught most errors at this point, but I'll spend some time with a quality management hat on so that any playtesters can focus on playability/balance.
 
You can use technology 83 for the flak effect. I'm using that as Proximity fuses and it will become available after Advanced Radar II is discovered.
 
12/1/18 (a.m.)
-Added corresponding factory terrain for aircraft factory under (I believe) all units currently on map.
-Changed Wilde Sau references in readme to correspond with current system
-Wilde Sau improvement no longer able to be built and describe.txt and pedia.txt changed as appropriate.
-Updated readme to reflect current points scheme for France
-Renamed "Special Target" "Historic Target"
-Did change rules so that it doesn't look like terrain can get a bonus from irrigation or mining considering that irrigation and mining aren't possible in this scenario. Terrain should now show as "N/A" for any bonus from same.
-Describe.txt is COMPLETE
-Units in describe.txt are complete
-Completed the governments section in describe.txt
-Completed Game Concepts section in describe.txt, mostly by lifting from ReadMe
-Made decision that terrain in describe.txt would take too much time for no benefit - no need for a description.
-Added Proximity Fuse technolgy (83) and references to same in the readme.
-Added neutral territory for Switzerland and Spain so that Allied bombers can't evade German patrols by going into neutral lands.
-Beacuse we'll have moving clouds, I've removed the "special resource" cloud graphic and name from regular terrain so it doesn't confuse players and they don't think they have a defensive bonus when they don't. The regular clouds look much better, anyway.

TO DO:

-Add in section of "naval forces" and "land forces" to the readme
-Give German fuel to start game with
-REMOVE "Defensive fire unit" (110) from secondary attack for light cruiser, heavy cruiser, and battleship - this unit will not be used. Light Cruisers will react defensively and their role is to defend the fleet from air attack.
-Change the freighter reward from Allied Tanks to Allied Infantry. I feel like it is more realistic to have a huge infantry army with a small tank arm than vice versa.
-Change clouds to underlying terrain, including farming, etc. underneath it - please let me know when/if you've determined that the weather will be possible/work and I will then commence this lengthy task
 
Is there something I can start thinking of/preparing? Will I eventually need a list of storm center coordinates? I can start gathering a few for heavy, medium, and light cloud cover. I just need an idea of what I need to gather.

-Change clouds to underlying terrain, including farming, etc. underneath it - please let me know when/if you've determined that the weather will be possible/work and I will then commence this lengthy task

I'm 99% sure my cloud system will work. I expect it to work as follows:

Each 'storm' will have a 'category', an 'intensity', a 'heading', and a 'storm center'. The 'storm center' is the current 'location' of the 'center' of the storm. The 'heading' is the direction it is travelling. This will be mostly eastward, with some deviation northward or southward. The heading will have some random probability of changing a little bit. We won't have westward clouds so that we don't have to worry about what happens when two storm fronts collide.

A storm 'category' has various 'intensities'. A storm category and intensity together choose where there will be clouds relative to the storm center. A lower intensity generally means fewer clouds. The category will tell if the storm is just as 'large' but less densely covered in clouds, or if the storm has a similar cloud density but is simply 'smaller'. Storms generally gain intensity over the ocean (where they are not necessarily visible, since clouds don't cover oceans), and lose intensity over land, but there will be probabilities of the opposite happening. Some storm categories could be lopsided or have clear patches.

I will provide (hopefully later today) a script that will let you place terrain on a map as a representation of clouds, and get the console to print the table constructor for that intensity and category. (Which can then be cut and pasted to the events -- or another file temporarily). It won't be necessary to run it in the OTR game, so you can choose an empty map. TOTPP allows changing terrain in cheat mode using the keys 1-10 (as I find to my annoyance when testing my key press functionality), so building up storm categories will hopefully not be too difficult.
 
Ok. Attached please find a save that has cleared the skies over England and Ireland for testing purposes. I will continue to push forward with removing clouds everywhere else in the meanwhile! Tedious, but achievable.
 

Attachments

Thinking this through some more - the script will probably need to store data for what tiles have farmland, mining, irrigation, and rivers - wipe all of these if a cloud is built over it, and then restore them as well.
 
Here is a script to create tables for cloud patterns. The table constructor will be printed in the console, which you can cut and paste into a text file for use later. We won't put them into the Events.lua file just yet. In fact, we'll probably keep them in the required file instead of the main one.

Open a new game, open the console and load this script. It will give you a little information on the functions. The function 'gatherPattern' is the one that will make the cloud pattern table. setMapTo(10) will make the entire map ocean. From there, choose a terrain type (probably 1 or 2) and set down a cloud pattern on the map (With TOTPP you can use the keys 1-9 to set terrain types). After you have a pattern, use gatherPattern to print the table constructor, and cut and paste it to a spare text file.

Let me know if you need more info.

Thinking this through some more - the script will probably need to store data for what tiles have farmland, mining, irrigation, and rivers - wipe all of these if a cloud is built over it, and then restore them as well.

Uh-oh. Rivers might be a bit of a problem, since we can only set terrain types between 0 and 15, and the river requires us to set a negative number. I don't think this is a problem for high altitude day, but night could be a problem. We could do clouds as fortresses, so clouds disable stack kills rather than offering a defensive bonus (I don't think fortresses help against air attacks). We'll think about it some more. A solution is simply to not cover railroads with clouds, which might be necessary in order for trains to move on the night map anyway.
 

Attachments

A few questions :

1. So am I basically drawing the "starting point" for the clouds as they would appear on the first turn they load?

2. What happens to clouds in the pattern over the ocean? Are they "stored" until they move over land?

3.Do (or could) the clouds "loop" once they hit the eastern edge?

4. I'm fine with their not appearing on rail track on the night map. Do you think the game can store irrigation etc. Or do I need to remove that from the high alt maps?
 
1. So am I basically drawing the "starting point" for the clouds as they would appear on the first turn they load?

Think of it this way: we're going to "stamp" clouds onto the map, and where we stamp is going to be determined by the progression of the 'storm centers'. What you are doing is designing the 'stamp' itself. Every so often, we remove all the clouds from the map, move the 'storm centers' and stamp again. If the storm 'intensity' is the same, then that exact cloud formation is moved east by, say, 10 squares and then placed again. If the storm intensity is changed, then a different 'stamp' is used, but one that is pulled from the same 'box' as the last stamp. Other storms can have different categories, so the 'stamps' for that storm are pulled from a different 'box'. There can be multiple 'storms' on the same map, so you only have to make, say, a 20x20 diamond for a particular 'storm' (and the clouds don't even have to cover the entire 20x20 diamond)

2. What happens to clouds in the pattern over the ocean? Are they "stored" until they move over land?

The 'stamp' won't show up over the ocean, but when the storm moves over land, the new 'stamping' will show up on the appropriate land tiles.

3.Do (or could) the clouds "loop" once they hit the eastern edge?

In my method, once the 'storm' moves off the map, it is gone, but new 'storms' generate on the western side, along with new 'stamps'.

4. I'm fine with their not appearing on rail track on the night map. Do you think the game can store irrigation etc. Or do I need to remove that from the high alt maps?

Yes, I can store terrain improvements. In fact I do so for radar. The problem with rivers is that I can't place them again, since TNO 'guarded' against 'incorrect' assignment of terrain types, by only allowing terrain type assignments of 0-15.
 
Think of it this way: we're going to "stamp" clouds onto the map, and where we stamp is going to be determined by the progression of the 'storm centers'. What you are doing is designing the 'stamp' itself. Every so often, we remove all the clouds from the map, move the 'storm centers' and stamp again. If the storm 'intensity' is the same, then that exact cloud formation is moved east by, say, 10 squares and then placed again. If the storm intensity is changed, then a different 'stamp' is used, but one that is pulled from the same 'box' as the last stamp. Other storms can have different categories, so the 'stamps' for that storm are pulled from a different 'box'. There can be multiple 'storms' on the same map, so you only have to make, say, a 20x20 diamond for a particular 'storm' (and the clouds don't even have to cover the entire 20x20 diamond)

So just to clarify - if I were to draw a "stamp" that looked like a giant "JP", and we then set that to storm intensity "10" then as long as the next time the dice rolls for a storm the intensity is 10, we'd get a "JP" on the map somewhere?
 
So just to clarify - if I were to draw a "stamp" that looked like a giant "JP", and we then set that to storm intensity "10" then as long as the next time the dice rolls for a storm the intensity is 10, we'd get a "JP" on the map somewhere?

The way I think about it (and intend to implement it) is that there are "categories" of storms, and "intensities" of storms of particular categories. Let's call one category of storm "JP Category", and in "JP Category" there are three intensities "Huge", "Big" and "Small". Huge JP Category has a huge JP as the 'stamp', Big JP Category has a big JP as the 'stamp' and Small JP category has a small JP as the stamp.

Let's assume that clouds can be put on the ocean for this example.

On turn 1, the dice roll and somewhere on the western edge of the map, a JP Category Storm is generated. Current intensity is 'small', so a small jp is drawn out in the Atlantic. On turn 2, the storm moves due east 10 squares, and the jp is drawn again, 10 squares east. On turn 3, the 'intensity' changes from small to big, so a big JP is now drawn on the map, even closer to France. On turn 4, the storm move east again, and reaches land. The storm intensity is increased again, so a huge JP is drawn over the west coast of France and England. On turn 5, the storm moves inland, and the intensity falls back to 'big', so there is a big JP over France (and maybe the south of england). On turn 6, the storm intensity falls again, and a small jp is drawn over the border between France and Germany. On turn 7, the intensity diminishes again, but since there is no smaller intensity, the storm disappears completely.

Another storm category could be "PG Category", which would draw cloud covers of PG's of various sizes over Europe, until it either petered out or crossed out of the map.

In practice, since clouds can't be drawn on the ocean, the JP would remain invisible until it reached land.

So, different categories of storm do different things when they change intensity. One kind of storm might keep a large area, but have fewer clouds within that area as the intensity falls, while another category of storm always has dense clouds, but the area of the storm shrinks as intensity falls.

Personally, I would draw the smallest intensity of a particular category, take the 'snapshot' then add more clouds (and maybe remove a few) and take another snapshot for the next intensity.
 
Ok so then I am not painting the entire map full of clouds - I am drawing a particular storm system that could pop up anywhere across the map?

Edit--which should mean I cold draw this system on any new flat map and it needn't be the same size as the scenario map, correct?
 
Ok so then I am not painting the entire map full of clouds - I am drawing a particular storm system that could pop up anywhere across the map?

Exactly.
 
So if I spend tonight making a txt document that looks like this, this is what you'll need?

--System 1 - low intensity
05B04188

--System 1 - medium intensity
05B04568

--System 1 - high intensity
05AFCED0
 
Just realized I need to actually fill out ( ) after gatherPattern - can I use the coordinates for the entire map to simplify or should I work in smaller box?
 
The table constructor would look something like this?

05B04188

No, it will be something like

Code:
stormInfo[1][1]={[1]=true,[2]=true,[4]=true,[5]=true,[6]=true,[7]=true,[9]=true,[10]=true,[17]=true,[20]=true,[24]=true,[25]=true,[26]=true,[27]=true,[30]=true,[39]=true,[51]=true,[58]=true,}

The stormInfo[1][1] doesn't really matter, since it might be changed later anyway, but it will help us keep track of what each table is for.

Just realized I need to actually fill out ( ) after gatherPattern - can I use the coordinates for the entire map to simplify or should I work in smaller box?

gatherPattern(terrainNumber,maxDistance,category,intensity,x,y,z)

Terrain number is the terrain type used to mark where clouds should go. maxDistance is the maximum number of squares from the center that the code will look for 'cloud representing terrain'. If it is larger, than it has to be, it doesn't matter. It's mostly there in case you want to put several 'storms' on the same map before going through with the script and 'making the stamp'.

Category and intensity give stormInfo[category][intensity], which you should probably change so that we can keep track of what each table corresponds to. If x,y,z are omitted, the script defaults to the currentTile.

you probably want to use setMapTo(10) to make the whole map ocean.

EDIT: We probably only need 3 or 4 'categories' of storm just now to work as a proof of concept, even if we want to get variety later.
 
Here is an updated save that totally removes all clouds from both maps as well as a table of 3 categories of storms with 3 intensities each to test the concept:

Code:
gatherPattern(2,20,cloud1,1,21,19,1)
stormInfo[nil][1]={[8]=true,[15]=true,[28]=true,[31]=true,[38]=true,[52]=true,[57]=true,[62]=true,[72]=true,[73]=true,[74]=true,[88]=true,[105]=true,[114]=true,[153]=true,[155]=true,}
table: 06423818


gatherPattern(2,20,cloud1,2,21,19,1)
stormInfo[nil][2]={[2]=true,[8]=true,[15]=true,[16]=true,[18]=true,[28]=true,[31]=true,[38]=true,[45]=true,[48]=true,[52]=true,[55]=true,[57]=true,[58]=true,[61]=true,[62]=true,[63]=true,[64]=true,[65]=true,[67]=true,[72]=true,[73]=true,[74]=true,[77]=true,[87]=true,[88]=true,[90]=true,[91]=true,[98]=true,[105]=true,[114]=true,[115]=true,[153]=true,[155]=true,}
table: 0642B530

gatherPattern(2,20,cloud1,3,21,19,1)
stormInfo[nil][3]={[2]=true,[8]=true,[10]=true,[14]=true,[15]=true,[16]=true,[18]=true,[19]=true,[21]=true,[24]=true,[28]=true,[31]=true,[38]=true,[41]=true,[42]=true,[45]=true,[48]=true,[52]=true,[55]=true,[57]=true,[58]=true,[61]=true,[62]=true,[63]=true,[64]=true,[65]=true,[67]=true,[68]=true,[69]=true,[72]=true,[73]=true,[74]=true,[77]=true,[79]=true,[87]=true,[88]=true,[90]=true,[91]=true,[95]=true,[97]=true,[98]=true,[105]=true,[114]=true,[115]=true,[119]=true,[136]=true,[139]=true,[153]=true,[155]=true,[163]=true,[184]=true,[185]=true,[187]=true,[188]=true,[215]=true,[240]=true,}
table: 06417330


gatherPattern(2,20,cloud2,1,17,21,1)
stormInfo[nil][1]={[24]=true,[30]=true,[36]=true,[37]=true,[48]=true,[62]=true,}
table: 0641D588


gatherPattern(2,20,cloud2,2,17,21,1)
stormInfo[nil][2]={[13]=true,[24]=true,[30]=true,[33]=true,[35]=true,[36]=true,[37]=true,[44]=true,[48]=true,[58]=true,[62]=true,[72]=true,[74]=true,[112]=true,}
table: 06433738


gatherPattern(2,20,cloud2,3,17,21,1)
stormInfo[nil][3]={[5]=true,[6]=true,[7]=true,[13]=true,[24]=true,[30]=true,[33]=true,[35]=true,[36]=true,[37]=true,[40]=true,[44]=true,[48]=true,[58]=true,[62]=true,[70]=true,[72]=true,[74]=true,[104]=true,[112]=true,[150]=true,[152]=true,}
table: 0641A1E8


> gatherPattern(2,20,cloud3,1,18,24,1)
stormInfo[nil][1]={[1]=true,[2]=true,[4]=true,[5]=true,[6]=true,[7]=true,[8]=true,[10]=true,[17]=true,[20]=true,[31]=true,[43]=true,}
table: 0641DF40


gatherPattern(2,20,cloud3,2,18,24,1)
stormInfo[nil][2]={[1]=true,[2]=true,[4]=true,[5]=true,[6]=true,[7]=true,[8]=true,[10]=true,[17]=true,[20]=true,[31]=true,[43]=true,[48]=true,[49]=true,[61]=true,[62]=true,[66]=true,[76]=true,[78]=true,[93]=true,[95]=true,[98]=true,}
table: 0641D568


> gatherPattern(2,20,cloud3,3,18,24,1)
stormInfo[nil][3]={[1]=true,[2]=true,[4]=true,[5]=true,[6]=true,[7]=true,[8]=true,[10]=true,[17]=true,[18]=true,[20]=true,[24]=true,[26]=true,[31]=true,[43]=true,[48]=true,[49]=true,[61]=true,[62]=true,[66]=true,[67]=true,[69]=true,[70]=true,[72]=true,[75]=true,[76]=true,[78]=true,[87]=true,[89]=true,[90]=true,[93]=true,[95]=true,[98]=true,[105]=true,[107]=true,[117]=true,[131]=true,[134]=true,[136]=true,[141]=true,[157]=true,[186]=true,[187]=true,[188]=true,[189]=true,[209]=true,[211]=true,[271]=true,[275]=true,}
table: 0642DBD0
 

Attachments

Just to clarify my understanding further - will we basically be adding a polka dot pattern of some sort to the map of storm centers that clouds can form on? I ask because the examples above are fairly large storm systems but I suppose I should also create several clouds that start with perhaps 2-3 tiles, then 4-5, then 6-7 but are small and localized?
 
Prof. Garfield and I are aiming to release this scenario within a few weeks. Though we've had one playtest, we've changed considerable things based on our findings. It is challenging to self-playtest a multiplayer scenario so we will release this and then take the community's commentary into consideration for potential changes later.

We're hopeful that many of you will start up a game against each other. Perhaps now would be a good time to start thinking about who might partner with you, to make arrangements. Note, this is a 2-player game. It would be great if people who paired up with each other would be willing to attach Prof. Garfield and myself to their private game message or post a thread in the forum so that we can keep track of your thoughts.

This is a scenario that can move fairly quickly. Yes, the first turn of course will be long, but once you get on a role and situated it should prove possible to play up to several turns per day if you and your opponents' schedules align. This could make for a nice change of pace from some of the slower games out there.

Attached please find the completed and revised readme. It is lengthy but should give an idea of how to play this scenario. I thought I would release it now to give everyone a chance to get acclimated sooner than later.

@McMonkey @Northerner @Civinator @techumseh @CurtSibling @Fairline @Tanelorn @Patine @tootall_2012 @voltar
 

Attachments

Back
Top Bottom