WEEK 15 – REFLECTION

Week 15 is the final week of the semester, and that also mean this will be the final dev blog. It’s been a long and winding road and we’re proud of what we have learnt and what have we achieved over the past 4 months. If you’ve been following the blog you would have noticed quite a few changes in the website recently. This is because we’re phasing in to the post-production phase and putting our product out in the open, for everyone to use at their convenience. The latest build of Alice’s Adventure is updated on the website and you can download and try it for yourself by clicking the “Get Alice’s Adventure” tab on the home screen and extracting the zip file that gets downloaded. We have instructions on how to use the tool in general and troubleshoot potential errors, and that will be updated in the coming week too.

Also up next is the final presentation at the Entertainment Technology Center RPIS, where we have 15 minutes to describe our project and show what we made this semester, based on which we’ll receive our final grades for the course. So what we present on that day is very important, and the content is something that we’re deliberating over (and also practicing on stage).  We’re also making a Kickstarter-esque trailer video of Alice’s Adventure which we’ll upload on the website, so look out for that.

This week was more or less a build up to the ETC Open House which happened on Friday. Open House meant that lots of people from various background who may or may not have any idea about what adventure games are or what programming is, are gonna visit our project room. We prepared for it by having sample games made from AA playing on the big screen, and we set up multiple laptops which the tool open. The idea was that people know what they’re doing before they learn how to do it.

We had a fantastic reaction to our demonstrations, as people of all ages were quick to understand the concept and most of them sat down to play a sample game and even build interactions on the tool. We were fortunate that we didn’t have any technical problems or bugs that showed up, and it is a reflection of the hard work and the late nights put in by the programming team.

Watch the website for any updates, and don’t forget to download and play Alice’s Adventure. Au Revoir!

WEEK 14 – CONCLUSION

As we begin winding up this semester and this project, we start thinking about how best to wrap it up and look to the future to continue the legacy of Alice’s Adventure. Week 14 has been an important one for us, as now we stopped developing features on the product and now are officially in the phase of polishing, documentation and post-production.  We started off this week with the ETC Soft Opening, often called softs. All ETC project teams are supposed to have a completed build of their product by softs, from which point nothing more should be designed or built. This is judged by faculty and instructors who visit us in groups of 3 or 4 and test each product, and offer their comments and advice. We’re also graded for the same.

The faculty complemented us on a job well done, as our walkthrough and the tutorial wizard impressed them. They also gave us several pointers though, small instances on how we can improve it even further.  For example, one of the faculty feedback was that we could add pictorial representations to the characters, items and scenes which we declare in Step 1 of the tutorial, something so that the user knows before-hand the options in the asset for their perusal.

Before the end of the semester, we plan on getting a lot of documentation and advertising work done. Currently we’re working on a ‘trailer’ for the project, which encompasses all that we’ve done this semester in a 2-3 minute video.  We would also like a few sample videos of the games that we can make out of Alice’s Adventure, so that children know the endless possibilities of this tool, and of course, instructions on how to make them. There are also documentation and a post-mortem synopsis required as per the ETC curriculum, which we’re also looking into right now. On the tech side, the main target is to get this compatible with as many platforms as possible right now (It’s only usable on Firefox and Edge browsers currently) and other operating systems too.

After Week 15, we only have the final presentations for the project left. Since we’re up first on Monday, a little bit of time has to be allotted for that too next week. It’ll also be the final blog post of this eventful semester. Don’t forget to catch that, as we’ll be giving out instructions on how you can access Alice’s Adventure from the comfort of your house. See you then!

WEEK 13 – INTERPRETATION

This week was busy for Alice’s Adventure as we were working to meet self-imposed deadlines and work towards softs presentation on Week 14. Up till now, we had only implemented the main window which shows the editor and the interaction box. That meant that all our playtests before had not featured the 5 step tutorial, which is a major design point of the project. We had arranged a playtest on Friday evening (Thank you once again, John Balash!) and we required the tutorial to be implemented by then, so that was what we concentrated on for most of the week.

By Friday evening, we had a final build ready to be taken to a community center at the previous home of the Johnston Public School.The build contained the tutorial for 4 steps, as we couldn’t make the navigation decision step in time for Friday evening. On arrival at the venue, there was an unforeseen problem because all the computers in use were Linux systems, and our program is made only for Windows & Mac OS. Luckily we had a few spare laptops, but the numbers of students still outnumbered the number of computers available. But we used this to our advantage as we paired up the kids on one system.

