Week 32: It was a long way, but we made it! Alice OTM Post-Mortem

The last surprise

So, what can I say about the last week? It definitely didn't go as expected! With time crushing down on us we were very tight and had to prioritise a lot of things before the DMU hand-in. We wanted the level to be fully playable, yet whenever I worked on implementing missing components something else would break, resulting in me having to spent time fixing everything. We were getting close to the end as the week went on, but then the tutor's decided to pull out their final surprise for us: Hand-in requirements!

While we were given a clear brief right at the beginning of the project, this did not include any sort of information on what and how we will be handing in our work. This is always a huge deal with group work, as it has to be clearly visible which person on the team created which part of the final product. In past projects this meant we had to fill in a couple of documents to make this part clear and hand those in together with our work.

For this project, however, the tutors decided to wait until the last 2 days before telling us what we needed to do in order to hand in our work. This included not just a document, but also the creation of a separate scene to show off the work we have contributed towards the group. As you can imagine, this wouldn't quite work with what I personally have done so I had to get in touch with the tutors and ask a bit for advice. In the end the easiest way to show off what I personally have contributed was by creating videos and so once I got home that day I sat down and worked until 4 in the morning on creating videos and writing my document. I didn't fully manage to complete it, even though I spent all night on it, so on the next day I went to labs to finally get it done. This meant that I did lose a whole 2 days that I could've spent improving the level and making sure everything works. In the end I still got back to the level and did some more fixes, however all in all while the level might work now (I say might, because it has a tendency to show some bugs), I am not fully happy with the state it was in for the hand-in.

While the end state might not be that satisfactory to me, the process of getting there was by far the best out of all the group projects this year, but let's round this whole project up with a final post-mortem.

Alice OTM Post-Mortem

To start off, here is a quick summary of the brief: We were given 3 different topics to base our idea on: 'Oxford, Underground and Gardens'. For each of these topics we were provided with resource materials, such as sounds, maps and information/text. The task was to create an interactive level using those resources and sticking to our chosen topic. We decided to choose 'Gardens'.

The duration of the project was originally 10 weeks, with addition of the Easter holidays (3 weeks). However, we were given an extra week, bringing the total duration of the project to 14 weeks.

There is a couple of things that went really well with this project. In particular I am happy to say that for once during this year I had a group project that didn't fully end in disaster. We worked very well together as a team and established a rule right at the beginning to not take any feedback on work personally, which allowed us to give constructive criticism without the fear or upsetting one another. Time management was a big issue in the past and while with this project I feel as if we could've still done a better job, it was actually quite good. We usually spent our time working together in the labs, which saved us from having to organise regular meetings to know what everyone was doing. In addition this also allowed us to distribute work more evenly and easily between each other.

Another thing which really stood out to me was the productivity levels right at the beginning of the project. Within just a couple of days we already had a blockout of our level done and within just a week we already started to slowly populate the level with assets. All while doing concepts on the side. This was great, since during the past group projects our team had spent far too long on creating concepts and only started creating assets way too late.

However, there is also quite a few things that went wrong. While our teamwork was mostly outstanding and I enjoyed being part of such a fantastic team, there was one thing that I just couldn't quite forget about: Team Leadership. As with previous projects, there was no clear leader for the group and while there were 1-2 standout group members who sort of acted as leaders a couple of times, there just wasn't the ultimate leader who was able to take the project where it needed to go. Now this is a point that people can argue about and while our team did function quite well without a assigned leader I still feel as though it could've really needed one. However, this is more of a problem with the fact that we are all students, rather than it is a problem with this project. Since everybody needs to work on developing their skills it would be hard to have one person just focus on leading the team, therefore I don't think there is much that could've been done about this.

Going back to time management there also was a couple of issues that annoyed me. Number one was the fact that I ultimately wasn't given enough time to do what I wanted to do, however this is partly my own fault for underestimating the time I would need to get everything done. I didn't get full access to the level to create the many scripts that I needed to create until very late in the project and this meant that while I did get most things done, it wasn't to the standard that I had hoped and it was riddled with bugs, leaving me to fix those bugs within the last week, which obviously turned out to be a problem due to the documentation getting into my way.

We also had a problem with planning. Since we jumped straight into creating everything, from concepts to assets, we completely forgot about creating an actual asset list. This hadn't been created until a few weeks into the project and even then was still quite vague and missing many assets that we ended up having to add in later.

There was a big change within the project about half-way through, when UE 4.7 had been released. We previously had problems in UE 4.6, since our level was mostly foliage and Unreal at that point didn't have any real foliage shaders, meaning we had to try and fake them, which wasn't ideal and didn't look too great. When the engine update got released we were happy to see that one of the major new features was an entirely new foliage shader and this had helped us a lot, so we immediately updated our level to the newer version. This was a risky move, since updating a game engine in the middle of the project can usually cause a lot of things to break, but luckily for us it seemed to be fine.

