A short explanation

I just wanted to take a bit of time to talk about the game and it's mechanics.

In the tutorial area mechanics are introduced, for further use and implementation later on in the game, these are all very simple but open a lot of opportunity. The mechanics and puzzles also each follow a difficulty curve, so that they can be designed to get more complex or intense as the game player progresses through the game.

The bird boss has 3 stages, going from being passive and avoiding, to avoiding yet thinking about what to do, and then thinking about what to do and actively facing the bird. Turning around the battle as it progresses, and also increasing in intensity and player interaction.

I feel as though although there is still a way to go, balancing and what has been included so far works well and give s a lot of potential for the future of the game.

Half way reflection

So, we're half way, how do I feel I am doing, how do I feel about the game and what can we accomplish? These thoughts I will be exploring here.

I feel as though I am doing alright. What do I mean? Well I feel I am doing a lot better than I was last year, the player knows where they have to go and how to get there is not overly complicated, this is something that I want to carry forward throughout the project. I also feel as though the puzzles I have in mind once practiced by the player can be iterated, creating higher levels of difficulty and combined in different ways. 

Although the level plan works and it is only the first area, I think to myself that it is perhaps a little too simple or narrow. For now this is fine, however later on puzzles and rooms may be a bit more open, and it is then I will need to put in to practice how to compose each area properly and guide the player's interest and eye to where it needs to be. If I am combining different puzzles together or have them so that they follow on from each other in some way, I am going to need to do this well. 

In terms of puzzles I feel as though I have thought of some strong ideas, however looking at classic puzzles in past games and how mechanics where used before, I feel like I have taken quite a departure from them. I do not think that this is a bad thing, I just feel as though if I really pushed to my limit, then even crazier or more interesting puzzles would come out of it, that they would all fit together like a glove and have some really good synergy between them. There is still a lot of time to go, and with that time and the puzzles ideas that I have already created and tested I am going to try and get as close to reaching this point as I possibly can.

So what is there to think about? How interesting the puzzles are, whether the player is having moments to explore, whether the section uses animated environments to it's advantage, how the area is composed both in terms of how it looks and how it guides the player, how to introduce the player to different puzzles and then iterate them in different ways, where jumping, climbing and the grappling hook come in to all of this (which of course I have thought about) and how all of this fits and works together to create a memorable, natural, challenging and intriguing experience. I find this pretty exiting and daunting.

I like the game, in terms of what we have created it is pretty cool, seems to work well, however in terms of the game's potential and what we want to do with it, that's where I really get exited. Even if we only have a few other small areas and one boss, there is so much potential within them. Of course I hope we can do more than that, the more we do, the crazier the puzzles and environments can become, and the bigger story we can tell.

What we have in mind for this game is perhaps the most exiting things for me, I feel as though with a minimum goal there is still a lot of potential, it just takes thought as to what we should include in that. The story of time and space ripping apart, the sands and what we could do with that I feel is also scale-able. 

At this point I am not sure how far we will get. Realistically I do not think we will accomplish three different time periods with three different levels and bosses, though if we are smart about it and re-use things in clever ways you never know. I am confident that we can manage the finished tutorial area, a polished boss and have another area, whether it is another part of the canyon or the castle, with 3 rooms that are a bit bigger than what we have now, which created proper puzzle environments. I do not know how puzzle heavy these could be, but each area could do something clever.

At this point there is a lot of looking forward, planning, implementing and organizing to do and this where we can all really shine and put together something awesome, and for me this is the start of having a lot of fun designing all of these new puzzle areas. I guess we'll see what exactly we'll be able to have within the game in the time to come.

Also, you may be wondering how I posted up 13 blog posts in 6 minutes, that is because I kept them as drafts until they were ready and I had made sure everything was included, I have actually been working on them for the last 14 days.

Puzzle Experimenting

Puzzles! That's pretty much the description for this post.

As I said in a previous post, we had a lot of puzzle ideas, some of which we had refined and worked down to what was practical and manageable. I then thought about what my favourite puzzle aspects were from the list, and what ideas had been spinning around my head the most. 

