Week 21: Puzzle Time!

Progress and Problems

We're making progress! - or so it seems. The level for our Off The Map competition entry is coming along great. We are slowly, but surely populating the scene and I am liking how fast we are getting on with this whole project. However, there is a slight issue. There is something that just seems off.

We have been receiving feedback from a set of tutors that was designed to our group throughout this project and continue to regularly receive feedback twice a week. One thing they pointed out was that our level - while it looks great - just doesn't look like Alice in Wonderland. While we have referenced quite a few parts from the book (like the lake of tears, the tea party and the croquet grounds and palace), the whole thing just doesn't look a lot like Oxford, which is the city that Lewis Carroll lived in when he was writing the book. Since it was his home town, he would've taken a lot of inspiration from it when writing the book and we somehow need to incorporate this in our level.

Our level so far.

Models and EVEN MORE Blueprints!

Aside from that let's see what I have been working on this week. I spent quite some time modelling a tree. I am currently learning how to get better at modelling foliage. I have an awesome tutorial, which teaches how to model foliage from scratch and then use that modelled foliage to bake down diffuse and alpha maps to use as texture for making foliage. I didn't get around to finish it yet though, as I was also working on more blueprint related stuff.

I have implemented a system that switches the character between worlds. We wanted to have a rabbit hole, which would lead the player across the river and into the tea party area, in which everything would be like a different dimension. Instead of the luscious, green grass, we would have a purple sky and a very misty and surreal environment. So to do that we basically created a copy of the level and changed a few parameters to achieve that effect. The blueprint would then load this level and teleport the player to the other side of the river. I had to create a text displaying on the HUD to notify the player that the next level was being loaded and I also had to learn a bit about save games in UE4, which was a bit hard to get my head around at first. Basically, you can not transfer variables between levels. Everytime you load a level, everything from the old level gets deleted and reset. This was a problem, since later on I will work on scripting in a collectible system and I wouldn't want the player to lose all his collectibles when he entered the other level. This is where a save game comes in. It allows you to save a bunch of variables into a special blueprint and then save the whole batch into a file, which can then be loaded again once the new level has been opened.

Tea Party (slightly outdated screenshot)

Another thing I have been working on was a puzzle. We wanted to have a massive fountain right in the centre of our level and decided we could use that to implement a jumping puzzle. I have been working on optimizing this puzzle and it is now working great. It included a set of blocks at the base of the fountain that have a pattern of going up and down in different speeds. The player needs to jump from platform to platform to reach the second stage of the fountain. From there he would then need to jump onto a set of cards, which are flying around the fountain in different directions and speeds. Once the player reaches the top, he will be rewarded with a collectible.

The hard part about making this puzzle was making it achievable for people of all skills. When I created the puzzle at first, I made it challenging - or at least what seemed challenging to myself - but because I was already a seasoned veteran when it comes to PC games it was way too hard for people who don't often play PC games. I had to tweak quite a lot of things, like the controls of the player, which were very sensitive. One person pointed out, that they have problems, since they like to keep their hands touching the keys, however an ever so slight movement would result in an accidental quick button tap, which would launch the player forward. To counter this I implemented a very slight delay (0.05 seconds) into the controls, which is just enough to not make the player launch every time you simply tap the key, but it's not noticeable if you actually intend to move and hold down the key. The controls feel a lot better now.

Another thing that I changed was the collision of the platforms. I noticed that many players who don't often play PC games tend to look straight ahead to the next platform when jumping, instead of looking down at the platform you're jumping from. This would cause them to often jump too early and loose a vital bit of distance and fall down instead of getting to the next platform. By making the collision slightly bigger than the platform itself, it would not take away from the challenge, however make it less punishing if you miss-time your jump. I am thinking of incorporating this into the level in addition to creating a system that will incrementally increase the size of the platforms if the player keeps failing, so that the game would gradually get easier as they keep trying.

I had to tweak the speeds of platforms and distances between platforms quite a lot, as well as change the size of 2 platforms, between which I wanted the player to use the sprint feature that I scripted into the game, however at first it didn't seem obvious and people who tested the game always wanted to jump between these platforms at first without sprinting. I wanted it to be more obvious, so I make the platforms longer in size, so that it looks a bit more like they have enough space, making the player more willing to sprint.

Fountain (with puzzle)

Finally, I have been working on a small script that allows the player to pick up objects within the level. This wasn't too hard, as there was an example of exactly what I wanted within the Example Contents of UE4. While introducing me to a few new nodes within the blueprint editor, I quickly understood what they meant and re-scripted it within our level.

More additions to come.

I plan on implementing a checkpoint system, so that if you reach the second half of the fountain, you wouldn't have to do the whole first part again incase you failed, as people who didn't usually play PC games found it quite frustrating to get half way through only to fail and having to re-do the whole puzzle. More on that next week~

Week 20: Water Shaders and More Blueprints

Water in Unreal Engine 4