Earlier on in the week, we had met with ETC Faculty Member Jessica Hammer to give us some pointers on how best to conduct the playtest.  She talked to us about clearing defining our playtest goals, and also mentioned pair-programming as a good strategy as it makes the users talk out loud their problems, which would really help us. And this showed, on the actual playtest day, just that it was in a manner not intended by us! The kids caught on to the tutorial and the editor modes pretty well, and once they were able to make an interaction successfully it was easier for them. The one thing that really wished were to have in the game was their favorite movie and cartoon characters, and also their favorite songs playing for the games.  The team has previously talked about a work-around to intellectual property in our tool, but due to legal implications we’re leaving that part for the kids to add in. Other than that, we also found several bugs on the UI and Settings, and also several Interface changes that could improve the user experience. We have compiled and made a list of the same, which we will continue working on next week.

Our goals for next week are clear then. Monday and Tuesday are dedicated to softs presentation, where all the ETC faculty will visit our project rooms and grade us based on our product.  After we get through that, a part of the team will concentrate on documentation and all the things required as part of the production grade, like the project trailer and the final website. That’s it for this week from Alice’s Adventure!

 

WEEK 12 – ENDEAVOR

With time running out for the project to end (three more weeks!), we find ourselves sprinting to perfect our product. After last week’s playtests, we had made a list of bugs and features that we had to work on, stat. Some of them included editor fixes such as locking the scene editor or making the buttons more friendly and natural in a user experience perspective. We also needed to find engineering solutions and implement new features, such as having a run function on the editor so that a user need not build the game to test his work, midway through a project. The work seems to be progressing in a good way, and now it is just a matter of scope; how much can we afford to put in before we stop and comb through our project for bugs and refinement.

A crucial deadline we have set for ourselves is before the softs opening at the ETC. On softs, we have a beta version of our product which we’ll be demonstrating to the faculty. They’ll be grading based on our work, and it is expected that we complete our working project by then. Alice’s Adventure already is close to be completed, but there is still a little work to be done in terms of polishing up our experience. We are aiming to have a playtest at the end of Week 13 at a school with teenagers trying out this tool, so that we’ll have good reviews to take back to our faculty. There will be more info on that next week.

We ended this week by presenting our project at the 7th CMU Summit on US-China Innovation and Entrepreneurship. We represented the ETC as a sample project, along with one other past ETC project. Jeremy presented a short introduction and summary of what we’re doing this semester, followed by a sample demo. I’m pleased to say that audience was very impressed and we received lots of kind feedback.

WEEK 11 – ASSESSMENT

The highlight of this week was the ETC Playtest Day we had on Saturday. Our intentions for this day were to glean as much information as possible, watching children use the Alice’s Adventure tool, which now has taken shape (although in need of extensive fine tuning). We had enough of the product ready so that a tester can make interactions and build the game. We wanted to teach children to make one game in particular, so we had the assets imported for that game in itself, and we planned to show the children how to do the same.

The game that we were showing for our playtests was the same game we showed as a demo for our half presentation. The objective of the game is to make a sandwich and feed it to a cat, and when you do that it takes you to a win screen. To make a sandwich, one has to assemble a knife, bread and jam, and switch it out with the ‘knife with jam’ and the finished ‘sandwich’. They do this by collecting the objects into the inventory and then combining them in there. Once you have the sandwich, you bring it back to the living room and drag it onto the cat, who replies with a dialog saying “I love you”. A win screen pops up at this point.

After our halves presentation at the end of Week 10, we received generally good feedback about product and presentation. Some of the points we felt we needed to concentrate on were about testing, documentation and future planning. So this playtest Saturday was a great opportunity for us to re-confirm our goals and tick off a checklist of ideas successfully implemented for our design. The engineers worked hard over the week, and by Friday we had successfully combined our engine, front-end and UI. It was clunky, and there were a lot of last minute bugs, but it does the job. Luckily for us we have plenty of time to polish.

We had 3 batches of varying number of playtesters, all of whom were teenagers.  The kids’ reactions to the tool were promising; they grasped the concept of adventure games well enough and they instinctively knew how the scene editor and the interaction boxes worked (However, it has to be noted that a few of them had seen and used tools and programs like this before). We learnt a lot about positioning our buttons and boxes in the User Interface, and we’ll be improving them. Some of the verbs, like “Observe”, were ambiguous and invoked varying ideas in the kids’ minds. We’ll be looking at it carefully again next week and working on solving the above-mentioned issues. We also have faculty (non-instructors) visiting us on Monday and Wednesday to offer advice, so we’re also looking forward to that. I’ll be back with those updates at the end of next week. See you then!

 

WEEK 10 – PRESENTATION

It’s been a very busy week for Alice’s Adventure, as we had our halves presentations this week. Our slot was originally intended for Wednesday afternoon, but it got switched out to Friday which gave us a little more time for prepping. So this meant that we had a little more time than other teams to get the slides right and fine tune our timing. I’m glad to say we used it wisely.

