Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 2 3 [4] 5 6

Author Topic: Rectifying Timescales Across Modes: Revisited  (Read 1945 times)

Andeerz

  • Bay Watcher
  • ...likes cows for their haunting moos.
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #45 on: July 10, 2012, 03:00:17 pm »

Luckily, there's no situation where dwarves are both economically active (and their actions need to be abstracted to stay interesting) and in combat (where minutes matter). So instead of switching the whole game to a different speed one can make a distinction between military operations (and messengers, caravans, etc: whenever timing is important) and domestic affairs (you don't need to witness real-time how every lunch of the whole year is eaten and how every stone block is cut: dwarves taking a few symbolic meals each year and still outputting the appropriate average production in a year is adequate to our needs). This means that you have dwarves in two modes at the same time, sometimes (eg. most of your fortress inside, producing, and a few squads outside battling). So one group of dwarves will move slower in comparison with the other. Since there's an upper limit to speed (a technical one and because you still need to be able to actually see what your military does), the military dwarves will then move at the speeds they do now, while the economic dwarves will move much slower. When combat is over all dwarves are into economy mode and then the game will display the economic dwarves at the speeds they have now in the game.

I think you and I agree on many things, Silverionmox, and generally are on the same wavelength when it comes to why this time discrepancy thing is a problem that needs to be fixed.  However, I think where we differ (and results in the differences in our solutions) is that I consider EVERY action an entity in the game makes as "economic", including combat and all of the other "time sensitive" things you mention; if it involves the moving and/or consumption of resources (including people, time, and information), it is an economic activity that has relevance to the goings-on of everything in the fort.  The relevance might not be immediate and direct, but that doesn't matter.  This is a game of emergent behavior; little events earlier on can have profound, often unforeseen effects down the line with things that are seemingly unrelated (think "butterfly effect").  And I think it would be really silly to introduce such a break in continuity of movement... Combat would seem to me as if everyone except for the combatants are statues.  And how to define someone as a "combatant" or "time sensitive" or whatever in a way that doesn't seem clunky and kludged-in and possibly game-breaking seems impossible to me.  I believe that EVERYTHING in this game is time-sensitive and, when combat is occurring, involved in combat in some way, shape, or form. 

Also, in the heat of battle, it's foreseeable that an occasional arrow would miss its target.  What if such a stray arrow (or stray dwarf being hurled by a colossus) hit one of those non-combatants that is moving at a snail's pace?  What happens when we are dealing with siege machinery which might someday be able to destroy constructions and walls?  It seems to me like this suggestion would require what you (Silverionmox) are weary about, namely:
There will be tweaks, then tweaks to compensate the unintended side effects of tweaks, tweaks to counter their side effects, and so on. For the game as it is jury-rigging like that could work, but there are plenty of features - many of which concern interaction of sites with the outside world -  to be added still, and the cumulative effect will be a huge mess of stopgap solutions that cause more problems than they solve, IMO.

...which echoes what I said before about "butterfly effect" stuff.

The reason I prefer my suggestion to that of others including yours is that there would be no special cases that would change how the game works for anyone.  Everyone would obey the same rules regardless of game speed or what is happening, so many unforseen exploits or problems would largely be avoided (and I can't think of any huge problems other than possible burdening of the CPU).  My suggestion would require fundamental changes in code for only one thing; movement (and maybe also fluid modeling... but that's outside the scope of the current discussion).  Everything else is just a change in values for existing parameters.  And pretty much the changes in movement would only be the following: Keep the existing movement code for when the game runs in adventure-mode(slow) time, and have the SAME movement code in dwarf-mode(fast) time EXCEPT change the distance moved per tick of the game clock to keep speeds consistent with adventure-mode(slow) time AND include a novel path caching system (which would be useful regardless of this suggestion). 

I hope I make sense.  I just feel that my suggestion introduces the fewest (and least problematic) opportunities for unforeseen problems, the necessity for tweaks upon tweaks, and all of that.

EDIT:  And if my suggestion removes the charming aspects of seeing dwarves move from tile-to-tile (which is charming, I will admit)... so be it.  It's not like one wouldn't be able to see that if you just toggle the game to adventure-mode time.   
« Last Edit: July 10, 2012, 03:21:19 pm by Andeerz »
Logged