I then grabbed an A3 piece of paper and sketched out an idea for a chain of puzzles, this was a way to get everything down as quickly as I could, and literally experiment with everything. I threw in a puzzle where the player pushes blocks, a climbable part the you have to unlock, objects that fall to create a Rube Goldberg effect, which then form a ramp leading to another section, a platform that moves as you do and a teleporter where you need to figure out which takes you forward. Then walk around a room that turns upside down, going back into the room you where just in, but now upside down.

Each of these was sketched out to flow together, one puzzle needing to be completed to move on to the next. I designed these to be as complicated as possible at this stage, this ended up meaning that the way the puzzles were pieced together was complex, but that each puzzle alone was simple.

To get a feel of this I decided to create a rough working version of the scene. Some of this did not take too long, due to scripts and scenes that I had created earlier in the project, however other parts, such as moving blocks around, walls that slide and close up and a platform that moves relative to your position took some more thought.

The gap that closes itself I got working well without too much effort. 

The blocks took some editing to get them right, I had to surround the puzzle with cuboids to stop the blocks going where they weren't suppose to and platforms to make them easier to push. I also turned up the drag to infinite to stop them the blocks sliding. The puzzle works and for the most part is contained, though a this stage they can get temporarily stuck in the outside parts of the platform. 

The platform that moves in relation to you was initially jumping from point to point quite roughly, this was done in quite a messy way, however I have since created a much smoother and cleaner version.

This was an interesting test area, there wasn't too much about it I didn't like, so for the moment I felt everything as is, though of course some parts I liked more than others.

This isn't all I created though, since the start of the project I have wanted to create a puzzle with a rotating room or corridor in some way, so I put together a puzzle where different shapes and paths needed to be rotated, 4 shapes per section and 4 sections long. The player would need to rotate each section in order to create the path across. This again was a test, so it was as complicated as I could make it without it getting out of hand. I am very pleased with the result of this puzzle and am hoping to create similar puzzles withing the game. In the screens below, the path across is the path at the top of the top-down view.

After thinking about what puzzles I had made so far and what I would take forward, I decided to sketch out another potential test stage (the upside down part of the room) and this would use the idea of platforms moving around you as you move, giving the player a puzzle where they have to figure out how to get across the room. I have not implemented this yet but I am very exited to see how it is going to work.

I think there are some things I could have done better here, and overall I could have designed better puzzles, the brain fog I felt was hindering me. Though at the same time I am really happy with what I came out with and how we can use this in the part of the game to come, as implementing it in a real and fun way that people are actually going to experience is one massive part of the challenge where designs can really shine.

Putting the Scenes Together

By this point everything was done and ready to be built and shown at the upcoming presentation, though Joe's work and my work were in two separate scenes, so this meant spending some time combining the scenes together, and this was more time than I expected.

I first had to get everything in my scene ready to export, so I created each level section, including objects, scripts, spawn points and whatever else I needed, as a prefab. I exported these, as well as any character scripts that needed to be transferred over, and began to work in a new scene of Joe's project. I imported the package and put everything into the scene, as well as assigned the correct scripts to the character controller. Though of course it wasn't that simple.

I need to recreate every tag that I used in the other scene and re-tag every game object with what it needed, this took a little while though I managed to finish it and keep track. The more confusing job was re-assigning every public game object to the desired script and slot, this took a long time and was a nightmare to keep track of, I would play the game, get bugs, see where the bugs are coming from and find out what I had to do through it, as well as using other methods. 

Once I had done all of this, there were more bugs! The first bird boss would lift you into the sky and not let you escape, due to it forcing the character controller above itself whenever they collided. I found a work around for this bug so that it wasn't game breaking. The second bird boss would barely chase you if you ran past the eggs, I did not understand why this happened and I still have the job of fixing it. The final stage of the boss saw the bird sinking half way into the floor whenever you distracted it. I did not understand these bugs as the scripts, object and tags are identical to the original scene, but these are all things to figure out and at this point none were game breaking.