Our presentation consisted of four major parts; Introduction to the project, our current design and playable prototype, our road till this point, and our path ahead. Since we’ve already discussed the first three points in previous posts, I wont go into that too much. As part of our future plans, we made a schedule chart of our plans (as required for the presentation) for the next 5 weeks, until the end of the semester. As you can see from the same schedule attached below, we’ve made plans for each week where we’d be dividing tasks among ourselves. We expect bugs and loopholes in design to creep up inevitably, and that may only turn up after rounds of testing, so we’ve been liberal with allotting time for focusing on that. Another task that we’d be actively taking up now is the documentation part of this project. Aside from the fact that it is a core requirement for all ETC project groups, it is also the untold requirement expected from us as the creators of this tool, meant for all those who would happen to use this in the future. We’ll be making user-friendly (and hopefully interactive) tutorials and guidelines, for both teachers and students, so that they can use our software as efficiently as possible. There will be further updates on that in the coming weeks.

Our engineering team is going full steam ahead, striving for a minimum viable product before the ETC Playtest Day, which is on Saturday, the 7th of April. We’ll be hosting youngsters coming into the ETC just for the purpose of playtesting projects. So getting a build ready for that will be our primary target for next week. I’ll be back with more updates next week, so see you then!

WEEK 9 – CONCEPTUALIZATION

Week 9 in the academic calendar coincided with the Game Developers Conference, which meant that Alice’s Adventure was lightly staffed this week. But we had taken into consideration that time we were losing and had decided on methods to make up for it. Despite the absences, we got a lot of work done in terms of general design of the tool, as we focussed on our goals to lead the design direction. After several back-and-forths with our faculty instructors and our client, we finally carved out the right approach to this. We had to pivot from our initial design to satisfy client goals.We placed it in such a way that it doesn’t affect the technological base we have already established, and yet, the client still sees the principles that he wants in there, like adventure game verbs and familiarizing children with game design formats, and the creation of it.

On to this week’s design. Our initial ideas that we’ve discussed and shared so far were centered on a more open framework tool, much like Unity or Photoshop, sprinkled with a bunch of features that allows the user to create a wide range of content, in the style they choose. This meant total freedom of choice, more of a learning curve for the tool, and more preparation material that we would require to actually teach a user how to go about implementing things. After our client meeting with Eric, we decided to take a more procedural, tutorial based approach, where we directly ask the user questions about their games, and their answers and choices craft the game and game logic. Our solution was a step-by-step approach that the user goes through, where they fill out required details which sets the base for the rest of the game. The summary of the steps are:

Step 1: Specify scenes, characters and objects in your game, and where they’re located.

Step 2: Replace placeholders with actual assets in a scene editor, and work on aesthetics.

Step 3: Specify the one interaction which causes you to win the game

Step 4: Specify how scene transitions take place among the scenes declared before

Step 5: Fill up all the other interactions in your game by choosing your object, and also free to edit functionalities of any of the above steps

We’re currently working on creating UI prototypes for the the steps above. We also made a list of the interaction verbs in our game, so that we could run sample games through our design and see if they fit in. Interaction verbs are the conditions, reactions and state, which when put together form an action sentence which describes the behaviour of an object in our tool. All logic implementation in our program would have to be set using the interaction boxes. The following image shows a list of these interaction boxes.

As we progress through iterations, these may be added on/ cut off depending on requirement and functionality. Our attention now turns to halves presentation next week, as our preparation material and presentation skills may need a few iterations themselves. More about it next week…

WEEK 8 – DECISIONS

It was the week before spring break and we were starting to feel the crunch, both with the demands of the projects and also the assignments and mid-sems of the different courses that we have taken on this semester. Another thing that was on our radar was the halves presentation in Week 10, which is fast approaching. For those of you who’re not familiar with halves, it is a mid semester evaluation of our work so far, and our thoughts ahead. We as a team have 15 mins to present our work in front of all the faculty and our peers, so we go on stage and talk about what we achieved so far and our discoveries. It is a valuable opportunity for feedback, and we’re taking it very seriously. We had meetings with our faculty about this, and they gave us plenty of guidelines and tips that we should take care of while preparing and presenting for halves.

We worked on re-prioritizing our goals for the end of the summer, and talked to our client about the issues. A good way to find answers is to plot user stories and help fine tune everything from the UI to our design directions. Sophie got to work on that and made a few paper prototypes for the User Interface.