Silverionmox

  • Bay Watcher
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #46 on: July 10, 2012, 03:01:03 pm »

why can't you just put the rest of the world into fortress mode scale when using fortress mode? if it takes you a week to walk to the edge of a map it should take several months to travel to other forts or cities. so if you send out an army you could check travel reports while fiddling around with your fortress until they arrive.
Because that would essentially slow down the rest of the world. If caravans had to walk from the mountainhome to your fortress at the same speed as your dwarves, it might take decades or even centuries before they arrived.

Whenever damage is done to a dwarf is a bad trigger too, because that means whatever enemy you have is already in the fort, giving you no time to prepare, as well as a series of other problems.
In any case, enemies entering the map would either move at fortress mode speed until a mode change is triggered, so you can see them coming. Whenever they're at crisis mode speed, that means at least some of your dwarves are too.

Triggers: If "whenever a dwarf panics/sees an enemy" is a bad trigger, we need to scrap that idea.
Please elaborate. Enemy recognition is a rather specific requirement, and one that will have to be adressed sooner or later anyway.

Having messengers force slow-mode until they reach your guards is dumb; how do you define guards, and what if you're not protected by them and rather by, say, some kind of trap/s?
Anyone with some kind of official capacity would suffice. If you choose to bunker in and kill anyone that approaches with traps, that's a choice with consequences.

Can you not see issues with marking critters as unimportant at will?
It's an optional measure, not essential. Since it's completely under control of the player, I can't see what would cause problems for him: after all, he would forego the option to have precise controls.

And why is "dwarves handle time-sensitive issues" not a good way for fast responses to happen when most things that would require them autopause the game? And of course it's vague--there's at least a thousand situations it would apply to.
They have to recognize time-sensitive issues, they have to figure what is better in that specific situation, and given their walking speed, there's not that much more efficiency you can wring out of them. And if that was no problem, why wouldn't they always do things the more efficient way?

Games are not about forcing you to do stuff, they're about letting you do stuff within limits. By your logic, the best game would be an awesome but non-interactive one, whic isn't really a game at all.
Then yours would be an editor, nothing more. The player has to face some constraints, otherwise he would reach his goals as soon as he had formulated them. In any case, I'm not forcing the player to do anything, just as the current version of the game isn't forcing the player to do anything but to follow the calendar and timing rules used in the game. Tell me what I force the player to do.

If tere is the slightest difference between the modes, as far as anything goes, it will be abused. It's not like "minimising haling distances improves efficiency," or even "building this complicated device improves efficiency," but "oressing this button improves efficiency."
Disagree, there's no button to be pressed and there are no efficiency differences between modes.

I think that reaching the edge of the territory you control taking a week isn't too unreasonable, considering that you'd have to be pretty damn far away in DF for it to take a week. Dwarves aren't as slow as you all seem to think--a muner can dig many tiles a day, and I don't think it takes multiple days to build something in a workshop, barring huge haling distances.
They walk slowly. Too slow for soldiers, messengers and even traders. As said before, economic activity can be abstracted without much problems: the military and diplomatic manoeuvers are where the problems lie.

And one last question: Why is the slow mode needed? Couldn't we accelerate the working and consuming speeds a la the suggested fast modes and leave out all of the issues, obvious and not, which would occur with such a fundamental change to the Fortress Mode engine?
The fast modes, AFAI've seen, contain a mass of arbitrary production changes: that will make abuse inevitable, balancing becomes an enduring headache for each update, and it breaks suspension of disbelief much more than a mere time speed change for some dwarves in specific, predictable situations. In addition the game derives much of its charm from the fact that every craftsman has to walk a very specific path to a specific storeroom to pick up specific items. Lastly, fortress mode already is a kind of fast mode, because it minimizes working/sleeping speeds to make time for dwarves walking around, and only shows a limited number of work/eat/sleep cycles instead of one for every day of the year.

edit: ninja'd by Andeerz
>This is a game of emergent behavior; little events earlier on can have profound, often unforeseen effects down the line

Then I wonder why you would abstract them further away?