Another big change was when I decided to change how the level was being loaded. There is currently 2 ways in unreal of loading different levels: One being the usual load level, which causes the game to stop running until the new level was loaded and two being streaming, which involves quickly 'streaming' in each asset within the level, which allows for faster loading times and gives the level the ability to continue running while the level is being loaded. We originally used the traditional load level, which had caused a bit of issues, so I decided to switch it to be streaming instead, however this meant that there was now a new way of working with the engine, since all of our levels would basically be merged into 1 massive level. This later on turned out to be a bit of a problem, since working within the streaming level would cause a lot of issues, especially with foliage and landscape, which would end up crashing the engine. After we discovered this we had to resort to loading in the levels separately in the editor to avoid these crashes.

All in all, however the project did go quite well compared to previous groups projects. So while I wouldn't do a lot of things differently there is one thing that I would definitely change: Start scripting earlier!

I spent a lot of time at the start just coming up with ideas for puzzles and how I would make the whole level playable, but not actually spent time creating these scripts. They were just lose ideas that I had floating in my head and while most of the time I had some sort of idea of how I would create certain scripts, when it finally came to actually making them, I always encountered some problems. Partially this whole workflow was caused by me not having access to the assets that I needed in order for the scripts to work, for example when creating the fountain puzzle I had to make sure that I actually have the fountain itself so that I could create the puzzle accordingly. However, with some of the scripts I could've probably done most of the work earlier on and then just replaced placeholders later on and changed the script in case it needed changing.

Another thing I would probably do differently is spend more time on creating assets. I like 3D modelling and I am a bit sad that I didn't get to do it much during this project. While I love the unreal engine 4 blueprint system, this is not something that will secure me a job later on and I really want to focus a bit more on modelling, since this is something creative that I feel like I can actually do and is something that will help me in the future, since while I plan on specialising in technical art, I also want to keep my options open and I am always keeping an eye on environment art.

Finally, I am happy to say that we finally did it! The level is playable and looks great; something I could've only hoped for during the last couple of projects. I am glad that we got it over with and frankly I do not really want to look at it anymore, however there is still work to be done and if want to submit our project to the OTM competition we need to keep on working. For now though, I am just happy that it's gone. It was a very stressful couple of months and we all did our best and pushed on until the very end.

To end this post-mortem I would like to share with you the final result of all our hard work: 

A massive well done to the rest of my team at this point. Make sure to check out their blogs here:

Anya: https://anyadmuga.wordpress.com/

Becky: http://beckygibsonart.blogspot.co.uk/

Denise: http://denisecjj.blogspot.co.uk/

Mark: http://markeastlanddmuga.blogspot.co.uk/

Sharn: http://sharnleightaylorgameart.blogspot.co.uk/

Stay tuned~

Week 31: The Dark Side

Full Speed(?) Ahead!

A lot of stuff happened during the last week and the weekend, which is why this blog is once again a bit late. We finally got the dark world sorted and it looks amazing. There is still quite a few tweaks that need to be done, however it is implemented and I had the chance to finalise the level switch script. This was the first thing I have done during the week and also turned out to be a major challenge. Mostly due to the fact that I had to manually save every single variable that I wanted to save during the level switch. This meant that I had to consider every possible outcome that might be the case when the player switches the level. Has the player found any collectible yet? If so, how many? Has the player done the rabbit puzzle yet? Have they even started it? And if they have, how far did they get with it? Everything needed to be saved, so that when the player returned they would be at the exact the same stage as they were when they entered the dark world.

Near the end of this long process I then discovered that I could've just saved the character blueprint itself as a variable instead of every single bit... great! At least I learned something new. Another factor which greatly increased the time that I had to spent on this was testing and engine stability! UE4 has a tendency to crash and with that you would lose a lot of work, unless you save regularly. This is a major issue on the PCs in the computer labs as it takes absolutely forever! I'm not kidding, one time we nearly sat there for a whole hour waiting for it to save. So every time I changed something I first had to save everything I have done to prevent loss in case of a crash and then after an average of about 20 minutes saving time I would then have to load up the level (which also took about 5 minutes at times) and then walk down to the hole to test everything. I can safely say that about 50% of the time I spent on scripting the level switch into the game was spent waiting for the engine to save/load/play.

Our team members after saving the level for the 10th time in a row.

Nonetheless, the level switch was done and with that I was ready to tackle the next hurdle: The Mad Hatter puzzle (or Tea Party puzzle). We wanted the Mad Hatter to give the player a riddle describing a particular object and then have the player go and find said object, pick it up and bring it to the Mad Hatter. I already implemented the picking up mechanic earlier so that wasn't too much of a problem and it was mostly just writing dialogue. Denise wrote the riddles for this puzzle and I implemented them and scripted the logic behind the puzzle (such as detecting which object the player brought to the Mad Hatter and then deciding whether that's the right or wrong object).

Later on during testing with other people we found that there is a problem with the objects having physics applied to them, which can cause the objects to either be shot out of level bounds or even under the floor, causing them to fall indefinitely into the abyss. This can be fixed by resetting the object once this happens though and I already had to implement a reset function as part of the puzzle so it's not too concerning.

Wonderland Playability

