15 replies to this topic

[suliman]

Hi
Im doing a multiplayer medeival strategy/adventure game where you ride around with your army and manage your towns. See it as a mix between total war and mount&blade. Problem is timescale.

My first idea was to have each month take 10 sec. Scales good with travel speed, seasons and construction time of town buildings. But battles becomes 2-3 months long then which is a bit ridiculous (the player needs to see what happens and issue some overarching commands in battle). I dont want the game to pause for all players when one player is performing a battle. But could it be ok if so much ingame time passes during a battle or does it seem to wierd for an otherwise semi-simulation kinda setting/feeling of the game?

The other option is to abstract time. Not call it months and years but just let time pass without quantifying it. This removes the fact that battles take to long time but also removes the feeling of actual years/seasons passing in the gameworld. And what would i call the timeunits? Levying 100 infantrymen takes "2 clocks"? It makes the game much more "gamey" which i would like to avoid.

As you see, Im in a bit of a pickle here
Any input is appreciated, thanks
Erik

[Acharis]

Abstract time, that's what I would do. The units of time in MMOs are frequently named "ticks".

[suliman]

But it doesnt sound very medieval to say "it will take your labourers 4 ticks to complete these great city walls my lord"
If im going for abstract time in a simulation i need a catchier name. Which i cant think of right now.

[Dragonsoulj]

Say you have 2 moons, use one for the long events, one for the short events. It will take 20 ____ lunar cycles where ___ is your moon's name.

[Siao]

You can try making time feels slower while in battles... Example, when you encounters an enemy army the time display freezes "15th Jan 1234" ... After the battle time suddenly moves forward with the clock jumping at a fast rate to "current time" and display all news between the start and end of battle.

Actually you will have more problem with the following scenario...
Player A meets Player B on the battlefield after 2 hours in real life (2 months in game time)... while the battle is going on Player C arrives with another army to reinforce Player A. Together Players A and C defeated Player B... All seems well until you realised that Player C raised this army within 2 months in game time and marched them hundreds of miles to destroy Player B.

I hit similar design issue as yours until I came up with the following idea..
1. I "instantiated" my battlefields and make them inaccessible to other players except for certain situations see point 3.
2. Each battles have limited time example: 1 month in game time.
3. Before the start of each battle, players within 1 month game time of marching/transportation etc, will be prompted if they want to join in the battle. If yes the game will auto calculate at which point of time their force will enter the battlefield.
4. Only players that knows of the battle are able to participate in it.

[jsj795]

How long do you think will the typical battle last?

[suliman]

Good points there.

A battle will be 20-30 sec i think

[ShawnCowles]

You could dramatically increase the time it takes to raise troops and build things, letting you run at a faster rate of time, so battles would only take days instead of months.

In game-play terms you'd order your cities to build things and they would be done the next real-world day.

[jesot]

But it doesnt sound very medieval to say "it will take your labourers 4 ticks to complete these great city walls my lord"
If im going for abstract time in a simulation i need a catchier name. Which i cant think of right now.

Just use a different language and act like it's a new word.

e.g. you can use "tids". Tid means Time in Swedish and Danish. Or czas which is time in Polish. Ido is Hungarian. All sound better and less distracting to immersion than ticks.

[jsj795]

You could dramatically increase the time it takes to raise troops and build things, letting you run at a faster rate of time, so battles would only take days instead of months.

In game-play terms you'd order your cities to build things and they would be done the next real-world day.

That's what I was thinking of too. If the battle lasts 20-30 seconds, making 10 seconds a day, and thereby saying that the battle lasts 2~3 days ingame time, and building something takes about a week (70 seconds in real time) or so. balance them out somehow.

[Luckless]

Find a copy of Lords of the Realm III. They dealt with a similar issue.

From what I read, it didn't work well.

[Rybo5001]

If you say 10 seconds = 1 day

That's reasonable for both, because then if a building takes a month that's roughly five minutes, most strategy games require you to wait a while for a building to be complete and I would say five minutes is a reasonable wait.

[lithos]

Most people just go for "as long/fast as the story demands". Babylon 5 writers coined it so they didn't need to answer questions.

[davekuyk]

If combat is the major problem then combat events could be encapsulated to essentially allow them to take place outside of time. (Kind of like the US Govt. has items that are "off-budget. I should try that. But I digress.)

The way I see it working is the player decides to allow each combat encounter to run on "auto" or actively participate. All combat encounters take the same amount of time (a week, month, whatever is appropriate. For the active encounters everything outside of that encounter is paused, allowing the player however much time as needed for that particular encounter.

[ShawnCowles]

If combat is the major problem then combat events could be encapsulated to essentially allow them to take place outside of time. (Kind of like the US Govt. has items that are "off-budget. I should try that. But I digress.)

The way I see it working is the player decides to allow each combat encounter to run on "auto" or actively participate. All combat encounters take the same amount of time (a week, month, whatever is appropriate. For the active encounters everything outside of that encounter is paused, allowing the player however much time as needed for that particular encounter.

That's how battles run in the Mount and Blade games. While you're in the battle the outside world is paused. I tried doing a simple space combat game where the outside world ran while the player was still in a battle. The result was pretty frustrating, enemy fleets that weren't even in the same star system when the battle started would show up and totally overwhelm you before you could finish off the fleet you attacked.

[Platinum_Dragon]

I dont want the game to pause for all players when one player is performing a battle.

....If combat is the major problem then combat events could be encapsulated to essentially allow them to take place outside of time....For the active encounters everything outside of that encounter is paused, allowing the player however much time as needed for that particular encounter....

....While you're in the battle the outside world is paused....

Your answer did exactly what the Original Poster did not want to do. Hey, the dilemma is always there. If you want to synchronize time, then either pause the overworld or slow it down. Better to just slow down the overall game speed and have a constant game speed regardless if players are in battle or not. Why do people like time skipping so much?

"as long/fast as the story demands"

Games are not stories because of time synchornization. It's always the problem with multiplayer games. Either the overworld pause or slow down the the time scale of the battle. Hey, at least slowing down the the time scale of battle is better than pausing the game right? NO! because the "story" is too slow for the players that are not in battle, and thus plot is never as fast as the story demands for the players that are not participating in battle. This is the difficulty in having a shared story. Everybody wants to timeskip over the parts that they are not involved in.

I give three solutions: When a player is in battle, everyone must suffer by having the (1) game slow down or (2) paused. OR (3) constant time scale (you could make sure the game is slow in the first place so that it does not matter whether the player is in battle or not.)

• slow down the overworld for all other players
• pause the game for all other players <- what you don't want to do
• constant time scale, this requires the game time to be slow enough

But then, it's really only 2 solution since you don't want to pause the game as a valid solution.

Real life siege battles could last more than two years, so whatever solution you will make will need to accomodate these type of situations as well. That's the problem with "Siao's" solution of "instantiated." It cannot accomodate siege battles.

My choice would be constant time. However, any solution to a multiplayer game will get rid of any players that want to have the plot as fast as the story demand.

This (timescale issue) is also one of the reason why single player games are better than multiplayer games.