Over the Reich - Creation Thread

[JPetroski]

Well I have an issue. Over the past week or so my laptop has been turning off randomly and now it is turning off almost immediately and consistently. Luckily I have backed up every thing I needed to including the scenario but it'll be at least a week before I get this sorted. I'm weighing my options.

I spent a few hours today trying to fix this and don't think its heat so I'm not sure if it is the motherboard or what. I'll try calling a repair place tomorrow and see what they recommend.

If its unrepairable or uneconomical I'll have to consider other options which might take a bit longer. It's not something to jump into...

 

[Prof. Garfield]

It turns out I was prevented from doing much work on the events after all. Since I'll probably be prevented for a few more days, I'm giving back the events. (Though, I see now you might not be in a position to make changes anyway.)

 

[JPetroski]

Yes it is annoying! I believe it is a hardware failure and am waiting on the recommendation. One way or another, I'll be operational within about two weeks.

 

[JPetroski]

I should be operational this weekend, but I dont think I need the events right away if you still have some stuff you want to work on.

 

[JPetroski]

I'm back in business

 

[JPetroski]

I have a few days off to go fishing with my son, who promptly came down with the flu, so now I'm sitting around here while he sleeps quite a bit. Let me know if you're making changes to the events or if they're still available. There's a couple small things I want to fix. Nothing urgent if you're in the middle of things, but I can find some time.

 

[Prof. Garfield]

I haven't done anything to the events. You can use them. I hope your son recovers quickly.

 

[Prof. Garfield]

Honestly you seem rather hard to please. If I build something in Lua and don't post it, I seem to get criticized; when I do post it, I basically get criticized anyway -- or at least "damned by faint praise".

I freely admit there are shortcomings and missing features in version 1.0 -- it was a first attempt, after all -- and this will probably also be true with version 2.0. You are always welcome to build something yourself that works the way you want it to and aligns more perfectly with your needs. Seriously, there are no hard feelings if you prefer to go that route -- it's exactly what I would do if I found resources online that weren't quite what I was looking for. I'm merely offering what I have, no pressure, in case it's helpful.

I'm very sorry.

About the only thing we're not doing in this scenario is modelling supply lines and encirclements. If we were, your supply line module would do a perfectly good job out of the box as it is. It is true that I have a preference for modules where the details for the specific scenario are specified in the events.lua file rather than in the module itself, but that preference is relatively small, and, for all I know, others might actually find it easier to use modules the way you write them. However, to make the supply lines module do what I want (check if there is a path between a unit and a particular city), I need to be able to change the definition of "supply depot" every time the function is used. I may also want to be able to make it so that air units can't block the path, and probably make battle groups block the path from a few squares away, so I would probably need to make changes to that part of the code as well.

I wasn't meaning to criticize or demean your work, but I can see how it could be taken that way. Perhaps an analogy would make my thought process clearer: I need to sink a screw, but don't have a screw driver. However, I do have a sledge hammer, and you have a very nice pair of visegrips. Maybe I can weigh the screw down with the sledge hammer and turn it with the visegrips. It might work, but the result will not be elegant and maybe I'd better think of another way to do this that might work better. Or, maybe, if you're going to the hardware store anyway, you might pick up a screwdriver or, better still, a drill. On the other hand, much of my workmanship is pretty ugly as it is, so I shouldn't get fussy now about how it will look when a screw is sunk with a sledge hammer and visegrips. I wasn't thinking in terms of being polite about the visegrips, since they were bought for a different project and aren't meant to sink screws.

I should have kept in mind that while I was thinking of the supply module as an already existing tool that might or might not meet my needs, it was something that you created and, now that I think about it, hasn't been used in a scenario yet (at least to my knowledge). I apologize for my lack of respect.

 

[Prof. Garfield]

I'll probably get back to this later this week. I've written most of a "text" module (stuff like automatically splitting text into multiple boxes if it is too long, automatically producing a menu from a table, deferring messages until the next after production sequence for the appropriate player, archiving messages to be read later), but I've only tested a little bit of it so far, and I want to post that first.

 

