This document describes the history of my BlackBox™ implementations and the technologies used to create the instances of the game.
While this version is a complete rewrite of the game, and prior players of BlackBox™ may note minor changes in the user interface, the mechanics of the game are unchanged from the previous version.
The rewrite was necessary to address performance issues with the previous Java-based backed and relational database used to store the game information. This version replaces the backend and frontend with a NextJS implementation, along with the use of a MongoDB database.
The most prominent, and requested, new feature is in the Leader Board. The Player Games section has been enhanced in two ways:
As with the previous versions, games can be bookmarked and restored at any point by saving the game's URL. Older games have been migrated to the new database, so games saved from older versions of the game can continue to be viewed, and unfinished games resumed.
This version of BlackBox™ features the following technology changes:
Sincere thanks go to Jay Barnes for providing the cool 3-D graphics for the game.
Much appreciation is also given to the people who write open source software and reusable components, and share their work with the rest of us. The open source software and components used by BlackBox™ include:
The skeleton of the application was generated using create-next-app.
And, of course, thanks to Parker Brothers (now a subsidiary of Hasbro) for creating such a fun game in the first place!
This is the twelfth implementation of BlackBox™ that I have written. Yes, twelve versions! The history of the previous versions is recounted as follows:
My first implementation was a command-line version of BlackBox™ and was only the second real program that I wrote when first learning programming back in 1978. (The first was a Tic-Tac-Toe program.)
The program was written in BASIC on a Control Data Cyber, and emitted an ASCII art rendition of the board after every move. Rather tedious on a 110-baud teletype, but you work with what you've got!
While working for Digital Equipment Corporation (DEC), I wrote the first GUI version of the game in the mid 1980s using DECforms, a GUI-management system for VAX/VMS and Digital UNIX that managed user interfaces for charcater cell and X11/Motif programs, on whose development staff I worked.
The language was BLISS (a language used almost exclusively internally to DEC to write system software), and it was the only version of BlackBox™ that I was actually paid to write as part of my job, as it served as a demo of DECforms' capabilities outside the realm of normal business programs.
As it turned out, it revealed itself to be a really good test of the display management component, revealing a number of bugs, and pointing out weaknesses in performance. I was commended by the project leader for “thinking outside the box”, har-har.
In 1992 I wrote another GUI version of BlackBox™ for Windows 3.1 as part of teaching myself Win16 programming. The language was C.
When Win32 and MFC came around, I refactored the game using C++; I guess I should have considered the refactored implementation Version 4, but I thought of it then, and still do, as Version 3b.
In the 1998 time-frame, I wrote a Java Swing version of the program as part of learning Java.
I'm not sure if I should actually count this one as I never really completed it. But it was really really close to being finished. Honest!
The reason I never actually finished this version is that I came to realize that desktop Java wasn't really all that, and it all began to feel like a waste of time. But, as we shall see next, I was about to discover where the true power of Java resides: on the server.
In early 2000, BlackBox™ was re-invented yet again as a web application as a means to learn the then-new Java Servlet and JSP technologies. This version was heavily reliant on server-side activity to manipulate the UI and used an invisible <iframe> element to make contact with the server without the need to refresh the whole page.
This was long before I, or anyone else, had heard of Ajax so I give myself props for coming up with a similar concept all on my lonesome.
The sixth version was a modest revamp of version 5, using XMLHttpRequest to make the Ajax calls back to the server in place of my home-grown iframe approach.
While still a Java web application, the next version was completely re-written using Java 1.5, better practices, less reliance on the server side to perform user interface tasks, and with jQuery to assist with the client-side programming.
I would go on to write the three editions of jQuery in Action being so impressed with how easy jQuery made writing the client-side code.
This incarnation of Black Box™ was a 100% client-side implementation in JavaScript using the AngularJS JavaScript framework. There was no server-side component.
The code followed the MVC pattern as defined by AngularJS. This worked out really well as the game engine only had to concern itself with updating the model, and the framework took care of updating the view to match the model.
This was the first version of the game to incorporate sound, utilizing the HTML5 audio element.
That was all as cool as the North Pole on Christmas Eve, but the number one request from fans of BlackBox™ that I'd received was the ability to bookmark a game in progress and be able to return to it at a later date. (For the record, the #2 request is multi-player capability.)
Book-marking made me think “stateless”, and thinking “stateless” led me to...
The concept of stateless immediately made me think of a RESTful API, and so the ninth version of BlackBox™ was the first to be persisted to a database (initially PostgeSQL, soon followed by MySQL, but the code could use any JDBC-compatible database).
The game state was, and still is, persisted behind a RESTful API that allows the game state to not only be persisted in a stateless manner, but allows the details to be obtained at any point in the future.
The client part of this implementation was an SPA that heavily used Ajax (via jQuery) to access the RESTful API, and communicated its data via JSON.
Each instance of a persisted game is assigned a non-guessable nonce that is recorded in the anchor of the URI, allowing each game to be individually addressed and bookmarked.
This allows any game, running or complete, to be revisited at a later time, preserving its game state, by simply bookmarking (or otherwise recording) its URL.
The tenth version of BlackBox™ was completely re-written such that the front and back ends were separated into their own services. The back-end continued to be a RESTful API powered by Java and the Play! Framework, and became its own self-contained project. The frontend was completely re-written as a JavaScript SPA using React and Redux.
In the eleventh iteration of BlackBox™, the frontend focused on the use of React hooks, React Context, and the useReducer hook.
Additionally, the native Fetch API was used for backend communication.
The RESTful API supporting the frontend was been completely rewritten using Java8 and Spring Boot.
In this current version of BlackBox™, the frontend and backends were rewritten using NextJS. This allowed me to ditch the use of Java in the backend and write the entire stack of the app in TypeScript. Players should note a marked increase in performance and responsiveness.
The relational database used to store game information — current as well as historical — was replaced with MongoDB. This proved to be more performant (as well as more cost-effective),
Thanks for reading this far. I have a lot of fun working on this game. And I have a lot of fun playing it when I get a chance. I hope that you do as well.
Question? Comments? Kudos? Castigations? Contact Bear