I feel very happy because I woke up thinking that there's no way I'd be able to duplicate function names for extender functions in AGS without the compiler throwing a fit but it just works, not sure how I never knew this.
@ThreeOhFour yes! it's actually a happy accident that the compiler is capable of this. unintentional behaviour but we're all happy for it
@vga256 My heart is telling me this shouldn't work, but I kind of suspected it from the fact that I could call things like Character.Scaling AND Object.Scaling and the editor is okay with it. But wow, what a weird setup!
@ThreeOhFour yes!
it's a side-effect of having the engine written in C/C++.
C-likes treat functions with the same function name *but different parameters* as separate functions:
Say(this *Character)
is seen as a different function than
Say(this *Object)
because the parameter between the brackets is different.
you can take advantage of this for all kinds of things!
@vga256 I love this insight, thank you! And yes, combined with the strength of custom properties this is going to save me so, so much tedious work.
@ThreeOhFour it's awesome. having unlimited custom properties sure opens up a lot of possibilities for doing cool things at runtime
@vga256 I imagine your forays into more systemic design have had you exploring this area a great deal.
@ThreeOhFour it was so much fun begging pleading and screaming ags into a simulation machine
@vga256 I am definitely not planning anything so systemic or intricate. But I do have a number of simple systems, and I believe that rather than going "Oh no this only works on particular hotspots that the magic designer hinted at", I can make things always work by default and make a much less stubborn, linear, "I'm the puppet master, you're the puppet" kind of adventure.
@ThreeOhFour that's so great. assigning common properties to "kinds" of objects and people and places makes things so much more interesting
@vga256 My north star is *kind of* The Incredible Machine. If Kevin Ryan and Jeff Tunnell had built an RPG the fireball spell would definitely have worked on wooden doors & crates. The ball physics don't stop working in some cases because the designer decided that it's 'wrong' in this instance.
My Machine will just be way more Credible hahaha
@ThreeOhFour oooo that's tantalizing. that game is my touchstone for perfect UI design and goofy fun behaviour
@vga256 Yeah! And like, it might have opened up more interesting gameplay if the "turn this thing green" draft had worked on everything, right?
@ThreeOhFour i wish so much that those spells hadn't been hardcoded :\
i understand what they were going for, but i love ruining a game with bad behaviour
@vga256 For me I kind of think of it as like improv. Everybody knows the rule to improv is you don't go "no", you go "yes, and". So if you give me a shrink ray, I should be able to shrink, like, everything I can click on.
@ThreeOhFour that's a great way of thinking about it. also, the best way to not be an asshole irl!
@vga256 I am not making a very complex game, but I have a few core systems to play with, and I believe it's sensible to make those systems work when the player wants to use them, regardless of whether or not I have a puzzle in mind linked to that action.
@ThreeOhFour eden and i had a long conversation about that yesterday. it's a design contrast that doesn't have to be treated as a conflict or tension. some players love only puzzle-solving, others love toying around and clicking on everything to see what blows up. catering to both types of can only make things more enjoyable.
and it's even better when you get that behaviour for free using (or faking) a little simulation
@vga256 I had a chat with Eden a few weeks ago when my ideas were a lot more nebulous and went over some of this stuff. I've since honed and clamped my plans down by a lot, into something I know I can make, and I think I can make fun, but yes, I agree, let people mess around with things.
@ThreeOhFour awesome :) she's a treasure trove of design