> What was an issue was my inexperience designing code properly, which is how it turned into a tangled mess.
My point is that everything that's complicated enough soon gets turned into a tangled mess.
I guess we'll just have to agree to disagree here then. I'm not sure I communicated it properly, but since learning how to design code properly, I don't find things turning into a tangled mess anymore.
The problem with that is that you have little reusability. For instance, this "If distance(enemy.x, enemy.y, player.x, player.y) < 100" could be compacted to a custom condition called "is within attacking range?" - you'll obviously need to repeat that all over your code.
You also have similar cases, such as "is within field of view" and "no obstacles between me and player" which could be abstracted away.
I'm not sure how that would benefit in this example, as a custom condition called "is within attacking range" would actually be more complex than a condition "If distance(enemy.x, enemy.y, player.x, player.y) < 100" as the definition of the custom condition would need to be defined somewhere else, and it would still be one condition.
For more complex situations though, having a custom condition that has multiple conditions defined elsewhere could be handy I suppose, but personally I think it would actually be often harder to follow then just having the conditions laid out there instead. That's a matter of personal preference tho.
Except when you're referring to instances such as:
Similarly, if you have more than one condition that triggers "chasing code" or "pathfinding", you'll need to copy+paste the chasing/pathfinding code again at those positions, violating the "DON'T REPEAT YOURSELF" principle of software design - either that or you make a huge OR block with all the possible conditions that trigger pathfinding/chasing.
That's what functions are for, which are in CC but not officially in C2 yet (there is a third party plug in). That basically takes the place of custom actions as well. Basically they allow you to run another event inside an action list or expression.
The point about hidden variables is that I don't want to clutter the editor with tweakable properties (public variables), which are things I need to adjust to balance/polish my game, with internal stuff (private variables) which are just small storage bins that allow the object to do its work.
You can edit/rename/delete/make public those hidden (private) variables, of course, it's just that they're hidden out of view in your normal workflow, similar to how you can lock a background object in the layout editor so that you can click your objects easily.
Hmm... Instance variable groups?
I wasn't very clear there - although you can encapsulate the "kamikaze attack" in a group, you can't say "there you go, enemy! time to do your kamikaze attack!!!"
You can't do that without using weird workarounds like "is group active?" and "disable/enable group". It feels like a hack.
Maybe I'm communicating wrong, because I don't have to use "is group active" or enable or disable groups using my example. I leave the groups all active and the instance switches between groups on its own based on the 'mode' variable. The code to define a behavior is going to have to be somewhere - in my example it's in the "attacking" group.
It sounds like what you want are custom behaviors defined by events? Which are an awesome idea which has been mentioned before, and I'm hoping they are on the to do list. :)
I know you didn't ask, but I'll give an example: I could have a sprite representing the turret body, another representing the beam (I'm thinking of a beam cannon), a particle object, a post-processing layer, and then have a big spaceship composed of other stuff, with multiple beam cannons across its surface. (the spaceship on the whole is a container composed of the hull, shields, hp bar, and then multiple copies of the "beam cannon" container).
Yeah, you can do that stuff already, though it's not the simplest thing.
On spaceship created
for "loop" 1 to 10
set turret.turretnumber to loopindex
set turret.spaceshipid to spaceship.uid
For each spaceship
Place turret at spaceship action point turret.turretnumber
For each laser
Place laser at turret
I'm thinking specifically of the Factory Pattern and the Strategy Pattern
I expect custom aces should make design patterns implementable.
At least for one of those links, I think functions are what you want.