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.


Question and Answer

We changed many things about floob during the process of development, as most games do. Most of these changes came after having a playtesting session. One  major piece of feedback we got from our first decently sized playtest was that the camera just was not good enough. What we had initially intended with having a fixed angle camera that rotated to face the sides when the player was on the edges of the map was making people extremely disoriented. The players repeatedly felt that they wanted move the camera themselves, even slightly. So what we did was to completely change the way our camera functioned and instead made it so the player can fully rotate the camera with a limited y axis then giving the player more freedom of vision within the level. Upon the next playtest there was absolutely no problem with the camera for the people playing, so we moved on to other problems, like the light jumping section, or the significant use of unnecessary invisible walls. To get feedback on things like this, I wanted to try and get the player to write about what stood out to them so that they could be both positive and negative, letting me get an understanding of how they felt whilst playing, while also having questions that asked for the player to label issues they found for themselves whilst playing.

For example, one of the questions I had was “Describe a moment that stood out to you most whilst playing”. This was an attempt to get the player to describe their play story both good and bad. However, I found that the question was probably much too vague because the answer I got were very much vague and non-descriptive. Often the player would simply describe a mechanic of the jelly cube, rather than a moment that they experienced. I’m not sure how to word the question to discourage this and encourage more involved answers, it may very well just be that nobody really wants to write a large amount of text about anything when they can write a few words and get enough across. There’s still much to learn, I think there always will be, but for now I’ve definitely benefitted from having a questionnaire when playtesting, I just need to focus more on how to get people to start writing, and find ways to get targeted information without blatantly pressuring the player into saying something specific. I hope to learn just that one day, but the only way to really learn is to fail.

TDD’s. Write them, or spend all your time fixing something you don’t understand.

So, Floob right? It could have been so much better if we had just sat down and written a TDD. But what is a TDD I hear you asking?(pretend you’re asking here) Well, a TDD, is a Technical Design Document. A TDD can serve as a set of instructions that can map out how the game’s scripts communicate with each other and what parts of them can be tweaked and in what way. The document also acts as Tracker for how things can, and probably will, go wrong and also can contain solutions or alternatives to these things if and when they do go wrong. This was one of the major things we were missing when it came to Floob. You may not be aware, but we as a team wasted a large amount of time being completely unsure about whether or not the jelly cube would actually be able to resize for a large portion of our development. This was due to the strange way unity’s spring joints worked, which was the core of how we made the jelly look like, well… jelly. If we had taken the time early on to sit and consider where this could fall apart, we probably could have made a plan early on for how to work around the jelly cubes wobbly nature. We probably also could have avoided the hazy line between designed movement and programmed movement, the designers could have been much more involved with how the player moved rather than simply stating what it should do and crossing their fingers and hoping that it works. We also would have massively benefitted from having a recorded way in which the jelly cube and the rest of the game would work, so that we wouldn’t have to have just one person having any idea how the jelly cube worked and what would and wouldn’t destroy it with a single touch. Because from what we had, there was one person who knew exactly how the cube worked and why things happened, there was another who knew some of the scripts behind it but wasn’t really confident enough to dive in a start helping out, and the rest of us who were treating the cube like schrodinger’s cat, just hoping that if we waited long enough the the cube would be working when we opened the box. This really negatively affected us because it chewed up almost half our time simply trying to make the jelly move like jelly. I do not want to have to waste that much time on a project again, and I would much rather spend the time improving on the game rather than making sure its not broken before shipping. But I sadly cannot change the past, no matter what hat I wear.

Image result for marty mcfly gif hat

GDD’s aren’t just an item on a checklist

