Constellation

Specs

My role: Programmer
Team Size: 4
Engine: Unity
Language: C#
Development time: 4 months, 3 hours a day

About Constellation

Constellation is a 2D puzzle game for the Samsung Galaxy Tablet A. In the game, players connect stars into shapes in order to help the main character, Comet, return to their home in the night sky over the course of nine unique levels.

Constellation was developed using Unity Engine with a team of four team members over the course of three months. Our team had two level designers, one artist and I was the only programmer in the team. The project went very smoothly and we all had a great experience working with each other.

Download Link:

Google Drive

Navigation:

My Contributions

As the only programmer in the team, I did most of the C# scripting and all the major systems in the game including star-connecting, character movement and undo movement, and the user interface. I packaged functionalities in prefabs so that the level designers can simply drag-and-drop when building levels. There were several times we did some changes to the game mechanisms and I had some trouble re-designing the architecture. But eventually, we were able to finish everything in time with a decent quality.

Core Features

Stars connection and character movement

This is the basic and core feature of the game: The player draws a shape using the stars, if it matches the shape on the ground tiles, the character proceed towards the tile.

Notice that once the stars turn blue, the player can no longer draw on them.

In the early stage of the project, the moving mechanism was different, you just have to draw a line from left to right to move right. Later on, after we get some feedback from playtesters, we came up with this new feature.

Pick up Collectibles

Here shows the collectibles. Basically, when the character goes to a tile with a lollipop float on it, the player gets a collectible. We added because we wanted to add some optional challenges for players.

The lollipop also unlocks our bonus page feature.

Undo Movement

This is the undo system. During the development, all the team members think there should be a way for players to regret each step because one cannot use stars that are already been used.

Turns out this is one of the biggest challenges of the game. I had to keep tracking all the information as the player proceeding each step, apply the reverse step when the player undo. And any new features we added, we have to make sure it works together with undo.

One example here, the player drops collectibles when undo.

Development Details

In the Update(), the code first detect if drawing is initiated, and call StartDrawing() in HandleDrawingProcess(). Then before the player lifts the finger up, we run Drawing() to connect any available stars that the player slides through. Finally, when the player lifts the finger up, we check the shape formed and see if it matches an available movement.

This is the function that translates shape into character movement. Each shape and each tile has a unique id. Once a shape is finished, this function will be called to check if the id matches one of the tiles that character can move to. If there is a match, player will move to the next tile.

Here is the Undo function. It is called when players touch the undo button. Each movement of character will create an "action", storing all the information in the movement including which tile the character was on, which tile the character moved to, did the character picked up a collectible, etc. This function takes the latest "action" and reverses it.

Bonus Page

This is a bonus feature we added in the last milestone. The player has to collect lollipops during the game to unlock content here.

What's in here are pretty much our early-stage stuff: early build of the game, concept art and paper prototype. Each has some description to it.

I made this very convinent for level designers to add new content, all they have to do is drag image in the Unity Editor and type descriptions. The the bonus page adjust width of the images and sort them automatically.

Post Mortem

What Went Well:

Team maintained open communication and stayed on the same page, which helped production stay on task
There was very little conflict throughout the production cycle
Team members worked diligently on their respective tasks and integration
Consistently delivered strong submissions for each milestone
Dynamic among team members remained positive and respectful throughout development
Addressed feedback and came up with new ideas in response to this quickly
Entire team bought into the game from the beginning
Process went smoothly due to the entire team finishing their tasks on time / in around the estimated time
Tasks were divided clearly and efficiently between team members
Positive attitude towards feedback throughout the development cycle helped team members respond to and incorporate it into the game
Adapted to changes in the game, and were able to kill our babies when needed
Communication both in and out of the studio was open, which led to smoother team dynamics
Successfully tackled tasks that came up that were emergent or unexpected
Team members did not hold on tightly to their own tasks and shared in their work, keeping the end goal in mind
Everyone was always quick to help each other out

What Went Wrong:

Added content very late in the process, which added risk
Team felt too content, which led to not being critical or objective enough to identify major issues with the game
Underestimated what it would take to communicate our mechanics to the player, which delayed production on other parts of the game, since we were caught on
Early milestones had less collaboration between team members, due to everyone focusing on their individual tasks
Spent time on game development things rather than on documentation, which then meant we had to make up time on the GDD
Attention and focus being primarily on the tasks and their completion wound up taking away from the details of Scrum
Deviation from Scrum practices affected documentation
Coding architecture not being clean and organized made it inflexible, making it hard to develop new features
UI planning was not thorough enough and led to assets having to be made on the fly
External stress/worries were not managed and affected the team and game development

Even Better If:

Allocate a small amount of time every day to documenting what had been done so that documentation can grow incrementally
Get more feedback as often as possible in order to get a sense of how the game is playing out
Don't worry about making mistakes because the team can overcome and fix them together
Continue to buy into the process ( paper prototypes, brainstorming, etc. )
Maintain a balance between constructive criticism and team positivity
Maintain objectivity about the game so that you can
Focus more on game pillars and the core of the game early and often to guide design development
Code architecture is designed from the start to be flexible
Before starting art assets, get the specs for what is needed for the engine for better integration and smoother process
Better planning for all assets and a more thorough list of what is needed for the game will help deal with dependencies
Think about the big picture of the game, then break it down from there into smaller subsections
Take care of yourself mentally and physically so that you can be at your best for the team
Improve understanding of the disciplines and their workflows
Explain more of the why/what/how of what is needed for the game, as well as your individual stance on design decisions and how you came to them
Getting a clearer sense of what team members are good at and/or interested in to organize/delegate tasks

Page updated

Google Sites

Report abuse