As anyone who was in the presentation saw, there was a bug where the bird would float away from the player, this is a bug that I had and fixed before though in this case I am confused as to why it is happening. Some of these bugs I found are probably due to the change in version of unity, as it may be stricter or behave differently in certain aspects.

Looking back at this and how long it took, I thought to myself that there must be an easier way to do it. Though with moving everything to an updated version of unity, I am not sure what that would be. I realize that transferring everything into an updated scene is something we should do more often, to make sure there aren't any unexpected bugs.

Figuring out jump distances

By this point I had put together a test area for climbing, using the player's height as a reference, but the next stage was to figure out the jump heights and distances. This wasn't as simple how far or high the player can just, though that was the basis of it.

I first figured out the character jump height, by getting the character's height reference,, putting it next to the controller and testing out the effect of different values to get a height that was just right, this ended up being just under half the character's height, something plausible for them to do. This also made sure that they could jump up the lowest climbing blocks, and get some extra height for climbing. I tweaked the gravity so that it was not too light and floating or heavy and unforgiving. After figuring out the height, that then set me up for figuring out the distance.

Though it isn't quite that simple, first we have to decide what they player's movement speed will be, and once a natural movement speed is found there may need to be more tweaks made to the gravity or jump force, though in my case there weren't. After this had been decided I set up two blocks, and tested different jump distances and got measurements for jumps that were impossible, very tricky to make, a challenge, mid-range and easy jumps. 

I then took the character's jump height into consideration and did tests for impossible and maximum jump distances for jumping to a ledge just above, just below and far below. This all took a while, moving blocks very slightly one way or another to see if the character can still make it. The curved shape of the capsule collider on the controller was also something to look out for, as you may sometimes make a jump, but only the edge of the character controller has made the landing.

I then made reference blocks for building the levels later on, so distances can be easily implemented without worrying about the player being able to make the jump. 

Although this all went well I did make a mistake, when we met as a group we decided that the character was moving too slowly, which looking at the movement with refreshed eyes I agreed with. This means that the jump distances would need to be re-measured, of course this won't take as long as it did the first time, the frame work and jump test area is already in place, it just needs a bit of tweaking.

This whole process taught me just how useful these test areas are, and having different types of blocks and jumps measured out allows me when building the grey boxes to put in the exact jumps I want to. Monika can also use them whilst turning the grey boxes into environment pieces.

This process caused me to end up with a more overall fleshed out testing area.

Finalizing Prototype Code for the Tutorial and Boss

Now that everything was in place it was time to finalize the prototype code. This task didn't involve making all the code efficient and organised, though of course I tried to do this as much as possible whilst working. This task involved ironing out all of the bugs, to bring the game from something playable to something that always works.

For the push and bridge area there wasn't too much to do. For this part I made the bridge disappear as a place holder, and set up a re-spawn, so when you fall down the pit it gives the effect of killing you. We wanted to turn the block that you push from being physics based to being animation based, however I ended up focusing on other things, but it still worked.

The sand area involved a little more work. First of all I changed the sand plane rising to a single trigger, rather than have to hold a button down, using a bool. This also meant that I could set it up, so that if you hit the interact-able object with the grappling hook, the sand would rise. The bool came in handy for sorting out the death and re-spawn, if the sand rise hadn't been triggered it would kill you, otherwise you can walk across it to the other side.

The climb area did not need much work, there was still a teleport that took you to the top of the climbing section, it was mostly waiting for the climbing mechanic to be implemented in the game.

Similarly the spiral area did not take much work, I just set up a death a respawn if you fall down to the bottom.

The first section of the bird boss was not even there at this point, so of course I needed to get it in, and it was very simple to create. I copied some of the code I used for one of the other boss stages, edited it slightly and positioned any new spawn points as I wanted in order to create the effect of the bird swooping and flying in to the roof. For the roof getting destroyed I used a collider and had 2 different object which I set active/inactive, making the roof collapse and fall along with the player, taking them to the next section of the level.

