Wrap or extend PIXI?

[tmr]

Hi all

I was wondering what your thoughts are on how you go about using PIXI in your projects when you need to change / extend the default behaviour of the PIXI classes.

For example, option A could be to have my own repo of PIXI, and make changes to that. So, for example, if I made a change to how Sprites worked, I could make that change directly and within my code still use PIXI.Sprite. Advantages to this is that all use of rendering is to PIXI, and making changes directly within the classes is often easier. The negatives being I would have to manually sync my version of PIXI vs the official version.

Option B could be to create my own wrappers the classes I want to change. So in the example above, I would create my own rendering libs and use MyLibs.Sprite instead of PIXI.Sprite. Advantages here are that the PIXI code stays clean, and it becomes easier to upgrade to the latest PIXI versions. The disadvantages are that some changes are just easier to make within PIXI itself, and unless I wrap all PIXI classes, throughout my code it could be switching between namespaces, say a PIXI.Container adding MyLibs.Sprite, which could be confusing if I had more than one dev helping on the game knowing which namespace to use!

What did you guys go for?

[d13]

Wrap!

[ivan.popelyshev]

Extend!

[fire7side]

As a new user, extend makes the most sense to me.

 

[d13]

17 hours ago, tmr said:

 

My reason for suggesting Wrap is because I never, ever use classical inheritance.

I know Pixi uses it everywhere, which is why extending classes might seem the sensible choice.

But, I don't like it. 

I find I'm able to produce much more modular code using functional composition.

So whenever I want to change the way Pixi works, I just create little wrapper functions that modify or add to Pixi's default behaviour.

That way I don't have to change or think about Pixi's source code, and I can build my own custom API library that does what I want it to. 

 

 

 

[tmr]

So whether you guys extend or wrap - are you essentially creating your own API, JSDoc-ing it separately and never use PIXI directly? I can see that working for certain parts of PIXI like Sprites, Text, Shapes and Containers, but...

1. what about if there was a change to how the Interactive Manager?
2. what about accessing PIXI filters? Would they just create an alias for them? I don't know why it bother me so much, but the idea of using both PIXI and MyLibs namespaces offends my OCD nature!

Thanks again

[JDW]

I guess it's a choice you have to make. Stay fully compatible with PIXI's future updates or freeze a stable version of PIXI for your project and use it.

I prefer to extend PIXI but I also freeze a stable version of PIXI when the project is near alpha release and do not think about compatibility anymore. I guess not all type of projects can afford to accept this but for mobile games, it's not like you are going to update your PIXI code once the game is released and risks major device incompatibilities.

[fire7side]

I use mixed, doesn't bother me any.  Most of it comes down to sprites, for me.   It might depend on size of project, etc.  The thing with sprites is I can make them interactive, give them their own abilities, etc without redoing that code all the time.  Not that I've done much with wrappers but it sort of sounds like Unity with their components.  I just do not like that.