Under the Comanche Moon (dev thread)

ThichN

Prince
Joined
Aug 15, 2022
Messages
304
Under the Comanche Moon
Development Thread

1701888976298.png


Premise
Under the Comanche Moon puts the player in control of the "Lords of the Plains," the Comanche people / "empire" that stretched from Texas to Colorado, and raided well beyond. The scenario will take place from 1836 to 1861, and begins after Texas has won its war of independence against Mexico, and directly after the Comanche raid on Ft. Parker, where a war party kidnapped Cynthia Ann Parker.

The date was chosen for a few reasons: while the Comanche rise to power in the southern plains and 18th century wars against Spain and the Apache are fascinating stories, they also pose less of a challenge to the player. The 25 years after Texan independence would mark a massive increase in settlers/homesteaders to the West, and see the Comanche giving -- for a time, at least -- Texan, Mexican, and US authorities a run for their money. This all abruptly changes, in history, with the spread of disease, the lack of unity among some Comanche tribes and allies, the railroad / rapidly diminishing bison population, and the booming population of "Anglos" in the Texas area. Eventually outnumbered, out-gunned, and their buffalo dying in droves, the Comanche would surrender to reservations, but hold on to threads through the 1870s.

This scenario ends at the start of the American Civil War. The goal is simple: bring the West to its knees. What this looks like, to the Comanche, is enough fear and intimidation to slow down settlement, and to create a renewed demand for a clear, demarcated boundary/border (historically, something the majority of Comanche tribes attempted to bargain for, and almost got [but we know how that turned out for the Lakota...]). So it isn't to annihilate everyone. In fact, this scenario's strategy will lie in formulating a delicate balance: anger frontier American/TX settlements too much, and you'll have to contend with more elements of the US military than you can handle. But some of their people will need to be raided. Goods stolen. Guns taken. People taken, too. The West is not black and white.

Texas is another story. A fledgling nation (though most, even at this time, assumed an eventual joining to the US) with US support -- but not necessarily guarantees -- means that some of their frontier towns are ripe for looting. Yet they also generate profitable trading houses, good for the Comanche, who are wealthy in horses and require other goods. This is another balance: to raid, or to trade? Raiding is more immediate, good for the short term. Trading is a bit more sustainable. But one thing is clear: the Comanche will need guns and ammo and experience.

Then there is Mexico. Mexico is an "easy" target: civil disorder, unrest, and an unreliable central government from Mexico City means that the entire northern Mexico frontier is virtually undefended. A recent humiliating defeat by Sam Houston has also left the military in shambles. Still, the Presidios along the Rio Grande are walled with thick stone and cannon... dangerous, but tempting, targets, if they can be breached. Easier, though slightly more involved, are the frontier towns. Cattle can be taken, and more horses. These can be sold to the Anglos, and traded for guns.

Throughout this, there are wild card characters that may tip the balance, if cards are played right: the Apache, while soundly defeated by the Comanche and pushed out of the plains, are vengeful and still roam West Texas and Mexico. The Cheyenne and Arapaho are not quite as bitter enemies of the Comanche, but will not hesitate to attack -- until, perhaps, an alliance can be forged. Yet they have their own enemies: the Osage. Furthermore, Mexico has placed a bounty on Comanche scalps. Who knows what riffraff will come out of the woodwork to hunt you down. Then there are the Comancheros to the West, locals of Nuevo Mexico, who are willing to ignore orders from Mexico City to continue a healthy trade relationship with your braves. Could they become a steady source of arms?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Some Oversimplications
In the name of trying to make a fun scenario, the Kiowa are being lumped together with the Comanche. There will be a unit or two to represent the Kiowa. They were allies, and often raided together. Therein lies the main oversimplification, though: that the Comanche were ever a unified group of people. Historically, they were dozens of bands, with some major ones representing. They did often raid together, and in large numbers, but did not have any kind of centralized authority. In this scenario, the player gets to control all of these tribes, and with this unity, can hope to tilt history in the favor of the Numunu people. Some mechanics will simulate the "disunity," or potential conflict/disorder there. But generally speaking, I want you, the player, to have a tool chest to change history with and explore this part of history and the West. Additionally, the subject of how important guns were to the Comanche in particular is disputed. Braves would often fire once, drop the gun, and move in with their bows and arrows and lances. Yet guns, if anything, were symbols of battle prowess for many braves, and having them represented an advancement in fear factor and adaptability. Part of the a-historical narrative of this game is the opportunity for the player to procure guns to arm their braves with more widely, especially in later years when they'll become more available.

