Hey everyone!
As the title suggests, this week was about exploring new options and deciding on a framework to build, from where we can start constructing our project. After last week’s discussion we had to finalise how it is that we’re mapping Computer Science principles to some of the mechanics a student using our tool would have to do, based off of what feedback we received from Eric last week.
We decided to use some of the mechanics from the famous mobile and tablet game “Doors and Rooms“. The game consists of levels which progress in difficulty, where the sole objective is to open the door. But as each level progresses,the door gets harder and harder to open because you have to solve a puzzle to find the key for each room. We thought that if we could target (by halves) to create a platform where a user can place a door and a key into a scene and write the logic to make a Start point and an End point to a “game”, then we’re in decent shape. At the point it would only be building upwards and adding more features to the tool until we have the time to. Of course, constant playtests and user feedback would be necessary.
Some of the key mapping that we’ve made in terms of CS Principles and Mechanics were as shown in the figure below. We later segregated them in terms of Authoring Mechanics and Game Mechanics, and plan to iterate and improve when we start playtesting.
In terms of technology, our programmers took quite the effort in researching different options to provide a good base engine, have a flexible and child-friendly UI and materials that have good documentation coupled with plenty of features. We decided that since the engine does not have to be very graphics and physics heavy, we do not have to lean on C++ coded engines. We are creating a Desktop Application using JavaScript,HTML5 and CSS as languages. The primary engine we decided to go with is PixiJS, a cross-platform 2D game engine library which is based on WebGL and JavaScript. PixiJS was chosen for its easy to use and convenient 2D rendering and animation systems, and it also good with cross-platform building. We also integrate Blockly, because it is an important block based coding interface which is a feature of our tool. Blockly is Open Source and it has a large user group, and it is also very easy to save/load a file using XML. For UI, we plan to use ElectronJS. Electron can design UI’s in H5,CSS and JS and it is consistent with our other platforms which gives immense ease in usage. It also doesn’t have old fashioned aesthetics, which some of our other options were guilty of. We created an architecture map of how we are implementing the whole thing
Sophie also created a few mockups of the UI that we think would be a good target to have in mind to develop towards. We plan on having the student switch between two modes:
- Design Mode, where the user can create a scene and drag a standard asset or a custom asset into it to set up the scene and the objects in it
- Prototype mode, where the user can select one of the assets already set up in the scene and create a logic/interaction for it to have particular behaviour.
We demonstrated our research and ideas to Eric and he gave us his feedback and on it. So for next week, our main aim is to implement more adventure game mechanics into our block-based structures, so that its less computer science syntax and more adventure terms. Stay tuned for further updates, and watch this space for some of the cool artwork and posters for our project!