Greetings from Wonderland!
As we get closer to Quarters Walk-arounds and sit-downs, the team is putting in more hours grinding down details for what we’re going to present and explain to the faculty who are going to visit us for the very first time and know nothing about our project. Before I start elaborating though, this is the project’s official poster that Sophie whipped up for us
Based on our pitch to Eric last week, for which we got the green signal, we decided to proceed with a JavaScript dependant engine. We tried to integrate Blockly, PixiJS and ElectronJS, and had good results. We had split tasks among our programmers so each one of them set about working and trying out new stuff with different parts of the pipeline. We used Blockly Developer Tools to help generate our own blocks. Blockly Developer Tools is a web-based developer tool that automates parts of the Blockly configuration process, which includes creating custom blocks and building our user-defined toolboxes. It also has a JavaScript translator, which is convenient for us as it is easier to sync with the rest of the code. Up till now we’re exporting (both in XML and JS) three types of files for Blockly: Workspace,Toolbox and Library. These laid the foundations for the blocks that we generated in the Gold Spike application.
We used native node modules for ElectronJS, which contains the library to write not just web applications but also to convert it into a .exe file, which is what we are targeting. With this we combined all the PixiJS Libraries functions, which when put alongside with the Blockly code we were able to see the desired output. The first function we tried implementing was the “MoveFor”. This function takes in an X and Y coordinate and moves the sample squirrel in the scene that many pixels up, down, left or right, as determined by the coordinates. A few sample screenshots are attached below.
A principle aim for this week was to delve deeper into how Computer Science principles can be hidden inside game creation tools, in a way that feels like we’re tricking children into learning. The best place to look was none other than Alice. Our instructor Dave offered to help us with an overview of Alice from that perspective and we set up time for the same. Even though Alice 3.0 isnt the latest tool in the market, some of the techniques it used as a teaching tool stood out. Dave explained how Classes, in a programming perspective, are implemented for objects and items (used in Alice) as instances of a class, while the scene is both the instance and the class. The program also writes its own sequence of events, which it plays one by one on runtime. Dave also mentioned that while the underlying code structure of Alice has been very helpful, there are a few weaknesses in terms of implementing concepts that our project can learn from. All this gave us plenty to think about.
We sat down and started drafting a vocabulary for our tool. This took a while because it wasn’t just about finding enough adventure game references, but also sorting them into mechanics and classes, and properties like what sticks to the entire game, to the entire scene, or just an individual item. We finally drafted a list of all the types of behaviours an item can have, each with its own set of properties. For example, if an item possessed the ‘key‘ behaviour, some of the properties it should have are ‘lock‘, ‘unlock‘, ‘pick up‘, ‘look at‘, ‘discard‘ ,etc. Some examples of our vocabulary include (not limited to):
- Objects
- Variables
- Game State
- Player
- Output
- Conditions
For our presentation, we used these integrated with Blockly blocks, for an ideal example. We used an interaction from the adventure game Machinarium as an example to show how it works.
So the above blocks explain how an object “red cone hat” when interacted with “white paint bucket”, creates a new item “white cone hat” and is then moved into the inventory. But this is the most simplest of interactions. We need to create block structures like these for hundreds of other verbs used in adventure game, which would be a task we take on next week. To summarize in computer science vernacular, we built a UML to show the general flow of classes in our tool.
That’s about all for this week. Next week is quarters week so we were looking forward to get our work reviewed by faculty, and getting fresh perspectives and ideas which would help with our thinking process. Also, watch out for our first themed team photo!