...And Fictionalizations
Finally, I aim to have some pretty fun unit types floating around, that may fictionalize aspects of the West -- or perhaps, over-embellish. Vigilantes will prowl Texas if too many women/children are kidnapped, leading to the Texas Rangers. Wanderers will roam the mountains, and can be bargained with. Historical events will occur, absolutely (the Mexican-American War, which the Comanche can take advantage of if they wish, the movement of settlers along the Santa Fe Trail and beyond, the discovery of gold, etc.). However, some other, non-historical events or characters may arise, too, depending on player choice. I am for strong historical, semi-realistic bones, fleshed out with imagination and possibility.

On Timeline
I know that Adobe Walls and Palo Duro Canyon were major sites of Comanche/US armed engagement. Nevertheless, they were very late encounters, and actually quite minor on the grand scale of things, being more symbolic of the end of both the Comanche and free-roaming bison herds. Qanah Parker is an interesting character (his father, Peta, will lead the Comanche in this scenario), but ultimately, I think 25 years is a good chunk of maximum time for the scenario. At 12 months/year, we're looking at 300 potential turns. Yikes. But the player can certainly win before 1861.

Victory
"Victory" is all relative here. There will be no Comanche raids on Washington. Victory, as mentioned above, will be to unify just the right numbers of tribespeople, gain suitable numbers in the face of disease and onslaught, develop your bands, and create a balance between defending your land and annihilating frontier towns and setting back the waves of settlement just enough. The Anglos are notorious for signing deals when convenient, and not honoring them later. Your job will be to force them to honor the deal.

Playable Civs
Only the Comanche

Other Civs
Americans
Texans (allied w/US)
Mexicans
New Mexicans (allied w/Mexico)
Plains Tribes (representing Cheyenne + Arapaho)
Apache

The Map
A huge map that covers all of Texas and adjacent American territory, Colorado, New Mexico, and North and North-Central Mexico, as far south as Guadalajara. I aim to capture the vast distances and disparate groups of people connected by the Comanche range. Comanche units, in my current thinking (if mounted) have alpine and a fairly high movement rate, allowing them to move from the panhandle of Texas to Durango in a single turn (preferring some terrain, at the cost otherwise of some HP). I'm utilizing all available terrain types.

comancheria.png