This week I continued to work on the Off The Map competition project. As part of our level we wanted to have a lake of tears and for that we needed a water shader, so another member of my team and me set out to have a little competition as to who can create the better water shader. Following a simple tutorial online I managed to create a quite good shader, however it required a lot of tweaking which is what I spent most of this week doing. In the end we got a decent result, however we couldn't get any reflections on the water surface.

A bit of research later we then discovered that UE4 currently doesn't support reflections on translucent materials, so I sat down again and created another water shader and made it opaque. The reflections that we got from that shader looked even better, however we really wanted to stick with the translucent water as well, as this would also give a nice effect once you are actually below the water surface. We tried out having a plane of opaque water on top of the translucent water and while that looked kinda good it just didn't work. In the end we just stuck with using translucent water and ditched the idea of opaque water completely.

Opaque Water

Translucent Water

Blueprint Work

In addition to creating the water shader I was also working on some additional blueprints. In particular a simple jumping puzzle that I am still working on, which involves a massive fountain in the middle of our level. I wanted cards (which for now are just simple blocks) to rotate around the fountain in a particular pattern and have the player jump from card to card. I wasn't quite sure how to achieve this at first, as there is no way of changing the pivot point of meshes in unreal, however I was able to solve this by creating a scene component and then attaching the card mesh to that scene component. Instead of rotating the card I would then rotate the scene component and the card would move with it - Or to keep it short: I worked around it by using a scene component as a make-shift pivot point for each card.

The blueprint was working perfectly. however since the fountain itself hasn't been modelled yet, I wasn't able to complete this puzzle yet. Mostly due to missing collision. I also attempted at creating a simple level switch feature. We currently have a spot in the level where we want the level to completely change from being all green and beautiful to a more purple and ominous atmosphere. I got the level to load using the 'Open Level' feature just fine, however this way the old level gets completely removed, including all saved variables, which would be a problem first of all for setting the player position to what it was when he switched the level (instead of the player start), but most importantly for collectibles, which we plan on putting into the game. The level switch would completely reset all the collectibles, which is something we cannot do.

So instead I tried using the level streaming feature that is built into unreal, thinking I could just stream the level. Which worked... just fine. In fact it even loaded much faster than using the open level node. However, there was a split second gap as the level was loading where the levels were both overlapping, due to me loading the new level and after that unloading the old level. I tried switching around the order, however that way it would unload the level and the player would start falling into the void, before the new level could load fully. So unfortunately this method also didn't work out.

I went back onto using open level instead of streaming and got myself some information on savegames. Unreal has a way of saving variables into a file and then enabling you to read from that file after you've switched the level. This is great, just what I needed! I created a simple function that would save the player location in a save game and then load it back up and teleport the player back to it once the new level was loaded - and I am sure it would work perfectly, however messing around with the level so much has caused it to just constantly crash as it is. I will have a look further into it during the next week. It shouldn't take me too long to fix this issue.

Looking ahead!

We are now at the beginning of the third week. It feels like we have absolutely ages for this project, but the reality is that time is slowly ticking along and we are getting closer and closer to the end. Not just for this project, but the end of the second year. I am not sure whether I am too happy about what I have achieved this year, however I can safely say I got a lot more confident in using zBrush as well as Unreal Engine 4 - and with another 2-3 months ahead of me I am sure I will learn even more. I will probably focus more on building a portfolio during the summer, as I currently don't feel like I have anything that really shows off my skills well enough for me to be happy to use it as part of my portfolio. Speaking of portfolio, I actually got around to creating a model this time. I was asked to produce a bush for our level so I sat down and made one. I am not particularly too fond of it, however my team members have said that it will do. Here is a quick screenshot of it in our level:

Sweet Briar Bush

It's pretty tiny, however we will hopefully use it multiple time in the level and just have it overlapping a couple of time to make it seem a lot bigger.

I am looking forward to the challenges that the next week will bring up. Stay tuned~

Week 19: Alice's Adventures Off the Map!

New Beginnings

Apologies in advance, this might be a bit of a short post, since I am personally not feeling all too well at the moment (mostly, but not limited to, suffering from tight hip flexors, which put me in excruciating pain everytime I move and contributing to a lack of sleep).

We started our new project this week, which is also our very own entry to the 'Off the Map' competition. You can find a lot of information about this competition here: http://gamecity.org/alices-adventures-off-the-map/ Since it is celebrating its 150th anniversary, this years Off the Map competition is based on Alice in Wonderland by Lewis Carroll. This is a group project, but luckily this time around they decided to assign us groups based on what we think we are best at and I am quite happy with the group that I was put in.

This week mainly consisted in a lot of decision making and personally for me I didn't get to do a lot stuff. I started off by sitting together in my group and discussing possible ideas of what we could create. Our university specific brief was pretty much the same as the original Off the Map brief, with the slight modification of stating that it had to be a playable game and not just a pretty environment. Originally the brief asked for a side-scroller but was changed soon after they announced the project to be more open. In our case we therefore decided to make a first person adventure game. We also came to the conclusion to base our level on the topic 'Gardens'.