[Knighttime]

Thanks very much for your response @Prof. Garfield; I appreciate you taking the time to come back to this. I'm relieved to hear that I misinterpreted some of your statements, or took them to have a tone you didn't intend.

It is true that I have a preference for modules where the details for the specific scenario are specified in the events.lua file rather than in the module itself, but that preference is relatively small, and, for all I know, others might actually find it easier to use modules the way you write them.

I agree -- ease of use (implementation), and being able to organize or segment code by "purpose" as much as possible, are probably the most compelling reasons for writing modules that are designed to be customized for each scenario. That definitely makes my modules different than true libraries, of course -- and I see a lot of value in libraries as well. Ultimately, I'm hoping that we can draw some (more) scenario designers without a programming background into Lua, and start to get their feedback on what approach has the lowest barrier to entry.

Perhaps an analogy would make my thought process clearer...

Got it. Yeah, I guess your previous comments struck me as either arguing that my visegrips weren't a very effective screwdriver, or -- worse -- saying that I shouldn't have spent my time building visegrips when that isn't what most people need. To use a different analogy, I felt like I built a Model T Ford, and you were plainly unimpressed because you want a Formula One race car. Well, sure, a race car would be great -- and I fully agree that what I've released so far isn't one. But there are also some people out there who are looking for a basic family sedan -- or an 18-wheeled semi truck! My perspective is, hey check this out, I built a vehicle with a working internal combustion engine. Now the door is open to iterate on that and introduce improvements to meet a variety of needs.

I do think that version 2.0 of my module will be going in the direction of making this a more generic tool -- in other words, the trend is towards the broader goal of "pathfinding" and not the narrower one of "supply lines". Since it's still a module that's intended to be edited by the implementer, though, you (or any designer) are welcome to tackle more advanced adaptations as part of that process. Perhaps that's another advantage to this design style -- it lends itself more easily to functionality tweaks that I didn't anticipate or explicitly support.

However, to make the supply lines module do what I want (check if there is a path between a unit and a particular city), I need to be able to change the definition of "supply depot" every time the function is used. I may also want to be able to make it so that air units can't block the path...

I think the upcoming version 2.0 of my module intends to support both of these goals, although the code might not be structured exactly the way you envision it.

... and probably make battle groups block the path from a few squares away, so I would probably need to make changes to that part of the code as well.

Correct... "zone of control" is on the list of enhancements I have not tackled yet. I had jotted down at least two different options for how a designer might want this to work in a functional sense, though, and now you've just raised a couple more: support for an extended ZOC with a radius greater than 1 tile, and having different ZOC rules for a customizable set of unit types.

I should have kept in mind that while I was thinking of the supply module as an already existing tool that might or might not meet my needs, it was something that you created and, now that I think about it, hasn't been used in a scenario yet (at least to my knowledge).

Adoption is always going to proceed pretty slowly in a small community like this, so I'm not discouraged at all. I've actually received several private messages about this module from interested parties, which is pretty cool, so I'm optimistic that a scenario using it will eventually be released. One of those conversations was the impetus for many of the version 2.0 enhancements I've been working on.

 

[JPetroski]

I'll probably get back to this later this week. I've written most of a "text" module (stuff like automatically splitting text into multiple boxes if it is too long, automatically producing a menu from a table, deferring messages until the next after production sequence for the appropriate player, archiving messages to be read later), but I've only tested a little bit of it so far, and I want to post that first.

The events are yours - the only tweak I made was to add the torpedo to the list of units deleted each turn and that's a quick redo later.

 

[Prof. Garfield]

I've started modifying the events.

 

[Prof. Garfield]

