A mobile game created by New Bee Studio
Neesarg Banglawala – Programmer
Claire Bian – Lead Artist
Aspen Clark – Game Designer/ Level Designer
Rakhil Soman – Programmer
Jami the Jelly is a 2D exploration-based game developed by a small team of students at SMU Guildhall to meet the requirements of the Team Game Production 1 course. It follows the journey of Jami, a jellyfish searching through a series of maze-like underwater caverns to rescue his friends and lead them out of the caves and to a festival. Along the way his journey is fraught with perils, including a host of underwater monsters like sharks, eels, and angler fish.
Jami the Jelly was developed by a team of five students over the course of nine weeks. Throughout development students became familiar with Agile development processes including conducting daily Scrum meetings and working with the spiral development cycle. Challenges faced during development included learning to work on a team, optimizing performance for mobile devices, and tailoring a project to meet stakeholder requirements and user feedback.
The team set out to create a game that would appeal to new or inexperienced players. As such they focused their attention on creating a visually appealing setting with intuitive controls and a charming story. The result was a highly-polished exploration game with simple touch controls and a series of unique environments with a cohesive tone and spooky atmosphere.
Roles and responsibilities
As the only artist for our game, I created all the sprites and animations in the game, including those of the characters, enemies, and environment. I designed the UI and HUD for the game and had been updating and reiterating based on my team and the stakeholder’s feedback. I am also the voice actress for the game that recorded Jami and the babies with the help of my team. In the later stages of our development process, I created all the marketing materials like the poster, our disc cover, our disc case cover, and screenshots of our game. I was also responsible for keeping the art documents updated such as the GDD and our MindMup.
What went well
I managed to implement what I learned from my art classes to improve the art aspect of our game.
I was able to deliver all the art assets on time for my teammates to accomplish their part of the work.
I managed to keep the art style of our game generally consistent throughout the development process.
What went wrong
The resolutions of art assets were inconsistent, which led to some pixilation issues in final game build.
I did not prioritize my tasks well enough to be able to polish all the art assets.
I over-scoped on some of the tasks that I slowed down not only my own progress but my team’s too.
What I learned
Being more aware of how much time it would take me to finish a certain task could help me better plan my scrum board for each sprint, so that I would be able to provide a better general schedule of creating art assets for the team.
Knowing better about the pipeline of art creation for games in the industry could lead to a better result on game art quality for my own game.
It’s essential for the artist to check with the team on a regular basis to make sure the art work is not over/under-scoped.
What Went Well
Our team had a cohesive vision when coming to integrating feedbacks, and through our development process, our team’s adaptability was good enough that we adjusted our schedule to complement them. Since we welcomed a new member to our team after we already started our development process, we spent time implementing him into our pipeline workflow, but it didn’t take long because we had good communication, and a healthy and happy work environment, and he ended up being a valuable team member for us. The teamwork was efficient, either it’s between disciplines or within. Both the LDs and the programmers in our team managed to establish a good workflow between two people.
We had a bad milestone experience during Alpha, because we added in Mr.Biggie to our game, but we did a good job recovering from it, and it turns out that Mr. Biggie is one of the highlights of our game. Other than that, we had a good scope throughout our development that we didn’t need to work too much out of TGP core hours.
One of the biggest success of our team is that every member listened and trusted each other, and that’s our foundation of making a good game.
What Went Wrong
Sometimes our team was too nice to each other. For instance, saying “it’s good” feels great, but doesn’t really help at all. However, being too hard on yourself and your personal work can be demotivating, both for ourselves and the team. We do feel like we didn’t get feedback as soon as possible and getting it sooner was better, but we also didn’t make the proper changes after considering the feedback due to working on things that had already been decided it needed to be worked on earlier.
We did seem to run out of tasks later in our development cycle and our time management wasn’t exactly great and we had way too much placeholder tasks in planning, even though those did get replaced. Generally, separation wasn’t good for the team, as individual work while alone wasn’t the best and communication suffered while apart as well. Our integration testing wasn’t exactly the strongest, which was exacerbated by crunching at our Alpha milestone. While we did stick with roughly the same idea set from the beginning, there wasn’t enough brainstorming, which led to difficulty in establishing what else needed to be done.
One of our biggest issues was that optimization was subpar for most of our development cycle, as we realized that under certain conditions our game slowed down significantly, and our game didn’t really work on devices other than the one we initially started making it for.
What We Learned
Our team learned that it’s important to create structures roles for a team project. For example, our programming team did an excellent job at assigning certain mechanics to certain developers and seeing them through to the end. Department-specific schedules and tasks were well organized, and we learned that this practice benefited everyone.
On a similar note we discovered that pipelines really work, and that sticking to them helps teams integrate new members seamlessly. We also learned that we did our best work as a team and therefore limited our work outside of core hours. Consistently seeking feedback from other departments was another valuable lesson, as was the practice of iterating based on feedback. We strove for excellence from the beginning, and learned that maintaining a cohesive and consistent vision helps a project succeed. We talked frequently about every aspect of the project.
We learned that team dynamics are not always apparent to people outside our team and that showing our positive attitude and communication styles to stakeholders and outsiders is essential. On a similar note we discovered that observing other teams is a good way to improve our own practices. We found that positivity about the group and individual work is important, and an excellent tool for improving team morale and keeping spirits high. Maintaining positivity about one another’s work helped us integrate a new team member when he was added at alpha.
The experience of developing this game with a team who were essentially strangers at the beginning of the semester was incredibly positive. The team attributes this to our working practices and the lessons we learned during development.