This project was built for a publisher of interactive content who’s primary audience consists of K-8 educators. This made the project somewhat unique, as the game was designed for a classroom full of kids to be able to play together with the counselor/teacher acting as the “host.” It was important that the game could be played multiple times without repeats of questions, so we allowed teachers to design the curriculum of each session by choosing from a variety of word sets under major categories.
We also designed a fully separate final round that has students spelling words from the earlier exercises by dragging floating characters to an answer area with a time limit. This mode has physics, and the characters can bump into one another and send other characters flying across the screen.
Games require a lot of prototyping and testing. What you think might work in a brainstorming session may need heavy alteration to actually work in the real-world. It’s easy for code to become hard to manage as you prototype features, and this project really taught me the value of organizing your code, DRY (don’t repeat yourself) sensibilities, and planning for all the routes that a user might take in application.
It also taught me a lot about working with a team (the rest of the team worked on things like documentation and graphics) and working with clients. While I’ve created numerous websites for clients in the past, creating a game was an entirely different matter when it came to client communication. They didn’t have the light bulb moment of “this is going to work!” until after we were able to show a start-to-finish demo with some subset of the content.
I also learned a lot about the specific platform of Construct 2 and it’s limitations. Scirra (the creators) have since released Construct 3 as a SaaS product. Construct 3 addresses many of the issues I had with Construct 2, but I would still think very hard about using Construct again when creating any game centered around text and letters.