So with my work over the past few months, most of my projects have had Game Design Documents. But have they really worked like game design documents? No. Most of the GDD’s the projects had (if they even had them to begin with) were only done to check a box on a list, not to truly describe the game’s purpose or explain how elements should feel to the player and why the elements are there. One large thing they were missing was constant change, due to them being done to check them off a list, the documents were never returned to. So when the final product came around, it barely had any resemblance to what the GDD said the game would be. If the GDD’s had been updated as the projects went on, there could have been less disputes and confusion about what was and wasn’t in the game anymore. For example, when working on floob, we rarely updated our GDD, and at many points throughout development we had many people not agreeing on how certain things would work and being very confused about whether or things were still in the game. We repeatedly had confusion about how the water would work and how it would affect the player, if at all. We had disagreements about how the player would move and whether or not things had been scrapped due to lack of time or physics engine limits. We really could have saved time if we had a document that would just tell people these things rather than needing to have a discussion not everyone would remember. Our documents also had less information than we needed them to, because it needed to be describe elements that we didn’t entirely understand in a moment and rather than spend time deciding what the element would be, we just left it out. This was a very bad decision, because our lack of detail was one of the major causes of our confusion between members of the team. None of us really knew how the wall jumping would work, we just said “there will be wall jumping” and boy did that screw us over. There were times when the player could only wall jump off of specific objects and there was no consistency about how much force the player got from jumping off the wall, it was a mess. This is not something I want to do again, and I have plans to keep my GDD’s up to date for both my Shared House project and the Night n Day (now The Golden Hour) projects.

Getting into the building of my rooms

So I should probably write down my process for building my rooms for the concept of Shared House, so that, when it comes time to build more for the continuation of the project, I can make better ones. To begin, I began by simply making an extended rectangular prism, because the first room was just a simple box. Then came time to add the trim to the walls, so that I could make the transition between the walls and the floor much nicer. As I was doing this I needed to make the door trim and I also decided to add a window, with windowsill, in the process. So the room was kind of shaped like a normal room now, but It was all just white. I really wanted to keep with the visual style of the assets I had found to populate the room when deciding how to texture/colour the room. The models I had found were low poly and had face colouring with very soft colours to keep a cartoon esc. Style. I took care to choose colours that were not harsh and had a feel of warmth to them, so that I could match the models and make the room feel homely. This resulted with a room looking like this:  

Screenshot (1).png

But this was only the beginning, there was still lots to do with the possible shapes the room could take on and possible feature walls to attract attention and create contrast. The second room  I built was an ‘L’ shape, and had a ceiling cutting into it. I chose this shape so that the room could be memorable for the player, it was also to be able to create a sense of altitude, comfort and isolation while also being completely open. I chose to make the wall being cut into by the roof into a feature wall to attract the player’s eye and to tie the two ends of the ‘L’ shape together. But the feature wall really wouldn’t work by having a stark separation between the normal colour and the feature colour, so I added trimming to the feature wall to emphasise it and highlight the separation while also making it feel less sudden. Here’s what that one looks like:

Screenshot (3).png

The final room was probably the most interesting to build, due to its split level supported by pillars, the stairs to connect them, and the railing that separates them. First Up I wanted to make a room that had an elevated bedroom section because that’s always been a dream of mine, and they’re super interesting. But then I also wanted to make the room be more than a bedroom, so I transformed the section beneath the bed into a home cinema and also had a spacious office with large couches. But that’s besides the point. What was really interesting was creating the railing, pillars, and stepladder to fit the visual style of all my other assets. I made sure to keep simple faces and trying to imply intricate detail with simple volumes. For example with the pillars, I wanted to imply detail like these:


To do this I created pillars like this:


I then continued this motif through the ladder and the railing, making the theme of the room connected and singular. I’m pretty pleased with how the final room turned out, the only downside currently is that it is a little too large to populate the way I want to without creating more models to fit the visual style of those I got from the store. But all in good time.

There’s a reason they’re called Art Bibles

So do you remember way back when I made that super mario world 1-1 remake? Yeah… I’m cringing too. Anyhoo, One major thing I was missing when it came to making that game, was a bloody art bible. The one thing I had most free reign over was the one thing I planned the worst (not the sausage). If you can think back to when I blogged about creating the art for the project, you could quite easily see that I had little to no direction what so ever. But, if I had had an Art Bible, man would it have been different. I would have had a much better plan for how to approach the new sprites and maybe even come up with some of my ideas earlier on in the development process. I didn’t even know what kind of colour scheme I wanted to go for, or if i wanted to go for something pixelated or drawn. I didn’t know what assets I wanted and I didn’t really know how I wanted to convey Marcel Duchamp’s work through it. It was all just one big trash heap. That’s why I ended up with the utter monstrosities I used, like, what even is this:



I feel like I could have made a much better product if I had just sat down and thought about the art, before diving right into making it. But I guess hindsight is 2020. I know that Floob had much better results thanks to its art bible and how it could be used to describe to our 3D modelers what we were looking for with their product. Come to think of it, it could have been really helpful to have fleshed out or wants and desires for the audio in the same way. Because I think that would have greatly improved all the audio we received, rather than having to edit or scrap a fair amount of it.
Image result for the more you know gif

HCD nightmare

Well, we really could have used a detailed HCD for PR nightmare. As explained by this document, the purpose of a high concept document is to catch the eye and to quickly explain why a particular game is should be played and why someone would enjoy or at least appreciate the experience. We didn’t have this for PR nightmare. The game was very much a train wreck. We hadn’t actually considered why someone would enjoy playing it, we sort of just assumed that they would enjoy arguing, but also kinda enjoy the ridiculous situations. We never even considered if the two ‘sources of joy’ would blend well. This was extremely clear when the end result came about. Our ideas repeatedly felt half baked due to our lack of solid foundation. A key reason why we never had a HCD was due to our repeated situation changes because we just could not come up with a good idea to stick to. By the time we had come up with the idea we would run with, our pitch was over and done and we’d moved onward. If we had a set HCD ready for our pitch, we would have had an opportunity to look at our situation and seen how terrible it was before pitching. We also would have been able to have a proper understanding of the reason we wanted people to play PR nightmare to then have a better basis for the game itself. When it came to Floob, we did have a HCD, and oh boy did we benefit. The whole team had a solid understanding of what the game was about and why Floob was a game people would want to play.This really helped us when we were making decisions as a team and we all had something to fall back on when we weren’t sure. I don’t really want to go back to doing a project without an HCD, because that’s kinda like making a game that has absolutely zero direction, yes it has infinite possibilities, but it would ultimately become a mutated pile or trash like when homer tried to build a bbq pit.

What did I do for the past 2 days?

So over the past few days I did many things surrounding my current project, Night and Day. I worked on things like the game’s audio and scripting the transition between day and night. To begin this work, thought I’d get elbow deep into scripting the lighting changes. To begin this, I needed to start by adding triggers to my level for when and where the light should change. I added 5 triggers in total, creating 6 separate spaces, 5 of which will have light changes and the sixth just simply turning off the final particle emitter, each trigger was tagged respectively. After I did this I went on to create the script for the triggers,  so that I could have checks for when the player left the sections. I then had to decide which sections would have what lighting, e.g. Day and Night. I decided to have the game begin on Day, and alternate between Day and Night until the final sunrise/sunset. Finally, after the prep was done, I began deciding how I’d let the light change with both the directional lights and the skyboxes. At first I wanted to see if the concept would work, so I just simply had one directional light turn off and another turn on, while also changing the skybox. This did work, but was really jittery because it was an instant change, so I eventually came back to this and made the light levels smoothly change between each other. I was not able, however, to change the way the skybox changed, but due to the way the level commonly fills the majority of the players view when the skybox changes. Next up was to have the trigger deactivate the particle emitter. To do this I realised I could not just set its active to false, but I had to turn off the particle emission first then drop the intensity of the light i added to make the particles appear to glow, and then I could turn off the particle. Here’s what my code looked like after doing this:


Fading stuff (requires update rather than collision)


Sudden changes

So with the day and night transitioning nicely… enough. I decided I would sit and determine what sound would go where and what they would… sound like? I already had a good idea of what I wanted, footsteps and things, ambient bird sounds for both day and night, and music to accompany it all and tie it all together.

Here is a list of sounds that I found and then cut down and edited to fit my needs:

And here are the two music tracks that I just couldn’t pick between, so I used both and had the game randomly choose one:



I feel that the music excellently portrays the emotion of the space the player is walking in. It’s a somber and steady sound that encourages the calm slow footsteps that the player takes. The ambient sounds are very fitting and when I was implementing them I repeatedly forgot that the sounds were in fact coming from the game rather than outside my window. I feel the footsteps also help the player feel connected to the garden, rather than walking on stone or concrete like the standard sounds, having the gravel footsteps really helps.

The final audio thing I added was a sound for when the time changes, I’m not particularly happy with what I chose and I feel there could be better ones out there. I wanted a sort of cymbal shimmer sound, but I could only find the fade sound in the playlist above. It works well enough and does make the time transition feel a little better than it initially felt.

Here’s how it turned out:

