The standard way to implement AI in games is via a finite state machine. The example I mentioned is akin to one "state" of that machine (enemy). Things get a lot more complex when you have more states, and more complex behaviors. Sure, you can implement everything via events, but you can't easily go and change things once they're in place, and cascading states is also a lot more complex. Imagine your "power level" variable, now imagine 70 other variables like that, each used in a different context, by an enemy that already has to track things like distance to the player, current hp, current mp, max hp, max mp, list of available attacks, movement possibilities and tons of other stuff.
I don't know, I've coded things using finite state machines in events before, and had no problem with it. The enemies in loot pursuit have 79 variables and the number of variables they have has never really been an issue that I can recall. What was an issue was my inexperience designing code properly, which is how it turned into a tangled mess. ^^ Subsequent designs have been much smoother.
I do something like this:
If enemy variable 'mode'="wandering"
Code for wandering about randomly
If distance(enemy.x, enemy.y, player.x, player.y) < 500, check angle for field of view
If player variable 'powerlevel' > enemy.powerlevel
set enemy.mode to "running"
If player variable 'powerlevel' < enemy.powerlevel
set enemy.mode to "chasing"
If enemy variable 'mode'="chasing"
chasing code, pathfinding, etc
If distance(enemy.x, enemy.y, player.x, player.y) < 100, no obstacle in way
set mode to "attacking"
If enemy variable 'mode'="attacking"
Code for charging towards player
If enemy overlaps player
Set player variable 'mode' to "hit"
Which collapses to:
Etc. Using this method I can make behaviors as complex as I want and still find it easy to work with.
It quickly gets confusing, especially since we have no concept of "internal" variables - that is, variables that are specific to an instance, but that shouldn't be displayed in the editor, because they are used internally. A reload timer is a perfect example of this: you have the reload delay, which is a property of the object, and you have the reload counter, which the object uses internally to implement the reloading - you shouldn't see that second variable because you'll never want to mess with it in the editor.
I'm afraid I'm not familiar with the term (even after several minutes of googling), and don't understand. What if you change your mind about what you want the value to be, or edit out that feature using that variable entirely, or change the variable name to something else? The variable has to be editable somewhere. Why not simply have it in the same list? It seems the most logical place for it. I think doing it some other way would be highly confusing.
Wouldn't it be easier to code everything up in blocks and call those blocks something meaningful? I.E: this section means "run away from player", this section means "kamikaze attack", this other section means "try to ambush the player", and this one "flank the player" or "gang up on the player", and so on - if we had custom ACEs we'd be able to do that.
Isn't that exactly what groups are? That's how it works the way I do it with my example above. Though I'm not arguing against custom ACEs, those would be awesome too.
I hope containers can include other containers, and those sub-containers can contain other sub-containers, and that we can mix objects in those containers (not hard to imagine such a situation: think of a tank with a body and a turret [2 sprites], a buffer for dead reckoning in multiplayer [array object], player name [text object], post-processing layer [canvas object], health bar [another sprite] and effects [particle object]), and that we can dynamically include and exclude objects from containers.
At least in construct classic, containers cannot include other containers (which is a great idea), but all the rest of what you said as possible regardless (dynamic ones could be created with the pairer object), having a tank with the two piece turret, etc. It works better if the health bar isn't part of the container though - all you need to do is create an instance of that for each instance of the tank, place it to the tank's position and set it to the tank's hp and it'll automatically place itself to the right instance.
> Design patterns? I'm not quite sure what you mean by that?
Code reusability is the capacity to reuse elements of an engine. How many times did you have to code a platforming engine? Wouldn't it be a lot better if we could just design one with all sorts of fancy stuff like double jumping, wall jumping, jetpacks, powerups and whatever, then plug a game in it and tweak the values by enabling/disabling parts of the engine, or perhaps sharing such engine in the forums? It's doable now, but what if you have to work such engine into an already in-progress game, instead of building a game from scratch on top of an engine? This process should be easier.
I know what code reuseability is, that... wasn't what I asked. I asked about design patterns. ^^