Game Events

[ghost]

Events where something good or bad happens to the company. Example: A: Oh, NO the machines are malfunctioning. What should we do?

[MKelm]

Ok, nice, you do not have to do often additions in the upstream, it is better to make more full functional updates in a lower quantity or when you have an important part another one requested, that reduces the management overhead for you and me, it is important that you update your own local files often from the upstream only.

Some improvements for the mct data structure, the eventManager is affected too: https://github.com/mctteam/mct/commit/3ff92842fe37febdb5077d11f62b589eafda65c9 e.g. the mct.game wording was a duplication, because mct is the game

[jackery4444]

Ok. The new data structure seems much cleaner and easier to manage. Great work :)

This might be the java developer in me talking, but are we not going to use object orientation? From the few files that we have so far only one, EventManager, uses it, but I think it would be hugely beneficial to use a class-like system, especially in the later stages of development.

[MKelm]

Classes are in focus, when it makes sense, I think some refactoring tasks might benefit by that in the later stages.

[MKelm]

Added event message window calls into event manger https://github.com/mctteam/mct/commit/e2f4862568078b8d785518463e940dee839c336a

A welcome event window call is in the menu scene: https://github.com/mctteam/mct/blob/b9779e9af0a2aa48a369dba076b76fe80862d6a5/lib/display/scenes/menu.js#L120

Update: The word wrap works correct now, it might be better to determine the max line length by the available window size, but the current implementation was enough effort for now. The next important part is to fix the layer interactions, then I can extend the content text support for a text list view and some companies might be visible after that ... that are the aims for the next pre-alpha release ...

[MKelm]

I have added the first files for the MCT framework, the event manager does not fit in there yet, because it does not use prototyping. A refactoring to the MCT framework with prototyping might be good ...

I use prototyping like pixi.js, the framework is speed optimized, prototyping offers it ...

A benchmark in my node-webkit:

• without prototyping: 787 ms
• with prototyping: 40 ms (19.6x faster)

Test source -> https://gist.github.com/MKelm/6143399

More in MCT.js and the MCT folder ... https://github.com/mctteam/mct/tree/master/lib

[MKelm]

The game uses the utility class PIXI.EventTarget now, it is easy to use to dispatch events. Currently it is used to handle button interaction events, but it is needed to dispatch element event functions on game events too.

See more about it here:

• https://github.com/mctteam/mct/commit/60b147ea72af160faf826b03f9386edd7c8f69ca Implementation of PIXI.EventTarget
• https://github.com/mctteam/mct/commit/c3daddb7fa3df00c6f023085e540f9a669f6a8d5 Implementation first dispatched interaction events

[jackery4444]

That file means absolutely nothing to me. I'm afraid any PIXI.EventTarget programming will have to be done without my help, at least for the time being.

[MKelm]

Update: I renamed the issue to "Game Events" because the issue is not directly about logic events, but includes them.

Here is a comment to "Events (PIXI.EventTarget) ...

[MKelm]

More about game events and effect methods:

• effect methods can have an unique (effect) event type, e.g. "effectA" and can be located in different elements (as event target listeners)
• depending on the event.content each, e.g. "effectA" method, can perform different actions on the related element

That is useful to register listeners for effects without removing them, because the effect events will be available the whole game and the amount of effect methods in one effect event depends more on the amount of available elements related to the effect event.

E.g. if "effectA" has listeners in MCT.Planet classes (planet effect event) the amount of effect methods depends on the amount of available MCT.Planet objects.