For each of the bird section, I grabbed a Kiwi bird model off of turbo squid, and used its mesh to make the bird face toward the player. This made the next two areas mush more readable. I also smoothed the eggs, created a model for the bell and made some rough rubble, just to bring the scene to life a bit.

The second section did not need many tweaks in the code, aside from making the bird face the player. I made the bird faster so it was harder to run past it, made sure that the bird did not get stuck chasing the egg off of the edge of the stage and that was about it.

The last stage of the boss fight was where it got buggy. I made it so that the bird only looked at the player when it was distracted, and then faced a little nightmare of getting it to trip over in the right direction whenever it fell over the rope. Of course to make this happen I needed to fix the collision, the bird did not always accept that the rope was there, making the boss hard to play but I managed to fix this. I realized that I needed to constrain it's movement to only the X and Z axis, otherwise it would float in the air or go into the floor. After I had done this was stop it from killing you whenever you went up to hit to hit it, make sure it stands up again every time and put a hit counter on the head up display, so I did each of those.

The travel between each area, with the teleport and fade worked differently with the new controller. I didn't understand why, so Joe and I sat down and figured out the problem, ultimately creating a code that would be more guaranteed to work smoothly no matter what the character controller was doing. I also made sure each area was mapped to a hot key, so that you could quickly move between them. Travel between each area was done using colliders, the player must get to each collider (usually at the end of an area) to progress, and of course at times they can go back the way they came.

On the left is the controller about to reach the collider, and on the right is the controller spawning in the next area.

I am very happy with the result I ended up with through doing this and the amount that I managed to get done, both in terms of designing and coding. Though the code is rough being prototype code, and there probably where easier way to to some tasks. I feel like I got stuck in a bit of a rut with coding where I was mostly using what I knew worked and had used recently, rather than reaching into my own knowledge banks, previous scripts and online resources to really make the best decision, I think this was part of that mental fog and struggle to think clearly that I mentioned earlier. I think that when I carry on doing coding from here, even if it is only prototype, I will put my best into finding the most efficient and fast methods,

Tutorial Area With Textures

The next stage of the tutorial area iteration was to implement the versions that Monika had been working on as they had been textured. You can find more about what is going on with the creation and implementation of these textures at Monika's blog/post here.

As I am not the artist I cannot comment on this much, however I found that these textures gave the canyon a great look and feel, and I am really exited to see where artistically the canyon is taken from here.

More Puzzles and Ideas

Of course even though the tutorial area is designed and introduces mechanics, and the boss is designed, it was time I started thinking about to start thinking about what comes next, mostly in terms of puzzles.

I found this a very challenging process, partly because  wanted to push what I had done before, but also because I was having trouble process my general thoughts from day to day with some kind of brain fog which especially affected my work, though of course I still pressed on.

I started with the outside of the castle, knowing what we had in the tutorial area already I thought about how the player would get inside the castle to start with. I am not sure if we're going ahead with having an outside to the castle or if it's going to have any thought to getting inside, nor am I particularly fond of these sketches and nothing about it seemed very original, however there might be something here I can use or take forward.

The sketch on the left involved having a block that you climb up in order to dislodge a wrecking ball, hitting away some rubble so that you can climb back down and progress, entering the side of the castle.

The sketch on the right has a part where you push a block and climb to get over some rubble, then you go to the right of castle and find a key, which unlocks a room around the left of the castle, containing a mechanism to lower the drawbridge and allowing you to progress.

Inspired by a video on Youtube, the Mummy films and our own imagination we wanted to include a Rube Goldberg effect (domino effect). I really liked this idea, so I put together a scene and in it I created different Rube Goldberg machines, some of which were more successful than others. This was fun and I got something out of it, these machines were not too tricky to create, and with our goal of animated landscapes and environments, one of these could fit in very well, especially as part of a puzzle, or maybe even a bit of platforming.

After doing this I decided it was about time we decided what potential mechanics we could have in the game I had a lot of mechanics written down, different potential ideas, sections, puzzles and interactions you could have. So I sat down with Joe and together we ironed them out and cut them down to what we both thought would be practical, fit together and work. The scan and list of the progress we have made with these can be found below.

