You've been plugged on Indiegames.com:

> 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

          Create turret

          set turret.turretnumber to loopindex

          set turret.spaceshipid to spaceship.uid

For each spaceship

     If turret.spaceshipid=spaceship.uid

          Place turret at spaceship action point turret.turretnumber

For each laser

     if turret.uid=laser.turretid

          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.

Fimbul

Arima

FSM (finite state machine) architecture could be implemented in plugin.

I thought plugin is a good way to reuse events, since reuse-able events is a function-like structure, it has parameters and return values or some actions.

rexrainbow - yeah, there was a finite state machine plugin for CC, but personally I find a simple variable easier to use. Each to their own, though.

FSM (finite state machine) architecture could be implemented in plugin. behavior would be better, I think, because it would allow you to have many objects in different states simultaneously.

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" can think of more complex examples, I'm sure you could too...

My reasoning is this: you said that you don't want to repeat actions, and bundling them in functions would be the way to go. I call functions a "custom action" (they're synonymous right?).

Why not apply the same thought to conditions? You can bundle a complex condition in a "custom condition".

Hmm... Instance variable groups?now what? That's actually better than what I proposed. As long as you could collapse the groups (both in the code editor and the layout editor), this should work fine.

Maybe I'm communicating wrong, because I don't have to use "is group active" or enable or disable groups using my exampleah, I'm the one communicating wrong, I understood your example... I just meant to explain how I'd go about doing custom actions with the current system.

On a similar note, you can define custom conditions using boolean variables, but that feels like a hack as well.

Yeah, you can do that stuff already, though it's not the simplest thing. follow your logic, but this feels like it would get really complicated really fast, especially if you had to come back to your project after a month. I'm really anxious for those containers!

Fimbul

Yes, for me, "behavior" is one kind of plugin.

But the question is, many users does not know what is fsm, so I had not release this plugin.

> FSM (finite state machine) architecture could be implemented in plugin. behavior would be better, I think, because it would allow you to have many objects in different states simultaneously.

That's still possible with a variable, as each instance of an object can have a different value for the same variable.

I call functions a "custom action" (they're synonymous right?).

Close enough. Functions are entire event structures containing events, conditions, actions, groups, comments that get called as an action. So it works like this:

Event one:

Misc conditions

     - misc actions - place sprite somewhere, etc.

     - call function "function name"

     - other actions

Event two:

On function "function name" (this is a condition)

Other condition, such as is sprite visible

     - actions, sub events, etc.

As construct runs through the actions of event one, when it gets to the action 'call function "function name"' it puts event one on hold and immediately jumps to running event two. When it completes the event structure there, it goes back to event one and runs the rest of the actions there after the 'call function "function name"' condition. After finishing event one, it skips event two, because that only runs when then function is called.

Why not apply the same thought to conditions? You can bundle a complex condition in a "custom condition".

It does seem like it would be potentially useful to people. I'm not sure if I would use it though, as it seems like an extra thing I would have to keep track of and remember what it did while reading code.

> Hmm... Instance variable groups?now what? That's actually better than what I proposed. As long as you could collapse the groups (both in the code editor and the layout editor), this should work fine.

I like that idea too, as long as typing a variable name would search inside all of the variable folders the same way typing an object name does. Having a ton of variables on an object can make it take longer to find the one you're looking for sometimes.

We have some plans to improve the functional and reusability aspects of events. However these are long-term plans - we probably won't be adding anything in the near future, but we do have some interesting plans for things like custom ACEs and event-coded plugins.

Cool!

By the way, Ashley, any hints to when containers are coming?

Yeah i hope one day C2 will have scripting support in-editor :D

I hope it will never happened.

If someone need to write more code - please, use C#+XNA, or use Unity 3D with scripting. <img src="smileys/smiley9.gif" border="0" align="middle" />

Even people who use UDK, Unity3D and so on try to use Kismet or State mashines (like Antares for Unity3D).

What an informative discussion! And not a flame in sight!!