>And I think it would be really silly to introduce such a break in continuity of movement... Combat would seem to me as if everyone except for the combatants are statues.

Pretty much, so their actions stay congruent with the calendar, their productivity remains the same the whole year, while the dwarves that need it get their fast action. They become combatants too when threatened and flee at fast speed.

>And how to define someone as a "combatant" or "time sensitive" or whatever in a way that doesn't seem clunky and kludged-in and possibly game-breaking seems impossible to me.

Anyone fighting or alarmed by the fighting. Seems straightforward and simple to me.

>when combat is occurring, (everything is) involved in combat in some way, shape, or form.

Most dwarves are inside a fortress, fighting usually happens at the fringes.

> What if such a stray arrow (or stray dwarf being hurled by a colossus) hit one of those non-combatants that is standing absolutely still

That civilian will most likely already be alarmed, since fighting happens nearby. In the rare situation that he's not, he'll become alarmed by being hit and will flee to safety if he can or cry for help.

>What happens when we are dealing with siege machinery which might someday be able to destroy constructions and walls?

I don't see any problems that will cause. These are hostiles, so they'll alarm people.

>Everyone would obey the same rules regardless of game speed or what is happening / My suggestion would require fundamental changes in code for only one thing

On the contrary I'd say, you specifically mention different speeds, hunger rates, ways of moving about and production rates for both rates. Essentially, making an entire new game mode. Whereas I would only change the amount of ticks in a calendar day, and not even for all dwarves.

---

Taking reservations about in into account, I'd say that crisis mode should apply to any dwarf that's executing a military or diplomatic action.
« Last Edit: July 10, 2012, 03:40:00 pm by Silverionmox »
Logged
Dwarf Fortress cured my savescumming.

Andeerz

  • Bay Watcher
  • ...likes cows for their haunting moos.
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #47 on: July 10, 2012, 03:11:42 pm »

You just stick to the current fortress timescale and stay with it. You could make full moons last longer, have week long day and nights, and it would all come toghether. As for it taking several weeks for armies to move off the map, note that it's an abstraction. What would really happen is that they prepare and stuff for several weeks, and then leave, however, this is not shown in fortress mode

That has the deficiency of being really silly. Especially in a game that models toes and eyelids.

