[ian-reeds-games] Re: A response

  • From: "Allan Thompson" <allan1.thompson@xxxxxxx>
  • To: <ian-reeds-games@xxxxxxxxxxxxx>
  • Date: Tue, 22 Jan 2013 18:56:21 -0500

Those are great suggestions!
I think I like them all.

al
"The truth will set you free"
Jesus Christ of Nazareth 33A.D.
  ----- Original Message ----- 
  From: Zak Claassen 
  To: ian-reeds-games@xxxxxxxxxxxxx 
  Sent: Tuesday, January 22, 2013 4:11 PM
  Subject: [ian-reeds-games] Re: A response


  Tile effects could fill in for temporary terrain, so replacing terrain
  doesn't necessarily have to have a timer attached to it.  If both
  skills and effects can change terrain that would be a solution to
  splash_effects also causing changes to terrain.  This also reminds me,
  could you add the not_affect_flying flag to skills too?  What I had in
  mind was making melee attacks not reach flying units.  Oh and one more
  thing I thought about, having just effects applied to a unit when a
  point reaches 0 is a bit limiting, it would be useful to make it do
  something, like explode when it has been defeated or whatever.  Maybe
  if you could specify a skill which should be automatically triggered
  when a point reaches 0.  That way you could do more useful things with
  points reaching 0, like having a structure doing something every
  number of turns by making it lose a point per turn but having the
  skill triggered restore its points again.

  On 1/22/13, Allan Thompson <allan1.thompson@xxxxxxx> wrote:
  > I think I have to explain the map I am kicking around so that it makes some
  > sense.
  >
  > There was an old board game named dungeon. Up to six people would wander
  > around a large map that looked like a dungeon and  would take turns
  > wandering, going into diffrent leveled rooms, kill diffrent monsters of
  > diffrent difficulty level and find items and treasure, again based on level
  > of the room/monster. The first person with a certain amount of gold or items
  > worth gold, and makes it back to the starting chamber wins.
  > The ultimate purpose of the map is multiplayer. I figured the easiest most
  > basic map would be comparable to a board game.
  >
  > The board game had very low hitpoints. Monsters could be killed with 1 hit,
  > but monsters could hit the players if missed and could wound them. The
  > monsters would never leave the rooms or chambers.
  > In TB, when you have movment, the player can run up to a monster, hit it,
  > and if failed, and has movement left, can just back up one and avoide
  > getting attacked back. I didn't want to give the monsters higher ranges for
  > their attacks, so I gave them a movement point instead. However, that didn't
  > solve the problem if the player had more movement, so I decided to add a
  > stun effect. That way the player, when they attack or do a number of other
  > diffrent actions, will stand in one spot so that the monsters get their
  > turn, etc.
  >
  > The workaround I got actually works better then the previous attempt. I
  > added a at_zero=stun effect to anything that uses actions (monsters use a
  > diffrent point for doing actions). Anytime the action is performed, the
  > player is stopped for the rest of their turn. This works actually better
  > overall then the previous attempt so it all works well now.
  >
  > What Carlos mentioned threw me for a loop. Can that really happen? I thought
  > that was some kind of star trek thing, sending the mad computer into an
  > infinite loop that causes it to blow itself up, lol.
  > In my mind the best way would be a simple immunity flag. An immune=fire for
  > damage type would work great, at least, from my point of view. I don't know
  > if that would make damage go to zero or if the skill simply won't work by
  > comparing damage types. Come to think of it, couldn't there be an flag that
  > causes just one or two skills to  become unusable?
  > For instance, no_attack or no_longsword,fireball etc and so forth.
  > That might go towards a disarm skill, or a system failure on a ship or
  > something.
  >
  > So, if I get the jist of it, changable terrain is hard due to a number of
  > changes it could go thru in any one scenario. So you need a timer or point
  > counter to make the terrain change at a certain number of turns. So maybe a
  > terrain can have an at_xx= flag which kicks in an effect that causes a
  > change in terrain. When it reaches it's max number or at zero it could
  > remain a permenant terrain to end the cycle. So I guess one could have a
  > number of at_xx flags in one terrain. bear with me, I don't know how it will
  > ultimately look, but it is just how I am describing it in terms I understand
  > already.
  >
  > Maybe structures need some rework? Especially for bridges and things. Take a
  > way a need to be a team, give it terrain flags in addition to what it
  > already has, and it could problably fill some in the gaps like bridges and
  > whatnot. It could also easily "change" since it can summon. Once it is
  > killed thru point counter or some other way, it can have an summon effect
  > and an unsummon effect, where it summons a structure that replaces it as if
  > it was a terrain, and it disappears as it unsummons itself. So you can have
  > grass strucute changd to burning grass, then to burnt out terrain etc.
  > I don't know, maybe that is the stupidest   idea ever, lol. It just seems
  > taht you need just one type of  object that can do anything and everything
  > to fill in all the nooks and corners.
  >
  > al
  >
  > "The truth will set you free"
  > Jesus Christ of Nazareth 33A.D.
  >   ----- Original Message -----
  >   From: Ian Reed
  >   To: ian-reeds-games@xxxxxxxxxxxxx
  >   Sent: Tuesday, January 22, 2013 10:28 AM
  >   Subject: [ian-reeds-games] A response
  >
  >
  >   Hi all!
  >
  >   I've been pretty busy but am trying to catch up now.
  >
  >   Carlos, I've added random numbers for max and chance to my list.  As you
  >   say these should only be calculated once when the map begins.
  >
  >   Allan, parsing just means reading the file.  So really it was a generic
  >   error message.  I've tried to improve it a bit.
  >   Code can have so many errors and it's impossible to imagine them all in
  >   advance so it's helpful when you can let me know that a specific
  >   scenario gave a confusing error message so I can improve it.
  >
  >   Austen, sounds like downloading and running that file fixed 1.12 dev 1
  >   for you.  Is that right or was it something else you changed?
  >   Can you send me a map that demonstrates the game freezing on the first
  >   AI turn?
  >
  >   Glad to hear you like the chance and damage rolls and always glad to
  >   hear about getting more players for TB.  Thanks!
  >   Interesting about the AI summoning mines issue.
  >   Again, if you can send me a map that does this on the first turn that
  >   would help me figure it out.
  >
  >   Allan, I've added your feature requests to my list.
  >   Good to know about the line of sight bug after an enemy that blocks
  >   sight is defeated.
  >   I'll try to get this one fixed soon.
  >
  >   Austen, Allan and Zak, I like the idea that changes one terrain to
  >   another the best.
  >   So maybe a skill flag that looks like replace_terrain=grass|burnt_grass.
  >   So the grass is the only terrain it changes and it changes it to burnt
  >   grass.
  >   What about the scenario where you cast fireball and the splash damage
  >   affects a nearby forest tile.
  >   Should the forest tile somehow get an "on fire" effect for a certain
  >   number of turns?
  >   Or does it just change to a forest on fire terrain?
  >   And if it changes terrain it would seem we would need a way to change it
  >   again after a certain number of turns.
  >   We would change it to burnt forest, which no longer causes fire damage
  >   but may have different properties than a forest tile.
  >   I'm not sure the best way to handle all this or the simplest yet most
  >   flexible way for map creators to input it.
  >   I'm open to more thoughts on it.
  >
  >   Allan, you mentioned that if a skill fails to work due to a chance= flag
  >   then the effects it causes do not work either.
  >   At first I was going to say this was by design but then Zak brought up
  >   self_effects and self_inflict.
  >   Is this what you were referring to?
  >   I agree it's a bug that when a skill fails it does not do self_effects
  >   or self_inflict.
  >   Zak wondered how that would work if a skill intended to heal yourself
  >   failed but still did the self_restore.
  >   I think that if the purpose of the skill is to heal yourself then you
  >   should use restore= instead of self_restore= because when you are the
  >   target of the skill you could use either one to heal yourself but the
  >   restore= will only work if the skill succeeds.
  >   I will fix this bug in the near term.
  >   If you were actually talking about wanting inflict= to do no damage but
  >   for the effects= flag to still work then this is the other option Zak
  >   suggested about having a chance of for each effect, plus I'd need to let
  >   effects do initial damage so you could have a damage effect and a stun
  >   effect and the skill would have 100% success, the damage would have a
  >   smaller amount and the stun would have 100%.
  >   Not sure when I'll get around to that though.
  >
  >   Allan, you tried to make a unit immune to fire but found that the unit
  >   would always take 1 damage regardless of how high it's resistance is.
  >   This is due to some very old logic that ensured that every attack dealt
  >   at least 1 damage.
  >   Thinking about it now I think it should be removed as it's the map
  >   creators responsibility to make sure units can still take damage and it
  >   makes more sense to allow for the total immunity to fire scenario you
  >   mentioned.
  >
  >   Carlos mentioned that cost can not be reduced to 0 and I think this one
  >   is still important to keep for the reasons he mentioned.
  >
  >   Ian Reed
  >
  >

Other related posts: