Gone Crab has been completely released to the public and was quite the success. There are a lot of lessons I have learnt from this project and our success’s and mistakes. If you would like to play Gone Crab the itch link can be found here.

Gone Crab is a game that was built on the premise of “home”, or more specifically what home means to us (the creators). Our group decided to use the idea of a hermit crab needing to find larger shells due to outgrowing their smaller ones. We went with this because all of our members have had experiences with moving houses a lot during our childhoods so it was easier for us to achieve this experience. In Gone Crab the player will control a hermit crab around a tropical beach and must continuously find a new shell before they outgrow their current one. If the player has no shell they will fry in the sun and will be burnt to a crisp.

What Went Right?

1. Planning

The initial concept of this project was very clever and because of this there was a lot of momentum right from the start. The team was very on board with the project and we all had an idea of what our roles were going to be throughout the project. All of us had sufficient experience with source control and also Hack’n’Plan which is that platform we used for task allocation.

The designers got to work on the game design document in the very first days of the project, soon followed by an art bible. Our programmer made a technical design document for us as well which I was not expecting but it was very detailed and informative so we worked with it. Because of the amount of planning and reference documents that were available before starting to put it together, it was more efficient for time than without them. This also made it easier to communicate to the collaborators our intentions and thus resulted in consistent visuals that do not appear to be third party sourced assets.

We never came across something that we could not add with the exception of time limits. By prioritizing the tasks that needed to be done, we made sure that by the end date the most important things would be in place. By staying consistent and active on a communication platform and a project planning platform it can help get someone in the mindset of a work space and allocate more time to the project than to leisurely activities. This helped with time management because every time something popped up, I would just work on it rather than putting aside and having to plan for it later.

2. Collaboration

Animation and audio students were needed right from the start of the project. Pitches were held to their respective classes within the first week of the project. The pitch managed to gather 10 animation student and of those 10, 8 stuck with the project and made assets for us. Further down the road we managed to pick up 2 audio collaborators and a graphic designer. Overall the communication was really good between us developers and the collaborators. I was not running as the external talent liaison but I did sit in on one of the meetings and saw how it was being handled.

It is mostly thanks to the collaborators and those managing the relationship that we have such high quality assets that fit really well with the game. Also due to the large amount of reference material along side the consistent communication, the collaborators definitely provided us with the assets we needed.

3. Polish

This project was scoped very large because we wanted to push our limits. The mechanics were rather basic and the overall concept was not complex, but the visual style and quality of assets expectations were high. Because of this we could assure that the core game would definitely be there and most of the final polish work would be visual improvements and because of this we could just stop when we run out of time without having to worry about missing functions.

Even though we planned well for it, there were a few things that I was excited to implement but we later did not have time for. This includes things such as particle effects for the sands and the flocking for smaller soldier crabs, mainly small additions to make the space feel more alive.

What Went Wrong?

1. Roles in the final stretch

When the project was nearing completion there were fewer and fewer tasks that needed to be completed. Obviously this is good, it means we planned accordingly but because we had all worked full throttle through the first half of the project, production started slowing for the second half. This is just from being burnt out and the amount of work done in the first half made up for the lack of work in the latter half.

We could have added all of the extra work we missed if we had continued going full throttle but I don’t think it’s anything to worry about. We made it a lot further than I thought we would and planned accordingly. In the future I think it will be worth looking at how the work can be more stretched over the projects period so that the members don’t get burnt out.

Conclusion

Overall I think Gone Crab was a great success and helped me learn a lot of things I was unsure about and also showed me things I never thought of before hand. Because some of my previous group work has been not as successful I was confused on why things didn’t go so smoothly. Now after being with a really well managed team I can tell how to act as a designer in a small studio.

Throughout this studio I have been focusing more on how to better myself as a team member rather than focusing on my tool skills. Naturally when working on these projects I would slowly learn new things about Unity and other programs that I used so I didn’t have to worry about falling behind. After really applying myself to a group that had a very appealing premise and participating with all of the work, I feel more comfortable with group work than I did previously.

I have also gained more confidence in some designer specific areas such as my level design skills. Previously I had been very evasive on anything to do with level design but after this game I have realized more so the extent of level design. This is first project I have worked on that had a concept that would not usually appeal to me and turned out to be enjoyable to work on. Now that I have worked on Gone Crab I think I will approach other game opportunities more openly than I previously did.