Problem is, not only will all of these ideas involving a faster timeline take a while to implement (not a problem for something that's definitely a good idea), there's one of two problems depending on if you can switch or not. Either you take forever to go anywhere, or you have a group of issues depending on how you switch. Let's say for the sake of argument that non-switching time tweaks are a bad idea and hear how you suggest the switching work. To start, is it always player-chosen or are there some things that switch it to fast-mode or slow-mode?

Also... to address this... With my suggestion, it would be entirely player chosen pretty much, with the exception of any time a directed combat (or other damage-causing) action takes place (possibly including siege weapons firing, getting burnt by magma, crashing into a cart, cave-ins, etc.).  Combat and other such events should only take a short amount of time, should not be frequent at all, and sure as heck would deserve the player's attention. 

The game pauses any time things like this begin anyway, so I don't feel like it would be a problem.  Does this answer your question?

As for the siege question Qbert brought up...

Even if sieges in the game were to be like RL sieges (and sometimes take years upon years), I think the above stuff about when time goes into "adventure-mode" time would cover it.  99.9% of the time, a siege doesn't involve combat.  With what I suggest, the only time during a siege the game would make you switch to adventure-time mode would be when a siege weapon is fired, or someone targets someone else for a combat action.  Everything would behave overall as the game does now pretty much; business as normal in the fort until someone does something combat-oriented.
« Last Edit: July 10, 2012, 03:22:33 pm by Andeerz »
Logged

10ebbor10

  • Bay Watcher
  • DON'T PANIC
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #48 on: July 10, 2012, 03:21:47 pm »

Quote from: Silverionmox
Whenever damage is done to a dwarf is a bad trigger too, because that means whatever enemy you have is already in the fort, giving you no time to prepare, as well as a series of other problems.
In any case, enemies entering the map would either move at fortress mode speed until a mode change is triggered, so you can see them coming. Whenever they're at crisis mode speed, that means at least some of your dwarves are too.
[/quote]

But what if, say, I have an unguarded bridge, or even just dwarves outside. The enemies would teleport towards them (as by the way fast mode is elaborated in the OP) without giving me chance to react. If you are using the other suggested system(where everyone in PANIC mode doesn't get slowed down), the enemies spotting and chasing them would give them a speed boost compared to the others, giving you no time to get the other outside dwarves (who haven't seen the enemy) inside.

As for this can't be exploited. There's a difference between your suggested mode. Dwarves move faster in the PANIC mode. What about players using caged goblins to scare goblins to work faster, or using a drop tower, or an arena. The arena will especially be a problem, as the game won't be able to tell the difference between a real fight, an arena fight and prisoners escaping. Entering panic mode everytime someone fights would slow down the game to much, especially with hunting.

Third, what about the FPS if the game has to do all those different and complicated checks every tick.

Snip
Hunting based forts would then move at a crawl, as would forts with an arena, a live firing range or a siege training range.
Logged
Mostly Harmless

Andeerz

  • Bay Watcher
  • ...likes cows for their haunting moos.
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #49 on: July 10, 2012, 03:27:10 pm »

Snip
Hunting based forts would then move at a crawl, as would forts with an arena, a live firing range or a siege training range.
[/quote]

Oh... that is a problem.  Shoot.  Gotta think on that.  Thanks!!!

EDIT: Perhaps anything designated as a training target would be exempt from the automatic time-mode change?  And for hunted animals... perhaps there could be a toggle-able option that anything deemed a wild animal would be exempt?  This would still make things weird in terms of pathing and stuff in dwarf-mode time... Still gotta think more.

But what if, say, I have an unguarded bridge, or even just dwarves outside. The enemies would teleport towards them (as by the way fast mode is elaborated in the OP) without giving me chance to react.

And yet another excellent point!  But, here's how I would see it play out:  the game would pause as soon as gobbos enter the map detected (which the game does already).  This would give the player the opportunity to switch to adventure-mode time to micromanage their response.

And if this is happening during a prolonged siege after they entered the map...

A solution would be player-designated zones that cause the game to switch to adventure-mode time or pause outright when a detected enemy enters it (as in, seen by an allied dwarf) or paths through it.  I think that would be reasonable.
« Last Edit: July 10, 2012, 03:37:45 pm by Andeerz »
Logged

10ebbor10

  • Bay Watcher
  • DON'T PANIC
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #50 on: July 10, 2012, 03:39:02 pm »

Snip
Hunting based forts would then move at a crawl, as would forts with an arena, a live firing range or a siege training range.

Oh... that is a problem.  Shoot.  Gotta think on that.  Thanks!!!

But what if, say, I have an unguarded bridge, or even just dwarves outside. The enemies would teleport towards them (as by the way fast mode is elaborated in the OP) without giving me chance to react.

And yet another excellent point!  But, here's how I would see it play out:  the game would pause as soon as gobbos enter the map detected (which the game does already).  This would give the player the opportunity to switch to adventure-mode time to micromanage their response.

And if this is happening during a prolonged siege after they entered the map...

A solution would be player-designated zones that cause the game to switch to adventure-mode time or pause outright when a detected  enemy enters it (as in, seen by an allied dwarf).  I think that would be reasonable.
[/quote]
But then players could just use some mechanics and a captured goblin, and make their own Panic mode button. (Or is this the idea where you can switch in addition to being forced. I'm afraid I'm confusing ideas, a short overview and good names would be nice.)

And furthermore I think that such an important game mechanic should not be controlled solely by some build in rules. (Also, we need to destroy Carthage)
Logged
Mostly Harmless

QbertEnhanced

  • Bay Watcher
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #51 on: July 10, 2012, 03:46:16 pm »

I think it should definitely be toggleable. About hunting and the like, maybe one could turn the automatic pausing on and off for certain events?
For example, combat calculations in training would just go full steam ahead, the same for hunting. Then the player could choose to not even micro manage combat if they so choose.
Logged

Andeerz

  • Bay Watcher
  • ...likes cows for their haunting moos.
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #52 on: July 10, 2012, 04:10:35 pm »

But then players could just use some mechanics and a captured goblin, and make their own Panic mode button. (Or is this the idea where you can switch in addition to being forced. I'm afraid I'm confusing ideas, a short overview and good names would be nice.)

And furthermore I think that such an important game mechanic should not be controlled solely by some build in rules. (Also, we need to destroy Carthage)

Yeah, it's the other idea (I'm the original poster of this thread).  :D  So, no panic mode button!  I will work on an overview or something.

And what did Carthage do to deserve to be destroyed? :P
Logged

Silverionmox

  • Bay Watcher
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #53 on: July 10, 2012, 04:12:39 pm »

I'm going to make my own thread, it's becoming unclear. Sorry for the unintentional hijack.
Logged
Dwarf Fortress cured my savescumming.

10ebbor10

  • Bay Watcher
  • DON'T PANIC
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #54 on: July 10, 2012, 04:19:26 pm »

But then players could just use some mechanics and a captured goblin, and make their own Panic mode button. (Or is this the idea where you can switch in addition to being forced. I'm afraid I'm confusing ideas, a short overview and good names would be nice.)

And furthermore I think that such an important game mechanic should not be controlled solely by some build in rules. (Also, we need to destroy Carthage)

Yeah, it's the other idea (I'm the original poster of this thread).  :D  So, no panic mode button!  I will work on an overview or something.

And what did Carthage do to deserve to be destroyed? :P
Not invading and destroyting Rome, and therefore forcing me to learn French.
Logged
Mostly Harmless

Andeerz

  • Bay Watcher
  • ...likes cows for their haunting moos.
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #55 on: July 10, 2012, 04:20:39 pm »

I'm going to make my own thread, it's becoming unclear. Sorry for the unintentional hijack.

Oh, dude, it was awesome that you posted here.  It led to everyone raising great points and arguments for all sides involved!  :D
Logged

Silverionmox

  • Bay Watcher
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #56 on: July 10, 2012, 04:28:28 pm »

I'm going to make my own thread, it's becoming unclear. Sorry for the unintentional hijack.

Oh, dude, it was awesome that you posted here.  It led to everyone raising great points and arguments for all sides involved!  :D
Well, it's done: http://www.bay12forums.com/smf/index.php?topic=113068.0
Logged
Dwarf Fortress cured my savescumming.

Rakushun

  • Bay Watcher
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #57 on: July 11, 2012, 12:21:04 pm »

People have been discussing why they think their own idea for abstraction is better. The reason I think mine is the best (from the "Dwarf Mode Real Time Game Speed w/ Time Skipping" thread) is that for a game designed to run on emergent, procedural behavior, abstraction based on a procedural level with NO abstraction is superior compared to abstraction created arbitrarily by the game developer. As far as I'm concerned, with that unabstracted mode, you can then procedurally have as many different levels of abstraction as anyone could want without Toady having to rebalance everything for every mode.
Logged

Andeerz

  • Bay Watcher
  • ...likes cows for their haunting moos.
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #58 on: July 11, 2012, 02:39:39 pm »

edit: ninja'd by Andeerz
>This is a game of emergent behavior; little events earlier on can have profound, often unforeseen effects down the line

Then I wonder why you would abstract them further away?

Abstraction is unavoidable.  However, I feel my suggestion essentially makes the game abstract things out LESS.  What am I abstracting further away?

>And I think it would be really silly to introduce such a break in continuity of movement... Combat would seem to me as if everyone except for the combatants are statues.

Pretty much, so their actions stay congruent with the calendar, their productivity remains the same the whole year, while the dwarves that need it get their fast action. They become combatants too when threatened and flee at fast speed.

>And how to define someone as a "combatant" or "time sensitive" or whatever in a way that doesn't seem clunky and kludged-in and possibly game-breaking seems impossible to me.

Anyone fighting or alarmed by the fighting. Seems straightforward and simple to me.

>when combat is occurring, (everything is) involved in combat in some way, shape, or form.

Most dwarves are inside a fortress, fighting usually happens at the fringes.

> What if such a stray arrow (or stray dwarf being hurled by a colossus) hit one of those non-combatants that is standing absolutely still

That civilian will most likely already be alarmed, since fighting happens nearby. In the rare situation that he's not, he'll become alarmed by being hit and will flee to safety if he can or cry for help.

