RatMan’s guidance

So I realised Floob still didn’t guide the player through the game enough. So I decided to turn the guidance up to 11. It began with adding arrows, little pink arrows that would guide the player. They were drawn somewhat sloppily to try and convey two things. The arrows were meant to be a sign that other cubes had gone before and where guiding you out of the supermarket. The second reason they were made that way was to try and convey where their inspiration came from; Portal’s Ratman. These arrows were placed at many points throughout the level making sure to always have at least one and often two within sight.

They were positioned to attract the players eye towards the path that was already lit up, so that they could see the path they need to take from a distance. After placing these arrows within the level, I realised the final section just did not make sense in and of itself. So in an attempt to explain how to complete it, I created a small drawing that graphically briefed the puzzles function. After putting this into the level, I realised that I could not just have the little drawing come out of nowhere. I would need to ease the player into the concept of the drawings and how to decipher them. So I went on to create 4 other drawings that explained other key obstacles that are in the level. I am excited to see how players respond to the new guidance as I for one am proud of how they accomplish their purpose.

Who do I want to be?

I listened to a podcast today. It was Downloadable Context, and the particular podcast had Trent Kusters as a guest. Trent Kusters is an australian creative director, and cofounder of League of Geeks. In the podcast he spoke about his work and mentioned a few past experiences he learned from. I wanted to write about this particular podcast because I too would hope to be a creative director within the games industry. It was interesting getting to hear more detail about what a Trent does in his work and what a Creative Director’s role is within a games studio. For example Trent states in the podcast that his main job is trying to manage over 40 people across multiple countries and timezones to get them to collectively create one game. This particular part of his job is quite daunting for me, as I do not know if I would be able to manage a large amount of people very well at all. But I don’t want something like that to stop me from pursuing the goal of creative director since the role will never actually be the same in any studio and I can’t expect it to be. I also can’t expect to be going into a cozy easy job, it is going to be work no matter what it is. Before I get too afraid of my career aspirations, I should remember that a lot of what Trent said described almost exactly what I want to be doing one day. He stated that he was responsible for talking to the creators and telling them what he needed them to do, but rather than leaning over their shoulder the whole time they did it, he just let them go and be creative in their own way. He was aware that many of the people he was working with could do the tasks better than him and so he was letting them go and do it to their full potential rather than demanding they do specific things and simply asking them to colour in between the lines. So in summary, I feel that I would love to and look forward to hopefully directing and guiding the creative side of a game to create one concept, but I do not look forward to managing large amounts of people, since that is a very large task to take on and I feel I’d manage better with smaller numbers. This podcast and what Trent Kusters spoke about during it definitely impacted my understanding of the Creative director position, but it hasn’t pushed me away from aspiring to become one in my future.,.m

Lights to guide you

So I decided to try and make the level for Floob the jelly cube guide the player more. This was because our playtesting (as previously mentioned) was painfully demanding it. So to begin this, I thought I’d just light the intended path up, following the example of naughty dog with their critical path always being the lightest. This helped a little, but the spaces we didn’t want the player to go still looked inviting due to the ambient directional lighting. This needed to change. So I made the directional light much darker and removed almost all of the ambient light, so that there was a lot of contrast between the critical path lighting and the rest of the level. The final thing I had to do to try and guide the player through the level was to have shadows guide the player to specific parts of the level that were initially harder to find. For example, the section of the game where you need to go under a wall in the fridge to continue. Here I used shadows to emphasise that there was a gap in that portion of the level, however it may be necessary to use an arrow to blatantly guide them through there if they cannot find it. But that will need to be determined by future playtesting. I definitely look forward to seeing how this new lighting will affect the way in which players with navigate our level and look forward to learning what changes I can make to improve it further.

Testing the Floob Cube