More thought through/planned puzzles are: Climbing, Warped Navigation (Teleporting), Grappling Hook, Falling Objects & Sand, Strange Items, Not too complex (Support Exploration Feeling), Reward Effort, Switches or similar, puzzles bosses, and Domino Effects.

Other Puzzles: Items - Keys, Lantern, Rope, Fixed Camera if needed, recurring patterns/puzzles, escape (climbing/running), explosions, Wind/Water, and Optical Illusion.

Once we had all of these ideas in place it was time to start experimenting, but i'll come back to that later...

Boss Arena Decision and early Creation

For a long time, since near the beginning of the project, we knew that we were going to have a bird boss, though whether it was on top of a bell tower, it had a nest, sunlight hurt it, the arena was enclosed, it could fly and other things where still undecided. 

I started making some sketches and thinking of ideas for the boss fight. We wanted to have a circle arena, and I though of using climbing and fire in some way, or an alternative. I also considered using catapults, both for items and the player, and using switches.

The design of the left involves climbing up around the side, which heights are portrayed at the bottom, and stand up opposite the flame, and then use the flame to make the bird scared and angry so that it rams the wall underneath you, eventually making itself dizzy and being open to the bell drop.

The section in the middle I tried to make 3 different options to climb up to the top, I like the idea of climbing but I wasn't too happy with this sketch.

The boss arena of the right is quite complicated, it involves using fire to change where the bird stands, getting into a catapult, waiting for the bird to tread on the release switch which launches you up to a platform, where you can flip a switch, once the switch at the bottom and a switch at the side has been activated, you can anger the bird, get it to make itself dizzy and drop the bell on it. I liked some of the aspects of this idea, such as the catapult as it felt fun and pretty crazy.

Them top design here was all switch based, using fire to get the bird to ram different walls which are switches, activating different platforms to climb up, annoy the bird and drop the bell on it. I also thought that in the same area the bird can at first be swooping at you, and you need to take it down with the grappling hook. 

This is a potential second level with fireball catapults that you can fire at the bird.

However I do not have a scan of what we decided to take forward for the boss, and these drawings, for the moment, have become redundant. We needed to decide what the bird boss was going to be, and of course I put forward my sketches, however through discussion and for the most part ignoring my ideas, each of the three stages of the bird boss was decided, of course I voiced my likes and concerns about each aspect but that didn't stop them from being green lit by the lead designer. I did get to steer the discussion in some ways, for example I wanted to drop a giant bell of the giant bird, and that still happens.

Where these bad ideas? No, otherwise I would have been very concerned, though it was strange to me that the boss was designed and green lit so quickly with such minimal input from me, the lead game play designer. 

The first stage would see the player climbing up to the top of the bell tower roof, avoiding the swoops of the bird, until the bird crashes or the main character grabs the spike right at the top and tries t take the bird out with it, causing the roof to collapse. 

The second stage puts the player in the bird's nest, the player must use the eggs to hide from the vicious bird attacks, and use hiding or some kind of distraction as a way of sneaking past the bird to then climb up some rubble and cut the rope of the bell, causing the bird to try to ram you, fall over and get hit by the bell, making the floor collapse. I cannot remember if the distraction was my idea but using an egg for it was.

Lastly the player would be surrounded by rubble that they can use their grappling hook on, they have to use the rubble to create a rope that the bird can trip over, however they first have to distract the bird (my idea, I think) and dodge out the way, then finally injure the bird. Once they do this 3 times they win. This section has a much faster pace and more thought on the side of the player than the other sections. we had the decision about tripping the bird up, but in terms of how we do that I decided that it needed to be distracted, a part of my earlier designs that carried over.

Once the ideas where in place, it was still up to me to create the boss and make it fun. Through this I though about what the player would have to do and the player's though process, both the conscious and subconscious.  I used whatever room for maneuver was left in this stage after the initial design in order to get something as enjoyable and true to the original design as I could.

At this early stage, I am left with a block that moves as the bird should, with the final two areas of the fight coded in and working, with a few bugs.

