How do I refactor event sheets?

When a project grows bigger, you have many event sheets, you start to contemplate about refactoring it.

Well, I know how to refactor code, I usually follow all Martin Fowler's recommendations and it works perfectly fine for many years. But now I am looking at one huge project, and it's obviously unbalanced, so I have two questions:

• Are there methods, best practices, anything related to refactoring event sheets?
• Are there any known anti patterns in event sheets, that were noticed by C2 community?
• Are there "Event Smell", like we have "code smells" in programming?

Thank you.

I only could tell that : using "condition: every tick" very carefully ( the less the better )

rexrainbow, you would have received many negative reactions on StackOverflow with your "very meaningful" answers...

Do you know what "refactoring" is or you reply just to reply?

rexrainbow, you would have received many negative reactions on StackOverflow with your "very meaningful" answers...

Do you know what "refactoring" is or you reply just to reply?

Given that he has more plugs than anyone else, and is not a native speaker you might put a little effort into figuring if what he posts might have additional meaning.

shalmu

Please ensure posts are polite.

As Newt has said, there are many users on here that English is not there native language, and so posts can easilly be misunderstood. The best thing to do would ask for further clarification, if possible.

Sorry guys, I didn't mean to offend anyone.

rexrainbow, I will try to explain in simple words:

refactoring has nothing to do with "optimization for speed". Generally it is about a structure of code, it is when you move some parts of code to other parts, making the code more clean, but keeping the execution speed the same. For example, you work on something for a week and suddenly see that you have one huge class and many other small classes. Then you realize, that this class wants to do too much! After that you analyze this class and see if there are more than one entities (like topics, themes) to it. If you see, that there are 5 "topics", you split it to 5 different classes. This is an anti pattern, which is called "God object" in programming. There are many other "anti patterns", for example "Feature envy class", is when you have two classes and one of them uses too much features of another one. It is a sign for you that you probably should move some features from the second to the first one.

You can read more here: en.wikipedia.org/wiki/Code_refactoring

Here is a page about "God object": en.wikipedia.org/wiki/God_object

So I thought something similar can happen to Event Sheets, because those are lists of logic entities, which is very similar to code files in many senses and when you create big games with 25 Event Sheets, with 100 groups and 200 functions, there is something to refactor too. Or is there?

shalmu

Yes, I am very sure I am answering your question-

[quote:ebwlz5z5]Are there "Event Smell", like we have "code smells" in programming?

"Condition: Every tick" is similar with global variable. They could be ran (every tick event) or access (global variable) every time or everywhere.

For example. the project has 10 event sheets, each 1 event sheet has 10 "every tick" event. Designer need to check all of these 100 events very carefully when debugging, since they could be ran every tick.

Since there are a lot of non-programmer background designesr, I only could give this suggestion for them. Other topics like re-factory events into functions or using fsm ( I had made a fsm plugin ) might not be easy for them.

If you are a programmer already, try to encapsulate events like in the text code.

( Unfortunately events could not be exported/imported between projects, hope C3 could have this feature. )

shalmu

Moreover, designer could try to extract the logic model from events into plugins. Then he might create another kind of "language" (Domain-Specific Language) for a specific application. Finally the events will be very elegant when reorganize by these new plugins.

Lots of events that would normally not eat up cpu, do add up. Many things do not need to be checked every tick.

Additionally the condition "every tick" could probably be used just once with all the actions together for ease of debugging. Just be aware that order still matters.