Chapter 5 Overview

Object Oriented programming has become the predominant way of developing software today. While there are some people who believe that object-oriented programming (OOP) is a misstep, there are also people who quite dogmatic about OOP. Both of the Universities I have attended tend to favor the OOP approach but there is starting to be a look at the alternatives to OOP, with functional programming gaining traction. I am a bit more flexible when it comes to programming believing that methodologies, like languages, are tools and one should try and use the appropriate tool for the problem they are dealing with.

Object Oriented approaches are so common, however, that no matter what your stance on OOP is, you should at least be familiar with the concepts behind it. This section of the book takes a look at the core OOP features that JavaScript supports. Unfortunately, like a lot of things about JavaScript, things are not as straightforward as they should be. While JavaScript has always had support for Objects, the language itself did not explicitly support OOP constructs until the ECMAScript 6 standard was released. This means that older browsers do not support the new language keywords but there are a shrinking number of people who use those browsers. It also means that there is a lot of legacy code out there that does OOP the hard way. These techniques are still valid so it is wise to at least be familiar with them.

In this chapter we will look at a number of OOP related concepts looking at what the idea behind the concept is, how ECMAScript 6 supports that concept, and the "old" way of handling the concept.

To start with, in the "NameSpace" section we will be looking at the name space problem and how to get around it. Even if you are not into the other OOP concepts, name spaces are something that ALL non-trivial programs should use.

It goes without saying that objects are important to object-oriented programming so we will then revisit creating objects in "Creating Objects". This will be followed by "Constructing Classes". Classes are what most OOP languages use to define objects with a class keyword being something that was missing from JavaScript until the ECMAScript 6 standard was released.

One of the more powerful, albeit over-abused, features of object oriented programming is the use of inheritance. This allows you to create new classes based off of existing classes without needing to write most of the functionality and will explained in the "Inheritance" section. Polymorphism is how OOP languages take advantage of inheritance by letting you use a child class in place of a parent class. JavaScipt uses a variant of polymorphism known as Duck Typing which gives you a lot of flexibility and power but has some downsides. These issues will be covered in "Polymorphism and Duck Typing".

JavaScript handles classes a bit different from most other object oriented languages. This leads to a strange issue when trying to use an objects function as a call-back. This issue can be solved using something known as binding, which we will explain in a section strangely named "Binding".

What allows JavaScript to bind functions actually is a very powerful construct known as a closure. Closures are a bit confusing and you may not want to use them in your programs, but they are an important JavaScript technique so I will be covering them in the "Closures" section.

And that should cover all the object oriented JavaScript knowledge that you will need for the remainder of this book.

Coffee Quest Trilogy Plans

The Coffee Quest (CQ) series started off as an attempt to create a web-based role-playing game using the then-new Java programming language. Java, while a very successful language in many areas, failed in the browser and has been replaced by JavaScript using HTML5 components and CSS3 style sheets. This tends to be collectively called HTML5. My original plans for porting to HTML5 was to simply use an engine that supported HTML5  and finally get around to getting my CQFS engine working by building off the back of another engine. I started experimenting with the Unity engine but really do not like that engine. Then I remembered that for a game jam I participated in back in 2012 that I started working on a FPS version of Coffee Quest. That existing work, while still in an early development stage, would be perfect for the first three games in the series so I decided I would do a Coffee Quest Trilogy game that would combine the first three games into a single package. As this game is developed, the individual episodes will be released on Spelchan.com giving visitors to my site early access to the game.

The enhanced HTML5 version of the game will be mixed-time combining both real-time and turn-based play. I may make the option of an FPS mode where the game would be fully real-time. Each game in the series will have multiple episodes to reflect the different maps, and possibly a number of new maps, that will be made available. I have not decided if in the final game to lock the maps and require players finish other maps to unlock additional maps or if to make everything accessible. A third option would be to have all the Coffee Quest 1 maps initially unlocked to the player and once they have finished any of the maps, to unlock all the Coffee Quest 2 maps. Once a Coffee Quest 2 map has been completed, then the Coffee Quest 3 maps would be made available.  

My ideal release plans, which knowing history are very unlikely to work out, are as follows:

Quarter 1 of 2019 would be the release of the Coffee Quest release candidate with a new map (or two). The goal here would be to have a better automap, better quest status area, and the ability to click on the automap to bring up a full-screen map screen.

Quarter 2 of 2019 will hopefully be the beta release of the Coffee Quest 2 module which introduces monsters and inventory to the game. The Coffee Quest series uses the concept of conditions to weapons where the weapon deteriorates in quality over time and will break if the weapon or armor deteriorates too much. One change that the enhanced version of the game will have is that picking up additional copies of the same weapon will simply improve the quality of the weapon if you already have that weapon instead of filling up slots in an inventory.

Quarter 3 of 2019 will hopefully be the release candidate version of Coffee Quest 2 with a new map and enhancements/fixes made to the game.

Quarter 4 of 2019 would be a new Christmas game using the CQ-Trilogy engine.

Quarter 1 of 2020 would be the beta of the Coffee Quest 3 game which would introduce multi-floor towers.

Quarter 2 of 2020 will be an easter-themed game using the CQ-Trilogy engine.

Quarter 3 of 2020 will be the final build of the Coffee Quest 3 module.

Quarter 4 of 2020 will be the beta release of the combined game and will have some new maps as well as a halloween themed game.

If I fall behind on one of the quarter objectives then I will release additional maps for that quarter’s release. This would delay the final release of the game by a quarter. If things go smoothly I will finish the enhanced version of the original Coffee Quest Trilogy by the end of 2020 but odds are there will be a couple of quarters that I will miss so most likely this project will not be completed until 2021 or 2022 in the worst case situation. Depending on my situation once this project is completed, I will look into doing a similar project for the porting of Coffee Quest 4 and the final creation of Coffee Quest 5 and 6.