In Gone Crab we did not initially intend for there to be a narrative aspect of the game, but we later found out through testing that people were struggling to get the grasp of the game without any context. For the most part our game was very relatable because it was about a crab in a beach environment, we could assume that most player’s will have experienced a beach or have seen a similar theme in other media. The main things we were having issues communicating to the player is their goal and the shell mechanics. We needed a way for the player to load up the game and immediately see their goal and also realize that they are not big enough to activate the event and would need to grow in order to complete the game. We also needed a way for the player to be notified of a shells size and what the different sizes meant for the player.

Because of these reasons we opted to implement a simple dialogue system that would convey the player characters thoughts to the player. When the player tries to activate the end event the game will check the players size. If they are not large enough the player will be shown some dialogue of the character acting scared and intimidated of the larger crabs. The larger crabs guarding the goal also have an animation that is comparable to getting flipped off. This was not something we asked for but we figured it was a good idea to have the crabs seem more intimidating to justify why they are not approachable.

Some elements that were added later in development include the beach balls, seagulls and the cans seen scattered around the beach. At first the cans were randomly spawned in at a random size but we later found out through testing that cans should be a constant size so that the player can use them as a point of reference for their current size/progress. The beach balls are used as a filler mechanic for the player to fiddle around with on their journey so they don’t feel like they are constantly bee lining to their destination without doing much else. The seagulls were used to compliment the tropical beach feeling of the environment along side the cans and beach balls. Given these three additions it makes it a lot easier for the players to relate to the space because it adds a sense of life to the area with human related items and other wildlife.

The shell mechanic was the core element of the game and was required to convey the meaning the most. Many of our playtesters said that they could notice the growth of the character, and those who didn’t would still find out later in the game either by coming across the cans or retracing their steps and seeing the size difference. Because of this players could also tell that the shells would not grow with the player and are being outgrown due to the outline around the shell. This allowed the message of outgrowing a home and having to move on to the next to shine through just as we intended. Of course not everyone is accustomed to our games controls so we needed a way to communicate this to the player. We used a fast pop up animation with a controller image displaying what the buttons do. The reason we went with this method is because it is fast and gets to the point so that it does not frustrate the player. Also using a stylized controller just as we have done makes the game seem less serious and further compliments the light hearted feel of the game.

In our fourth project we were tasked with using analytics so that we could learn how to better ask for feedback from play testers. We have previously used questionnaires to get feedback from play testers so that we could better think of how to improve the game. Our programmer was confident with his abilities and opted to make custom analytics rather than using Unity’s built in feature.

There were two types of information that we were looking for, chunk data and overall data. The chunk data would be information that is recorded every set amount of time, the overall data would just be the information received at the end of each play through. Most of the analytics data we were aiming for was in relation to the procedural generation since we are using procedural generation for shell placement and environmental objects placement.

In the overall data area we were storing the length of a play session, whether or not the player finished the level, how many shells were collected (including values for each size of shell), how many times the player broke their shell from falling, how many times the player outgrew their shell and the total amount of time spent without a shell. Using this information we were able to determine if the player was finding enough shells that were the correct size for them at the time and also if the player was having trouble understanding the fall damage and outgrow mechanic. It also let us see if players were more likely to keep a shell until it breaks or if they pick up a new shell at every chance they get.

This would help us determine the rate of progression for the shells because if players stick to the same shell then they tend to keep walking and not wander around the same area too much meaning they would often get too far ahead of their recommended area. On the other hand, if the player is always changing their shell, they spend more time wandering around the earlier areas and sometimes end up falling behind the recommended area for their size. After testing we found it was more likely for people to stick to the earlier areas, this was thanks to using nice visuals and other quirky mechanics that the player would stop and enjoy before continuing on with their progression.

For the chunk data we were storing the players position on the X and Z axes, their current shell size and the number of shells they have lost up until this point. These values were mainly used to further the points mentioned for the overall data. The position data would help us see how consistent the progression was and making sure players weren’t getting stuck or reaching out of bounds areas. We found that many players would be getting to the later areas and be waiting around a lot because the growth rate was not scaling with the player’s current size. We also found that after finding the largest shell on the beach, the player would need to wait a while before they could finish the game. This was because in order to obtain a shell the player needs to be at least 70% of its size, this means that when collecting a size 10 shell the player only needs to be size 7. But with the end event the player needs to be a specific size which was set to 11. This means the size difference between the largest shell and the end point was size 7 to 11, we fixed this by lowering the size requirement of the end event.