Playtesting could have gone much better than it did, but in comparison to the last lot of playtesting it went spectacularly. This is because this time, we actually had a game to be able to test, last time our player controller was still a mess and wasn’t doing one particular thing we wanted it to do. But this time around we had a game ready and had people actually come and play it (Radical, I know). With this new play we found some key issues with the critical path of our game and discovered that we would have to make many changes in an attempt to correct this. The first and foremost issue with the game was the camera, people just didn’t like that they couldn’t move it themselves. This showed that we had designed the level and presented it in a way that made the player want this, since in previous demonstrations when people watched the game being played they did not think this. We could do two things to fix this issue, the first being to rebuild the camera controller so that the player can move the camera around and look where they want to. This solution would take more toll on the programming side of the project which may be too busy with other things at this current moment considering the state the player controller has been in during the entire development. The other thing we could change is to have the level present itself in a way that doesn’t make the player want to move the camera. Much easier said than done of course, since it would require many hours of playtesting to determine what is the right way to present the level. It probably would begin with the fact you begin facing a wall and are meant to jump towards the camera. After that the player is meant to fall onto another platform that would require the player to jump up and over a wall to get into the main aisle. This meant that the player would have to move toward the camera twice to begin the game, while not even knowing the level was set in a supermarket aisle, that is not good. This could be fixed by removing the part that forces the camera to face the wall at the beginning of the game and instead have the player begin with a custom angle facing the centre of the aisle from the shelf. The next key piece of feedback was that the quick fixes to the wall jumping we put in was not good because our player controller was too difficult to get up them. This is actually good for us, because it means our player controller is moving how we want it to, a little bit too difficult to do anything refined. So once we get the wall jumping working we should be able to remove those quick fixes and have a player controller that meets our desires. Another issue was that the level did not require the player to take the desired path or do anything that we wanted them to do. So we need to do two things to fix this problem, firstly we need to improve the walls in our level so that they take the path we want them to instead of them just rolling straight to the end. The second thing we need to do is make the desired path much more favourable and interesting, we can do this quickly by adding some lights to encourage the player. There could also be more colour and detail in the desired player path. These were the main things that I found from our playtesting feedback, but I’m sure there is plenty more to learn and much more to learn in future tests.

Programming Cookie defense systems

So as I’m sure you know by now, I made a VR game a while back. So I thought I’d look back on my approach when programming it’s interactions soon before I forget too much. So where did I begin? Well since this game started as a very experimental project to see what I could do with VR, I started with programming the firing mechanic to see if the concept would work. To start I needed to put the models onto the remotes which took me longer than I thought, since it took some time to get the rotation of the remotes to feel natural for both the cannon and the hammer. But once the primitive models where in place all I needed to was have a trigger enter event between the hammer and the bell portion of the cannon to fire a simple projectile that would just move forward forever. This formed the simple version of my firing mechanic. It was pretty fun to use and it was at this stage that I decided to continue with the idea. The next thing to do was to add the need for the trigger to be pulled before the firing could be triggered. This took a considerably longer than expected because the steam VR plugin is extremely complex. I spent so much time searching the internet to figure out how to check if the triggers were down. I eventually got the answer from a friend of mine since he had went through the massive process searching before me and had found the answer already. Using his help I made the firing require the player to have the trigger in the cannon hand held down while they hit the bell with the hammer. This made the firing much more interesting and was how I originally hoped to have it. So then came the time to have something to shoot. To start, my enemies were just white boxes, they don’t have any friction and they simply just slide forwards from their starting position. They lose their gravity when hit and float away to try and quickly tell the player that they are dead and initially the projectiles and enemies did not disappear. But this formed the core of the game very quickly and I decided to go full force into the project. So the first step was to add a more functional wave system so that the enemies could continue coming towards the player and increase in severity as they go. I also needed to make sure the projectiles and enemies disappeared after a time so that the player didn’t get covered and overwhelmed. To add the waves I added the ability to find out how many enemies exist within the level which would determine the progression between levels, I also added some primitive progression variables that would increase the enemy count per wave and lessen the time between spawning the enemies. The waves also gave the player a grace period before beginning a new wave so they could recover themselves since VR can be disorienting at times. After the waves were working and the enemies and projectiles were disappearing at the right time, I felt the game wasn’t really using the virtual reality part of itself but instead just simply adding depth to a game that could be played in an arcade. So to combat this feeling I decided to take the game from one ‘lane’ for the enemies to travel down, to eight ‘lanes’. This made the game feel much more exciting and fast paced since the enemies weren’t always in view when they spawned. But I was getting so disoriented when I spun around so I put in some quick scenery as a frame of reference. The next programming challenge was to have a scoring system with visual displays inside the game. Which was surprisingly difficult to get right since 3D text in unity likes to default to displaying on top of everything, which is just a pain for what I was trying to do with it. The reason the text was displaying above the objects was because of the shader that it inherently had, and so to fix this I had to try and learn as much as I could quickly learn about shaders to be able to create a new shader that would still be able to display text but display it as a part of the world instead of an ethereal, 4th dimensional presence. I eventually learnt how to fix this after trying to follow a few different old tutorials for people who had had the same issues as me with their text not displaying how they wanted it to. I needed to make a new shader script that I filled with the code that the tutorial that was provided since I did not wish to learn how to read the new language and then figure out what specifics I would need for this one time use. In addition to this script I also needed to find a font file for the text it was going to display, which was something new to me as well, but thankfully it was much simpler to do. After that it was just the standard text interactions that I’ve used before to change the displayed values in play. Now came the time to finally add sound, a long overdue task that I just kept putting off for more interesting tasks. But I did it, i spent some time finding some good sounds to fit the events that I wanted that I could get for free, and then used what I had learnt before to put in the sounds into the game. Something new that came up however was the need for 3D sound in a game. I had never used this before, but found that I desperately needed to to be able to pinpoint the enemy’s positions while not looking at them. Thankfully this was an easy thing to use since all I had to do was fiddle with some curves and settings and have the sounds be played at the enemy’s position rather than the players. I discovered that after implementing the sounds, the game became much easier to play since I could easily tell where the enemies were coming from, which fixed another issue I was having which was that I felt I was being overwhelmed too much. The final thing that I added to the game was a form of menu combined with a scoreboard with the players top 3 scores. It took some time to have the scoreboard working since I kept getting the if statements wrong when overwriting parts and moving old scores down the board, but after a bit I got the playerprefs to be saving correctly and the scores to move appropriately. Finally I do believe I have actually spoken about everything that I programmed in this project. Overall the result wasn’t perfect, but it definitely did that job it was intended to do.

