Finally, after weeks of subversively skipping development tasks to do things like write pages on GameDev math of sketchy value, it’s time to get back to coding! Time to actually fully implement all of the ideas from all of the code streams that I’ve been noodling with behind the scenes.

I’d like to start off by saying that it is currently Wednesday March 16th as I pen this particular bloggity update. Sometime this evening family will be arriving for a visit of a couple of days. Free time has been at a bit of a premium this week while we gear up (read: clean things) in preparation for the arrival. Naturally free time will be most likely non-existant for the few days that the visit is happening, because as much as I like development I like hanging out with family more.

That said, what I’ve been working on is actually implementing the vector handling code that I’ve been working with (and writing about) for the last couple of weeks into ts-game-engine proper, for its eventual inclusion into the last tasks of ts-tennis. This is the last hurdle to finishing of all of the tasks I have for that game, and then I can start on the next game in the Chris DeLeon course (which will involve porting my initial JavaScript version to TypeScript).

In adding in this vector code, I spent some time trying to decide how best to approach this, since in many ways Points and Vectors are tied together; they have the same properties, you may want to create one from another, and so on. The approaches I thought of are:

1. Make some common base class that includes the X and Y properties that both types of objects have, and probably some methods common to both types (e.g. create from array, convert to array). Then the Point and Vector classes would subclass it and specialize the operations for their own means.
2. Make an interface that describes the common properties of both, which is a more lightweight way to do the above. This would keep the code separate but at the same time provide a common type descriptor that could be used in method signatures.
3. Make a separate class for Vector which duplicates some of the code that is already in point. This provides for a more logical separation of things from a code perspective at the cost of duplicating code, which tends to upset my delicate sensibilities.
4. Just add vector methods to the Point class directly since the two are so similar. This gets rid of code duplication and provides the benefits of a common type descriptor all in one, but it seems like it would make final code a bit more unclear since the one type is used for two purposes.

In the end, I decided to do this as #3 and added a new vector class that duplicates some code. I’m going to leave #2 open for the time being and see how things progress when I start getting into the meat of code that needs to work with vectors. It seems like it might be a good idea to have an interface that indicates “This thing contains X and Y properties” that can be applied to anything; then code that wants to do things like find distances (for example) can generically refer to anything that implements the interface. I can imagine having the Entity class conform to it, for example.

I don’t want to fall into the trap of designing API’s that I don’t need, and this seems like it falls into that category, so I’m going to leave it for the time being and see how things progress. Certainly it is a very simple and non-involved change to create an interface and have things that already conform to it implement it, so it’s not like any re-engineering needs to be done (I hope).

That said, I have added a couple of functions to the Point class to mirror ones in the vector class, because I already know that I’m going to need them (based on the code I originally wrote that I’m deriving the final changes from). For example, the ability to convert a point into a vector, optionally providing a second point that is to be considered the origin, or converting a vector into a point.

Based on the timeline of things, I’m not sure yet if I will (or did, since you’re reading this in the future!) get around to merging the changes from my private dev-dev branch to the public dev branch on gitlab. It all depends on how far along I get before I need to close up shop for the night.