Blog Moved!

Blog moved to: http://dmathuse.wix.com/blog

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~