Floob: Good, Bad and the Ugly

So in floob, so many things went wrong. So many. To begin, we did not properly have assigned roles, but instead only did things when they were desperate, making some of us take on multiple roles and other have none whatsoever. This of course was a terrible idea, because it lead to some members of the team being completely stressed out and working way too much and others not really knowing what’s going on. We did improve this towards the end with the use of the HackNplan, but it could’ve been so much better if we had just done it from the start.

Another thing that went terribly wrong was the jelly cube itself. We initially thought that it would be hardest to make the cube wobble appropriately and would be super simple to do everything else. But it turned out that we were not able to use the unity spring joints the way we wanted to and instead wasted many hours trying to make it work until giving in and reconstructing the entire cube with custom spring joints. We could have saved so much time if we had sat down and thought about the process and what could go wrong before attempting to dive in, and could also have benefitted from having a plan to work around the spring joints in case they did not work.

A third thing that went wrong was the estimations for how long things would take to complete. We repeatedly gave estimated times that extended over much more than three times the estimate. The worst of which went from 2 hours to 2 weeks. If we had given more time for delays in our scheduling and not expected the work in the perfect condition times, we could have relieved a lot of stress on the situation and spent our time working to fix problems rather than trying to chase people down for work they said they would have already had done.

There were major naming convention issues with the whole project and we repeatedly had to go searching through lists to find particular objects or items amongst identically named items. This wasted a lot of our time and made it much harder for anyone trying to understand what had been done who was not an integral part of making it. It happened because we had not set out a specific naming convention at the beginning and instead completely forgot. It would be not too difficult to implement one for future projects but it may lapse a few times while it’s in use. But having any form of naming convention is so much better than having none.

Due to our poor scheduling early on in the project, we were lagging behind for much of the project, this resulted in poor playtesting sessions early on. There was also some doubt amongst members of the team and they did not wish for people to play the game in any sort of broken state in fear of being shunned. This severely hindered us and we were not able to get as much playtesting as I would have liked and so got less feedback on the games function and flow early on. If we could prevent this in the future and instead just display any pile of junk for playtesting earlier on, we could produce a much better product than we did.

What went right:

There were quite a few things that went right in the development of Floob. For example, the cube’s final state was spectacular and excellently portrayed a jelly cube. This was due to Kalvin’s devout attention to it and the many many hours he spent working on it and solving new and unique problems with it. The reason it went as well as it did was because Kalvin was devoted and he got to work on it early. If this level of productivity could be replicated in the future for more than just one element of the game, All of what we create could be massively improved.

Another thing that went well was the way in which the level guided the player. The use of lights and physical cues combined with portal esque arrows definitely helped with the player’s progression through the level. This was successful because of the amount of times it was iterated on, and how it was planned to guide the player from the beginning. With repeated feedback, and after watching many people playtest, I was able to understand what elements of the game were distracting the player from what we really wanted them to focus on. If I can repeat this in the future it would let me improve my level design abilities further. It could also be improved much further with more possible playtesting sessions and by taking notes more during these sessions.

The pitch for floob went really well, due to the way it was quickly able to describe its function and what the player would do. It was not able to, however, describe what camera perspective the player would have. We can repeat this by thinking more about mechanics early on, using diagrams more in pitches rather than words, and considering what issues may arise after having a prepared pitch so that we can improve it further.

What to do next time:

The most common thing that penalised floob during development was the lack of early momentum. We were not working as hard as we could have been earlier on and left too much for later on in the project. Another thing was our severe lack of documentation, this lead us to being confused too much during the rest of development. I want to be able to reduce these issues in the future by starting the flow earlier on, forcing space for more playtest, no matter what the game’s condition is, and assigning more time to iterating the documentation so that it can act as a solid foundation for our understanding of the game.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s