I learnt a few things from this early designing. I've heard that game designers need to be prepared to throw away their ideas, and although I have done this myself in the past, this is the first time it really caught me by surprise and it gave me a new challenge.

I was still involved in the design process, so I do feel like I was needed for this, but it more taught me that the lead game play designer isn't always the only one, though here I do feel as though the balance was off.

In hind sight, there are a few ideas I had that got carried across or that I thought we should have so they ended up being implemented, so my early design definitely weren't wasted, but decisions about changes still felt a bit strange and quickly made.

Iterating the Tutorial Area

After I had sent the initial floor plans to Monika, we had a few small discussions and she sent them back to me, with the floor, pits and walls, and they were build from multiple parts, such as parts for the walls being used efficiently, as parts were reused but did not appear repetitive.

There was one area that we discussed, the area where you can explore with an optional climbing section to find a secret. However as we thought about this, we decided to make the climbing compulsory, as this was something we wanted the player to definitely experience during the tutorial, with the secret just off to the side before the exit which we can draw the player to with a clever use of lighting or other methods. Monika and I discussed how the redesign would work and Monika put the it together with an eye for the environment.

I put these into the scene and created the script and spawn points that allowed you to travel around the stage, from one area to the next. This also meant that you could skip to any area you wanted for testing purposes. Of course then there was a matter of coding to do, I had to make sure that each area had functioning puzzles, and was as interesting as it could be at this stage without doing anything too complex. By this stage, Monika and I had made sure that there was no way the character could just jump across the stage and skip all the puzzles in the process, so there was not too much designing to do, aside from make it work.

In the first area, I need to have a bridge that disappeared when you touch it and a rock that you can push over to create another bridge. For the first I simple made the object inactive, for pushing physics I added a small force when the player gets close and interacts with it, making the new bridge. Using physics for this has a few potential problems, such as the block being pushed and moving when it isn't suppose to be, so we plan on making this an animation. If you fall down the pit, you start back at the spawn point.

For the sand in the second area at this point I simply made it a plane. When you fall onto this plane you re-spawn, however when the player gets close to an object nearby and interacts with it, the plane rises up, creating a path that you can now walk on to get across. The object also has code to be used as the rock that needs to be pulled out the wall using the grappling hook, a new idea that I have the scene set up for.

The climb area was something different. We did not have the climbing in place yet, so I created alternative ways to make it through the area. The controller that I was using for testing (the one we created for our game last year) had a higher jump, so parts of the area I could just jump up to get through, however for one part I had to create an object, where interacting with it teleports the controller to the top of the wall. This is some code I had in place before we decided to redesign the area.

For the next area, the spiral, there wasn't any coding to do, aside from making sure that falling kills you. It is just a section where you walk up to the top and progress on, this teaches the player to jump over gaps and gives them something else to explore, where they can see up and down, where they need to go and where they came from.

This created a full area, where you could run through and experience each part, to an extent.

Meeting and finding our focus

We had a problem, as it was early in the game's development we all had an idea of what the game was going to be, however everyone had a different idea and nobody really knew.

Just after I had designed the grey box area we held a meeting where we would play some games to gather some ideas and inspiration, and find what would make our game unique. We saw games that has nice set pieces, variations in game play and puzzles, and animated environments.

As we wanted our game to have a focus on exploration, we decided that animated environments where the way to go if we wanted to create a unique identity. Of course the puzzles and set pieces also gave inspiration to what we wanted the game to become.

However this meeting was not enough, as I started working on my next task I realised, along with Monika, that we had no real idea of what the context of our game would be, in terms of story and setting. I knew that I needed to know a lot more about what the puzzles could involve, and it seemed like we were straying from some of our original ideas. 

