I recommend tweaking how battles work. Irl, armies routed at 30% casualties. Fights to the death almost never happened.
I think this has real legs. However I would make one or two suggestions. Firstly, I think that there are too many vowels in the city/nation names, and so perhaps you could have more letter combinations that contain consonants. In addition, I would like to see nation borders on the map. You could have them coming out from cities to a certain distance, with them also running as straight lines equidistant from border cities. I don't know how difficult this would be due to my limited use of Tkinter.
I'm really not knocking it though, it's fantastic and far better than I could do. I wish you very well.
Bug found.
It freezes sometimes after a battle when reinforcements don't work.
The Meritocracy of Zouym has triumphed with 54 remaining troops!
They have taken the city of Udmqx from The People's Oligarchy of Xa.
Exception in Tkinter callback
Traceback (most recent call last):
File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1539, in __call__
return self.func(*args)
File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 590, in callit
func(*args)
File "./history_generator.py", line 129, in main_loop
i.move_armies(flatten([nation.moving_armies for nation in self.nations if nation != i]))
File "/home/thomas/Downloads/Spiele/History Generator/History Generator/civil.py", line 348, in move_armies
moving_army.step(armies)
File "/home/thomas/Downloads/Spiele/History Generator/History Generator/group.py", line 25, in step
self.on_end(self)
File "./history_generator.py", line 314, in do
self.attack(attacker, attacker_city, attacking.members, defender, city)
File "./history_generator.py", line 334, in attack
if not battle.check_end_battle():
File "/home/thomas/Downloads/Spiele/History Generator/History Generator/martial.py", line 516, in check_end_battle
self.battle_over(self)
File "./history_generator.py", line 362, in end_battle
attack_city.capture(battle.a_army, a)
File "/home/thomas/Downloads/Spiele/History Generator/History Generator/civil.py", line 48, in capture
self.nation.cities.remove(self)
ValueError: list.remove(x): x not in list
can't invoke "event" command: application has been destroyed
while executing
"event generate $w <<ThemeChanged>>"
(procedure "ttk::ThemeChanged" line 6)
invoked from within
"ttk::ThemeChanged"
- Stopped cell information window from opening on a focus switch to the map view.Could you add an option to not display battles? It's annoying when I let this run in the background and every two seconds the battle window pops up in front of whatever I am doing at the time.
so many updates
i've got whiplash
:P
No screenshots? :o
I haven't checked the latest version yet, but unless this means what I want (which I doubt)Quote- Stopped cell information window from opening on a focus switch to the map view.Could you add an option to not display battles? It's annoying when I let this run in the background and every two seconds the battle window pops up in front of whatever I am doing at the time.
Wow. I am incredibly impressed. How have I never seen this before?
I've thought occasionally about how I'd do something like this and while you've approached it very differently to my thoughts, I can't argue with the results.
You seem to have built, looking through a couple of the scripts very briefly, a lot which isn't yet used. I'm curious, what are you planning to use people and offices for? (Unless I'm being stupid and have missed it...)
Are the reinforcements other armies arriving or something else entirely? How are you working out the rate at which reinforcements arrive and how many start on the battlefield?
I don't know whether this is a bug or intended behaviour (the eternal conundrum...), but most nations seem to be using almost entirely ranged units.
A few comments:
- In battle, I'd make the arrows fly faster. As in, at least two or three times as fast. Archers seem to be having a lot of trouble dealing with smaller units or fast-moving ones, and that could deal with that problem, as well as improving their ability to deal with a large number of units. This should also stop units running out of ammunition so quickly.
- I'd recommend removing some of the lighter colours, as I am having difficulty seeing them on the world map, and find it impossible to see their arrows, especially.
- Some battles last a long time, simply because the reinforcements are coming on so slowly. Like I said earlier, I don't know how it works, but it seems a bit odd having over 700 reinforcements arriving in units of 10 at a time.
- I'd also either make the armies smaller or have each individual represent multiple soldiers. I feel that the battles are slightly too large for the system you're using.
So yes, seriously impressed by this and looking forward to seeing it progress!
You're right, that means that the first click (to focus on the window when its not already focused), won't open the information window for the cell. However, I did address your problem in this release, there's now a checkbox you can click on and all the battle windows will start minimized instead of popping up over whatever you're doing.Thanks! That helps a lot.
Reinforcements are more troops from the same army arriving. Essentially, each battle is a series of skirmishes. I created this system because it made the battles run much much faster, having 10000, 20000, or possibly more troops on the screen at a time is just too slow. As for using all ranged units, well, they shouldn't. It's a 50-50 chance for each unit type, so it should be pretty even. Based on my own observations, it seems to be working as intended (although perhaps that's not the right ratio for ranged to non-ranged unit types, but that's a separate problem).I think I have seen that there are different unit types (further divided than only ranged/close combat, based on unit size, attack/defense, movement speed…). It also seems that reinforcements always arrive in a certain order, that is, first comes one unit type and when those are all done for the next unit type appears and so on.
Anyway, you can use python to exe program, to turn your code into executables and then people will not need to have python to run.I prefer source distributions. I am on Linux, meaning that I cannot run python programs packed up in an *.exe when I could run them just fine if they were distributed in source form.
I think I have seen that there are different unit types (further divided than only ranged/close combat, based on unit size, attack/defense, movement speed…). It also seems that reinforcements always arrive in a certain order, that is, first comes one unit type and when those are all done for the next unit type appears and so on.
It seems strange.
Also it often enough happens that one army sends much more per skirmish than the other one despite having less reinforcements overall. The army sending more troops at once seems to be at an advantage.
Some fights can be pretty one-sided, completely independent of unit size. Some units just mop up opposing units. It almost seems as if one soldier there can kill hundreds of enemies before dying. Just now I observed a battle where close-combat units were doing moderate damage to ranged units. When the ranged units ran out of ammo and went to close combat themselves, they suddenly dominated the battlefield.
Another thing about battles: I have seen some ranged squads that were way more effective as soon as they ran out of ammo and started engaging in close combat. When they are attacked before running out of ammo they insist on continuing to use their ranged weapons, though.
I get why you'd want to use a ranged weapon instead of charging into battle. That one makes perfect sense, especially when you need to cross some distance in which you do no damage while receiving damage from enemy archers (or whatever they are).
It doesn't make sense to fire ineffectively into the guy who's charging at you and already at close distance when you could do way more damage (and thus prevent your demise) by using your close combat weapon.
It would be cool if every ranged unit had a close-combat distance. If an enemy squad gets closer than that, they should change to melee and charge to meet their attackers.
I prefer source distributions. I am on Linux, meaning that I cannot run python programs packed up in an *.exe when I could run them just fine if they were distributed in source form.
Anyway, you can use python to exe program, to turn your code into executables and then people will not need to have python to run.
- Units will now switch their targets to the closest unit every few steps even if their previous target has not been fully killed.Dedication is good, but it can be overdone. Good the soldiers now understand this, too.
- Fixed battle sizes (now troops are actually in the right proportions).Yeah, that didn't seem right.
The reason that some units seem to mop up the battlefield while other fights are much more even is that the attackers have a fully trained army, whereas the defenders are all levies drawn up from the general population. Armies in the defending city only actually participate in the battle if its the nation's last city, otherwise they run away to other cities owned by the nation.Ah, that makes sense.
Looks really cool how the shooters run to meet their attackers. From the first few battles I've seen now it looks like their survivability went up, but that's rather hard to judge. At least it doesn't feel anymore like they're getting slaughtered without putting up resistance and a single melee unit normally doesn't destroy multiple waves of ranged units anymore.QuoteThe reason that some units seem to mop up the battlefield while other fights are much more even is that the attackers have a fully trained army, whereas the defenders are all levies drawn up from the general population. Armies in the defending city only actually participate in the battle if its the nation's last city, otherwise they run away to other cities owned by the nation.Ah, that makes sense.
I see potential for diversifying nations here: Give every nation some fraction between 0 and 1. That fraction determines what portion of an army stays in an attacked town for defense. Take the square root of this number if the capital city is attacked. That same fraction would be used to determine how large the armies are that get send out for attack – larger fractions mean less troops are sent, to keep them prepared for defense.
A problem with the world map: It is obviously larger than the part that is shown in the map window, but scrolling around is not possible, as far as I can tell, so I never get to see some of the cities. There have been a few games where many (a majority of?) battles happened in cities I couldn't see. Maybe even just center the map on the city last attacked?
Actually it isn't, the cities just can't expand past it. Now I've made the world wrap around though (but I'm not sure this is the optimal solution, just the easiest. I might make the world bigger than the screen later, but I'm not really sure because that's a pretty drastic change with how everything is set up), so they just expand to the other side.Well, that change certainly fixes that problem, but this makes me wonder – the cities certainly weren't displayed on the map. So, where were they?
Well, that change certainly fixes that problem, but this makes me wonder – the cities certainly weren't displayed on the map. So, where were they?
One thing I noticed was that city growth is unlimited (as long as there's no other cities in the way). The need for food alone doesn't seem to be sufficient for limiting that. Maybe introduce building material as a limited resource that can only be obtained from nature (and then gets depleted) or by tearing down parts of already built stuff? That doesn't seem too sensible. Hrm…
improvement_chance = self.building_count() // int(log(self.population))+ 1This is causing a division by zero, which is what you probably wanted to deal with by adding this +1 at the end. The problem is, of course, that division has higher priority than addition, so it should look like this: improvement_chance = self.building_count() // (int(log(self.population)) + 1)
Only downloaded the new version now, haven't played it yet.
Terrain should do nicely, especially with regions in which building stuff is impossible or extremely hard – mountains, oceans, lakes, swamps…
Regarding the size of cities: I think there's a mismatch between what I expect the size of the world to be and what you intend it to be. I don't know, somehow the fact that the whole map is closed an wrapping implied that I am looking at something Earth-sized. Even if it was only the size of Asia or even Europe, the cities still would be excessively gargantuan.
But now that I think about it, if the map was actually Earth- or Asia-sized, the resolution probably wouldn't be large enough to allow city growth across the grid and I think it would be very limited with Europe-size, too.
What is the size of the map intended to be?
Add specific tile sizes and multitiles to, with that, have something dwarf fortress dont have.
Also it becomes easier to think about stuff later, as some example human walking speed, jump, falling damage and etc... is totally unrelated in DF
If you have any ideas for how to do the terrain, I'd appreciate them.Well, this is a far shot, since it's really computationally intensive, but it has really awesome results:
Well, this is a far shot, since it's really computationally intensive, but it has really awesome results:
Worldengine (https://github.com/Mindwerks/worldengine)
That thing does pretty good plate tectonics and then computes biomes, but startup time if you used this would probably be a few minutes or maybe even an hour, depending on size. Maybe generate with a smaller resolution and then scale up and smooth?
- Capital cities can no longer revolt.I don't know. It seems obvious, but many modern capitals are actually rather progressive in relation to other parts of the country and I certainly can imagine a revolution starting in a capital city.
That's looks really cool, but I was looking for something that's more of a quick noise generator, and I think I've found something. Thanks though.Thought as much. As I already said, it seems to be overkill for this project.
This looks cool. I don't know how to get it to work though.
Quote- Capital cities can no longer revolt.I don't know. It seems obvious, but many modern capitals are actually rather progressive in relation to other parts of the country and I certainly can imagine a revolution starting in a capital city.QuoteThat's looks really cool, but I was looking for something that's more of a quick noise generator, and I think I've found something. Thanks though.Thought as much. As I already said, it seems to be overkill for this project.
I've just had an idea: I swa these giant armies and realized that populations really were growing really damn fast. I see you already did something about that, but my first thought was to add natural disasters. They were popular in some games but at whole I think they're underrepresented in civilization simulations.
Heh, I like the different weapons. It's always a joy to see the guys with the Sarissas coming in. Although I guess this is the point where you'd need some better AI, because right now these things are mainly this effective because everyone is running right into them – if they'd spread out a bit before converging on their target, the long weapons would be way less effective, I assume.
Regarding optimization: It isn't unusual for the simulation to do nothing for a few minutes before battles or maybe after a battle when continuing with the simulation. It's kind of hard to discern with how close battles can be to each other. I assume it's battle preparation, though. Somehow makes more sense.
City size looks a lot better now, though they're still a bit on the large side for my tastes. I don't know, I guess that's a question of taste at this point.
It's really nice that there's not a ton of different nations anymore. This way I can actually make out a bit who is fighting whom and it's nice to perceive a bit of back-and-forth between two warring nations. Now it's not only nice to look at the sprawl but also to root for one side or the other.
Yes, indeed. I'm also looking into making names easier to pronounce, because it's kind of hard to relate (at least for me), to strangely named nation like Toaqkmohiiaua, rather than Phaag, and therefore, harder to root for them. But that's sort of low priority, I'd rather keep going with bug fixing, balanceing, performance improvements.Understandable you want to do other stuff first.
I've been looking for the cause of that for a while, and I think I've found it now, so it should run much faster now.Hmmm… I haven't been running the game for as long as yesterday yet. The problem is still present, although I'm not sure whether it is as bad as it was yesterday.
Yeah, the problem definitely still persists. After not even a century I can have waiting times of around an hour for a battle to finally start.You know what? Scratch that. I'm stupid.
Yeah, the problem definitely still persists. After not even a century I can have waiting times of around an hour for a battle to finally start.You know what? Scratch that. I'm stupid.
I downloaded the archive and left it at that. The version I was running was still the previous one. [Insert facepalm here]
"Simply" not allowing soldiers to get closer to each other than whatever should already do a lot for battles, I think. Of course I have no idea how simple that actually is.
An idea to restrict city size more absolutely would be to make food production (not solely) dependent on non-city squares nearby. Shrinking cities or razing conquered ones would start making more sense.QuoteYes, indeed. I'm also looking into making names easier to pronounce, because it's kind of hard to relate (at least for me), to strangely named nation like Toaqkmohiiaua, rather than Phaag, and therefore, harder to root for them. But that's sort of low priority, I'd rather keep going with bug fixing, balanceing, performance improvements.Understandable you want to do other stuff first.
When you get to name generation, I'd recommend Markov Chains. They're not fail-proof, but they certainly are awesome. Even more so, if you keep a separate instance running for each nation, feeding that instance with new names they used. This way they might diversify their languages over time.
Traceback (most recent call last):
File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1540, in __call__
return self.func(*args)
File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 590, in callit
func(*args)
File "./history_generator.py", line 301, in main_loop
self.diplomacy()
File "./history_generator.py", line 435, in diplomacy
self.handle_revolt(i)
File "./history_generator.py", line 419, in handle_revolt
revolted_nation.mod_morale(MORALE_INCREMENT * cities_revolted_count * int(log(army_revolted + 2)))
I guess you need to replace every instance of cities_revolted_count (on lines 419 and 422 in history_generator.py) with revolted_cities.countYeah, the delay is gone now. I'm really sorry for sending you on a futile bug hunt. :-[
There's a new bug, though:Code: [Select]Traceback (most recent call last):I guess you need to replace every instance of cities_revolted_count (on lines 419 and 422 in history_generator.py) with revolted_cities.count
File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1540, in __call__
return self.func(*args)
File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 590, in callit
func(*args)
File "./history_generator.py", line 301, in main_loop
self.diplomacy()
File "./history_generator.py", line 435, in diplomacy
self.handle_revolt(i)
File "./history_generator.py", line 419, in handle_revolt
revolted_nation.mod_morale(MORALE_INCREMENT * cities_revolted_count * int(log(army_revolted + 2)))
Made the change locally, I'll see how this plays out.
len(revolted_cities), by the way.
nation.remove_city(revolted_city)
replace with: nation.remove_city(city)
At least I assume it should be city, because that's the variable you're iterating with.
Seems you missed something else, too.
line 385 in history_generator.pyCode: [Select]nation.remove_city(revolted_city)replace with:Code: [Select]nation.remove_city(city)At least I assume it should be city, because that's the variable you're iterating with.
Regarding revolting cities: It seems they don't update their color properly.
I love to help. This simulation is already quite good and it's promising to become really awesome.
Say, could you reintroduce an option to run the simulation without any interruption at all? As it is, I need to restart it every time there's a battle. In times when there's multiple battles per year that can get really tedious.
I just saw a giant nation, age 125, ruled by a revolutionary, age 126. That doesn't seem right. Do people have a maximum age already? And a minimum age to become active?
I realize this is still in its early stages. Still, it's a lot of fun to watch. The idea of what might be only helps. ;D
Just saw something absurd: Units with spears were attacking units with hammers. The soldiers with the spears were all killed when attacking the hammermen without the hammermen ever being in reach.
I assume this happens due to the hammermen winning the attack as soon as the attack is started when they are in reach of the spears.
I think loosing a roll should only reduce health points if the loosing unit is in reach of the enemies' weapons.
Oh wow, has this changed in the time I've been gone. Full world map, with procedurally generated map, individual buildings, a full upgrade list, wow. Quite good!
I can't seem to pan around when in a zoomed in view. Is there a keybind I'm missing?
Bugs/Errors I've found:Spoiler (click to show/hide)
Download:
http://www.mediafire.com/download/i4hvdoi7ve1cx4d/History+Generator-2016-05-29.zip
Download:
http://www.mediafire.com/download/i4hvdoi7ve1cx4d/History+Generator-2016-05-29.zip
Zip is empty.
Looks very good. I'd recommend you put up screenshots and features on the OP.
Does anyone know how to get this to run on mac?
Your zipped files appear empty to me. Only yours. odd.
Does anyone know how to get this to run on mac?
I normally program on a Mac (and, naturally, also test it there), and I've never had any problems with it running. Could you be more specific with the issue you're having?Your zipped files appear empty to me. Only yours. odd.
That is strange. I guarantee there's something in it. You can verify by looking at the download page (it says the file size is 78.95 kB). I tried uploading a new zip file, if that doesn't work, try going to the GitHub page and clicking "Clone or download" then click "Download ZIP". It'll be a slightly updated version, but I think it's just as stable.
Here is the new download link:
http://www.mediafire.com/file/eyvi7o7i7odvco0/History+Generator-2016-12-30%282%29.zip
I really like this project, reminds me of something (also DF inspired) I made ages ago (I'm talking like ~2009 or so). BTW I started with a 2D square map, but later managed to get them running around making empires on a spherical world, which was really cool. Somehow I lost that specific branch of the code however :/
That spherical world code ended up as a Elite-style flight sim where you can travel between solar systems in real-time, but I'm actually thinking to do a space / roguelike / strategy game where you in fact have planets with cities and little armies marching around, cities, wars you can view from space.