Offspring: it's a matter of time

Users who are viewing this thread

565408-ministerio-tiempo-temporada-2-arranca-grande-spinola-ramon-langa.gif

+1 I hope you can have your son-daughter fighting side by side in your party and do all the dirty work for you.

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.

That option is possible:
IfahuzY.jpg
 
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.
 
I hope we can have dynasties like in Crusader Kings 2... But i understand if that is not possible  :cry: But i want games to last (in real life hours) as long as in Crusader Kings 2. Or actually, there should be no ending to games unless player so chooses. You should be able to play the same game forever, unless you choose otherwise. That is how i have always seen Mount & Blade.

I hope game will be very dynamic.
 
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.

You do know, mate.
tenor.gif
 
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.
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.

Why the hell was I still playing the campaign at that point? *Readies best guido voice* - "Don't ask questions you don't want the answer to."

Back on topic, it would need some workarounds but they would be fairly minor and would not involve making human breeding, building or traveling vast distances be out of the ordinary as far as the time required to do these things with the given level of technology being what it is.

The time of day could be determined by a new prompt where you could choose the time of day that you would prefer when at towns etc, 'today what time do you want to goto the Market/Tavern/Back Alleys?' etc, etc.

In battle some randomness could be applied and you would have an option to shoot for a time window rather than definitely choosing the one you want. The tactics skill could even come into play here and be measured against the skill of your opponent to see whose preferred time is closer to winning out when the battle actually happens.

And I am not arguing for the simulation of events in the game to be 24 times faster or anything, I am essentially calling for renaming hours to days and making the condition checks for buildings/quests/siege look for that metric instead of the old 'days' metric. Essentially, it should not be that difficult or time consuming considering as I think this could be done in Warband right now, now that I think about it.
 
Shaxx said:
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.
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.
Better make sure to have an epilepsy warning for the day and night cycles then :razz:

On a more serious note - that just switches one problem for another. Such a change to passage of time may fit growing up enough to be somewhat immersive, but a bunch of other events and developments in the game that were designed with slower time in mind would suddenly look very odd. Assuming that things weren't designed with a much faster PoT in the first place, of course.

It may just be my modder's scepticism speaking, but generally things are always harder than you think. Which is probably why very few mods have opted to really rewrite the mechanics of time in Warband. I haven't touched things in a while, but i think it's possible to showcase only days and years (heck, iirc we did that by mistake at some point) and then just speed things up to get the basic setup for what you want, yet the real challenge would be (re)building a world that suits this passage of time consistently.

Edith:

The above is not entirely accurate. (Things are always harder than they seem :razz:) The following governs displayed date and time in warband:
Code:
  #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),
    ]), 

So you can change the display as noted, but I don't think it would be possible to speed up the actual time as stated above. It is possible to change things up with
rest_for_hours                  = 1030 # (rest_for_hours,<rest_period>,[time_speed],[remain_attackable]),
rest_for_hours_interactive      = 1031 # (rest_for_hours_interactive,<rest_period>,[time_speed],[remain_attackable]),
but I believe they will force the player party to be stationary. Ctrl+Space, on the other hand, represents a hard-coded feature afaik - which means we can't really utilize it via the module system.

Still... this only means that the day and night cycle cannot be easily synched up with the dates. However, there may be ways to remove/hide that cycle on the worldmap. I believe Star Wars conquest does that, f.e.
 
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....
 
Duh said:
It may just be my modder's scepticism speaking, but generally things are always harder than you think.
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.
 
jamoecw said:
Duh said:
It may just be my modder's scepticism speaking, but generally things are always harder than you think.
while this is true we should keep in mind we aren't speculating at a modding level, or even a programming level.
At what level are you speculating then?

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.
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:
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),
    ]),

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....
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.

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 don't really see why a 'speed up time' option wouldn't work for this.

Once you're far enough into the game to be worrying about waiting for a child to mature into adulthood (at whatever age the game deems to be appropriate), it's likely that you'll be fairly well established as a lord with fiefs. At that point, you'll possibly be more concerned with higher-level management and political options rather than day-to-day things like running around the map with your party doing quests, buying supplies and recruiting low-tier units from notables. And in that case it wouldn't seem unreasonable that you might want to set up your priorities in the management screens and then sit back in your castle, speed up the game-time and wait for important events to pop up that you need to deal with.

That might make waiting the decade-or-so for your child to mature less tiresome. If you could do things like recruitment, supply acquisition or communication and diplomacy with NPCs through menus, and through delegation of menial tasks to companions and family members, that'd leave you free to wait out periods with accelerated time.
 
Duh said:
jamoecw said:
Duh said:
It may just be my modder's scepticism speaking, but generally things are always harder than you think.
while this is true we should keep in mind we aren't speculating at a modding level, or even a programming level.
At what level are you speculating then?
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:
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.
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:
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),
    ]),
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.
 
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.
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.

And this is not saying that it can't be done. It is just saying that changing the passage of time to suit one feature may not be sensible because it is quite likely to lead to clashes with a range of other features that work with the current setup. This is especially true for "simply speeding up time". Redefining how long a year takes would likely be more workable as it affects fewer base mechanics, but still exchanges one issue for several. (A shift from 1 week = 1 month to 1 week = 1 season, for example.)

