The first week of lectures covered an introduction to JavaScript and computational thinking. JavaScript was a programming language developed to provide functionality in java based applications in a secure way. It was originally done in a way that gave admin access to a user’s computer to run the code locally which was a huge vulnerability but only took 11 days to develop a solution in the form of JavaScript. Computational thinking is way in which to thinking while planning a solution by focusing on necessary points and to optimise the construction of the solution.

JavaScript’s mnemonic system has been easy to understand so far with those frequently used being very easy to remember such as ‘var’ and ‘let’. Functions such as ‘console.log’ has been a useful change from languages I’ve used in the past such as Python as they remove the need to use ‘print()’ as means to convey errors and observe runtime changes to variables.

Our weekly activity to complete has been a flowchart centred set of tasks. Task 1 was to create a flowchart to express the logic of a section of a game we’ve played before so I chose the one I have the most experience with: Factorio (450 hours and counting). Going into the task, I thought choosing the simplest factor of Factorio would be the best option so I focused on the logic of ‘inserters’ which are robotic arms that move items in and out of machines. However, the logic behind them soon began to build as I realised the specific programming that had gone into them.

Firstly, inserters will continuously pick up and place items but stop on very specific points of logic. They won’t move if they don’t have anything in hand, unless their holding capacity hasn’t been reached and they’re receiving a new item of the same type within a certain time frame. And they won’t return to collect anything else unless all items being held have been deposited. After weighing it up, it was decided that this was too specific to be included in the logical expression and abstraction (a form of computational thinking) was implemented to remove it as unnecessary.

Secondly, a bit of research I had previously done into Factorio while trying to optimise my frame rate produced a piece of interesting information. Factorio is programmed to run at a constant 60 fps or less. All machines, objects, enemies, and animations are programmed to run at 60 fps and won’t operate correctly at anything higher. Therefore, I thought it would be a good idea to implement a small delay into the logic loop to wait for the frame.

The final result was a working flowchart that demonstrated an abstracted logic of the Factorio inserter:

Next task has to express the logic of a guard patrolling from -100, 0 to 100, 0 except when the player is within 10 units of the guard at which point the guard will chase and try to attack when within 1 unit.

In hindsight, I neglected to apply the first step of computational thinking and didn’t remove all unnecessary information from my approach. I began by expressing the logic of spawning the player and guard, which wasn’t needed, but I refocused and decided to split my flowchart into 3 subprograms: The main loop, a distance calculation, and the guard logic.

This approach allowed me to focus on individual sections in order while also being able to return easily to change prior elements which was a use of decomposition as well as a form of waterfall development methodology. Pythagoras theorem was used to calculate the distance between the guard and player while ambiguous variables could be reassigned in the guard logic to allow for reuse of existing logic while patrolling or chasing.

The result was met with differing views from other students. While some stated that it was an interesting approach that covered a wide use case, other rightly pointed out that it was very complicated and relied on a prior understanding of programming to understand. If done again, abstraction would defeatedly be taken into account to slim down the logic and a pseudo-code or simpler approach would be used to express the logic in a much more readable way.

Due to Factorio’s interesting development strategy, I’d like to look further into it especially as a 2D game inspiration although my project will hopefully be simpler to develop due to the 1 month development time. And as next week will be looking to animation, I’ll be interested to look into it further considering my time in learning to develop using unreal engine and solving the problem of changing rotation speeds based on frame rates. Looking at the tasks set, frame based versus time based animations is a strange evaluation considering the face value of a controlled, time based animation. Although, it’ll be interesting the hear the possible computational and complexity benefits of frame based.