There was a few more things I did yesterday to do with solving some lighting issues that took much too long, but that’s all for an other day.

Making the Music work

Well, not exactly. I made music play. In floob. Because no one else would do it.


Well that’s why I’m writing this.

To begin I needed to decide what music tracks I wanted to include and what tracks didn’t make the cut.

So to begin, here is all the tracks we were given. There’s a mix of good and bad and just down right odd. After speaking with the audio guys they seem to be aware that not all the tracks are good, but since they were pressed for time they just gave us everything they had, warts and all.

So when we got all these tracks, I took it upon myself to listen to all of them, give feedback to the audio guys and then decide which ones were for the chop.

Some tracks like this one:


Just did not work at all. There was repeated sounds that happened out of time and the volume was much too confusing. Listening to it makes the listener feel as though there are two songs playing at once and that is not what we want. The second bad thing about this track is that it’s just another song with an increased time scale. The original track: 

Is better, but still does not feel entirely comfortable. I ended up choosing to use the second slower track but it is one of the worse tracks in the game.

Many of the tracks were excluded for reasons like this, and other reasons. Here is a list of the tracks we removed in the end:

So with the tracks decided, I needed to figure out how to implement them. To do this, 4 of the 5 tracks chosen needed to be set for certain sections of the level. To get a smooth transition between the tracks I needed to have the tracks fade between each other. It took me some time to decide how to do this, eventually deciding that I would have all the tracks playing and looping at once and then increasing and dropping the volume of the necessary tracks when the player entered different sections. I decided the section by using an enum state switch, which would be set to the current section the player is in. I then added triggers to the level that set the enum to play the correct track

Here is what my code looked like:


I’m pretty sure that there is a much more efficient way to do this, as there normally is when I program something. But I was forced to do it this way as I was pressed for time and the programmers for the project had left me high and dry when it came to background music.

One thing I would have liked to do is to make the menu music not immediately cut off when the player starts the game, since it is very jarring and takes away from the smooth transition we were hoping for. But due to the way the game is taken to a loading scene, I could not have the menu music audio source be persistent between scenes and so could not have the track drop smoothly in volume. But in it’s current state, it works and it is not dropping the performance in any way. So it’s good enough to move on from.

What did I do yesterday?

I spent pretty much all of this past wednesday working on my new project, Night and Day. But boy were my plans delayed. I had to spend the first 6 hours of my work without access to the internet, so I had to drastically change my plan of attack for this project. I was not able to plan out and concrete any of the documentation that I desperately needed for the project since all my existing documentation was on the google drive. So instead I decided to dive straight into a new unity project and start playing with possible level layouts. First up, to give myself some idea of what shape I wanted, I drew this Parti diagram.


This was the general path I wanted the player to take as they went through the garden. So the first thing I did was build a mockup of that. Something like this:


Can you see the similarities?

The next step was initially to start messing around with a time changing function, but thanks again to the lack of internet, I was not able to log into visual studio and so could not program the light and time changing mechanic. Instead I started playing with ways that I could have the light work, with manual changes. I did this by putting two directional light sources under one parent and began rotating them around. But I have since decided that it will be more efficient for me to just have a new light source for each time used, so that I can adjust the light levels and colours to fit the time appropriately.

Still not having internet, I decided to would begin making the background for the final sunset view of Night and Day. This began with a sketch of what I thought would look nice, which took inspiration from one sketch I did for the GDD.  

Left: for GDD                       Right: Concept Sketch

This resulted in a landscape like this:


The water was something I decided to add in the moment since I wanted there to be more colour underneath the sunset and didn’t want more trees or any physical props down their. I think the result looks alright considering it was made entirely from standard unity assets.

Next step! Add trees and grass. The garden needs life. To do this I decided I wanted the trees to seem natural, but also to frame the spaces and areas that key objects would be in. This began by filling corners with trees to discourage the player from entering those spaces, not preventing them since they don’t actually need to go there and there’s no problem if they do.


After the corners were filled, I needed to frame the paths so that the player would walk along them more than walk off into the grass. I did this by placing the occasional tree along the side of the path, but never too close to the path. Giving the feeling of detail and interesting views without ever needing to leave the path. Finally I needed to frame the key locations with trees, the three main ones being the final sunset view, and the to branches of the path from the centre circle.


