Splop’s development was largely successful. After the creation and selection of the prototype, the game largely stayed the same as it was. Splop has one simple interaction, jump jellies over other jellies, in order to score points. The more points you earn the more stars you earn. You use stars in order to unlock more level packs, and it becomes progressively harder to earn stars, and therefore unlock level packs. To make this easier, we offer power-ups, which can be purchased with in-game currency, which you can get by either watching ads or purchase with real money. The goal of Splop was too make a mobile game, with financial goals in mind. The game has a very cheery styling, with happy, colorful jellies, colorful visuals, SFX, and music.
What went well?
We determined our theme based off of our market research. We learned that for the most part, successful games in the puzzle genre often had cute characters and a bright art style, along with happy sound and music. I believe that with splop, we hit this particular point very well. In the future, I will be sure to follow this same process in the future, as I believe it’s something that will guide my game design process very well.
- Simple Interaction
From our market research, we also learned that most successful games were very simple to play, with one simple interaction from the player. In the case of splop, we originally had it that you would just tap on a jelly, then tap a valid space for it to move to, and it would happen. However now we have simplified it even further by making it just a simple swipe across a jelly to a valid move space. If in the future I create another mobile game with the same goal of commercial success, I should follow this guideline.
I believe that for the most part, we worked well together as a team. We all did the tasks we were given and communicated very well. However, we did have a problem here where work division wasn’t split evenly, due to members of the team having less idea of how certain systems worked, therefore being unable to work with those particular systems. In the future, I will always try to keep this up, as its integral to game development.
We always kept our documentation up to date, until almost the end of the project where we had to start rushing out things, that weren’t exactly to the design. However, I believe that for the most part, especially early in the project, we did keep up well with the documentation.
What went poorly?
In the early stages, we create a TODO list that we used to keep track of what needed to be done and who was doing it. It worked ok, but if we created a proper schedule by this point, I think it would have gone wat better. Later in the project, we did create a schedule and mostly kept to the milestones and tasks we had set up on it. However, we did not keep this updated properly as we went. This is because we had to start rushing things to get things in, and we quickly defaulted back to making quick to do lists, of the most important tasks. In the future, I will rather than create a to-do list, create a task list, complete with when they needed to be done by, so that could easily be formatted into a proper schedule. I believe that, were we to do this, our game would have been in a much better state much earlier.
- Cross-Discipline Collaboration
From the start of the project, we worked with an audio collaborator on the sound of Splop, our communication broke down in the middle of production. Our audio collaborator got snowed down with a lot of work of his own, however we also failed in keeping up good communication with them. In the end, we did get all of the audio we needed, however, if we kept up good communication, it could have been better. We also got animation collaborators very late in the project, which led again too rushed art and animations, along with issues with implementing the animation, due to using a system that was broken, but we did not know beforehand. In the future, I will try to keep better communication with collaborators, and I will better seek out collaborators, and try to bring them on much earlier in the project.
- Game Testing
This is something that definitely went poorly. We formulated a game testing plan, and sent out questionnaires with the beta build, however, this is something that might never be filled out. In future, I think I will need to be harder on people to get them to the questionnaire, even tho we still got good feedback, it could have been improved by this system.
In conclusion, Splop’s development went well, I believe we hit our target market, and our goal of making a mobile game with financial goals in mind. While I believe for the most part, development went well, we certainly had issues, mainly in the areas of Project Management, and Collaboration.