Forums » Code » 7 Impact plugins I made

I have been gathering my Impact plugins here:

https://github.com/city41/ImpactPlugins

There are seven of them of various size and needs. The most useful is the observable one, giving all entities the ability to fire and listen to events, and the state machine which allows you to create state machines easily for enemy AI and such.

All these plugins look really useful. I've added some of these same functionalities to my game, but not as a plugin. I like how you implemented your plugins so that they need to be injected. The way I was doing everything was through inheritance but that can get kind of heavy. Thanks for posting these

Oh, man, these are really excellent! +1 for not messing around with inheritance and going inject, too.

I'm going to immediately use these in my game.

I'm also reading the Plunder docs right now and I'm also going to use it immediately, too. Thanks for these!

Thanks man! I didn't post about Plunder because it's still pretty alpha. It does work well though, I used it quite a bit in my game.

The usefulness of these plug-ins and the quality of the code is fantastic!

Doing plugins as mixins is a GREAT idea. Thanks very much for sharing these!

Would someone please explain why plugins as mixins is a good way to go?
Are there any downsides to it?

Would someone please explain why plugins as mixins is a good way to go?

It allows you to do multiple inheritance in a sane way.

From an OO perspective, I'm a bigger fan of composition over inheritance in general – I more often have "behaves like a" than I do "is a". Deep inheritance hierarchies tend to get super rigid pretty quickly.

Deep inheritance hierarchies can impose a runtime penalty on JS as well because of the intersection of being weakly-typed and prototypally inheritance-driven. Too many lookups make JS interpreters a sad boy.

In my particular case I&039;ve solved a lot of problems in the game I'm working on by having an #EntityPlayerBase class. It sets the base spritesheet, the default behaviors, the size, gravity, etc. My other player entities like EntityPlayer (the one the player actually controls), EntityPlayerFallingDeath, EntityPlayerEnteringPortal, etc, all inherit from it.

Say I wanted to combine two different plugins that used inheritance. I can't, since JS can't do multi-inheritance and I already have an inheritance hierarchy in place. Mixins end up being more composable as well.

@drhayes I also have a base player class, but it's called EntityBaseplayer. Then I have EntityPlayerswimming, EntityPlayercrawling etc.

Here's a good description of mixins in Javascript (I just learned about it myself)

That's a good article. I tend to do a lot more functional style these days vs. straight classes; I'm not that much of a fan anymore of straight classes.

A better example might be some of the enemies in the game I'm working on. For the most part, I want them to stay on platforms and be sort of mindless. Occasionally, though, I'd like to place one in Weltmeister and assign a different behavior to it without cluttering up my entity list with "EnemyWithSlightlyDifferentBehavior". That's why I wrote my behavior framework, so I could vary things a bit within the same class.

Feels too Java-y, though. Like, seriously, I gotta have a State pattern up in here? It's JS!

Anyway. ( =

@city41 Thanks for these. Observable is just what I needed. Cheers.