Originally we had an idea of a dream-like world, with time and space ripping apart, and you find things that wouldn't necessarily belong there, then through your progression you would save it, with some clever time travel elements along the way. However then it began to involve a castle area in 3 different times, which was set in a desert and we started thinking about what would be there logically however this felt inconsistent, as there was also a castle, bird and a bell tower. I also found this quite limiting and this would make a lot of puzzle ideas void. The story involved sands in some way, probably along a sands of time story. We held another meeting, this time we also decided to choose a lead designer to keep things on track. Whomever wanted to be the lead designer started by pitching what our their idea of the game was (including me, I will post my ideas below) and then a vote was held for who it would be, and it ended up being Joe. This then lead into a discussion with Joe making the final decisions, however we all discussed our idea, what we liked, what we didn't and what would fit in. The end product was a mix between what we started with, still involving a castle at three different times, however the idea of time and space ripping apart and strange phenomenons happening was taken forward, which gave me much more room for thought in my puzzle designs, to really create something cool and memorable.

My idea process and what I pitched for lead designer included thinking about of a variety of things and how they worked.

For game play I wanted jumping to be limited, not really high like it is in some games. Slopes are used sparingly which helps asset implementation and due to modular travel there are potential work-arounds to give a feeling of going up. Puzzles should not interfere with the feeling of exploration, but instead should support it, rewarding the player's effort. There should be various rotation elements to the game play.

Cross world elements, such as strange things that don't belong in places, I wanted to exaggerate. I wanted to have grass, swords and shields in the canyon, which was something I put in from my own thoughts and feedback from others. I thought of having a dream world bridge between main areas and really showing that time and space are ripping apart.

For visual style I went with what everyone was thinking already, it isn't really my area and I knew that people liked this direction.

I also pushed the idea of modular travel and game play, thinking that there is something clever that we can use it for.

Though I didn't get voted as lead designer, a lot of these elements ended up being highly considered or implemented anyway, which was useful for me and my process in creating the game.

From all this I realized that when people sit down, push the idea they want and really focus on bringing the game together and what it is going to be, then some really good and focused results can come from it, it isn't the complete end of the design process but does give a good clarity and direction. I also learnt that who the lead designer is really doesn't matter, so long as they listen well, have a clear vision of the game and make key decisions properly, and ultimately respect what everyone wants to achieve, and I feel that Joe is very good at all of these things.

Tutorial Area Grey Box Changes

After initially creating the grey box, I got a lot of mixed feedback and tips for creating grey-boxes in general and where to take it next, including doing the iterations.

One tutor said that I had approached it similar to how they would, starting in Maya and then bringing it into unity to get a feel for it, which was the plan I had. With the possibility of changing it in Maya and re-importing it if I needed to. Another tutor said they felt I had skipped a step and they would have boxed it out in unity before taking it into Maya, and would only take it to Maya when creating individual elements that the level is made up from, and then piecing them together in unity. I also knew that Monika and I needed to start iterating the level together.

I thought about the feedback and organised it as best I could, taking different elements from different people and forming it into a work flow that suited us. I decided to create a simple floor plan from planes of each area in unity, to give the size and shape of what each should be. I left each of them mostly flat as I had feedback from Monika that the previous areas where too sloped, so I left any decisions about that too her, as she was environment focused. After creating them I sent them to Monika.

During the group meeting we had decided that the player would travel through the level via separated parts, something to give an idea of distance with here and to use for puzzles later on. This is why I modeled and sent each section individually, as they would each be standalone in the scene. I liked this idea, it could create a feeling of travelling without the player needing to walk everywhere, and it made the level more iterative as a whole.

Climbing Test Area

Of course as we were going to be creating a character, who jumps and climbs, we needed to create a sandbox test area with different set heights, and this was up to me.

I started be defining the character height, and I also knew that he wouldn't be able to jump very high, this allowed me to take this into account and create different height blocks, for stepping up, pulling up, jumping and pulling up, and using the grappling hook. 

This simple climb area had iterations of each block as well.

After creating these I added in some more stuff, a vertical gap between two walls that was just under the size of the character's legs, so he could climb up the middle of them, and a wall that went around some of the outside of the area, encase the character would be climbing on vines.

From this I had the main area, and the original unity file where it was created, as well as the original blocks created in Maya, each set to the correct heights.