This week in game development news, I finished porting the tennis game from the Chris DeLeon course on game programming from its original Javascript to TypeScript (see previous blog entries for more information on that; links to source and such are in the sidebar). This is a faithful port of where I left off with that project previously with the sole exception of it having an “attract” mode (and screen shot creation, since ts-game-engine supports that out of the box). In any case, there is now an actual playable game posted on my GameDev site. Going forward that will be updated as new features are included.

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.

Option 2 : JavaScript events

Another way to go would be to have the event create its own Javascript events using the Event() constructor; then the Ball entity could create the events the first time one of its instances is created, and GameScene could add itself as an event listener; the ball just raises the event whenever the situation arises.

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.

Another is a more of a “code cleanliness” thing; events in Javascript are asynchronous, so does that cause any issues? Probably not, but as an example it bothers me at the moment that in a single player game, the event handler for mouse motion changes the player paddle location directly instead of just setting a value to be done in the update method. This is probably another issue with my seeing potential issues where there are in fact none.

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.