Mum always told me to make my bed

I made a bed. Well, not a real bed. A virtual bed. Not a very comfortable virtual bed either, I made a lowpoly virtual bed. This bed

15135639_631446203693961_345838086_n

But how did I make it? Well that’s the interesting part. I began with Blender, which for a beginner was extremely daunting. I had decided to begin with some tutorials that would teach me the basics for forming shapes and how to form the model I am aiming for. I discovered it functioned very similarly to the way that ProBuilder(the unity plugin that I’ve been using to make levels in other projects) works. So I decided to ditch the extremely tedious tutorials and forge forwards until I ran into a problem rather than sit and slowly melt my brains with tutorials. Beginning with a a large rectangular prism to act as the base of the bed, I then took a segment of that and extruded it to make the mattress that sits on the base. After getting that looking nice and sized to fit a mattress, I put the bed ends onto the base and the legs to make it look more, bed like. So the bed was starting to look like a bed, that’s good. But it needed to be more bed-y. So I added the blanket! Now, in other lowpoly beds I’ve seen, the blanket is perfectly smooth and has no blanket-y crinkles in it. So I decided to try and add some imperfections to the surface of the blanket. To do this I used the bisect tool, applying a smooth subdivide and then adjusting some corners to fix any excessive points. With almost all of the bed modeled, I needed to add pillows. But how did I do that? Well, I made a cylinder, squashed it a little to make a somewhat pillow shape, simplified some of the faces so that it would be more lowpoly than it was. I then bisected it twice across the centre and bisected the top and bottom into 6ths. With some more smooth subdividing and adjusting points, I had a pillow. I duplicated it and put them on the bed and voila, I had a bed. But it was all grey, yuck. So now came the tricky part, how was I going to colour the faces and more specifically how was I going to paint the surfaces without colour bleeding. Well the surfaces could easily be coloured with the vertex painter in built into blender, but that made the colours bleed into each other. So I had to create vertex groups and put a mask on them to make certain parts of the model invisible while I painted the rest, kinda like how you put tape on the lights and windows when painting a car.  So I had the model ready and painted, but it wasn’t in unity yet. I had no idea that this part would be such a hurdle to get over. Initially I thought it’d just be a simple export to get the textures and the model into unity, but NO, it had to be difficult. So I spent far too much time searching through numerous blender tutorials for countless different versions of blender to try and get the texturing into unity. In the end it turned out that I needed to create a smart uv map of the model and place the colouring onto that, then tack that image into unity on a certain rotation and apply it to a material that is on the bed. Which took way too much time to figure out. But, I did manage to do it:

captureTA-DA!

I do hope to make more models in the future, but this was definitely an interesting introduction into the complex world.

I dropped a box

So I made some sound! It was certainly a strange experience, creating sounds for Floob. It all began with me looking for cardboard boxes I could drop so I could get sounds for when the boxes in our game would fall. This took some time and some strange looks as I stood and dropped a tissue box on a table trying to find a sound that I felt worked. Once I found that I wanted a tissue box and an unopened cereal box, the next step was to record! This step consisted of me sitting on the floor in my study trying to make as little noise as possible while using my phone to record the box dropping sounds on different surfaces. This of course does not create great quality audio but it works great for my needs as placeholder audio. I spent some time doing this because I could not decide what surface was best and found that the recorded audio sounded very different to what I was hearing. Once I had a collection of drops from both the tissue box and the cereal box, I loaded them onto my computer and gave them a listen. As expected, they were not very good and most did not fit the kind of sound I was hoping for or had the sound of two drops at once because of how the box fell. However, I was able to find 3 for both the tissue box and the cereal box that I found the best of the lot. So I cut them out of the long recording and saved them as separate audio files. I had to make sure I got as close to the beginning of the sound without cutting into it so that the sound would best fit a momentary action and could be called when the boxes collide with anything else. Hopefully we will not have to use these audio files for our final product, but it is definitely good to have them available for now so that when the audio students give us their box dropping sounds, we can easily implement them into the game without much change.

The nightmare that was designing PR Nightmare

To begin designing project 2, we needed to come up with a theme, we spent way too much time as a team trying to be funny by copying other people’s jokes and making memes in the game. But they were never that funny the long run. So we took a step back, stripped all the theme off of the game, and decided to come up with an original idea. This new idea was that the town was coming up with what to make their town’s landmark. ‘The Big X”. This came from the idea that almost every small town in rural Australia has some sort of landmark to make it more memorable to the tourists, but our town didn’t have one. But before we came up with this theme, we came up with the mechanics of the game. Our key mechanic was the ability to modify a round in play, similar to how exploding kittens is played. This was an attempt at adding a sense of chaos to the situation, the results would become much more unpredictable as to simulate the environment of a pr team moments before a press conference. We also had a good idea about how the game would play and what the game loop would look like. We knew we wanted to have a limited amount of time to have a round to add pressure on the players, we to have a selected incident card and then have players pitch their responses. When the pitching would happen, we wanted to have a timer that pressured the players to decide quickly, if they didn’t decide a response would be taken from the top of our draw pile. The initial time limit was 20 seconds, but even our first playtest told us that this was way too short. It was resulting in too many undecided rounds, which removed the game part of our game. So we bumped the time limit up to 40 seconds, which was not too short in further playtesting. When we were developing the details to the theme and the incident cards, I decided to take a large amount of inspiration from The citizens of pawnee in parks and rec. The lines that they regularly say was exactly the kind of incidents I felt this game should have. Like people being angry about the landmark causing allergic reactions, or choosing to have a landmark that someone else already has. I really wanted to have the ridiculousness that they have in our game so that people could have fun and laugh at the situations that arise. I also wanted to further this by having two cards that referenced each other. These cards were the ones that referenced the big mango and how it was stolen a while back. I had one that stated the big mango had been stolen and that the town had chosen a big mango as its landmark thanks to a mysterious donator. Then I had another that had the people suggesting the big mango as their landmark but some results would state that Bowen already had that. These cards did not always work and the responses probably could be rewritten for the special circumstances where the other card has been played before, but it was fun being able to create a little joke like that with the incidents and responses. All in all however, the design process of PR Nightmare was a wild and crazy ride, there was a lot of decisions made and they were almost all rash and ridiculous.

Mathing a Mario

For project 1 there was a few things that required me to delve into the world of programming, even if the ‘delve’ was the equivalent of dipping a toe into the ocean. I needed to program the player controller, the audio controller, the goomba controller, the coin function, mushrooms, and of course a menu controller. I had a pretty good idea how to do these scripts, thanks to my prior work in scripting.

