Big and Small Puzzle

This week I received the engine file back from max, he has created the first area in a Lewis Carrol fine liner style. So with the engine file I created the first puzzle (almost).

The puzzle goes as follows:

Arrive at door too small to go through

Turn around and find a table with a bottle on it

Drink bottle and revisit door which has become much larger

Return to the table and see that it is much larger and that there is a key on it

Find the cake and eat it

Return to the table and see that it is tiny

Return again to the door and see that it is also tiny

Begin to cry, tears turn into waves and you are pushed out of the room

To make all of this happen it is a case of moving these meshes in and out of the room that the player is in. So the room is empty when you enter apart from the small door and a collision box at the door, once you enter the collision box this tells the table and bottle to move into the room out of the view of the camera, so when you go back the table will be in the room as well as a new collision box to activate the next part of the puzzle. Moving into that first collision box also moves the box itself out of the room so it cannot be activated again. Then the same process of entering collision boxes to move objects and new collision boxes into the room and removing old collision boxes so they cannot be activated again.

This was my first time doing something this complex with blueprints and took me all week, it’s just missing the last part where you are pushed out of the room at the end, I will do this next week.

More growing and shrinking with some modelling

This week I started making the growing and shrinking mechanics situational, so we can control when the player changes size instead of being able to do it whenever. We haven’t decided if the mechanic is going to be completely situational or not, but I’m going to learn how to do it anyway.

Turns out it’s fairly simple, you just need to put a variable after the key press, for example I made a box trigger and I only want the change to happen in this trigger. To do this I set this variable to become true when you enter the box trigger, and then false when you leave it. So when the key is pressed to change size the blueprint asks “is the variable true?” if the player is in the box then it will be yes and the blueprint will continue and change the size of Alice, if false then nothing happens.

The idea of perhaps instead of Alice growing and shrinking not being Alice’s character but the environment around her instead. Because we are undecided yet I made sure I knew how to do that as well.

So once I sussed out situational growing and shrinking I pretty much just researched and did small tests the rest of the week on how I’d go about changing Alice’s environment around her.I am going to receive the engine file next week ready to constructing the first puzzle in the game, and also the first puzzle I’ve created. So in preparation for this I wrote out a breakdown of the puzzle and how it works, and I created the assets for the puzzle full modelled and unwrapped ready for Monday.

 

In my spare time I’ve also been looking into how to make a flythrough for the Container City level so that I can put it in my portfolio. Working back on Container City is an after labs thing I’m doing, it’s not taking priority.

Big Alice, Medium Alice, Small Alice.

This week I focused on blueprints in Unreal, one of the main parts about the Alice in Wonderland is that she grows and shrinks throughout the story. I tried to make the growing and shrinking into a mechanic in the game, for instance the player would come across a small hole and would need to become small to fit through.

To make the player character grow and shrink I set up three meshes of the character in the character blueprint at three sizes (big, medium, small) and made it so that only one of the three meshes would be visible at one time. As a test to begin with I assigned each size to a button press 1, 2 and 3. So pressing 1 would make Alice small, so the process would be:

Press 1 > Set medium and big mesh to invisible > Set small mesh to visible

However this had a problem, the collision mesh for the character did not change. As a result of this if you turned to small Alice you’d be floating in the air and if you turned into big Alice then you’d be walking through the floor.

To fix this I added another part of the blueprint which told the collision mesh of the character to change size with the different mesh. So if you were to press 3 to make Alice big the process was:

Press 3 > Set medium and small mesh to invisible > Set big mesh to visible > increase collision mesh

But surprise surprise there was still a problem with the blueprint. When you increase the collision mesh’s size it increases from the centre outward, so when you turn big from medium the collision mesh goes into the floor and so does the mesh still.

To fix this I needed to elevate the player before the change, the simplest way to do this is to get the character to jump when it increases size (this goes for changing from small to medium as well as medium to big).

 Press 3 > Jump > Set medium and small mesh to invisible > Set big mesh to visible > increase collision mesh

But then there were still problems. When I went from small to big the character wasn’t jumping high enough, and if I just increase the height of the jump when you press 3 then you’ll jump a ridiculous amount when you’re medium going to big.

To fix this I added variables which prevented the player from skipping a step between big and small, you always have to go medium before you go big. Next week I’m going to look into how to make the changes situational.

This week wasn’t all boring and blueprints, I made our blockout in engine (yey!) all with illustrated diagram to show what we are willing to cut if needs be.

Off the Map Begins

This brief we enter the Off the Map competition, and this year’s theme is Alice in Wonderland. We started as a team of 6, but then dropped down to 5 in the first day, this puts us at a slight disadvantage to the rest of the course but it shouldn’t affect us too much. The first day we all threw some ideas around that we had and stuck it all on a board.

We decided to go for a sidescroller game which was first compulsory, and then not, but we had settled on a sidescroller before that change was made so we stuck with it. We all read the book the Monday night and Came back on the Tuesday. Again we threw some ideas around and I tried to illustrate my idea for the Cheshire Cat in a drawing, and it was a terrible drawing but it was technically our first piece of concept art, so we made it our team logo. And our name is from the film where the Mad Hatter declares a pocket watch “Two days slow”

We were allocating roles to each other, I was assigned environment artist and engine guy. I shared the engine role with another team mate so that we weren’t just doing mind numbing engine work for 12 weeks straight. Doing exclusively engine work seemed to diminish a person’s sanity after a whole brief in the past, so we shared it.

We decided on what parts of the story we wanted to do, and that was most of it, we think we can do it by abbreviating some sections so hopefully we can cram it all in.

I created a simple blockout in 3ds Max, Lewis then made a radical one which me realise how boring mine was. So I took inspiration from Lewis’ and made some iterations to find a medium point between the two ideas.

I then began playing with some engine stuff on growing and shrinking mechanics we plan to have in the game, not much to show now but it should be finished by next week.