These were made based on the plans and the outline of the UI we already had in mind (we have already started prototyping with this). Going through the entire sequence again, from before someone opens the application to when they reach the point when the game is done, repeatedly using these paper prototypes was immensely helpful. We also tried going through it using the lens of different play-testers. For example, what if the child is using the software for the first time? For the second time? Or for the tenth time? Will we ask the user the same questions then? We also thought about situations in which the student was doing it in the presence of teachers, and the absence of teachers.

Based on the above factors, we made a list of the features we ask the users to decide. We’re still iterating on this and also awaiting feedback from faculty about this.

On the technology front, the programmers finished integrating the Pixi engine with the front end, and now are scripting in the functions for the code-blocks (our adventure game vernacular) for the  behavior. Next week we’ll rope in all of these, and maybe even have a little demo for the halves. We’ll also be preparing our presentation slides and content for the same. So, see you then!

WEEK 7 – CONTEMPLATION

Another week gone as the project gathers steam!

After the busy week we had during week 6, we pulled back a little this week and re-evaluated what we had so far and how we need to proceed. We had plenty of information from last week which we collected from the children at the Carnegie Science Center. After collating the information, we discovered some interesting information that could be of very good use for our project. We had questions about the games they played, the tools they used on the computers and general experience with programming concepts and how they learnt it. We also had sections about storytelling and their areas of interest with regards to making games (We learnt that a lot of kids would start with music as the most important feature of their own game).

Simultaneously, we’ve also been busy with developing the technology and the product. This is happening in two areas parallely. Tianyi and Ruili  are developing features on the frontend and working with Sophie on fitting it in with the UI.  A feature that was freshly carved out was the ‘Save Project’ option, which allows users to save their work in the middle of a session. Miao meanwhile, is working on the Pixi engine. Next week we will try to integrate both these sections, so we can have a Minimum Viable Product and look at more direct playtesting options.

We also had several meetings with faculty instructors and client this week over our design and approach, and clarifying this with them. After a lot of research, we compiled a detailed list of design cycles and philosophies, of games that fit the genre and also those that don’t. We’ve summarized the flow in the following picture

Next week, we’ll be revising the list of our code blocks and adding to it, while starting to form a detailed design document and step-by-step walkthroughs from multiple personas, using our design structures as guidelines. See you all then!

WEEK 6 – EXPERIMENTATION

Week 6 has been a busy week for Alice’s Adventure. After quarters last week, we looked towards the feedback we received and how to proceed from there, in which we were helped by the quarters- sitdowns on Monday. In Sit-downs, a faculty member (not one of our instructors) visits our project room during a dedicated half-hour slot and discusses what we should do with our feedback, and give us advise on different topics. We were visited by Heather Kelley and Mike Christel in two sessions, and we had plenty of stuff to chew on once they were done. We hadn’t considered sounds and background music templates in our program, so a few plans regarding that were drafted into our scrum boards. Mike gave us a few sources from which we can gather further information about Computer Science education and standards in teaching, especially in Pennsylvania, which was super helpful. We received further help from John Balash, who set us up with a few events which we could use to our advantage, to find out more about our target demographic.

On Wednesday,  a few students and teachers from Cornell School visited the ETC and the Alice Team. They also dropped by our project room for a while and we got to talk to them about what kind of games and tools they use on the computer, and what kind of challenges they faced in Computer Science education. We had a few questions we planned beforehand to ask them, and we got exactly the information we were looking for. We talked to them about our project and showed them a demo. They liked the direction and idea of our project, and wished us well.

We got another opportunity on Friday to get more information from middle school kids, at the Engineer the Future event at the Carnegie Science Center. Teachers and students from dozens of different schools across Allegheny County came down to visit, where a hundred different stalls were set up showcasing the wonders of science and technology. The ETC had one of these stalls, and we got a good chunk of time to show samples of adventure game puzzles and talk about our project. Based on the information that we got out of the previous session, we made a detailed questionnaire to ask the children about, and we eventually got a good number of kids to fill out our surveys. We intend to analyse their responses carefully next week and hopefully find a few interesting points which will help us make choices, especially in those situations where we have to take a design choice. We’d like to give a huge shout-out to ETC Educational Network Coordinator John Balash, who helped us out with all the play-tests.

 

 

 

 

 

 

 

We also found time to work on designs and mockups for a possible future playtest (Week 8 maybe?). In terms of adventure game mechanics, we thought of four primary blocks and multiple secondary blocks, which students will have to drag and drop to create logic and behaviour for various components on the scene. These are

  1. Locks and Keys (Boolean logic)
  2. Passwords (Character strings for input)
  3. Conversation Trees (Branching flow charts easily editable)
  4. Timers (Countdown with an input with seconds)

We’ll be working on defining these more clearly throughout next week. Faculty and Client feedback will be vital, to help us mould this better. There will be further updates and hopefully a more concrete tech demo next week. See you then!