As my overriding goal is to go through all of the classic games in the course and (more importantly) follow along in the text book that comes with it and try to finish all of the exercises it contains, after I finished the initial port I went back to the text and started reading it from the beginning again just to catch myself up on everything that was said/taught up to this point. I can’t remember at exactly what point I branched away to work on something else so I’m not sure how many exercises are actually left at this point.
Along with development I’ve also been spending some of my free time playing games instead of working on making them, and I also did a little research, because that’s how I roll.
Something that comes up a lot in my prototypes is having an entity need to convey some state or information to something else based on a game condition. For example, in ts-tennis, the ball is responsible for updating its own location, so it knows when it has impacted on the walls, gone off the edge, or reflected from a paddle. All of these states require the scene to be notified so that it can act accordingly.
What’s the best way to handle that? I can think of three ways off the top of my head.
Option 1 : Specific Object i implementation
This is what I’m currently doing; in ts-tennis, GameScene specifically has methods to handle when the ball bounces, reflects or scores, a reference to the main Scene object is passed to the Ball entity when it is created, and the ball uses that reference to invoke the methods.
This requires the least amount of code, but seems messy to me because it couples the entity class tightly with the scene that will use it, which has the potential to complicate things in the future. For example, what if I decided the game over screen should have a ball entity bouncing around it while it shows you the score?
I don’t know how much that actually matters though, because it’s easy enough to fix if the situation ever arises. This may be my day job as a software developer shining through in a situation where it’s not as big a deal. It’s hard for me sometimes to not write code in the most optimal way I can conceive.
This is a lot cleaner code-wise, but potentially has more issues, assuming I’m not just too nit-picky. One is that browser support may or may not be widely available for this. That’s not a super concern because I don’t intend this code to be fully production ready or anything, but on the other hand it would be nice if it actually worked for someone other than me.
Option 3 : TypeScript Interfaces (a.k.a. “The Java Way”)
The last way that I can think of would be to do this in the “proper” way; the Ball class creates a BallEventListener interface that specifies the methods that the ball wants to invoke, the constructor takes a reference to BallEventListener and invokes methods on it, and GameScene implements the interface.
In the end, the code is way more verbose than option 1 but compiles out to exactly what I’m currently doing. The upside of this method is that there is more of a decoupling between the entity and the scene, so that multiple scenes could easily contain a Ball entity without any further code changes.
This is probably the option that I’m going to go with, despite the fact that it seems a little more verbose than I would otherwise want it to be. LIkely this is nothing to get overly bogged down with at this point (and in fact, I don’t even know if/how other game engines would do this or if they even work the way mine does), but I can only fight my OCD programmer nature so much.