The lead up to the sunset needed to feel like coming from a tight space to an open space, so i made a narrow gap in the trees expand into the full open view from the cliff. And for the branches, these sections are not key to the progression of the game, but instead need to feel like private off cuts that welcome the player while also being accessible and viewable from the rest of the game.


Hopefully the above image can explain to you how the trees circle the point of interest, with the path leading to them but not crossing the tree line. The trees also opened up more creating a slight bottleneck to welcome the player in and make them feel like they are in a private space. The grass accompanied all the trees to emphasise their role and assist with delivering the right feeling for the spaces.

So with the trees in and grass swaying nicely. The next thing to do was adding scenery. By this stage I had internet again and could search the unity asset store to find the models I wanted. Things like fountains and ruined walls was the main want.


Statues for private secluded spaces.


A fountain! Ft. ruined walls.

The fountain was most likely the main focus here, as I wanted it to be a center piece. I was not entirely happy with the colour but I later discovered I could remove the orange tint quite easily and replace it with a more grey-red tint to fit the rest of the ruins.But the key part of the fountain I wanted to focus on was the water I wanted spouting from the top. To do this I needed to use the particle effects system.


Ooh water!

particlesettings2To create this water I needed to do a few things to the standard unity particle system. To begin I made the particles be affected by gravity so that they could be shot up but ultimately fall back into the fountain. I changed the particle to be slightly blue so that they looked a little more like water spouts. To prevent the particles from consuming too much processing power I dropped their lifetime way down from 5 to 1.5 seconds but I also increased the number of particles being emitted at once so that it looked more like water while not killing the game. I also had the particles grow as they fell so that it appeared as though they were being squeezed out of the top of the fountain. Of course I had to tweak the angle of the cone it was spouting out to be sure the particles stayed inside the fountain. To the left you can see the finer details of my changes if you are interested.

The fountain, being a water feature, needed to be filled with water. So I took the water that unity had as standard, initially using one that required too much processing power clearly, and placed them scaled on each tier of the fountain. I really would have liked to use the more intensive version because the shadows it used reacted better than the one I ended up using, which simply cannot receive shadows. As you can see here:


After having added these details to the level and now having internet, I decided to try and fix an issue I was having with the grass. This issue was to do with the way they acted with shadows. The grass appeared to be rendering under the shadows, which created visuals like this:


Whats up with that?

This could not really be excused since it really looked out place when the grass swayed and clipping in and out of the shadows. But how do you fix something like that? To begin I found a few things claiming to have fixed issues with grass lighting, but they only worked with terrain that was made externally to unity’s terrain editor. Other fixes claimed that they fixed it but instead made all the terrain details become fullbright lit, completely removing the purpose of the shadows in the first place. The third solution I found was to make a custom tree that was just the grass image on one of the leaves with crossed structure, like these:


Pls excuse the spheres :3

This still created grass that was fullbright lit, but the trees continued being lit correctly and the new grass also cast shadows, creating more interesting detail. I ended up using a combination of both the unity traditional grass with this new tree/grass hybrid. Giving me some stuff to cover up the clipping shadows somewhat, while also somewhat keeping the darkness of the shadows.

Finally the last thing I decided to do, other than waste my time trying to make holes in a terrain (that’s a whole other story), was to add add some fancy camera lighting effects. First up was lens flare, since I was already aware of how to do it and I wanted to play with both day and night lens flares. This was quite simple, as I just added the lens flares as elements of the directional lights, setting the moon’s one as a smaller one than the sun’s since the moon is nowhere near as bright. The next was to add sunshafts, as part of unity’s standard camera effects. What I resulted with may be a little too overbearing and might need to be toned back a little, but I will need feedback on that. Here’s what that looks like:


However, initially the sunshafts emitter was positioned wrong and so the shafts were coming from below the sun’s position. To fix this, i just moved the sun away, literally.



I also have added a few things like anti aliasing and ambient occlusion, but I want to tweak those settings and see if they can improve the visuals enough for me to deem them worth the performance drops they will bring.

But there is still much more to do to the this game, as it isn’t even my game yet, its just a pretty shell. I still need make the game change the lighting and time as you progress through the game. But I am concerned that the skybox will cause problems with the lighting and may take away from the night time feeling. But these are all interesting and exciting challenges to tackle, time to get cracking.