This is the seventh in a series of blog posts I’ve been working on during COVID isolation. It started with the idea of refreshing my systems design and software engineering skills, and grew in the making of it.
Part 1 describes ‘the problem’. A mathematics game designed to help children understand factors and limits which represents the board game Ludo.
Part 2 takes you through the process I followed to break this problem down to understand the constraints and rules that players follow as a precursor to implementation design.
Part 3 shows how the building blocks for the design of the classes and methods are laid out in preparation for understanding each of the functions and attributes needed to encapsulate the game.
In Part 4 we get down to business… producing the game using the programming language PHP with an object orientated approach.
Part 5 stepped it up a notch and walked through a translation of the code to object orientated C++.
Part 6 delves into the world of translating the code into object-orientated Java.
Get in touch on Twitter at @mr_al if you’d like to chat.
Available on GitHub at: https://github.com/mr-alistair/ootest-js
Run-time available at: http://alistairlloyd.com/ootest/js/
There was also a great Debugger for Chrome (by Microsoft) which helped when stepping through issues within the IDE. All set.
Some key differences from the start included:
Defining arrays introduced me to the ‘push’ call, which I thought I had put behind me with an ill-fated foray into Assembly language as a teenager. Populating an array of Player Markers became an iteration around:
…where x_counter sequenced from 0 to 4. Yep, we only wanted to deal with Markers 1 to 4, but I cheated and filled in the first array position, 0, as well.
Math.random will return a floating point value. Multiplying this by the given upper-boundary integer will produce… a larger floating point value. This is great if you want an answer of 4.323 or 2.534 … but I wanted a nice, clean integer between 1 and 6 inclusive. Enter Math.floor which returns the largest integer less than or equal to the current number. Great! As it’s the lower boundary, however, we need to add one to it to bring the lowest possible value up from 0 to 1. So, we end up with:
Presto. One random number between 1 and ‘g_upper’ inclusive.
Back to arrays
Arrays had me pulling my admittedly sparse hair out a few times, particularly where null values or out of bounds results were causing fatal errors. This is where old-school stepping through code during debugs and setting ‘watch’ on variables can be a life saver. I was used to iterating through an array and referencing positions 1 through to 4; most of the arrays I was dealing with expected a value at position 0 as well, otherwise making a reference to the array ‘as a whole’ would trip the wire.
A simple/inelegant fix was to ‘push’ a dummy value to position 0 on the array prior to getting down to business. This value was to be ignored anyway, and for the sake of a few bytes of memory, I was happy.
Two dimensional arrays were just as fun. The breakthrough came when I realised that a two-dimensional array was effectively one array with another array ‘pushed’ into it several times. (My mind keeps thinking of that American culinary delicacy, the Turducken, but we shall not speak of this, here.) So:
…gives us the two dimensional array x_forecast_pointers which, at position 0, has an instance of array x_forecast_internal. A later loop (not shown here) then pushes additional instances into x_forecast_pointer by setting the values within of x_forecast_internal and pushing them into the next available position. I was legitimately surprised that this worked.
When it came to searching for values within an array, I fell back to iterating through the array sequentially. There is an array find() function but, when considering code portability, it is not supported in IE11. Mind you, I’m not particularly supportive of IE11 either, so we’ll call that one a draw.
Making a true independent copy of an array was far easier using the array slice() method, vis:
Walking the talk
So, they were the big-ticket items. Testing the code proved interesting, as with most browser-based renderings one typically must wait for the code to complete before it starts ‘writing’ anything to the document… in this case, the HTML page. It was fortunate that the Visual Studio Code IDE has a built-in console interface that you could output to which helped when it came to stepping through things.
The issue with this is that sometimes code got stuck in a loop (my usual problem of poor punctuation, generally due to missing a bracket on an iterator) and so it appeared to ‘freeze’ after it had flushed output to the first page of so of HTML. Tracing these, particularly with nested conditionals and repeated call-backs is a tedious exercise – it teaches one a wax-on, wax-off lesson about cautious coding, and alcohol consumption while doing so.