Going back to our original world there was still a couple of things that I needed to finish for it to be fully playable. Starting with this, I first finished the key puzzles by implementing a card guard NPC that would control that quest. I then also had to finish the rose puzzle, for which again I had to create a card guard NPC. Although they are both very similar, they required different scripting so it took me a bit to get both of them working. Finally I spent some time working on the final cutscene and the credits, when I realised that we still needed a main menu, so that when the player finished the game and the credits played we could reset the game back to the main menu, so I also worked on getting that done. At this point it is important to notice that all of the following components are only temporary placeholders for the DMU hand-in of this project: Any dialogue (except for the riddles), Credits, Start Menu, Final Cutscene. We wanted to have our level be fully playable in time for the DMU hand-in, however we don't have enough time to get those components to the stage we want them to be at, so for now they are really just simple placeholders that "do the job".

Finally a full game!

I am glad to say that we have finally reached a point where the level is fully playable from start to finish. This is what we wanted to achieve and we did get there. There's still a few bugs in the game that need fixing (although mostly just aesthetic bugs, there's unfortunately also a few game breaking ones) and we have loads of other things we want to change and add, but as it stands the level is pretty much done for the DMU hand-in. It was a long ride (the longest project yet), but it will be nothing compared to our FMP next year. Next-up will be handing in the project and writing a post-mortem.

Stay tuned~

Week 30: From a pretty level, to a game!

Time To Shine

This week I finally got my hands on the level and had the chance to properly work on getting it to a playable state. I started off by working on dialogue boxes, particularly those of the dialogue with the white rabbit, which would initiate the first puzzle in the level. For the puzzle itself we wanted the player to explore the lake area a bit, so we decided to have the white rabbit lose his gloves and nosegay flowers and send the players on a quest to find them. For the beginning cutscene I decided to start off by showing Alice and the Rabbit from a third person view. Then after that pat of the dialogue was finished the camera would cut to show a bit of a fly over of the lake. The camera then cut to show the gloves, to at least give the player an idea of whereabouts the gloves are hidden. After that the camera would cut to show the nosegay flowers, before finally cutting back to Alice and the rabbit. This way it wouldn't just be a boring static screen that shows Alice and the rabbit talking and it would also aid the player in completing the objective.

Implementing the actual dialogue boxes wasn't too hard, but I encountered a tiny problem. Currently in UE4 to make other cameras in the scene active (for cutscenes) I used a node called "Set View Target with Blend", which allows for the player's camera to temporarily switch to another one, which worked great. However, the problem with this is that any UMG HUD that the player has displayed on their screen, will not work with this. It will simply disappear. When doing dialogue boxes I used a UMG HUD to display them, so I came into a bit of a problem when they wouldn't show up. Unfortunately. there wasn't an easy way to solve this either and I had do change the blueprints that I had created so instead of using "Set View Target with Blend" I ended up changing the blueprints to be actual pawns that I could then "Possess" instead. This worked great for what I wanted to do, since it would not only allow me to display the UMG HUD, but it would also automatically remove the player's ability to move, since possessing a different pawn would completely detach the player controller from his character. Since I didn't want the player to move during the cutscene anyway this came in quite handy.

This did cause another problem though, which I only noticed on Friday, which was that the HUD for the player was currently created "On Possess", which meant when I ended up possessing the player character agian after the cutscene, it would end up creating another HUD on top of the original one. So I changed it to be created "On Begin Play", which caused it to disappear completely and the reason for that was probably the reason why I originally set the HUD to be created "On Possess". This happened because we start off the game inside a matinee cutscene and not in the character. We only possess the character once the matinee has finished playing. For the HUD to show up on the screen we need to have the player possess the character BEFORE creating the HUD, so when I go back on Monday I'll need to work around that and fix it.

Rabbit (with Quest)

Puzzles!

After I had created the cutscene and dialogue boxes I then focussed on getting the puzzles in the level to work. I had been told by Mark to concentrate on the actual level for now and leave the Dark World and with that the Mad Hatter puzzle out for now, since they still have to actually create and adjust the mood within that level. So I started off with the rabbit's puzzle, which I had mostly finished before anyway, by creating the HUD that shows what items had been collected already. I just needed to add a bit extra to check whether both items were collected and if they were, allow the player to end the puzzle.