Which, of course, doesn't mean that you can't or shouldn't speculate to your heart's content. I just feel that some people get a little bit too excited about the less likely scenarios and I would rather they don't end up terribly disappointed.

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.
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?
 
Rather than speeding up time to get our offspring into the game, the easiest approach is to repurpose what TW have already promised. We can start with nephews and nieces in addition to siblings. So hopefully, we can start with a 10 year-old nephew/niece and roleplay them as a son/daughter - either illegitimate or the offspring of a dead wife (assuming your culture discourages polygamy) to avoid any lmmersion breaks on marriage in game. Equally for those too literal to roleplay this in their imaginations, I’m sure a minor mod could also make the titles and dialogue conform.  :grin:

Personally, I’ll be happy as a foster parent for a 10-15 year old nephew/niece who can be trained from day one as a successor on perma-death.
 
That would be an option, though, Ruwa suggests they are aiming for actual offsprings - possibly with a shorter incubation and/or growth period.
 
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.

I expect I’d be disconcerted by marriage on week 24 (= year 2) and a 10 year old offspring joining my party in week 36 (one game year later). However, I could be wrong - it never seems odd that time stands still (campaign map time that is) while visiting a scene/settlement or fighting a battle in Warband. Who knows what we can seamlessly adapt to once immersed in Bannerlord’s fantasy?
 
Duh said:
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.
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?
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.

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.

as for wild speculation, people are speculating about dragons, machine guns, multi-party coop, and dynasties. on these forums people speculated about multiplayer M&B during the development of the original game, which was well outside of the bounds of possible at the time. i am sure you have heard of m&b: warband though, so that speculation did in fact bear fruit. there was speculation about elephants and camels, dwarves and hobbits, and warband ended up supporting different sized skeletal rigs, again wild speculation bearing fruit. siege weapon actually destroying walls was another, which is being implemented in this game (from what has been said). i could go on with the crazy speculations that have resulted in actual results, or those that have simply died. one big difference between then and now is that then we had our hands on code and thus when something seemed impossible to do we could figure out how it could be done. currently as you have demonstrated we have to assume that they are using stuff similar to what came before.

i have debated on different things in the forum before, assuming that things would be similar to what came before and people have pointed out things that show radical departures from the previous games. at this point i'd caution against making such assumptions, as it would seem that some of what was done before had to do with simplicity, as the development was down to 2 people at first. what we get may be completely different than what we have come to love.
 
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.
I don't think you really understand my point. Or at least none of this really relates to it.

Modding tools don't matter to developers in this regard, because they have full access to the game anywho. More importantly, the fundamental technical ability to make a change does not mean that any change suits the world you are building or have built. This is what i mean by "how the world is built/underlying logic of the game world". Not the ability to use algorithms or booleans (what language doesn't allow that? :razz:), but what these tools are being or have been used for. For example, that time flows on the worldmap, but stops in scenes. For example, that worldmap behavior is RTS with auto pause rather than continous or round-based. For example, that the world was build with a certain speed in mind. (Consider how budget reports once a week allow for reasonable gameplay if it means that they pop-up once every 5-10 minutes, but may very well make for an annoying experience if they were to pop-up every thirty seconds.) All of this may be adjustable from a technical perspective, BUT the more elaborate and complex your world is, the harder it becomes to retroactively change one of its core tenets.

My point is that the M&B worldsim is fairly complex and looks to be more complicated in BL yet, that the same fundamental approach to time (RTS w/ autopause) has been taken (see my or any other GC gameplay), that it is unlikely that the current passage of time allows/was designed for CK 2 style dynasties or casual thousand year playthroughs and that drastic changes to time will likely clash with a range of worldsim rules/features/mechanics - because they were build around the current setup.

And just to reiterate - this doesn't mean that it can't be done. Just that I believe it to be quite unlikely due to the work required - and the potential consequence of it meaning a stark departure from the M&B formula.

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.
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.
 
Duh said:
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....
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.

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.
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.

Also regarding party speed, it would stay the same. Parties won't be whizzing by the screen. Only the day night cycle would be shortened. So you may be chasing a bandit party and in the old system it would take you some hours but in a new system it would take days. Party speed remains the same. As for the budget reports they could come monthly rather than weekly. In fact most reports would come less frequently cause events would take longer to happen. Honesty, my aim is to have the game operate as normal but stretched out so a campaign would take longer. I just want a longer game :lol:

You do have a point about the constant light to dark shift. I don't mind it but other players might find it annoying.
 
Duh said:
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.
I don't think you really understand my point. Or at least none of this really relates to it.
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.

we aren't in a position to say what is or is not possible, but what has been said is that the modding system will allow any of the scripts to be replaced (though the original will not be touched). if this is true then virtually nothing is hardcoded in a traditional sense, should the game run like the original M&B. it all comes down to us not knowing anything to tell them it can't be done, so why not let them speculate? sure they may be disappointed when it comes out, but i am positive there will be plenty of people that will be disappointed that don't frequent these forums. i am also positive that there will be plenty of people who would be overjoyed that don't frequent these forums.
 
Back
Top Bottom