Also, it would be good to be able to assign them to a fief so they get some experience and increase their skills accordingly.
Bjorn The Baker said:Also, it would be good to be able to assign them to a fief so they get some experience and increase their skills accordingly.
RoboSenshi said:I hope this is expanded on in the "dynasties" blog but I hope the passage of time has been modified. To allow these features to be really enjoyed, time must move much faster. IMO turning one month into one week is not enough. The day night cycle should be much faster. I'm thinking seconds for a full day. Journeys between cities could then take days or even weeks. If it was up to me, an in game day would be 5-7 seconds. So a year in game can go by in about 7 minutes.
If the devs don't want to push it that far I hope they make the option modable.
RoboSenshi said:For Dynasties to work time must be sped up by a lot. I posted this in a blog thread:
RoboSenshi said:I hope this is expanded on in the "dynasties" blog but I hope the passage of time has been modified. To allow these features to be really enjoyed, time must move much faster. IMO turning one month into one week is not enough. The day night cycle should be much faster. I'm thinking seconds for a full day. Journeys between cities could then take days or even weeks. If it was up to me, an in game day would be 5-7 seconds. So a year in game can go by in about 7 minutes.
If the devs don't want to push it that far I hope they make the option modable.
I want a playthrough to last hundreds of in game years. So that the map is completely unrecognizable from the start of the game.
They could just pass time in days instead of hours rather than pushing human breeding into Warhammer Greenskin territory. In a recent Viking Conquest campaign I was up to 623 days passed, that would be 14952 days or 40 years in this new system with all other things being equal which would bring about the possibility to have grandchildren whom are of age at that point.Duh said:Even here there may be some issues with time, but I think it more likely that they will speed up pregnancy and growing up rather than the passage of time.
Better make sure to have an epilepsy warning for the day and night cycles thenShaxx said:They could just pass time in days instead of hours rather than pushing human breeding into Warhammer Greenskin territory. In a recent Viking Conquest campaign I was up to 623 days passed, that would be 14952 days or 40 years in this new system with all other things being equal which would bring about the possibility to have grandchildren whom are of age at that point.Duh said:Even here there may be some issues with time, but I think it more likely that they will speed up pregnancy and growing up rather than the passage of time.
#script_game_get_date_text:
# This script is called from the game engine when the date needs to be displayed.
# INPUT: arg1 = number of days passed since the beginning of the game
# OUTPUT: result string = date
("game_get_date_text",
[
(store_script_param_2, ":num_hours"),
(store_div, ":num_days", ":num_hours", 24),
(store_add, ":cur_day", ":num_days", 23),
(assign, ":cur_month", 3),
(assign, ":cur_year", 1257),
(assign, ":try_range", 99999),
(try_for_range, ":unused", 0, ":try_range"),
(try_begin),
(this_or_next|eq, ":cur_month", 1),
(this_or_next|eq, ":cur_month", 3),
(this_or_next|eq, ":cur_month", 5),
(this_or_next|eq, ":cur_month", 7),
(this_or_next|eq, ":cur_month", 8),
(this_or_next|eq, ":cur_month", 10),
(eq, ":cur_month", 12),
(assign, ":month_day_limit", 31),
(else_try),
(this_or_next|eq, ":cur_month", 4),
(this_or_next|eq, ":cur_month", 6),
(this_or_next|eq, ":cur_month", 9),
(eq, ":cur_month", 11),
(assign, ":month_day_limit", 30),
(else_try),
(try_begin),
(store_div, ":cur_year_div_4", ":cur_year", 4),
(val_mul, ":cur_year_div_4", 4),
(eq, ":cur_year_div_4", ":cur_year"),
(assign, ":month_day_limit", 29),
(else_try),
(assign, ":month_day_limit", 28),
(try_end),
(try_end),
(try_begin),
(gt, ":cur_day", ":month_day_limit"),
(val_sub, ":cur_day", ":month_day_limit"),
(val_add, ":cur_month", 1),
(try_begin),
(gt, ":cur_month", 12),
(val_sub, ":cur_month", 12),
(val_add, ":cur_year", 1),
(try_end),
(else_try),
(assign, ":try_range", 0),
(try_end),
(try_end),
(assign, reg1, ":cur_day"),
(assign, reg2, ":cur_year"),
(try_begin),
(eq, ":cur_month", 1),
(str_store_string, s1, "str_january_reg1_reg2"),
(else_try),
(eq, ":cur_month", 2),
(str_store_string, s1, "str_february_reg1_reg2"),
(else_try),
(eq, ":cur_month", 3),
(str_store_string, s1, "str_march_reg1_reg2"),
(else_try),
(eq, ":cur_month", 4),
(str_store_string, s1, "str_april_reg1_reg2"),
(else_try),
(eq, ":cur_month", 5),
(str_store_string, s1, "str_may_reg1_reg2"),
(else_try),
(eq, ":cur_month", 6),
(str_store_string, s1, "str_june_reg1_reg2"),
(else_try),
(eq, ":cur_month", 7),
(str_store_string, s1, "str_july_reg1_reg2"),
(else_try),
(eq, ":cur_month", 8),
(str_store_string, s1, "str_august_reg1_reg2"),
(else_try),
(eq, ":cur_month", 9),
(str_store_string, s1, "str_september_reg1_reg2"),
(else_try),
(eq, ":cur_month", 10),
(str_store_string, s1, "str_october_reg1_reg2"),
(else_try),
(eq, ":cur_month", 11),
(str_store_string, s1, "str_november_reg1_reg2"),
(else_try),
(eq, ":cur_month", 12),
(str_store_string, s1, "str_december_reg1_reg2"),
(try_end),
(set_result_string, s1),
]),
while this is true we should keep in mind we aren't speculating at a modding level, or even a programming level. hopefully their claims about how moddable the game will be will come to pass and one can mod just about anything into the game. though if have been gaming as long as me then you know not to put much stock in such claims.Duh said:It may just be my modder's scepticism speaking, but generally things are always harder than you think.
At what level are you speculating then?jamoecw said:while this is true we should keep in mind we aren't speculating at a modding level, or even a programming level.Duh said:It may just be my modder's scepticism speaking, but generally things are always harder than you think.
Again - the issue with this is not just technical limitations. Even if you can change the passage of time, a big challenge is with rebuilding the world in a way that suits that speed. Which (the worldbuilding) is technically possible in Warband but a gargantuan task. Take this random snippet from module simple_triggers - everything that is part of the worldsim is designed around time:jamoecw said:hopefully their claims about how moddable the game will be will come to pass and one can mod just about anything into the game. though if have been gaming as long as me then you know not to put much stock in such claims.
#Player raiding a village
# This trigger will check if player's raid has been completed and will lead control to village menu.
(1,
[
(ge,"$g_player_raiding_village",1),
(try_begin),
(neq, "$g_player_is_captive", 0),
#(rest_for_hours, 0, 0, 0), #stop resting - abort
(assign,"$g_player_raiding_village",0),
(else_try),
(map_free), #we have been attacked during raid
(assign,"$g_player_raiding_village",0),
(else_try),
(this_or_next|party_slot_eq, "$g_player_raiding_village", slot_village_state, svs_looted),
(party_slot_eq, "$g_player_raiding_village", slot_village_state, svs_deserted),
(start_encounter, "$g_player_raiding_village"),
(rest_for_hours, 0),
(assign,"$g_player_raiding_village",0),
(assign,"$g_player_raid_complete",1),
(else_try),
(party_slot_eq, "$g_player_raiding_village", slot_village_state, svs_being_raided),
(rest_for_hours, 3, 5, 1), #rest while attackable
(else_try),
(rest_for_hours, 0, 0, 0), #stop resting - abort
(assign,"$g_player_raiding_village",0),
(assign,"$g_player_raid_complete",0),
(try_end),
]),
#Pay day.
(24 * 7,
[
(assign, "$g_presentation_lines_to_display_begin", 0),
(assign, "$g_presentation_lines_to_display_end", 15),
(assign, "$g_apply_budget_report_to_gold", 1),
(try_begin),
(eq, "$g_infinite_camping", 0),
(start_presentation, "prsnt_budget_report"),
(try_end),
]),
# Oath fulfilled -- ie, mercenary contract expired?
(24,
[
(le, "$auto_menu", 0),
(gt, "$players_kingdom", 0),
(neq, "$players_kingdom", "fac_player_supporters_faction"),
(eq, "$player_has_homage", 0),
(troop_get_slot, ":player_spouse", "trp_player", slot_troop_spouse),
#A player bound to a kingdom by marriage will not have the contract expire. This should no longer be the case, as I've counted wives as having homage, but is in here as a fallback
(assign, ":player_has_marriage_in_faction", 0),
(try_begin),
(is_between, ":player_spouse", active_npcs_begin, active_npcs_end),
(store_faction_of_troop, ":spouse_faction", ":player_spouse"),
(eq, ":spouse_faction", "$players_kingdom"),
(assign, ":player_has_marriage_in_faction", 1),
(try_end),
(eq, ":player_has_marriage_in_faction", 0),
(store_current_day, ":cur_day"),
(gt, ":cur_day", "$mercenary_service_next_renew_day"),
(jump_to_menu, "mnu_oath_fulfilled"),
]),
# Reducing luck by 1 in every 180 hours
(180,
[
(val_sub, "$g_player_luck", 1),
(val_max, "$g_player_luck", 0),
]),
#courtship reset
(72,
[
(assign, "$lady_flirtation_location", 0),
]),
#reset time to spare
(4,
[
(assign, "$g_time_to_spare", 1),
(try_begin),
(troop_slot_ge, "trp_player", slot_troop_spouse, active_npcs_begin),
(assign, "$g_player_banner_granted", 1),
(try_end),
]),
# Banner selection menu
(24,
[
(eq, "$g_player_banner_granted", 1),
(troop_slot_eq, "trp_player", slot_troop_banner_scene_prop, 0),
(le,"$auto_menu",0),
#normal_banner_begin
(start_presentation, "prsnt_banner_selection"),
#custom_banner_begin
# (start_presentation, "prsnt_custom_banner"),
]),
# Party Morale: Move morale towards target value.
(24,
[
(call_script, "script_get_player_party_morale_values"),
(assign, ":target_morale", reg0),
(party_get_morale, ":cur_morale", "p_main_party"),
(store_sub, ":dif", ":target_morale", ":cur_morale"),
(store_div, ":dif_to_add", ":dif", 5),
(store_mul, ":dif_to_add_correction", ":dif_to_add", 5),
(try_begin),#finding ceiling of the value
(neq, ":dif_to_add_correction", ":dif"),
(try_begin),
(gt, ":dif", 0),
(val_add, ":dif_to_add", 1),
(else_try),
(val_sub, ":dif_to_add", 1),
(try_end),
(try_end),
(val_add, ":cur_morale", ":dif_to_add"),
(party_set_morale, "p_main_party", ":cur_morale"),
]),
#Party AI: pruning some of the prisoners in each center (once a week)
(24*7,
[
(try_for_range, ":center_no", centers_begin, centers_end),
(party_get_num_prisoner_stacks, ":num_prisoner_stacks",":center_no"),
(try_for_range_backwards, ":stack_no", 0, ":num_prisoner_stacks"),
(party_prisoner_stack_get_troop_id, ":stack_troop",":center_no",":stack_no"),
(neg|troop_is_hero, ":stack_troop"),
(party_prisoner_stack_get_size, ":stack_size",":center_no",":stack_no"),
(store_random_in_range, ":rand_no", 0, 40),
(val_mul, ":stack_size", ":rand_no"),
(val_div, ":stack_size", 100),
(party_remove_prisoners, ":center_no", ":stack_troop", ":stack_size"),
(try_end),
(try_end),
]),
I believe that is a bit naive (for lack of a better word). It puts a week at 35-49 seconds. Which means you are getting ~1,5 budget reports per minute. Now consider all the other various menus and presentations that can be triggered. Pretty annoying alongside a continous light to dark shift every 5-7 seconds per day and night cycle. Consider also how swiftly parties will move around and how difficult it will be to avoid encounters or seek them out - given that there is fog of war. And that's just the very surface of the iceberg.RoboSenshi said:I don't know about setting hours to days but simply having a full day in game last 5-7 seconds wouldn't break anything. That's the only change that I feel needs to happen.
The only thing to modify would be the time frame for completing quests. I think....
at the fan level. sort of like what would happen if black panther fought batman. there is the wouldn't it be cool angle, the technical aspects in which we talk about there different gadgets, and even the logistics of such a fight such as where and how they would fight. in the end it is wild speculation, and the creators might decide to implement it or not based all sorts of things well outside the hands of the fans.Duh said:At what level are you speculating then?jamoecw said:while this is true we should keep in mind we aren't speculating at a modding level, or even a programming level.Duh said:It may just be my modder's scepticism speaking, but generally things are always harder than you think.
except that is the modding script for M&B:WB, rather than the script for M&B2. of course i could be wrong and they might use the same scripts, though they did say they were going to use xml. they said a bunch of other stuff as well, and while i have more faith in them than other companies i have been told very similar things in the past and seen it all turn to ****. in the end i am going to just sit back and throw money at them when they'll let me, and assume they will at least partially live up to my expectations. though i am not going to go out of my way to lift those already high expectations.Duh said:Again - the issue with this is not just technical limitations. Even if you can change the passage of time, a big challenge is with rebuilding the world in a way that suits that speed. Which (the worldbuilding) is technically possible in Warband but a gargantuan task. Take this random snippet from module simple_triggers - everything that is part of the worldsim is designed around time:jamoecw said:hopefully their claims about how moddable the game will be will come to pass and one can mod just about anything into the game. though if have been gaming as long as me then you know not to put much stock in such claims.
Code:#Player raiding a village # This trigger will check if player's raid has been completed and will lead control to village menu. (1, [ (ge,"$g_player_raiding_village",1), (try_begin), (neq, "$g_player_is_captive", 0), #(rest_for_hours, 0, 0, 0), #stop resting - abort (assign,"$g_player_raiding_village",0), (else_try), (map_free), #we have been attacked during raid (assign,"$g_player_raiding_village",0), (else_try), (this_or_next|party_slot_eq, "$g_player_raiding_village", slot_village_state, svs_looted), (party_slot_eq, "$g_player_raiding_village", slot_village_state, svs_deserted), (start_encounter, "$g_player_raiding_village"), (rest_for_hours, 0), (assign,"$g_player_raiding_village",0), (assign,"$g_player_raid_complete",1), (else_try), (party_slot_eq, "$g_player_raiding_village", slot_village_state, svs_being_raided), (rest_for_hours, 3, 5, 1), #rest while attackable (else_try), (rest_for_hours, 0, 0, 0), #stop resting - abort (assign,"$g_player_raiding_village",0), (assign,"$g_player_raid_complete",0), (try_end), ]), #Pay day. (24 * 7, [ (assign, "$g_presentation_lines_to_display_begin", 0), (assign, "$g_presentation_lines_to_display_end", 15), (assign, "$g_apply_budget_report_to_gold", 1), (try_begin), (eq, "$g_infinite_camping", 0), (start_presentation, "prsnt_budget_report"), (try_end), ]), # Oath fulfilled -- ie, mercenary contract expired? (24, [ (le, "$auto_menu", 0), (gt, "$players_kingdom", 0), (neq, "$players_kingdom", "fac_player_supporters_faction"), (eq, "$player_has_homage", 0), (troop_get_slot, ":player_spouse", "trp_player", slot_troop_spouse), #A player bound to a kingdom by marriage will not have the contract expire. This should no longer be the case, as I've counted wives as having homage, but is in here as a fallback (assign, ":player_has_marriage_in_faction", 0), (try_begin), (is_between, ":player_spouse", active_npcs_begin, active_npcs_end), (store_faction_of_troop, ":spouse_faction", ":player_spouse"), (eq, ":spouse_faction", "$players_kingdom"), (assign, ":player_has_marriage_in_faction", 1), (try_end), (eq, ":player_has_marriage_in_faction", 0), (store_current_day, ":cur_day"), (gt, ":cur_day", "$mercenary_service_next_renew_day"), (jump_to_menu, "mnu_oath_fulfilled"), ]), # Reducing luck by 1 in every 180 hours (180, [ (val_sub, "$g_player_luck", 1), (val_max, "$g_player_luck", 0), ]), #courtship reset (72, [ (assign, "$lady_flirtation_location", 0), ]), #reset time to spare (4, [ (assign, "$g_time_to_spare", 1), (try_begin), (troop_slot_ge, "trp_player", slot_troop_spouse, active_npcs_begin), (assign, "$g_player_banner_granted", 1), (try_end), ]), # Banner selection menu (24, [ (eq, "$g_player_banner_granted", 1), (troop_slot_eq, "trp_player", slot_troop_banner_scene_prop, 0), (le,"$auto_menu",0), #normal_banner_begin (start_presentation, "prsnt_banner_selection"), #custom_banner_begin # (start_presentation, "prsnt_custom_banner"), ]), # Party Morale: Move morale towards target value. (24, [ (call_script, "script_get_player_party_morale_values"), (assign, ":target_morale", reg0), (party_get_morale, ":cur_morale", "p_main_party"), (store_sub, ":dif", ":target_morale", ":cur_morale"), (store_div, ":dif_to_add", ":dif", 5), (store_mul, ":dif_to_add_correction", ":dif_to_add", 5), (try_begin),#finding ceiling of the value (neq, ":dif_to_add_correction", ":dif"), (try_begin), (gt, ":dif", 0), (val_add, ":dif_to_add", 1), (else_try), (val_sub, ":dif_to_add", 1), (try_end), (try_end), (val_add, ":cur_morale", ":dif_to_add"), (party_set_morale, "p_main_party", ":cur_morale"), ]), #Party AI: pruning some of the prisoners in each center (once a week) (24*7, [ (try_for_range, ":center_no", centers_begin, centers_end), (party_get_num_prisoner_stacks, ":num_prisoner_stacks",":center_no"), (try_for_range_backwards, ":stack_no", 0, ":num_prisoner_stacks"), (party_prisoner_stack_get_troop_id, ":stack_troop",":center_no",":stack_no"), (neg|troop_is_hero, ":stack_troop"), (party_prisoner_stack_get_size, ":stack_size",":center_no",":stack_no"), (store_random_in_range, ":rand_no", 0, 40), (val_mul, ":stack_size", ":rand_no"), (val_div, ":stack_size", 100), (party_remove_prisoners, ":center_no", ":stack_troop", ":stack_size"), (try_end), (try_end), ]),
Yes and no. While all is speculation, there is much less speculation on dragons and machine guns in the base game. Because people understand and accept the constraints of the setting. The same principle applies for technical and design limitations. One prominent example is multi-party coop which deeply clashes with the way time is designed in warband. Another is massively speeding up the game. It is a bit odd to me that people have trouble understanding the difficulty in this tbh. They seem to understand that time currently appears too slow for a CK 2 level dynasty system. Maybe even too slow for offspring's to be anything but a late game feature or gimmick. Yet they do not apply this understanding of the impact of time on one feature to other features.jamoecw said:in the end it is wild speculation, and the creators might decide to implement it or not based all sorts of things well outside the hands of the fans.
It is irrelevant what language is used, because the snippet is just meant to showcase how the Mount & Blade worldsim is built. I.e. unless the underlying logic of the game world is fundamentally different to previous titles, the point still applies. And the GC demo looked like it was following this type of time-based logic. And ... how else would one built a worldsim anywho?jamoecw said:except that is the modding script for M&B:WB, rather than the script for M&B2. of course i could be wrong and they might use the same scripts, though they did say they were going to use xml. they said a bunch of other stuff as well, and while i have more faith in them than other companies i have been told very similar things in the past and seen it all turn to ****. in the end i am going to just sit back and throw money at them when they'll let me, and assume they will at least partially live up to my expectations. though i am not going to go out of my way to lift those already high expectations.
Duh said:That would be an option, though, Ruwa suggests they are aiming for actual offsprings - possibly with a shorter incubation and/or growth period.
you are right in that the language doesn't matter, but how the worldsim is built does matter. in addition to that how the language interacts with the base program also matters. if we were to look at half-life versus starcraft you can see a distinct difference. starcraft's tools were a robust map editor allowing massive changes for a map editor, even to the point of new units and map entities. on paper it looks to be as robust as half-life's, both use object interaction as the basis for script triggering and regulation (instead of time like M&B). both use simple mathematical and boolean variables with basic entities overlaid with graphical representation. in the end half-life's tools were far more useful for modding, yet starcraft's was easier to produce simple alterations.Duh said:It is irrelevant what language is used, because the snippet is just meant to showcase how the Mount & Blade worldsim is built. I.e. unless the underlying logic of the game world is fundamentally different to previous titles, the point still applies. And the GC demo looked like it was following this type of time-based logic. And ... how else would one built a worldsim anywho?jamoecw said:except that is the modding script for M&B:WB, rather than the script for M&B2. of course i could be wrong and they might use the same scripts, though they did say they were going to use xml. they said a bunch of other stuff as well, and while i have more faith in them than other companies i have been told very similar things in the past and seen it all turn to ****. in the end i am going to just sit back and throw money at them when they'll let me, and assume they will at least partially live up to my expectations. though i am not going to go out of my way to lift those already high expectations.
I don't think you really understand my point. Or at least none of this really relates to it.jamoecw said:you are right in that the language doesn't matter, but how the worldsim is built does matter. in addition to that how the language interacts with the base program also matters. if we were to look at half-life versus starcraft you can see a distinct difference. starcraft's tools were a robust map editor allowing massive changes for a map editor, even to the point of new units and map entities. on paper it looks to be as robust as half-life's, both use object interaction as the basis for script triggering and regulation (instead of time like M&B). both use simple mathematical and boolean variables with basic entities overlaid with graphical representation. in the end half-life's tools were far more useful for modding, yet starcraft's was easier to produce simple alterations.
This seems to be in the same vein of "technical ability to change time" as above, so I would refer you to my previous answer that technical ability is not really sufficient.the way they describe the interactions between program and modding tools sounds like half-life's, and that interaction determines what you can ultimately do with the tools. faking fixed time was something that was learned to do early on in modding with both half-life and starcraft, so just because something looks like it is the foundation doesn't mean it is. we have to wait until we get our hands on the scripts they use before we know for sure.
That's exactly what I was suggesting. I didn't mean speed up time and leave it at that. I want time progression to be faster and also every subsequent feature to be modified. Using my limited game design knowledge, I assumed only quests would be affected. Which I guess was wrong.Duh said:I believe that is a bit naive (for lack of a better word). It puts a week at 35-49 seconds. Which means you are getting ~1,5 budget reports per minute. Now consider all the other various menus and presentations that can be triggered. Pretty annoying alongside a continous light to dark shift every 5-7 seconds per day and night cycle. Consider also how swiftly parties will move around and how difficult it will be to avoid encounters or seek them out - given that there is fog of war. And that's just the very surface of the iceberg.RoboSenshi said:I don't know about setting hours to days but simply having a full day in game last 5-7 seconds wouldn't break anything. That's the only change that I feel needs to happen.
The only thing to modify would be the time frame for completing quests. I think....
Even if one was to consider all of this "workable" it would be much less enjoyable. To avoid that, near everything regarding the world-sim would have to be redesigned and rewritten.
i think you are missing mine. all of this seems very out there due to how things probably work now, but who cares? in the end it comes down to technical limitations (that we simply don't know the extent of), and the desires of the fans. once the desires are fleshed out, if the desire is strong enough to overcome the technical challenges then it will happen. at this stage it is the desire of the devs, vs. what their challenges. maybe they will decide to put it off till next game, or not. maybe the desire will gather steam and mods will figure it out once the game is released. maybe neither will happen and the fans will just talk among each other hyping themselves up for the release.Duh said:I don't think you really understand my point. Or at least none of this really relates to it.jamoecw said:you are right in that the language doesn't matter, but how the worldsim is built does matter. in addition to that how the language interacts with the base program also matters. if we were to look at half-life versus starcraft you can see a distinct difference. starcraft's tools were a robust map editor allowing massive changes for a map editor, even to the point of new units and map entities. on paper it looks to be as robust as half-life's, both use object interaction as the basis for script triggering and regulation (instead of time like M&B). both use simple mathematical and boolean variables with basic entities overlaid with graphical representation. in the end half-life's tools were far more useful for modding, yet starcraft's was easier to produce simple alterations.