OOP in ECS

[John Nyquist]

I'm curious, how much OOP makes it into your Ash projects? The sample Asteroids had very little, would that be typical? When (if) it does make it in, where do you see it most (views?).

[Richard]

Hi John

Sometimes very little. I tend to do the in-game hud with components and systems, as in the Asteroids example. However, sometimes there are lots of menu systems and data services that are not part of the gameplay but are rather systems used to introduce and configure the game and show high score tables and the like after the game is complete. In this case I might use an MVC architecture to present these menus and just build the core game with Ash. The menus will configure and launch the game, then sit back and wait for the game to finish.

For example, in Stick Tennis, a tennis match is driven entirely by Ash, including the hud, pause screen and scorecard. But all the menus displaying the different game modes and letting the player select which match to play are outside of Ash and use a simple MVC architecture.

Richard

[John Nyquist]

Thanks Richard, it helps to hear that. Over the weekend I was trying to restrict myself to Ash and it led to some insights into--and appreciation of--Ash. 

It's quite an exercise to solve programming problems in such a different way from OOP, I'm enjoying it. 

Regards,

John

[John Nyquist]

I'm finding that for certain scenarios I'm migrating some code that I'd initially put in systems into a component. More specifically, if the functionality relates solely to the component and it's own state. For example, I've a grid component where I'm querying it (like getting neighbors of a tile, or getting an individual tile). That code feels reasonable to be back in the grid class, but I'm not really sure if that's my OO experience trying to get a piece of the action.  :-)