Events are available, but post if you take them. (Maybe I'll figure out how to do trainlift, and start.)

Changelog: "Scouting" Implemented
-- Battle Group Scouting
-- Terminology: "Scouting" refers to a unit's ability to reveal certain other units automatically at the
-- start of a turn. Units are "scoutable" if they can be revealed by scouting units
-- If a unit is scouted in a location it can't defend (e.g. canNotDefendAirfield table), the unit will be moved to an adjacent tile if possible.
--
-- If a unit can scout, it is included in this table, and its scouting range in
-- tiles is listed as the value
local canScout = {}
canScout[unitAliases.RedArmyGroup.id] = 10
canScout[unitAliases.GermanArmyGroup.id] = 10
canScout[unitAliases.AlliedArmyGroup.id] = 10
canScout[unitAliases.AlliedBatteredArmyGroup.id]=6
canScout[unitAliases.GermanBatteredArmyGroup.id]=6

local canBeScouted = {}
canBeScouted[unitAliases.RedArmyGroup.id] = true
canBeScouted[unitAliases.GermanArmyGroup.id] = true
canBeScouted[unitAliases.AlliedArmyGroup.id] = true
canBeScouted[unitAliases.AlliedBatteredArmyGroup.id]=true
canBeScouted[unitAliases.GermanBatteredArmyGroup.id]=true

Note that battle groups can't be "scouted" in cities, since they are allowed to stay there, and can't be spotted by a spotter unit outside the city. I think this is both acceptable and reasonable, since cities are large and not easily "scouted" from afar.

Note that only minimal testing has been done for scouting.

Stuff that has already been discussed and must still be done:
Trainlift (which I have to think about how to implement)
Set the airlift flag for all air bases, so that fighter schools can't be used for airlifts
Port sabotage (must decide exactly what to do, or scrap idea)
Allied Port Capture Bonus (decide what it is, or scrap idea)
Make submarines re-spawn in the West, or somehow be more likely to reach the Atlantic. (need specifics)

Anything not in this list, I've forgotten about.

Other stuff that should be done/improved:

Replace the Archive/Newspaper system in OTR with the text library archive system. This doesn't require input or discussion, I just have to do it.

Re-do combat reporting (probably as a portable library). I'm thinking this should be both a "casualty report" style thing (I'm not sure why the actual casualty report doesn't work; maybe TOTPP overwrites that data) and generating a text file that records important events. Both of these things mean the player doesn't have to mess around with logs while they play, so the game goes faster.

If you have ideas for this sort of thing, I'm interested in hearing them.

I'm thinking of a system where the scenario designer specifies a list of "landmarks" (i.e. a tile and a name, cities may or may not automatically be landmarks) and reports are organized based on proximity to landmarks.

Trainlift thoughts and discussion:

The basic trainlift is: If the source has a train yard, destination has a train yard, and track connects source and destination, then the unit is transported either for free or for a fixed fee. I'm inclined to think one trainlift in or out of a city in a single turn, and that all movement should be used up.

A more complicated trainlift would vary the cost based on the distance between the source and destination, and maybe allow fighter-bombers positioned over the track a small chance to destroy (or, maybe just damage) the transported unit.

What would your ideal trainlift do? Is "simple" all you want? If you suggest something that turns out particularly difficult to do, I'll ask if you really want it.

 

[JPetroski]

Stuff that has already been discussed and must still be done:
Trainlift (which I have to think about how to implement)

Set the airlift flag for all air bases, so that fighter schools can't be used for airlifts

-Port sabotage (must decide exactly what to do, or scrap idea)
-Allied Port Capture Bonus (decide what it is, or scrap idea)

In all honesty I'd say we scrap this as it isn't air-power related. Maybe we have a mechanism where the Allies can gain bonus armies on the regular schedule if more military ports are knocked out for the Germans? Say if >50% of the German military ports are out, the Allies get a second army and if >75% are knocked out, they get a third? This puts the onus back on air attack.

Make submarines re-spawn in the West, or somehow be more likely to reach the Atlantic. (need specifics)

-In my 1-player playtest of the current system, what happens is the U-Boats tend to stack up in the North Sea. Playing an actual player, these are effectively out of the game. I'd suggest that we group German ports into two tiers:

Tier 1: Brest, Le Havre, Bordeaux, La Rochelle

Tier 2: Hamburg, Bremen, Wilhemshaven, Lubeck, Kiel, Rostock

The first choice for the spawn should be a tier 1 city with an active military port. If it can't find that, it looks for a tier 2 city with a port. If neither has it, then no U-Boat is respawned.

This would make the French sub pens prime targets and the "main" German ports important too. The other ports will serve other functions but not this.

Replace the Archive/Newspaper system in OTR with the text library archive system. This doesn't require input or discussion, I just have to do it.

Re-do combat reporting (probably as a portable library). I'm thinking this should be both a "casualty report" style thing (I'm not sure why the actual casualty report doesn't work; maybe TOTPP overwrites that data) and generating a text file that records important events. Both of these things mean the player doesn't have to mess around with logs while they play, so the game goes faster.

If you have ideas for this sort of thing, I'm interested in hearing them.

I'm thinking of a system where the scenario designer specifies a list of "landmarks" (i.e. a tile and a name, cities may or may not automatically be landmarks) and reports are organized based on proximity to landmarks.

I like the landmarks idea. If it was as simple as giving each coordinate a name in lua "Paris," "the Channel" etc. and the game reported activity near the landmark, that would be pretty cool. "Heavy fighting over [the Channel] with [X] Spitfires lost." If you put in the functionality for a few of them as a sample and released the events to me, I could do the busy work of putting in all the cities and any other landmarks I think are noteworthy/important.

The basic trainlift is: If the source has a train yard, destination has a train yard, and track connects source and destination, then the unit is transported either for free or for a fixed fee. I'm inclined to think one trainlift in or out of a city in a single turn, and that all movement should be used up.

A more complicated trainlift would vary the cost based on the distance between the source and destination, and maybe allow fighter-bombers positioned over the track a small chance to destroy (or, maybe just damage) the transported unit.

What would your ideal trainlift do? Is "simple" all you want? If you suggest something that turns out particularly difficult to do, I'll ask if you really want it.

I think simple would be fine for this scenario, though I do like the idea of allowing enemy aircraft to potentially intercept, especially if a table can be built where I can determine what aircraft have what chance of effect (so Thunderbolts would be more likely to strike a train than Mustangs, for example).

 

[JPetroski]

I have the events but should have them back to you later tonight.

 

[JPetroski]

I would like to "complete" this scenario within October if at all possible. I'm sure you have other projects that have more luster at this point and I have a few I'd like to play with as well (for example, converting Germanicus on the Rhine to lua events using your converter -- that would be a good scenario to add music to given I know some composers who specialize in Roman-sounding music and allow free distribution of their work if properly credited).

I think that we've dramatically transformed the scenario even from its initial playtest and probably alleviated much of the concerns and issues. I think if we finish up the stuff on your list we'll be in a good spot. The big challenge for me over the next month is going to be aligning the text fields so they match up with all the changes and don't lead people astray.

I do think we're going to need to playtest this vs. humans one last time just to make sure the balance is reasonable and also to fix the odd bug here or there. I'd love a rematch if you're up for it once we wrap up some events in the next few weeks.

I would hold us to not dream up new things to add and only brainstorm ways to fix any critical issues that we unearth, however (with 11 modules and 9299 lines in the main events code, I think it's fair to say we both got a little carried away here, but hopefully you have enjoyed it and had a good place to test theories that will pay off for you in future endeavors too).

 

[Prof. Garfield]

I would like to "complete" this scenario within October if at all possible. I'm sure you have other projects that have more luster at this point and I have a few I'd like to play with as well (for example, converting Germanicus on the Rhine to lua events using your converter -- that would be a good scenario to add music to given I know some composers who specialize in Roman-sounding music and allow free distribution of their work if properly credited).

Yes, that should be possible. I had a bit of an "oh, shiny!" moment with music, but that should be completed the next time I have a few hours to work on it (probably tomorrow). It looks like I have some time off next week, so I will hopefully be able to complete most if not all of the outstanding work next week.

You can probably find some military style music at musopen.org for Over the Reich if you want.

I think that we've dramatically transformed the scenario even from its initial playtest and probably alleviated much of the concerns and issues. I think if we finish up the stuff on your list we'll be in a good spot. The big challenge for me over the next month is going to be aligning the text fields so they match up with all the changes and don't lead people astray.

I do think we're going to need to playtest this vs. humans one last time just to make sure the balance is reasonable and also to fix the odd bug here or there. I'd love a rematch if you're up for it once we wrap up some events in the next few weeks.

I was thinking that maybe we could screencast and post to Youtube the gameplay. If I get automatic logging to work, we won't have to spend time making notes for the next player. Also, if we've done our job right, turns should only be 10-15 minutes, which is a reasonable length for a video.

If you want to do this, and you want custom music, it might be best to search the royalty free music Youtube provides for military style music so we don't have to worry about content ID. Or, we just leave the TOT soundtrack, which doesn't seem to be in their system.

I would hold us to not dream up new things to add and only brainstorm ways to fix any critical issues that we unearth, however (with 11 modules and 9299 lines in the main events code, I think it's fair to say we both got a little carried away here, but hopefully you have enjoyed it and had a good place to test theories that will pay off for you in future endeavors too).

I learned a lot working on this project, and I'm very glad that I did.

To keep things simple and the project on track, I'll just do the most basic trainlift (fixed transport cost, no fighter interception). If we get a lot of repeat players, the scenario can always be changed later.

You play music on the first turn of the scenario, for both the Allies and Germans. I believe that uses a playSound event. I can make it work as a playMusic event instead (even without the custom music event I'm working on), if you would prefer.

 

[JPetroski]

You play music on the first turn of the scenario, for both the Allies and Germans. I believe that uses a playSound event. I can make it work as a playMusic event instead (even without the custom music event I'm working on), if you would prefer.

I was thinking that maybe we could screencast and post to Youtube the gameplay. If I get automatic logging to work, we won't have to spend time making notes for the next player. Also, if we've done our job right, turns should only be 10-15 minutes, which is a reasonable length for a video.

If you want to do this, and you want custom music, it might be best to search the royalty free music Youtube provides for military style music so we don't have to worry about content ID. Or, we just leave the TOT soundtrack, which doesn't seem to be in their system.

I think that a "let's play" might be helpful for a scenario that changes the game as much as this does. It also might help draw some bites over to ToTPP in general. To avoid legalities I'd probably just temporarily disable the scenario music (it's not that critical after all) though perhaps putting the TOT soundtrack back in would be nice. I feel like I haven't heard it in ages.

The events are available. I'm going to see what I can do about tackling more of the text files over this weekend. I have to travel most of next week for work so I need to get done what I can while I'm here.

Changes:

I focused on some balancing aspects. In my initial playtest I've found that the payload (as expected) had a big impact on points, so I'm playing with the numbers a bit to compensate:

-Added torpedo to units to be deleted each turn
-German score increment per turn = 0 (now that we aren't reducing it when the Allies score, there is no need for this)
-German score for killing an Allied heavy bomber is now 0.1 instead of 1 (they kill *a lot* of heavy bombers).
-Increased Allied score for destroying any industrial target to 7.5 to match urban (payload seems to necessitate this per testing. Also urban is a good target for several reasons now and doesn't need extra incentive)
-Increased Allies score for freighter from 2 to 6 (there are less of them now).
-Increased fuel bonus for political support from 4000 to 6000

 

[JPetroski]

Edit - never mind - I found the file in the one you sent while my machine was out of business.

 

[Prof. Garfield]

I have the events.