Now that our project has come to an end, here are a few of our reflections on our process and other lessons learned.

What Went Well

Good commitment and feedback from HCII

HCII were committed to giving us feedback regularly, which really helped in early brainstorming and design. We were also able to get feedback from Sesame Workshop early on. This helped in eliminating certain design choices and story choices. With their help, we were able to design the game appropriately paced and challenging for our demographic.


Leveraging on past experience

Based on past experience of some of the members on the DARPA ENGAGE project, we were able to determine some design decisions early. We knew we had to make a 2D game as children did not understand depth well. Also, we knew we should be using the mice and keyboard in a simple way. For example, children are not good at using left and right click. We also knew that we needed to wrap the game experience with a narrative or children would not want to continue playing the game


Leveraging on expert advice

We were able to get constant feedback from Sesame Workshop. They provided us with play testing resources and shared with us some of their best practices for developing games for children. We had weekly emails or calls with them, where they would provide us with feedback on story, UI, gameplay, etc.



We managed to get Box 2D physics to simulate the movement of the beam with weights.

What Could Have Been Better

Communication – Internal

It proved to be challenging for artists to use ImpactJS. Artists would sometimes have to provide x and y coordinates of positions of their assets to the programmers. Using Unity, the process is much more streamlined as the artists know how to use Unity and they can edit asset positions without having to look at game code.


Communication – External

Initially, there was a team member in charge of communication with external clients and another member in charge of internal communication for development. This might not be ideal as information might get reinterpreted twice. The team would probably benefit well from a producer who handles all internal and external communication.


Make Design Decisions Early

There were many meetings at the beginning of the semester, which we spent debating game design ideas. It would have been better to build prototypes and place them in front of children. It did not help that we were also choosing a HTML5 engine to use. We should probably have prototyped using Unity and then made the final game in ImpactJS. Also, this is important because there are a lot of aspects of the game to get correct, like voiceover, tutorial and story, before there can be useful playtest. Hence, it is important to finalize design early and start development.


Need for flexibility in making design decisions

We were tasked to include many features into our game design. These included having the Social Emotional learning, scientific inquiry and the scientific logbook. We need to have the flexibility to drop some of these features from our game because the language can be too difficult for children in the game. For example, the logbook would require us to use the words “support”, “refute”, “hypothesis”, which children find hard to understand.


ImpactJS Limitations

There are various limitations with ImpactJS, which we have discovered over the semester. First off, it is much more limited than Unity. It does not provide tools for animation, particle effects, UI design, which make game development less streamlined than with using Unity. We also found that some of the engine API, like playing music, does not work as expected to in the documentation. Artists or sound designers are also unable to help with placing assets. The engine also does not support having hierarchies of entities, which is a huge problem in developing the beam motion. Toward the end, we also found the game made by ImpactJS does not run well on Safari.


Lessons Learned

Team requires strong leadership

There are many stakeholders involved in this project. Meetings with HCII often involve 5-10 people on their end of the call. Sesame Workshop was also involved as they were interested in having our game on website. There needs to be good strong clear direction from the team because there are too many requests to meet. The team would greatly benefit if there was a producer whose role is dedicated to communication with all of these stakeholders. Multiple opinions can also arise out of both internal and external meetings and it is important to have strong leadership, so that specific decisions are made after these meetings.


Team requires strong documentation

Due to there being so many stakeholders, there is also a need for strong documentation. Sometimes certain ideas resurface after a few weeks during meetings. It could have been mentioned before that we were not going to use a particular idea, but this often does not get passed to each and every single stakeholder after meetings.



We feel that we have made a good game this semester using a new HTML5 engine. We made good use of existing knowledge and experience. We were able to meet our client requests for the educational elements in the game. We found out that our tool of choice might not have been the best solution to having the game easily deployable to multiple platforms. But we know that the game would still work well in other situations.

Go to Top