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~