So it seems that what may be useful is a script flag that can add, subtract or set some point, say overdrive, based on the current values of other points. Something to the effect of overdrive += (hp damage taken) in the points file. -----Original Message----- From: ian-reeds-games-bounce@xxxxxxxxxxxxx [mailto:ian-reeds-games-bounce@xxxxxxxxxxxxx] On Behalf Of Craig Brett (Redacted sender "craigbrett17@xxxxxxx" for DMARC) Sent: Tuesday, March 31, 2015 1:51 PM To: ian-reeds-games@xxxxxxxxxxxxx Subject: [ian-reeds-games] Re: Overdrive? Not that these point_level=effect type ideas are a bad idea, in fact I think they were suggested before, but they wouldn't actually help my use case, strangely. This may seem like a subtle difference, but in Final Fantasy (the original inventors of the overdrive), I believe overdrives didn't actually care about your health, but on how much damage you'd taken as a proportion of it, if that makes sense. So if you healed after damage, you'd still be closer to earning an overdrive. After taking a big hit, you get a nice chunk of overdrive, and that stays even after you quickly scramble to heal from it. It's more about the beating you've taken as opposed to how beaten up you are. Am I making any sense? With that in mind, Victorious's idea about using the after_point_damage script event is a pretty good idea. I could increment a point based on how much health damage was inflicted, and then I need to think of a way to make the overdrive effect get applied. Maybe that effects 100=overdrive or whatever format we decide on in here looks good could work for this. Or maybe I do need an at_max one, I don't know. Sorry if it feels like I'm shooting down anyone's ideas, maybe it'll help now I've given a more in depth explanation. I haven't had time to reply to all the messages in this thread, but there's some interesting ideas floating around here! Keep it up. Craig On 31/03/2015 01:41, Victorious wrote: > Hm just thought about it more. Some possible conditions/relational > operators: > 5% <= health <= 25%, 5 <= health <= 25, health >= 50%, health < 50%, > health = 500, health != 100%. So anyone who has even a passing > familiarity with how inequalities are usually written in mathematics > will feel right at home here, and this covers every possible > condition. Writing the string processing code to handle this will looks like > its going to be an adventure. > > > -----Original Message----- > From: ian-reeds-games-bounce@xxxxxxxxxxxxx > [mailto:ian-reeds-games-bounce@xxxxxxxxxxxxx] On Behalf Of Carlos > Macintosh > Sent: Tuesday, March 31, 2015 6:13 AM > To: ian-reeds-games@xxxxxxxxxxxxx > Subject: [ian-reeds-games] Re: Overdrive? > > Perhaps a more inclusive way would be to use relational and logical > operators in point flags. The format would be effects_when condition > effects. I.e. > effects_when <=5||>=25 power up //could simulate both desperation or > true heartiness in a unit effects_when =0 death //would be the same as > at_zero=death effects_when >=13&&<24 power_up //power up if the point > is between 13 and 24 multiple instances of this flag would be > supported in the same file to supply as many conditions as possible. > > > On 3/30/2015 4:58 PM, Allan Thompson wrote: >> Yeah, that makes a lot of sense to keep it as simple and straight >> forward as possible inho. >> The above and below is also a good idea. I wonder if number ranges >> could come into play, or would those two flags cover that? >> >> For instance a super punch comes into effect when health is between 5 >> and 10, , but superdooper punch kicks in when health is , lets say, 2 thru >> 5? >> >> >> -----Original Message----- >> From: ian-reeds-games-bounce@xxxxxxxxxxxxx >> [mailto:ian-reeds-games-bounce@xxxxxxxxxxxxx] On Behalf Of Ian Reed >> Sent: Monday, March 30, 2015 2:54 PM >> To: ian-reeds-games@xxxxxxxxxxxxx >> Subject: [ian-reeds-games] Re: Overdrive? >> >> My 2 cents: >> instead of at_10=super punch have flags that specify whether the >> thing happens below or above a certain number. >> Because it might be quite difficult to get a certain point at exactly 10. >> So: >> below_10=super punch >> above_10=super punch >> But then most of the time we would want that number to be inclusive. >> So we could introduce more keywords like: >> below_or_equal_10=super punch >> above_or_equal_10=super punch >> but that seems a bit cumbersome and I'm not sure there are real cases >> where we would want to exclude the number. >> So maybe the shorter versions are all that is needed, and they are >> inclusive by default. >> Of course the above is missing the point name. >> And I haven't thought this through thoroughly, just making a point >> that sometimes a point should grow to trigger something while other >> times it should shrink. >> >> HTH, >> Ian Reed >> >> >> On 3/30/2015 9:29 AM, Allan Thompson wrote: >>> Excellent! That would certainly be useful. >>> >>> al >>> >>> -----Original Message----- >>> From: ian-reeds-games-bounce@xxxxxxxxxxxxx >>> [mailto:ian-reeds-games-bounce@xxxxxxxxxxxxx] On Behalf Of >>> Victorious >>> Sent: Monday, March 30, 2015 11:07 AM >>> To: ian-reeds-games@xxxxxxxxxxxxx >>> Subject: [ian-reeds-games] Re: Overdrive? >>> >>> Yup, that is sort of what I'm proposing, only have that be >>> implementable through scripting or to have scripts be able to know >>> when points change. This would be an example use for such a feature. >>> >>> -----Original Message----- >>> From: ian-reeds-games-bounce@xxxxxxxxxxxxx >>> [mailto:ian-reeds-games-bounce@xxxxxxxxxxxxx] On Behalf Of Allan >>> Thompson >>> Sent: Monday, March 30, 2015 11:04 PM >>> To: ian-reeds-games@xxxxxxxxxxxxx >>> Subject: [ian-reeds-games] Re: Overdrive? >>> >>> What about something ian talked about a while back. >>> I mean having a 'at zero' like flag on points, except instead of >>> zero, the number desired could be input. >>> For example... >>> >>> At_10=super punch >>> >>> Were 10 is the threshold at which an effect could kick in that does >>> the add and remove skill stuff. I guess you would have to make such >>> flags for effects etc. >>> >>> Just a thought. >>> >>> al >>> >>> -----Original Message----- >>> From: ian-reeds-games-bounce@xxxxxxxxxxxxx >>> [mailto:ian-reeds-games-bounce@xxxxxxxxxxxxx] On Behalf Of Craig >>> Brett (Redacted sender "craigbrett17@xxxxxxx" for DMARC) >>> Sent: Sunday, March 29, 2015 6:34 PM >>> To: ian-reeds-games@xxxxxxxxxxxxx >>> Subject: [ian-reeds-games] Overdrive? >>> >>> Hi all, >>> >>> In a new little map pack I'm working on, I wanted a couple of the AI >>> controlled friendly units to have overdrive type functionality. >>> Where in after they take so much damage, a new, awesomful attack >>> gets unlocked for them to use. >>> >>> I've experimented with a few ways of doing this, none seems ideal. >>> So advice would help. >>> >>> 1. This way kind of works, minus the AI never picking these skills >>> as they're further down in the list (something else I'm trying to >>> see if I can fix through AI scripting). But I've got an overdrive >>> point for each of these AI controlled unit types and each, at 0, >>> applies an effect specific to that unit, but all with the friendly >>> name "Overdrive". This effect adds the relevant skills. These >>> skills, in turn, fill the overdrive points and remove the overdrive >>> effect. I then made all inflicting skills also do damage to this >>> overdrive point, depending on how much actual damage they use. Whew. >>> That's a lot to explain but it kind of works. Problems with this >>> approach, though, are that the overdrive points being "inflicted" >>> means they're announced, despite being hidden. I could put in game >>> fixes for this, but not sure if it would effect anyone else. It also >>> feels like the overdrive "gage" should be going up instead of down. >>> 2. I then considered using some sort of after_perform_skill script >>> that checks for a point to see if it's at max and if it is then >>> grant an effect. But I'm not sure if this is an optimum approach >>> either. It does mean that I only have to release scripts and >>> possibly release something that people could use for other things, >>> and also that overdrive changes aren't announced until the effect is >>> there and you're ready to do damage. But I'm not sure if I'm >>> shimmying around the problems in 1. >>> >>> In either case, I've got the AI problem. And I've also got the >>> problem that add_skills doesn't care about what unit there is in >>> question, I can't think of a nice way to make add_skills unit >>> specific, hence the overdrive point and effect for each unit I want >>> to do this to. >>> >>> Of course, I could have just given it a point cost and waited until >>> you had enough of that point, but a nice "has been effected by overdrive" >>> announcement, coupled with a brand new skill showing up in your >>> menu, I think is much cooler. >>> >>> Any thoughts? Is this overdrive functionality even a good idea? Or >>> am I better off going old skool? >>> >>> Craig >>> >>> >>> >>> >> >> >> >>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
