Dev Blog

Week 5 meant it was quarters walkaround week for all the ETC students! Quarters Walkaround is when we show/demo what we’ve done so far to all the ETC faculty.They visit us in batches of two or three for 15 minute slots, and this happens six times! These 15 minutes are really valuable, as it is an opportunity to explain the designs and goals of our projects and get valuable feedback, from different perspectives. So it was a session we spent a lot of time preparing for.

Since our walk-arounds was on Wednesday, we had a little bit of time to prepare for it.  Our lead designer Jeremy created a mock-up of the presentation while highlighting some of the key topics that we wanted to show and discuss about. We consulted our instructors then who pointed out some of the points that faculty usually look to stress on more, rather than details of, say, technology and platforms. We revised the draft and also consulted Eric to get his opinions from a client’s perspective. Eric was very helpful too, as he helped realign priorities and also gave us the finer details of some technicalities. Armed with all this knowledge, we made a final deck of slides that Sophie compiled and beautified, ready to go.

We made a presentation that lasted for about 5-7 minutes and we took turns presenting because it can be quite exhausting for just one person to do it continuously. All of our presentations went quite well and we received a lot of feedback, which I’m happy to say was mostly positive. A lot of the faculty were of the opinion that we should start thinking about testing with our target demographic, because the best way to develop such a product would be to work alongside a set of students and teachers, continuously iterating based on feedback we receive from them. We too felt that was an important thing to do, and decided to take help from ETC faculty John Balash and Jessica Trybus to get networked with the education circle and to find out how to proceed with playtesting then.
The faculty also stressed how important it was to get a good sense of design and idea as to how we should build our platform. We intend to be different from all other game creation platforms out there, possessing the best features with none of the weaknesses. To achieve this, we should inspire our target demographic (middle-school kids) to want to have to create adventure games and experiences. Small things like testing with two children working on the same station, offering incentives for different designs, and having an introductory example to get the kids going, are really interesting ideas that we’re definitely going to discuss and possibly integrate.

Meanwhile, our programmers have started planning and working towards achieving an MVP, a minimum viable product. Our target is to make an application which has a basic prototype and design mode, so that a user can make a basic interaction, save their work and run the game. The ideas is that if we take this out for testing we can get a general feel of whether the kids are receptive towards it, and probably come across problems we wouldn’t have considered before. We’re hopeful of having a build by the end of next week. So that will be our primary focus for Week 6.

I will leave you with a team photo that we took last week as part of our branding requirements. These are individual photos stitched together by Sophie, and you may recognise some of your favourite characters from Lewis Carroll’s works, but with a new look. See you next week!

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!

 

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:

1. 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
2. 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!

 

Greetings! We’re  Alice’s Adventure, and this semester we’ll be making an adventure game creation tool to help kids make their first ever video game, but with the head-fake of learning computer science principles.  The first point of discussion this week was the roles each of us are taking for the project, which are:

Jeremy Liu : Designer
Miao Ren: Programmer
Ruili Tang: Programmer
Sophie Kim: Artist & UI/UX
Tianyi Zhao: Programmer
Vasant Menon: Designer & Producer

After much discussion, we arrived at Alice’s Adventure as the team name, as it clears the motives of the project quite well.  Our instructors for the project are ETC faculty Dave Culyba and Ruth Comely, who we met with over the introductory week. They advised us to do our research, well, by playing adventure games! It was a good idea as we sat down as a team and made a composition box, outlining the resources we should take inspiration from, what kind of product we want to create, and what needs we are solving for our target audience. We presented our composition box at the Playtest To Explore Workshop and improved upon our ideas too.

The rest of the week we spent in a cycle of research and meetings. We each assigned ourselves an adventure game to analyse or a tool to study, used/played it the whole day and the next day met up to together talk about what we learnt and some of the interesting points we think should be kept in mind when we start building the product. We compiled all of our results and Sophie made a cool slide deck that we presented to Eric Brown, Director of Alice and also our client, with good feedback. Next week we start implementing some of this and looking more into the engine side of things and outlining how the rest of the semester would go, week by week. So see you then!

 

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!