To begin, I made the player controller (of course). I decided to make the player use a rigidbody so I could easily make it work with unity physics. So for the beginning of movement, I used simple add force to the rigidbody based on key inputs. The force variables were the tricky part to get set, and it took a while to balance to something that moved comfortably for the build. I also needed to make the ‘boost jump’ function as part of this because if I want to recreate Mario, I’m going to have to make him jump higher if you hold the jump button. This took more time than the rest of the player controller, simply because it was difficult to get the player to float up the right amount. I had some issues with the player’s ground check initially because I had the ground made out of many singular blocks. So I removed the ground check that would prevent jumping after exiting a block, and instead made the check turn off when the player jumps. This did allow the player to jump after walking off an edge, but that was ok since not many people noticed it during testing. After the player was moving well enough for a basic, botch build, I moved on to the goombas. The goombas also used a rigidbody, since they needed to be able to fall off of things as well as walk along the ground. The movement for the goombas was quite simple, just adding force to a rigidbody in a set direction. Getting the goomba to turn around was the tricky part. I started by placing a trigger collider on the front of the goomba and getting it to change the direction of the goomba when it hit anything that wasn’t the player. But then the goomba would just walk off the edge of the platforms and fall to his doom. I eventually made a second collision area beneath the level that would stop the goombas from falling off the map while allowing mario to. I know it would probably have been better to have a trigger collider that turned them around rather than a wall. After having made the goombas, I realised the mushrooms moved in a very similar way, so I took the goomba script and applied it to the mushroom item, and then made a different tag that would act differently when triggered by the player. With the mushroom item in, I needed to make the player act appropriately when using the mushroom. To do this, rather than making a new player version to replace the smaller mario, I just doubled the y scale of the payer and made a system for ‘lives’ to mimic the normal, big mario.

I then went on to add the coins after this, so that I could closer recreate the 1-1 level to the best of my ability. I used a trigger on the mase of the blocks that would spawn the coin item above the block. The coin item would then be a separate object that would play the coin sound, add one to the score then delete itself after a small amount of time. This function needed to account for the multi coin blocks within mario 1-1, so I made the function have a counter that would allow a certain amount of coins to be collected before it set the image to a new block. I took this coin function after this to create the basis for the block breaking function. This function would break the brick textured blocks. I did not get this to only function when the player was big sadly, so I probably could have done that. The Final thing I did was to make the win and lose states combined with the menu screen and lose screen. The flag did not function the way I intended, I originally hoped to make the player lerp down the flag to the ground. They instead teleported, stood still for a moment and then the game cut to the win screen. The menu was quite simple and was just some ui buttons that progressed to the game or quit.

PR nightmare postmortem

So now that the majority of the work for our second project is done, now is probably the best time to look back on the work we did as a team. We had a lot of flaws, but what team doesn’t? We did deliver in the end, and that’s a big plus but of course there was a lot that could be improved.

Communication was all right, but task delegation was our major downfall. There was a major imbalance with the work being done within our team and that resulted in less getting done than there was possible. It also left us as a team being very confused with what direction the game was taking, since the ideas seemed to only be coming from a few people and then having no real solid agreement on the final direction. Much of the work seemed to left to the last minute because it hadn’t been strictly assigned to anyone. And sometimes when it was assigned, it was still left till the last minute, then resulting in having two versions of the same task because someone else would do the task by the time it was needed, and the assigned person would come in with a completely different model that didn’t fit what so ever. So that would be partially communication issues as well as task delegation. This result could be improved by using the decent communication more often when tasks have been delegated as to check in on the task progress and stay aware of the project’s progression as a whole. Also, if we had taken more time at the beginning of the project to assign/volunteer for tasks we could have had a better understanding of roles and required work as a team.

Based on player feedback, players laughed a lot during play. So we can assume they enjoyed it. But people also felt that there was no conclusion, which is difficult to wrestle with in a game that’s meant to fit into an overarching story as well as be replayable. But this is definitely something to consider next time. The players also didn’t seem to argue as much as we intended, which isn’t entirely a bad thing, since they seemed to enjoy it more when they laughed together. The game definitely has a limited audience, it needs people who are willing to raise their voices, based on observations the people who were not willing to speak up did not enjoy the game at all. I’m not sure how we could make this better for them, it’s quite difficult to coax people out of their comfort zone. Because of this, it may just be easier to find that they are outside of our target audience and be aware that they may not be able to enjoy our game as much as others.

So for next time, we need to have a better idea of our target audience, a much better communication system, better ways of assigning tasks and tracking progress, and an openness to pivoting our ideas around key parts that people enjoyed.