>What happens when we are dealing with siege machinery which might someday be able to destroy constructions and walls?

I don't see any problems that will cause. These are hostiles, so they'll alarm people.


What if the civilian is already on its way to a stockpile to pick something up to haul it somewhere but gets alarmed through whatever means, and when it flees out of danger, it flees towards the stockpile that was its original destination (out of danger at this point) and starts hauling what's in there?  The dwarf would effectively be quicker at getting to its destination and would therefore make hauling in this instance more efficient just because the dwarf was (un)fortunate enough to be in the line of fire.  I know this is a somewhat contrived situation, but it's one that could happen on its own.  And it might be minor in its impact alone, but if something like this happens frequently enough (or people find a way to happen artificially)... every little bit counts!  And it's situations like this where I take issue with your suggestion.

>Everyone would obey the same rules regardless of game speed or what is happening / My suggestion would require fundamental changes in code for only one thing

On the contrary I'd say, you specifically mention different speeds, hunger rates, ways of moving about and production rates for both rates. Essentially, making an entire new game mode.

Hmmm... You might be misunderstanding my suggestion.  Yes I suggest different speeds, hunger rates, and ways of moving about.  But these changes would apply to everyone equally and not be affected by toggling game speed.  And all of these changes would pretty much just be a simple changes of numerical values of a handful of parameters.  There would be no fundamental rewrite of the coding except for MAYBE the underlying movement stuff. 

Now, these changed hunger rates, speeds of movement, production rates... ALL of these would be the SAME between game speeds and for all dwarves no matter what is happening.  Essentially my suggestion is a way of putting in a speed toggle like you see in the likes of Sim City.  You can make the game go faster without any changes in how the game carries on its simulation (or as little change as possible...).

Whereas I would only change the amount of ticks in a calendar day, and not even for all dwarves.


How could you change the amount of ticks in a calendar day for only some entities and not others in the same game?  I don't see how that could be possible.  I mean, I see what your suggestion is overall, but I don't think it could be accomplished that way.
« Last Edit: July 11, 2012, 02:45:08 pm by Andeerz »
Logged

Andeerz

  • Bay Watcher
  • ...likes cows for their haunting moos.
    • View Profile
Re: Rectifying Timescales Across Modes: Revisited
« Reply #59 on: July 11, 2012, 07:15:55 pm »

Also... with regard to hunting, arenas, shooting ranges, etc.

For arenas and shooting ranges, I think what can be done is just have it run without triggering the slow-down so long as these activities occur in the designated area.

For hunting... hmmm...  perhaps any combat involving a hunter and a wild animal could be toggle-able as not able to trigger slow-down.

Possible issues would arise depending on problems listed in #2 in the original post.  If it is impossible for the game to calculate more than one complex action or movement occurring in the same tick... ugh... it would require combat to be abstracted in cases where one wouldn't want combat to trigger a slow down (i.e. hunting and arena combat).  The reason one would probably have to abstract combat is because most of the movements that happen during adventure-mode combat occur within a handful of seconds of game-time, which would occur within a single tick if we are talking about fortress-mode time (1 tick =~ 1.2 minutes).  That means any combat occurring in dwarf-mode time in my suggestion without triggering a slow down would have to be simplified to a single calculation every 1.2 game-minutes of combat determining what happens, as opposed to what would happen were the game to slow down to adventure-mode speed.  So, unless we are ok with such combats being pretty much auto-calculated (an average fight to the death probably wouldn't last more than two, maybe three dwarf-mode ticks; so that would mean two or three calculations determining the victor of a one-on-one duel, instead of many order more calculations in the same amount of game time in adventure-mode speed), combat would have to trigger a slow-down.

For maybe arenas and definitely shooting ranges, such an abstraction would be alright...  But for hunting, I think it would not be good to do at all, since the position and movement of the hunter is particularly important.

Actually... come to think of it... I think that this is a problem that cannot be fixed to my satisfaction, at least for hunting.  Crap!  I think this defeats my suggestion!
« Last Edit: July 11, 2012, 07:31:55 pm by Andeerz »
Logged
Pages: 1 2 3 [4] 5 6