After I finished creating the rabbit's puzzle I then went and attached the last key part onto the butterfly script that I made earlier in this project. This was one of our key part puzzles and the player would have to catch the butterfly to get the key part. This took a bit of figuring out, since I wasn't quite sure what I had to do to attach 2 completely different blueprints onto one another. When I finally managed to do it, it ended up not working in the game and the reason for that was that my collectable blueprint was using "Set World Position" to make the key part bop up and down. This ultimately forced the key to stay where it was and just bop up and down instead of fly through the air together with the butterfly. I fixed this by simply disabling the bopping for this particular key part, since it was looking a bit weird anyway (if a part of a key hovering below a butterfly and emitting sparkles isn't weird enough already!).

The next thing I wanted to do was a quick fix for the fountain puzzle, which was moving too low and would allow the player to simply jump straight onto the last platform (completely skipping the level). So I did this quickly by making the platform move less further down, which ultimately made them move slower and therefore making the puzzle easier, but since people were already struggling with it before I thought I might as well just leave it a bit easier anyway. We don't need the puzzles in our level to be too challenging, since we want everyone to be able to play through it.

Finally I moved onto maze, which was one of the first puzzles that I had originally created, however since the beginning of this project the maze itself had moved a bit and therefore it needed to be readjusted and I had to change some things to get it to work. The biggest problem I had with this was a simple stupid error, where Alice wouldn't be visible once I switched into third person. This was just because I thought she wasn't visible though, when actually she was visible, but from the camera angle that I chose she was about 1 pixel in size. This was because I disabled the beginning cutscene (in which Alice grows) for testing purposes and since you had to shrink to get into the maze, the actual Alice model was basically shrunk twice (exponentially!) I also wanted to get the Alice model to face the direction that she was moving in, since the maze controls disabled the mouse controls, so that it wouldn't be too confusing. This was also a bit challenging, since there was several checkboxes that needed to be ticked/unticked in order for this to work and it took me quite a while to find the last vital checkbox. After a bit of googling I eventually found this thread, which outlines all 4 checkboxes that control the camera/character rotation (Massive thanks to doC!).

The Maze

For a quick couple of pictures showing how the maze works, have a look at Mark's blog here: http://markeastlanddmuga.blogspot.co.uk/2015/04/dmuga-week-30-end-is-nigh.html

The Final Challenge

At the end of the week I got as far as working on the final puzzle, however while it is currently playable it is not yet finished. For this puzzle we wanted the player to paint a set of rose bushes from white to red within a certain time limit. I managed to create a timer that would count down the time and display it on screen and I also created the actual function that paints the rose bushes. The only thing that currently is missing for this puzzle is the card guard, which you need to talk to first in order to activate the ability to start the puzzle. I got a manual work around for this that I used to test the actual puzzle, but if you fail the puzzle like this, then where would be no way to retry. The guard itself should not need a lot of scripting though. It will just be another dialogue, for which I can just copy what I have created for the rabbit and then it would just need to set a boolean inside the puzzle to true, which controls whether you can play the puzzle or not.

Hopefully I will be able to quickly implement this during the next week, however our main focus for the next week is to get the Dark World set up, so that I can work on getting the last bits done during the final week afterwards. It's a very stressful time for us all, but we can do this!

Until then, stay tuned~

Week 29: Better late than never!

Workload Overload

This blog post is quite a bit late, so apologies for that. In fact with the last official week of this term going on at the moment, I find myself in a lot of stress to get everything finished. Of course we did get an extension for our OTM project, so I will have an additional 2 weeks to work on that, however there are a few things that I had to get done during last week.

Stressful times.

Presentation Time!

First of all it was the presentation. I did my presentation on geocaching, which is one of my hobbies and a great way to get outside and have fun! I am not going to go into too much detail on the subject now (I might do another blog post purely aimed at that sometime), but if you wish to read more about it then head to the official website: http://www.geocaching.com/

The presentation itself went pretty good. I practiced quite a bit to get it right and I was pretty confident on the day before the presentation, but once I actually got up to do it I was feeling anything but confident. Apart from shaking uncontrollably I kind of lost track half way through and had to pretty much read off my script to get back into what I was talking about. All in all it was quite good though, but I didn't receive a lot of feedback. There was a very few questions after I had done my presentation, however they were directed at the subject itself, rather than the presentation.

Extended Writing.

Another major thing I had to get done during the last week was my extended writing, which actually is due tomorrow! However, I spent my time and had it finished by the time the weekend had gone, so there is no more need to stress about that, since I already handed it in. For our extended writing we had to write a reflection of the second year in relationship to our career aspirations as well as an action plan for the next step.

My career aspirations always had been a bit of a mystery as I mentioned in previous blog posts, however in the end I decided that for now at least I will stick to becoming a technical artist. It just seems like that is the one position that is made for me.

Update in Wonderland

Regarding our OTM project I did not get a lot of work done during the last week. This was mostly due to me focussing on getting my theoretical part out of the way first. I did however create a couple of minor cutscenes to get started on the workload of scripts that I had to work through, but it was nothing major.

During this week I am putting a lot more of my time into working on the level and I will update my blog again with what I have achieved within the next few days, so stay tuned!~

Week 27 - 28: Easter Holidays - The End Came Quickly

Still more issues!

I didn't do a post for last week and this post is a bit late as well. The reason for that is that not much happened. I tried optimizing the framerate and researched a lot into it and tried many different ways, but I couldn't get it to run any better. When we came back from the Easter holidays I asked some tutors and as it turns out UE4 is not particularly good with rendering alphas, which results in us having to re-do a lot of foliage. The main problem that occurs in our case is overdraw, which is mainly caused by polys overlapping (a standard procedure of creating foliage in games is by overlapping planes with an alpha mask). To counter this issue, we need to further cut out the alpha planes using additional tris, so that there will be less overlap.

Apart from that nothing really happened since I decided to actually take a break over Easter and enjoy the holidays. I will now have to focus on getting my work done over the next few weeks, which might get a bit stressful. On top of the Off The Map project I also have to create a presentation and an extended piece of writing.

I will update my blog next week with what I have accomplished!

Week 26: Easter Holidays - FPS Optimization?

A level full of lag.

Another week has passed and we find ourselves within the ongoing Easter holidays. This will be a rather short post, since not much has happened this week! While it is a bit of time for me to rest, it is also the time where I finally get to implement most of the gameplay into our Alice In Wonderland level though, so I will try and get more done during the next week.

The problem we are having at the moment is with FPS and optimization. We started off the week by implementing the much needed LODs into our level and after all the work of implementing them had been done, we noticed only a very slight increase in FPS, which is not what we had hoped for! The level still runs with an average of 15-25 FPS and that's simply not good enough, especially considering that we are using high end PCs and we simply can not expect the judges to have a similar machine to run the level on. So I took another look into it and got in contact with some communities online to figure out what exactly was causing the FPS lag. After quite a bit of digging I discovered a tool that would help me debug the frame rate and with that I could easily see that one major issue was lighting.

My first step was disabling all the dynamic lighting on the foliage, since (thinking about it now) having thousands of meshes cast a shadow, which changes every single frame would obviously be quite heavy on performance. This however meant that we would loose all the shadows in the level, which made it look a lot worse, so I decided to try using static lighting instead. Unfortunately I did run out of time in the end and wasn't able to build the lighting yet to see what the level would look like with static shadows, so I will have to try this out as soon as possible.

There was another element that was causing a lot of FPS lag (approximately the same amount as the dynamic lighting), however I have to further investigate into that as well. Hopefully by the end of all this I can get the level to run at 30FPS+ and then focus on getting the gameplay elements implemented.

Until then, stay tuned~

Week 25: Breakages and Aspirations

An Eventful Ending

The Easter break is finally here and with it we say goodbye to the last major term of this year. After the holidays we are back for another 2 weeks before the hand-in of our last project and then we get to work on own projects while our work is being marked for this year. Actually no, that is not quite true, because we actually found out this week that we will be getting an additional 2 weeks to finish-off our Alice In Wonderland project. Wohoo!

Although we were doing pretty well up to this point and I feel like this project is the first group project that I have done this year where not everything has gone completely wrong, we did have a couple of down moments throughout working on our Off The Map Competition entry. This was usually minor things, which only really seemed pretty major at the time, but were easily solved within a couple of hours. This time, we had a bit more of a major problem though!

Group work is super-awesome! (Well, sometimes.)

I had been working throughout Monday and Tuesday to implement a new mechanic into our level: Level Streaming! This would allow us to load levels faster and easier and also have animated loading screens instead of a frozen image with text. Awesome! However, this was also the first time we used this new system and it meant that we had to get used to switching between levels within the editor and having all the other levels be visible on the screen at the same time. This could get confusing, for example if we were to place an object within the dark world, but forgot to actually switch to that level and still have the normal world set as the active level. Once we would then unload the normal world, the object that we just placed would disappear with it, no matter if it was actually placed inside the normal world or the dark world.

In the end it turned out that this way of working (while it worked great for us) was just bad practice though and we faced a massive problem with our landscape completely breaking and causing the engine to crash everytime we tried to edit it. This was a major problem as Anya took over the engine from me to place a lot of foliage into the level and populate everything and the foliage she painted was bound to the landscape. Replacing the landscape with a new landscape would therefore mean that we would lose all of our foliage and that would've been quite a big impact on our progress. So we tried to solve the issue and I went into contact with an employee at Epic Games (the developers of the unreal engine) who tried to assist me by taking a look at the level. In the end it turned out that the only solution for this problem was to switch directly into the level we were editing, rather than using the level streaming within the editor. It took us a whole day to figure this out, but at least in the end we managed to save our project. Phew!

An engine crash! Oh wait.. wrong engine.

Technical Artist?

Furthermore, we had our formal reviews this week. Funnily enough I was actually looking at internships at different companies on the day before and discovered a position for a Technical Artist Intern at Ubisoft in Newcastle. I had a browse through and pretty much decided that becoming a technical artist would probably best suit me. Combining modelling and texturing with scripting is something that I personally feel like is interesting and it almost seems that it is pretty much what I am doing on this project right now already and what I have done on the project before. When I came into my review I was promptly told by my tutor that a technical artist is what I've been put down for as well. So clearly, this is where I am going, which is great!

I finally feel like I have something to aim for. So far I was always quite unsure of what to do, but it seems like I have found my goal and now I can focus on getting where I want to be. One of the things that stood out to me were the fact that I needed to have good knowledge of scripted language such as Max Script and Python for the internship at Ubisoft, which is something I have yet to look into. I am fairly confident when it comes to scripting, but I have not yet had the patience to sit through and actually learn a particular language. I know bits and bobs when it comes to PHP and back when I was playing a lot of Garry's Mod, I learned scripting from scratch using a made-up language known as "Expression 2" (http://wiki.wiremod.com/wiki/Expression_2) within an addon called "wiremod", so I am fairly confident that it should not be too hard for me to pick up on Max Script or Python. However, for now I will concentrate on getting our current project done.

Easter Holidays!

I am aiming to keep posting on my blog over easter, since I have quite a bit of work to do for out project. Most of the asthetics are done now, but I have yet to create many cutscenes and puzzles. We went over this during the beginning of the week and I have made a nice big list of stuff that I need to do. I am quite confident that I will get everything done though and if not, then I still have 4 weeks to finish it off after Easter and most importantly several months until the final hand-in for the actual competition. So I should be fine.

Stay tuned~

Week 24: Sounds fishy!

When will the blueprints end?!

The short answer: Not yet, and looking at it, probably not that soon either.

Over the past few weeks I have been focussing a lot on blueprints and I am glad to say that I have learned a lot! I am becoming increasingly more confident in scripting using Unreal's blueprint system and on top of that I am fully enjoying it, however there is a slight problem. I am still studying Game ART - and there's a reason for that.

I was originally always more inclined to become a programmer myself. I was naturally very talented in maths and my logical side of the brain is a lot more predominant than my creative side. After I had finished school I was aiming to study maths and computer science, however things went a bit out of hand and I found myself stuck taking a gap year instead, which was followed by another gap year in which I even started working, until I finally decided that I didn't yet want to give up on my aspirations of working within the games industry and had to get back into learning.

The 2 Sides of the Brain (Logic and Creativity)

During my gap years I had tried to learn programming myself, however I quickly lost motivation and it didn't go all too well. The subject was easy enough to learn, yet I just didn't want to go on. So instead I took up a course at college labelled "Games Development", fully knowing that it will most likely be either programming or art, since those seem to be the 2 major components of making video games. When I actually started the course this turned out to be art.

At first I was a bit scared that it might not be the course for me, as I never considered myself to be any good at art, even though throughout all my school history I studied art (mostly because it was compulsory back in Germany and when I finally moved the the UK I decided to choose art as a subject since I was so used to having it within my curriculum.) After I had spent a couple of weeks it quickly became apparent though, that most of the people on the course didn't seem to be the creative type either, so I adjusted. I then also discovered 3D modelling and quickly fell in love with it. Although I never considered myself to be a creative person, I absolutely LOVED creating things. 3D Modelling is quite a bit more technical than drawing and it suited me a lot more than using pen and paper, so it became one of my favourite things to do! I even took part in the very first 3D Speed Modelling Competition endorsed by World Skills UK and won!

So throughout my time at college, I discovered the second side of making video games and I was more inclined than ever to get a job in the industry. I ended college feeling quite comfortable with my 3D skills, however I knew my 2D was still quite lacking, so I ended up applying for DMU, since I had heard that the Game Art Design course at DMU is a lot more 2D oriented at the beginning and I had hoped that this would give me a chance to improve my skills in that area. Safe to say I was more than excited when I had heard that I managed to get accepted onto the course.

Looking back at it now, I definitely got what I asked for in the first year. A lot of drawing and still quite a bit of creating 3D models; And my skills in the 2D area improved drastically. The second year however, the curriculum had changed. The industry was moving forward fast, so the course had to change in order to adapt the changes in the industry. We went from covering the basics of art straight onto content creation and as much as I had liked to have another year of going out and drawing the world, I wasn't too fussed. In the end I knew that what I truly wanted to do in the industry was anything to do with 3D modelling (most likely environments, since I am still not too much into characters) and actually creating my concepts in 3D would help me get better in that area.

With the last project (Container City) and this project (Alice in Wonderland), my focus has changed a lot back into working more technically. Especially using the Unreal Engine 4. Since most people on our course are more creative than technical I sort of felt inclined to take over the scripting side of level creation; (A level is not a level, unless it's interactive!) - And I thoroughly enjoy it as such, due to my history of learning how to script and my more logical brain. However, I have slowly been thinking more and more about the art side and I really need to start taking care of that. So I really want to get back into doing more arty stuff for this project. However, as it seems right now this won't happen too soon, since there is still a lot to be done on the interactiveness of our level and I am working full steam ahead to make sure we get everything into our level that we want to.

So let's get into what I have done this week.

Funky Fishes and (K)omplex Kelp

This week started a bit earlier than Monday, since I had received a message from Anya who had finished rigging and animating her fish models and had them ready to be imported into the engine for me. So I sat down in the evening on the weekend and gave it a quick go, which worked out great and by Monday morning the fishes were all in the engine and had their animations assigned, so that I could begin scripting a simple AI for them.

To do that I took my butterfly blueprint as an inspiration and made minor changes to it to make it seem more like a fish than a butterfly. I am glad to say that I managed to get the blueprint working pretty quickly and the fishes look absolutely adorable! Unfortunately. I haven't got any screenshots available, but if you head over to Anya's blog you can have a look at them.

Furthermore I also took on another little challenge that arose this week. Anya had modelled a string of kelp and rigged it to animate it to move slowly so it looks more lively underwater. As it stands right now, you can't use the foliage tool to paint skeletal meshes in Unreal, which meant that we had to come up with another solution, since placing every piece of kelp by hand seemed a little over the top. To solve this issue we once again resorted to using blueprints.

I knew that it was more than possible to generate random foliage with blueprint, since there was an example of this in the blueprint examples demo in UE4. I also have been becoming a lot more accustomed to using the construction script within blueprints in UE4. This meant that creating this kelp generating blueprint wasn't all too challenging. However, I only managed to get it to work for a square area at first, by using 2 points that mark the start and end of the square that you could place as needed within the world. The hard part was making the kelp generate in a circle around the area.

My first idea to solve that issue was jumping straight into calculating the area of a circle: pi*r^2, however while that gave me the area of the circle, it was the size and not the actual coordinates. This was a lot more complex and after some research I finally got it. This is also when I realised that I did this sort of thing before when I plotted a circle into a graph using maths. The simple solution to this problem was using sine and cosine. Using sin(A)=x and cos(A)=y you can find a single point on the circumference of the circle. 'A' represents the angle (so 0 would be facing straight up and 90 facing to the right, etc.). So for my kelp generator I used a random float between 0 and 360 to find a random point on the circumference and then used a random float between 0 and the radius of the circle to find a random spot within the circle to place the kelp at.

You can find a bit more about this on Mark's blog and also about how we solved some more issues underwater.

Rocky Road ahead?

I still have to create some rocks in the near future. This is one of the only arty things that I got assigned to do for this project and I really want to get into it. I did some practice with zBrush earlier in this project trying to create rocks, however I haven't actually done a rock that I was pleased with yet. Due to a recent lecture from a third year about baking normal maps I think I found a reason why my rocks just didn't look that great, so I am aiming to get some better looking rocks done pretty soon.



Oh and I also did a bit of a personal project. I sat down and tried to script a little Tetris game in Unreal, just using blueprints. The game is still in development, however there is a playable version here: http://goo.gl/7R5aQh Tell me what you think about it in the comments.

Week 23: Like a Butterfly!

Little Problems and Weekly Changes

First of all let me say this: Our level is making an amazing progress!

I ended my last post by saying that I would aim to get the tea party puzzle finished by this week, however I quickly discovered this Monday, that this would not be the case. First of all I encountered a problem: Previously in older versions of the engine you were able to select a group of meshes in the level and convert them all into a single blueprint. I was going to use this to make a blueprint for the tea party table, which I could then play around with to take out some parts and enable the player to find them. However, as of 4.7 this feature has been replaced with something different, so I ultimately wasn't able to do what I planned to do.

I also thought once again about the puzzle in general and wasn't too keen on it anymore, so as a group we will have to think of puzzles a bit more. While we do have a few nice puzzles in the level, as it stands it just seems like we're still lacking gameplay. This will be an important part, as we won't just be judged on how nice the level looks, but also on how much interactivity there is. I hope we get around to this problem soon and find some nice gameplay elements that we could implement.

Additions: The Butterfly!

I did manage to work on something awesome this week though: A butterfly! I already started working on it a bit earlier, however this week I focused on completing it and now I have a fully working butterfly with very basic AI. I am using blueprints in this case to simulate AI, rather than using actual Unreal Engine AI systems. The whole idea is inspired by a butterfly that I found within the blueprints example of UE4. I made the whole thing from scratch however and also included a little addition. I wanted the butterfly to keep a distance from the player, as it would feel more realistic (anyone who tried to catch a butterfly before knows how hard it is to get close enough to a butterfly**) Everything works like a charm. The butterfly finds a random target to fly towards every few seconds and if something is within his range then it will land on it for a few seconds. If you get close to the butterfly it will quickly fly up high into the air and out of the player's reach. The model itself for the butterfly was made by Mark and it looks absolutely stunning!

Next up I am also planning on implementing a bird, which will work the same way. However, for that I would need a fully rigged bird with animations, as it would look weird if I have the wings of the bird flap in the same way as I have for the butterfly.

Additions Part 2: Collectibles

Finally, I have sat down and created a quick blueprint for collectibles. It's a fully dynamic blueprint, in which you can choose a static mesh and it will make it look and work like a collectible. I made the mesh glow slightly and added some sparkling particle effects around it. The object is then rotating slowly and bopping up and down slightly in the air. Looks quite awesome!

Plans for next week:

For the upcoming week I am looking into further thinking about puzzles and trying to implement some more things into our level. I will also probably look back at the maze that we have in our level as we are currently working on changing quite a bit of it. Also if I will find some time I want to try and do some more arty stuff. After all, I am studying Game Art Design :)

Stay tuned~

**- And yes, I have actually tried to catch a butterfly..(during a volunteering session I did as part of my job at McDonald's) and I succeeded:

Week 22: A Quick Week

Progress on the Project

Aaaaand woosh! Another week has passed. I feel like it wrote my last blog post just yesterday. Our level is progressing along nicely and we are slowly filling in the missing gaps with more and more assets. I was focussing on completing the fountain puzzle this week by implementing the checkpoint system. You can now return up onto the middle platform of the fountain once you've reached that point in case you ever fall down, which will make it a lot easier for people to complete the puzzle without getting too frustrated about it.

Another new addition this week was UMG. The Unreal Motion Graphics UI Designer is a great tool within UE4, that can help the user create a working UI without too much hassle. I used it to create text's within our level that notify the player of when he reached the checkpoint. It will also outline the key the player needs to press in order to return to the checkpoint once they fall down. In addition to that I also ported over my old HUD, which I used for switching between the worlds, since it was much less complex this way.

UMG UI Designer

I did encounter one problem while using UMG and that was the fact that, although you could have a tick event within a UMG widget, you couldn't run more than 1 line of nodes at the same time. Sequences didn't work and neither did custom events. In the end I had to resort to creating a single UMG widget for every bit of text that I wanted to appear on screen. Maybe not the best solution, but still a lot less complex than my previous HUD.

Apart from that not much has happened unfortunately. The week went by so fast that I didn't get around to doing a lot of other things. I did mess around with the water a bit and came up with yet another water shader, which I am quite pleased with, however there is a slight problem, since it is practically invisible when viewed from below the surface, meaning that once you enter the water the water surface disappears, leaving you feeling like you're floating or something. So far I have failed to find a work around for that...

Next Week:

Looking ahead I am starting on the next puzzle now, which I will focus on during the next week. Currently we are planning on having a puzzle within the tea party area. This will require the player to set the table by picking up objects and bringing them to the table within a certain time limit. So far I have touched this briefly, by creating a particle effect for fireflies, since our tea party area (within the other dimension) is quite dark and I found that you could barely make out anything on the table. I also have previously worked on creating the possibility for players to pick up physics items and carry them, which will take away a lot of the scripting that I need for this puzzle.

Glowing insects? Awesome!

I will aim to get the puzzle done by the end of the week. Stay tuned~

Oh and yeah, Unreal Engine 4.7 has been released and it's amazing! ( https://www.unrealengine.com/blog/unreal-engine-47-released )  We previously had some problems with foliage shading within unreal, but that problem has finally been fixed and the foliage is looking better than ever! Yaaaay!!

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: 

Week 17: From Engine Polish and FPS Problems

Slow Progress - Container Walls

This week just felt like I managed to accomplish nothing at all, however looking back at it, I must admit that I did actually get quite a few things done. It's just not as obvious as it usually is. I left of last week with a change in idea and how I assembled the level and lit it up with torches. The main problem I encountered was an FPS issue at this point, which in return would take me a long time to fix. While it was mainly the PC that was the problem, I wanted the level to run smoothly even on weaker machines, so I decided to take some time and optimise my torches so that they would create less FPS-lag. I started by looking into the particles itself and trying to mess around with the settings so that it would spawn less particles (even though I only had quite a few to begin with), but at the same time making sure it still looks the same. Not much changed after quite a bit of messing around. I only got a very small boost in the FPS.

I then decided to step back and work on materials. A member of my group was supplying me with textures for the walls and it was my job to put them into engine and create the materials. I wanted to make sure, that the materials were customisable, to enable us to mess around with them and do quick changes as necessary. One example for this was that we wanted for the rust on the wall to be optional, so I used Linear Interpolates to blend textures together. In the end we decided to not use this feature though, as a level with rust all around seemed to give off a much better feel. We went through quite a lot of work in getting the rust to look believable, which was a lot harder than we first imagined. One of our first tries resulted in this:

Rusty Container Wall - Take 1.

As you can see the rust just looked a little out of place, which we later found out was caused by the fact that the rest of the wall was just too clean. Our original plan was to just have some walls with rust and some without, but in the end it just looked better with rust all around. We also decided that while it was nice to be able to customise the colour within my wall material, it created quite a few problems with certain colours just not looking great at all, so in the end we just stuck to making the walls white, with a slight greyish tone. We also added a lot of dirt to them, to make them look more worn off. In the end we came to this:

Final Rusty Container Wall.

Wall Texture.

... which I was quite happy with. We encountered a slight problem with seams appearing on certain parts of the texture, but we solved this by creating a patch of dirt and using it as a decal to cover up the seams, which worked like a charm. In the picture above you can also see the ground texture, which was also created by my group member. For the ceiling we decided to use the same material as the walls, as container ceilings usually have the same metal walls on the ceiling, too.

Solving the FPS Issue

Or at least finding a work around... I took quite some time this week on trying to get the level to run smoothly. I tried even creating LODs for the particles on my torches, which on the faster PCs boosted the FPS from 40 to 60 on a scene, however on other PCs the FPS were still just under 10. So in the end after trying nearly everything I decided to get rid of the lights that were being emitted by the particles and instead put a point light into the torch blueprint. I then used the blueprints timeline function to give the light a dynamic intensity and radius to create the torch flickering effect. In the end it didn't look as pretty as it did before, but at least now the FPS were at a more acceptable 24 instead of 9.

Torch Blueprint (Dynamic Light)

Here is also a picture of the final torch:

Torch.

I decided to end the tweaking at this stage though and will now focus on putting in all the assets into the scene. My group members have been hard at work over the past week and all the assets are finally done (I even managed to do a few myself!), however they still need to be unwrapped and textured, which is what we as a group will focus on for the upcoming week. Hopefully, we will be able to get everything done though, since most of the scripting and tweaking within the engine is pretty much done, thanks to my efforts from this week. This should save us some time and once the textures are done we just need to put them into the engine and everything should work just fine. Since there is a bit of confusion as to when our hand-in actually is, we are aiming to complete this project by Friday (instead of Monday), so hopefully in the next post I will be able to show off the rest of the level itself.

Stay tuned~