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~

Week 16: Change of Plans

Containers in the ground?

Plans do not always work out as intended and so did we encounter a slight problem with our original idea. Last week I introduced to you the new project that we are currently working on in groups of 4. Our original idea was to create our container city level underground inside a cave, however we quickly found out that this wouldn't be possible. The reason for that is that the brief states that the level has to be made out of containers, so while it technically would be possible to create our level the way we intended to, the style in which we planned on doing it just didn't work. We wanted our walls to be made out of bricks and/or stone, but why would anyone create stone walls inside a container?

So we decided to change our plans and while we are still keeping our level indoors, it is now located above the ground. After all, having containers buried in the ground or inside a cave just doesn't seem like a good idea either. We got rid of the whole crystal cave idea and our temple idea has been a lot more simplified. We will basically just keep to containers for the design of our level, but have some Aztec symbols spray painted onto the walls. The idea behind that is that after the apocalypse happened, a bunch of people brought back the original beliefs of the Aztecs and built themselves a base out of containers. The player will break into the base and has to get into the elevator which will lead him into the treasure room to steal the Aztec treasure. All of our other level elements are still in place (such as the key and the generator).

Getting some work done!

Unfortunately I didn't have much time to concentrate on concepts during this week. Instead I took on the task of creating the modular components that will make up most of the level. For that I started by taking our level floor plan and dividing the walls into panels. To do this I first thought about different sections and the different panels that I would need and sketched them on a paper. I then measured out the level and created another floor plan, showing all the component parts in their right places. I also drafted out my component sketches to make the whole thing a bit neater:

Modular Component Floor Plan

I then went into 3DS Max to create all of the required components. It was important at this stage, that the components had a seamless texture, so that I could put them together in any sort of way, without having seams all over the place. At the same time it was very important that the measurements were all correct, so I changed the units in 3DS Max to feet and fractional inches and changed the grid to show 1 inch at the time. I then used snapping to make sure all of the components would fit together perfectly. I also created a high poly version of the 10ft wall and baked it down into a normal map.

I was messing around quite a bit with the normal map and the low poly model until I had a decent looking wall and then used the same normal map on the rest of the components:

Modular Components with normal map.

Testing out the wall component in UE4.

I tested the wall in UE4 and created an instanced material that allows me to change the colours of the wall and border pattern very quickly and easily. After that I started assembling the level itself using my floor plan as a guide.

Once all the walls were in place we soon decided to do another change to the level. We wanted the area with the security room to be completely dark, so we thought that instead of having electrical lights, we could give the place some flame torches instead. The area with the security room would then have flame torches that had gone out and the player would have to go down to the locked generator room to pick up a flashlight. This meant, that the generator was only powering the elevator and we decided that it would be stupid to have it so far away, so I quickly redesigned the layout a bit to better suit our idea:

Modified floor plan.

Extending the stairs to go down 2 floors instead of 1.

Placing the generator directly under the elevator.

Scripting and Level Assembly

As you can see in the second screenshot, I also decided to get started with the blueprints we need for our level. I first created some simple torches, using particles for the flame and just a simple placeholder mesh, which I will change out later. The turned out pretty well and didn't take me much time to get ready. I then also created a blueprint for a door, complete with sounds and opening animation, as well as a variable which will check whether you have the key or not. I was going to do some work on the HUD to create the blueprint for the key, however I got asked to instead focus on creating assets so I went back into 3DS Max and created some very simple models for the ceiling and floor of the map.

I then completed assembling the level and placed torches all around the map to light it up. We then encountered a small problem with the player mesh getting lit up by the directional light, which we would need to create an outside area right at the start (with the entrance leading into the container complex). I solved this issue by creating a trigger around the indoor part of the level, which upon entering will turn off the directional light, leaving the torches to be the only light within the level. While I also scripted for the light to be turned back on when going back outside, we decided that once the player would enter the containers, we would look them inside by closing the door behind them.

Unfortunately after getting to this stage I was having some troubles with getting my level to run smoothly on the PCs that I was working on, which was most likely just because the PCs themselves were quite slow. (Our level itself is just made out of modular components, each having round about 150-200 tris and sharing a 512 texture sheet for the normal map, so I doubt the level itself is too resource demanding.)

Hopefully though I will get the level to run a bit smoother on a different PC and I will aim to get some screenshots up of the level as it currently is soon. Until then, stay tuned~

Week 15: Welcome to 2015!

Catching-Up

First of all I'd like to start by wishing everyone a happy new year at this point. Hope you all made it well into 2015 and are looking forward to another exciting 12 months. The Christmas holidays (which covered week 12,13 and 14) are over and we are back at work with a new project: Container City!

Group Work

Just like our first real project (The Film Room Project), our new project is a group project; and just like with our first group project we were first assigned to find ourselves within groups of 4. Not again... Why can't they just assign us groups?! Guess I'll just have to keep hoping. Luckily this time I quickly got a group together and I am quite happy with my group members as well. Enough of the whole group talk, let's get into more details on the project itself!

Drafting Floor Plans

The Container City Project is an environment project in which we design and create a playable level, which is made out of containers. Whether indoors or outdoors is completely up to us and we have been granted a lot of freedom. When we first sat together as a group we weren't quite sure how to approach this project so we started off by brainstorming a couple of interesting elements that we wanted our level to have. Since the brief stated that we had to have at least 1 interactive element in our level, we quickly came up with the idea of having the player taking an elevator to finish the level. However, the elevator was to be out of power and thus the player would first need to turn on a generator, which would be found inside a locked room. To open said room the player would need a key, which it would get by climbing through a slightly hidden vent into another locked room.

We then drafted a quick floor plan and decided that we should all do a couple of floor plans each. So I sat down and created 3 floor plans myself. I was careful to stick to the original container dimensions so that my floor plans would all be up to scale:

Plan 1

Plan 2

Plan 3

After each of us had created their floor plans we sat together and chose 1 floor plan from each person that we then had to create a basic block out of in 3D. To do this I sat down and created a set of building blocks which used the shipping container measurements that we had been provided with. When we then sat down to review those block outs, I had an idea of merging 2 of my other team members block outs together, with which the rest of my group agreed with:

Final Floor Plan

Having finished the floor plans I then took up the role of creating the final floor plan as a basic block out in 3D, which was easy since I used my team members' block outs as a base to work from.

Themes?

We then had one major problem left and that was deciding on a theme for our level. No playable level is appealing if it's made out of bland blocks, so we decided to brainstorm some ideas. We decided early on that our level was going to be underground, so we thought of possible things you could have underground. Like prisons, vaults, temples, etc. We then assigned a couple of those themes each between us and created moodboards. I had been assigned with "Prison" and "Laboratory" and soon went to research some pictures for my moodboards.

Laboratory Moodboard

Prison Moodboard

We then fed back on each others' moodboards and soon decided to make our theme an "excavation site based inside a temple that was discovered in a series of crystal caves."

Concepting!

The next step was to start coming up with some concepts. To do this we decided to use screenshots from our block out and sketch/photobash over them. We quickly discovered a problem however: How were we going to stick to our theme, but at the same time make the whole level out of containers?

So this is the stage we are currently stuck at and we are having another talk with the tutors tomorrow to see how we can resolve/work around this issue. I will update this blog next week and hopefully be able to show off some concepts so stay tuned~