Work in progress. Featuring the high plains, cross timbers, and hill country, the Red, Arkansas, and Rio Grande w/ocean tiles, countless other rivers (can't see when zoomed out), and Mexican frontier towns flanked by the Sierra Madre. Pretty sure I'll use 1 terrain slot to be "impassable" black tiling, which will be placed over the oceans.

Some Game Concepts
The Economy: I'm working on a new in-game economy for this scenario. The player, the Comanche, do not have or ever maintain cities, keeping with their presence as a nomadic people. Instead, they have tipis and bands clustered in 3 primary locations to start with, which can be expanded or settled elsewhere. It is in these tipis that Comanche units are made. The tribespeople chain is essentially: women -> children -> youth -> women/warriors -> braves (also need to win a few fights to get here) -> chief. Maintaining populace, keeping everyone fed and warm, and keeping tribe numbers up was essential to survival.

Chiefs (Paraibo) can create new tipis.​
Hides are the backbone of the economy. They can be harvested by a specific Bison terrain tile by Youth, Warriors, and Braves, and "carried" using @Prof. Garfield 's wonderful landCargo module in lua. They can then be taken to a tipi and "used." To upgrade all of the units in the chain, you need hides. To create a new tipi, you need hides.​
Bison tiles are generated randomly each turn (each game month). This is a tile type that is placed on High Plains tiles, and moves around each turn, simulating moving herds. Warriors must go to these tiles and press a key to harvest hides. The numbers of bison could decrease as the game goes on, depending on player actions. This will be a huge handicap for the player, so it is a goal to keep those numbers up.​
But hides are useful for another reason: coveted by folks from the east, they can be traded for Guns. Guns can be carried by any mounted Comanche unit and taken back to tipis. They are required to create 1 variant of Warriors (w/guns; the more powerful variant), and to create Braves (in addition to hides). These units will be essential for combating encroaching settlers and military personnel.​
Horses are represented with gold (the word changed from gold to horses). Horses can also be traded for guns (purchased, essentially). Horses are also needed for units in that chain above.​
Historical events will roll through the game world. You can interact with them, and potentially use them to your advantage. Depending on player actions, non-historical events may also occur.​
Diplomacy will not exist in Civ2 game form, but will be via menus where you can craft temporary agreements. This can buy you time (but can also buy your enemies time).​
Settlers/Homesteaders will take off from Independence, MO and head westward. Raid or trade or leave alone?​
Take Captives in your conquests, which can be used in tipis to create other units, or bargained for through trading houses.​
Towns will be destroy-able, and destroying enough will tick objective boxes for the player. Still need to figure objectives out, though.​
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Current Status
I have much of the lua started (mechanics). No events yet, though. Cities are placed. Units file and most other graphics completed.

That's all for now! I thought it good to make this specific place for all of the questions I've been asking recently. I learned a lot from making my mod (which I am still working on updating!), and wanted an outlet to put some of the ideas I had floating around.
 
Last edited:
Lua question! I am getting this error:

Spoiler :
Code:
...e of the Summer Moon\MechanicsFiles\keyPressSettings.lua:309: attempt to index a nil value (local 'unit')
stack traceback:
    ...e of the Summer Moon\MechanicsFiles\keyPressSettings.lua:309: in field '?'
    ...e of the Summer Moon\LuaCore\discreteEventsRegistrar.lua:383: in field 'performOnKeyPress'
    ...mancheria\Scenarios\Empire of the Summer Moon\events.lua:624: in function <...mancheria\Scenarios\Empire of the Summer Moon\events.lua:622>

This is my code in keyPressSettings.lua:

Spoiler :
Code:
    discreteEvents.onKeyPress(function(keyCode)
local unit = civ.getActiveUnit()
if unit.location.terrainType == 7 then
    if keyCode == keyboard.h and unit.type == unitAliases.Youth then
        local newHides = civ.createUnit(unitAliases.Hides,unit.owner,unit.location)
        gen.setToSleeping(newHides)
        unit.moveSpent = 255
    end
    if keyCode == keyboard.h and unit.type == unitAliases.Warriors then
        local newHides = civ.createUnit(unitAliases.Hides,unit.owner,unit.location)
        gen.setToSleeping(newHides)
        unit.moveSpent = 255
    end
    if keyCode == keyboard.h and unit.type == unitAliases.Braves then
        local newHides = civ.createUnit(unitAliases.Hides,unit.owner,unit.location)
        gen.setToSleeping(newHides)
        unit.moveSpent = 255
    end
    if keyCode == keyboard.h and unit.type == unitAliases.HardBraves then
        local newHides = civ.createUnit(unitAliases.Hides,unit.owner,unit.location)
        gen.setToSleeping(newHides)
        unit.moveSpent = 255
    end
    if keyCode == keyboard.h and unit.type == unitAliases.BravesGuns then
        local newHides = civ.createUnit(unitAliases.Hides,unit.owner,unit.location)
        gen.setToSleeping(newHides)
        unit.moveSpent = 255
    end
    if keyCode == keyboard.h and unit.type == unitAliases.HardBravesGuns then
        local newHides = civ.createUnit(unitAliases.Hides,unit.owner,unit.location)
        gen.setToSleeping(newHides)
        unit.moveSpent = 255
    end
    end
end)

Any ideas what could be going wrong?
The actual keypress event is working great. When I press "v" to get a cursor or otherwise end my turn or hover over the unit in question, it creates this error.
Note: I am aware that "h" leads units to home city, but as the Comanche have no home city, I do not need the key for that purpose.
 
Lua question! I am getting this error:
"Attempt to index a nil value" is the error you get when you try to get the value for a key, but the table/object you're trying to 'index' (get the value for a key) is actually nil.

In this case, civ.getActiveUnit() returns nil if there is no unit currently active. That means that the `unit` variable is nil, so you get this error when you press h in view mode.

Try something like this:
Code:
if not unit then
    unit = civ.getCurrentTile().units()
tile.units is an iterator for the units on the tile, meaning that tile.units() gives the "first" unit on the tile.
 
"Attempt to index a nil value" is the error you get when you try to get the value for a key, but the table/object you're trying to 'index' (get the value for a key) is actually nil.

In this case, civ.getActiveUnit() returns nil if there is no unit currently active. That means that the `unit` variable is nil, so you get this error when you press h in view mode.

Try something like this:
Code:
if not unit then
    unit = civ.getCurrentTile().units()
tile.units is an iterator for the units on the tile, meaning that tile.units() gives the "first" unit on the tile.

Thank you! I tried placing that in a few different spots in the code, but no luck. The error is happening only with keyPress events that require specific terrain types to activate (I have another unit that does this on any terrain, and it works well!).
 
I made a backup of my files and went into Lua Core into munitions.lua and added a tertiaryAttack, and it is working well! Is there anything I should be aware of as to how this could break other things? At the moment: "k" generates Hides when on Bison terrain, "u" generates arrows for those units that use them, and "p" creates a new unit using resources on the tile.

A note: my "generateUnitFunction" for secondary attacks does not work (this is before meddling with munitions.lua). Generating the Hides for a primary attack successfully puts them to sleep immediately, and therefore in the inventory of the unit, but for secondary attacks the unit does not sleep.
 
I made a backup of my files and went into Lua Core into munitions.lua and added a tertiaryAttack, and it is working well! Is there anything I should be aware of as to how this could break other things? At the moment: "k" generates Hides when on Bison terrain, "u" generates arrows for those units that use them, and "p" creates a new unit using resources on the tile.
I don't think anything will break, based on a quick look at the code in the template. However, I think if the tertiary attack uses the payload mechanic, the re-arming functions won't work.

A note: my "generateUnitFunction" for secondary attacks does not work (this is before meddling with munitions.lua). Generating the Hides for a primary attack successfully puts them to sleep immediately, and therefore in the inventory of the unit, but for secondary attacks the unit does not sleep.
I don't know why this is, since the primary and secondary attacks use the exact same code. What happens if you change which attack gets the "primary"AttackTable and "secondary"AttackTable? This could help distinguish if it is a problem with the secondary Attack, or the secondary Table.
 
Sorry, I misspoke there. When the function is placed in the primaryAttackTable, it operates correctly: Hides generate and immediately are set to sleep. If put into the secondaryAttackTable, they generate, but do not go to sleep. Happy to send you code if it will help! I'm great with the hides being the primary attack, but was just curious.
 
Sorry, I misspoke there. When the function is placed in the primaryAttackTable, it operates correctly: Hides generate and immediately are set to sleep. If put into the secondaryAttackTable, they generate, but do not go to sleep. Happy to send you code if it will help! I'm great with the hides being the primary attack, but was just curious.
If the exact same code generates sleeping hides when in the primaryAttackTable, but not when in the secondaryAttackTable, then I'm interested in seeing the code. Both tables should be exactly the same, apart from the key that triggers them.
 
A note: my "generateUnitFunction" for secondary attacks does not work (this is before meddling with munitions.lua). Generating the Hides for a primary attack successfully puts them to sleep immediately, and therefore in the inventory of the unit, but for secondary attacks the unit does not sleep.
It turns out the "U" key wakes up all ground units under the active unit. That's why the units don't sleep like you want them to.
 
Is there any way to delete/kill all units on a tile if that tile meets certain conditions (e.g., if a unit enters the tile?)?
Code:
for unit on tile.units do
    gen.killUnit(unit)
end
 
Latest lua question:
I'd like to "force" some AI units (Wagon Trains) to move westward on the map along a certain set of coordinates. "gen.moveUnitAdjacent" seems like it would work well, but not sure how to utilize it appropriately. If I gathered a specific set of coordinates of adjacent tiles in a pathway, could I somehow map these units' movement along that pathway fairly consistently, then having them "delete" at the end? What happens if a unit gets in their way? Will they simply not move, or find a different tile, but try for that path each time?

This feels exciting to me, if it is possible. I'd have Wagon Trains generate (first one IIRC is 1836, the starting year of this scenario), and the player can interact with them in numerous ways, but they'll always keep moving. When the Mormons begin migrating, could be another interesting event. It also provides north of Arkansas river interaction in addition to the Kiowa and Osage.
 
I'd like to "force" some AI units (Wagon Trains) to move westward on the map along a certain set of coordinates. "gen.moveUnitAdjacent" seems like it would work well, but not sure how to utilize it appropriately. If I gathered a specific set of coordinates of adjacent tiles in a pathway, could I somehow map these units' movement along that pathway fairly consistently, then having them "delete" at the end? What happens if a unit gets in their way? Will they simply not move, or find a different tile, but try for that path each time?
gen.moveUnitAdjacent uses civ.teleportUnit/unit:teleport to put a unit in an adjacent square. Its intended use was to move a unit off a tile, if you wanted to place a different tribe's unit on that tile (or uncover an air protected stack). If you already have a known path for the unit to follow, civ.teleportUnit is the appropriate tool.

Alternatively, you can just give AI units goto orders to a destination, although they'll stop if they come across a foreign unit. The "role" of the unitType can matter here. JPetroski had some trouble forcing freighters to move across the sea, since the AI wanted to override their orders to use them as "sea transports". Changing their role (I think to attack) solved that problem.
 
Thanks Prof.! Here is what I tried, and changed the role to 0. The unit generates and is moving around, but definitely not towards the coordinates I provided. I even made sure they had "mapped out" a route to the coordinates (not unmapped terrain). Any ideas? civ.teleportUnit is my next option. In this, I'm assuming the unit can "hop" from one coordinate to the next?

Code:
    if turn == 7 then
        local newWagon = gen.createUnit(unitAliases.WagonTrain, civ.getTribe(6), {145,13,0}, {homeCity = nil, veteran = nil})
        gen.setToGoingTo(newWagon, {34,60,0})
    end
 
Top Bottom