I then went onto reading the book. The first step to making a game based on a book is logically to read through it. This covered pretty much most of the first day. I also did some research into games that we could use as inspiration. After that we sat down once more within our group and started discussing our level in more detail. 'How is it going to work?' 'What does the player have to do?' We also thought about a couple of designs and eventually settled on a final design pretty quickly. I then went into creating some basic game mechanics, since for this project I decided that it would be most beneficial for me to stick to engine related work. as well as modelling (These seem to be my strongest points). One of the first things we wanted to have was the ability to shrink and grow the player (just like Alice shrinks and grows throughout the book.) This was quite an easy task to achieve for myself and I managed to draft a quick blueprint for that.

Throughout the rest of the week this continued onwards and I created more useful blueprints. I also started modelling some rocks, which required me to once more dive into zBrush and figure out a way of using that piece of software. I seemed to get the hang of it towards the end, however I wasn't too pleased of the final baked-down results within engine, so I will have to spend a bit more time trying out different things for that at some point in time.

Unfortunately that is it so far. I haven't got any pretty pictures to show, however you can head over to Anya's blog for some great environment concepts, as well as Denise's blog for some amazing character concepts. Also check out my other team-mates: Mark, Sharnleigh and Rebecca. See you next week~

Week 18: Through Sweat and Tears - And Blueprints! (Post-Mortem)

Unreal Scripting

Where do I begin? - I finished off last week by writing about my torch and the problems I encountered with it, however this was just the beginning of all the scripting I had to do, in order to get this level to work. I wouldn't consider myself a scripter/programmer, however I did have previous scripting experience as well as a pretty strong logical mind and that definitely helped a lot in this project.

The scripting system in unreal engine 4 is known as blueprints. They are easy to understand for most people (even those who have never done any programming), but when it comes to complex scripting it can be quite hard and I learned that the hard way. While most of the things I wanted to script into the level were quite simple, they turned out to be a bit harder for some things. For example:

I wanted to make text appear on the HUD. One bit of text which shows the controls to the player, that can be toggled by holding a button and several other bits of text that appear and fade away when you pick up items, etc. While that might sound quite hard I didn't expect to produce something as complex as this!:

HUD Blueprint

I can already hear some of you say:"But Hey! HUDs are never really easy to create!" - and that's true! - However, there was even simpler things that were a lot more complicated than they had to be. Like Global Variables.

Why can't I just create a variable in the level blueprint (which btw. has access to any component within the level) and then be able to change it within every other blueprint? There is of course a way to do this, however it's a bit more complex. It involves either in you having to link 2 blueprints that you want to interact between together or you have to use what is known as casting. Now, for those of us that never heard of casting: It basically means that temporarily you switch over to another blueprint and do something AS that blueprint. For example if I want to have a global variable (or at least something similar to that) then I can create a public variable in blueprint A and then in blueprint B cast to blueprint A and set that variable to whatever I want to set it to.

If it was that simple, it wouldn't have been a problem though. It is actually even more complex. On top of the casting, you also have to specify which EXACT blueprint instance you are casting, too. This means the blueprint needs to be in the scene so you can select to cast to that particular instance, which then again is not too bad, until you get to the HUD or player controller. Which are both blueprints that are NOT in the scene, but rather get created once you play the game. In that instance, however, UE4 has got a simple node to help you out for that such as 'Get Player Controller' and 'Get HUD', but WHY is this so complex? All I wanted to do is set a simple variable to true and let ALL blueprints know about it!

Anyway, enough ranting. Another feature that I implemented which took quite a bit of scripting was the flashlight. I wanted it to move together with the camera. First I had to change the pivot point to be very similar to that of the camera itself and then it took a bit of scripting to find and set the position of the camera and the flashlight. I also created a socket at the front of the flashlight for the light itself to be in, so that the light would move with the flashlight. Here is a quick overview of the blueprint for the flashlight rotation:

Set Flashlight Rotation

Finally another scripting challenge was the end part of the level. We planned for our level to end with an elevator, so I had to script in the button to open the elevator door, which would only work if you had previously turned on the generator. It would have to open the door and upon the player entering the elevator I wanted a message to appear that told the player to press E to end the level. I would then want to switch the player to a camera and slowly fade out the level, while playing music and having the elevator rumble to create the illusion of it moving. After quite a lot of time scripting and testing I managed to produce this:

Elevator Ending Blueprint

The Final Result

I did manage to get there in the end and managed to complete the level; And I have learned A LOT about Unreal in the process. I can now safely say that I am pretty confident in scripting within UE4, which is great! Unfortunately, I haven't been able to do much else within this project. I was mainly focussed on getting everything to work and creating the materials in engine. I also got sounds to help set the atmosphere. I did model a very few objects, however my main part in this project was unreal, therefore I can't show off much. I am, however, able to show a video of our level. We had problems with the framerate and ultimately only got it up to 40-50 FPS, which meant that in the recording process it was running quite slowly, so I was only able to record it at a resolution slightly lower than 720p. I scaled it up a bit and here is the final result: