Sunday, 30 August 2020

Learning Agreement

 L E A R N I N G    A G R E E M E N T

Project Proposal                      

Name

Vernon Wroe

MA Course

Games Design

Date

30/08/20

Version Number

1

Project Title / Research Question

Wind Waker Demake

Proposed study / What?                                                                                                          (100 word limit)

For this semesters project I’m going to attempt to “demake” The Legend of Zelda Wind Waker. By demaking, I aim recreate a portion of the game but at a greatly reduced level of visual quality akin to a previous generation of gaming[1]. This will involve using assets from the game and altering them to fit and scripting everything to make it playable.

Rationale / Why?                                                                                                                    (100 word limit)

This time, instead of remastering or remaking, I want to see if the same can be done when a game is demade. Compared to my previous projects its in the same group games, albeit demakes are still fairly new and are mostly fan re-imaginings.

I chose this particular game for two reasons; one it has already received a HD remaster and would a demake be just as good? Secondly, because of a demade trailer[2] for Breath of the Wild 2, which many fans loved.

Aim & Objectives                                                                                                                   (200 word limit)

For this project I aim to re-create what makes this particular Zelda game special, in the aesthetic / for the generation of the Nintendo 64. Mainly because regardless of is visual quality, the two games in the franchise released for this console are regarded as the best in the series if not the one of the best ever created.

In order to achieve this, a lot of research and planning will need to be done prior to any building. Demakes are new territory with less than a handful[3] of official ones on the market. So I will need to plan what I want to make, and also ensure that I have the means to accomplish such task, as most assets will be sourced externally this time. Also, research into how the games I want to emulate play and work is essential to.

Plan / How?                                                                                                                            (250 word limit)

Some of the times listed below will be carried out at the same time as other tasks, as the overall timescale can't exceed 4 months. That and many aspects are constantly under review to ensure they're the best I can deliver.

  • Determine what area to make (1 WEEK)
    • First Island
  • Any additional areas? (+1 DAY)
    • House Interiors
  • Research the technical capabilities of the Nintendo 64 (3-4 WEEKS)
    • Determine it’s specs
    • Resolution
    • texture sizing / colours
    • Research best way to replicate this in Unity
    • Try Open-Source PSX Renderer (Playstation-Style Graphics plugin)
    • Setting up a project to use gathered information
  • Researching how to collate assets from Wind Waker (4 WEEKS+)
    • Get plugins working
    • Combine and test in a new project
  • Research Zelda Ocarina of Time (1 DAY)
    • Look at gameplay, effects, rendering etc
  • Research Wind Waker HD (1 DAY)
    • List all assets required, effects etc
  • Begin creating engine (3 MONTHS+)
    • Gather all required assets and import
    • Create all levels / interiors needed
    • Implement more advance mechanics
      • Add visual effects to suit
    • Play test
    • Bug tracking and fixing
  • Record work (2 DAYS)
    • Combine it all in Premiere
  • Done!

Intended Outcomes of Project / What - solution?                                                                     (100 word limit)

I hope that through my work anyone can see that with just a bit of quality and skill, it isn’t too hard to achieve results. It does not matter what game it is, or what style of remake is being aimed for. If the goal is to re-create a game, then it should be done faithfully and to the best standard.

This project should also nicely compliment my previous work(s) and round them all up, offering a look into different styles of remakes.

 

References                                                                                                                           

[1] tvtropes.org. (2020, 06 31). Video Game Demake. Retrieved 15 04, 2020, from TV Tropes: https://tvtropes.org/pmwiki/pmwiki.php/Main/VideoGameDemake

[2] Youtube.com. (2020, 01 1). The Legend of Zelda: Breath of the Wild 64 Sequel – Nintendo E3 1999. Retrieved 15 04, 2020, from YouTube: https://youtu.be/8KTvjRe5vyA

[3] Destructiod.com. (2020, 08 30). Demakes. Retrieved 15 04, 2020, from Destructiod: https://www.destructoid.com/?t=Demakes

 

Saturday, 29 August 2020

Conclusion

Now that the project is over I can discuss aspects of it in more detail. As the project has gone on I tried to keep my blog updated, but during the pandemic I was merely doing a lot of testing. Until I was 100% sure I was able to use assets from Wind Waker (WW) and get them to work properly in Unity, so there wasn't a lot to talk about.

Admittedly I did somewhat forget about the project near the end of lockdown, I hadn't seen my immediate family in nearly 5 months, so I ended up having them over for well over a month. So as you could imagine, little to no work got done during this period!

When I got back into it though, I really got stuck in. I went from a tech demo to a fully playable project in about 2 weeks. This was possible because I'd already done any testing I needed, so I knew models would work and because of the work on my 2 previous projects, my skills were up to date and I had scripts I could migrate over to smooth the process.

Initially though, testing was not a fun process. I detailed a walkthrough further into the blog that goes through the process of extracting WW models and getting them to work nicely in Unity. This was a long process to nail down, the guide looks simple now but in reality, it took months. In fact, I vividly remember testing with the red post box, this took weeks! At first it wouldn’t extract, then when it did, its textures were missing, then its mapping coordinates were always obscured, then animations would break it even further and then scaling became an issue, until finally I got it working.

That was just the post box, Link had many more issues of his own. For example, his rig I had to export him many times and the plugin would mess up his bone structure randomly, so when i got him working then next time i exported him he was broke again. I had to manually re-rig him in Unity every time, until I found out I can just copy this Unity rig to each following import of him.

Link's Movement

After that, the next major issue was translating his animations from WW and getting them to work with the movement system I had set up. I did manage to get him walking and running, though anything else he would just refuse.

I did finally manage to export all the animations I would need for my vertical slice and after a lot of tweaking got them working with his movements. Turns out most of his animations needed specific tweaking to ensure they lined up correctly. But still his movement is not 100% I would have liked to make him feel just that bit more fluid, I think my biggest gripe is his jumping. He uses rays to detect ledges, but these are not very accurate, or at least they’re not for me, as Link won’t always jump, in fact he can fall off a little ledge and take damage (which is infuriating).

Also, to save time I had to weigh my options in regards to his overall interact-ability. For example, I set up Links entire movement system, but because he has multiple states there is much more than what I made, this is his movement system currently:

 


There should be at least another one like this because his movement and actions are slightly different for when he has his sword drawn. Switching between the two depending on context. It is at this point I decided to have more quality that implementing unneeded aspects. To get around this I attached his sword to his body and simply enabled its visual render when the player attacks. It is simple but effective.

Area Transitions

So, that was just Link and his movement. Another interesting obstacle I came across was interiors and area transitions. I had never done anything like this, connecting other scenes to a central hub so to speak. I had no idea how to code it or how its typically done.

I approached the idea using mini-cutscenes in the follow way; each time the player is in a trigger zone by a door and uses the interact button, it loads the attached timeline (cutscene) and plays it. Because of the work on his movement previously I made sure he had no root motion, so that means when I move him in cutscenes he actually moves and stays / continues from any movement.

So, with that in mind, each door is a cutscene. I found his open / close door animation, I trigger this and add a fade on each end to make it look much more cinematic. The logic behind this though is a bit more complex, I scripted a means to determine where Link has come from, where he is going and what should be loaded.

To do this, when the door is interacted with I run a specific routine, so for this example I will load the first house interior:

 


This tells my script to load said level and sets a variable to remember the current scene before the new one is loaded. It then loads the interior House A, which because it’s an enclosed area has its own cutscene upon loading. Now when exiting and returning back to the main island / hub my script detects this. Because it’s an important object I make it persistent throughout the game, so once it’s loaded it will never be deleted, even upon entering the same hub where its first initialised.

Anyway, every time the main island scene is loaded this runs automatically:

 


So, this checks that Link is returning the "Outset" (which is the name of the island) and if he is, it checks the variable mentioned previously to see what interior he's currently in. Because we know he travelled to "House A" you can see in the code above it notices this. So its checking that the level being loaded is in fact "Outset", if it is, what level did we just come from? If it's "HouseA", it finds a cutscene I made of Link opening a door back into Outset and then plays it immediately.

Now usually when reloading the same level, the player will always respawn where he is set in the level. But because I'm searching for a cutscene every time this scene is loaded, it plays said cutscene at the location I set it. So for House A, I placed this cutscene outside the hut, so when the code catches this event, it places him there so it appears as if he came back, when in fact it’s just re-loaded the level as if it was freshly loaded at the beginning of the game!

It may seem like a lot to take in, but this was the only way I could think of achieving this and it works and looks great too!

Grass / Breakables

This again was another aspect that caused me issues, but I managed to overcome. When I was testing enemies, I had a script to govern them, it allows me to control their health, spawn stuff and effect Link in a number of ways.

I realised that grass and pots were a type of enemy. They might be static, but they can be "destroyed" in a similar way, ultimately removing them from the world. So, I figured I would place all the grass in the level using a prefab, so that I can modify them all at once with ease. I placed around 400+ grass objects into my scene, all running this enemy code, I did not anticipate how un-optimised it would be. Playing the project caused my computer to lag for half an hour before I could return to editor (I had not saved and didn’t want to lose all my hard work).

The overall framerate for the project went from 100+ to 1 to 2, sometimes 5 depending on the camera angle!

Because cutting grass is a pivotable aspect of any Zelda game it was crucial I got it working. I ended up removing it for a few days because it was too unpractical to use, I even searched online for methods of instancing objects to reduce draw calls.

It then dawned on me... Because the grass prefabs are spaced all over the island, they don’t need to be constantly checking the player. With over 400 grass objects all simultaneously checking the player for input it was bound to make the project run slow. I fixed this by adding a distance check between the two for every object instead, just 3 lines of code improved my framerate massively:

 


So instead of checking the full enemy code many times a frame for each individual object it now checks the players distance to itself once a frame for every single grass piece, which is much more efficient. So, when the player is about 5 feet away, they then enable themselves to be interacted with and voila! Massive speed increase and I got to keep one of the most important elements to the game.

Sounds

I discussed this a few posts back, but I'd like to reiterate. Without them the project was bland, I cannot believe how much of an impact they make on the project. Even little things such as footsteps or the slicing of trees. Nintendo know this, that is why they put emphasis on sound through gameplay. In WW, they have chimed attack sounds for fighting enemies, the tone changes to create a melody every time Link attacks. Same for Mario in the New Mario Bros games; enemies and props dance in rhythm to the music!

I would have liked to include this but I did not have enemies so it would have been redundant.

Sounds however are something I will endeavour to include straight away in future projects instead of trying to retrofit them in later. As sound design is just as an important element as anything else in a game.

Improvements

I think the only think I'm sad about not getting chance to implement is a more dynamic interaction system. One where I could set contextual parameters such as: camera positions, player / NPC animations, sounds or even give items mid-conversation, all per message / dialogue box. It would have taken too long and not really required for this small vertical slice, but would had looked really nice.

Conclusion

So those above were just a few of the issues I encountered, they were probably the biggest though. I have learnt a lot throughout each of my projects for this course. I've learnt how to prioritise workload, not to create too ambitious milestones, coding efficiency and so much more. All of which I will continue to use in future projects.

I like to think that my work does highlight the issues of remakes and remasters in the industry. How I've managed to create 3 - albeit small - games to a pretty reasonable standard in such a small amount of time on my own. Then why are other studios, not putting as much effort into theirs with much larger teams.

If anything, I'm even more spurred on to create a fully functional game of my own. Not a remake or remaster, but something I can pour all that I have learnt into and call my own!

I hope that anyone who encounters my work will appreciate what I have done and that I inspire others to realise and act on the subject I highlighted:


How are Remasters / Remakes Effecting the Industry?


Video Submission







Friday, 28 August 2020

Finished

 


It's been a tough project, but it's finally done. I hadn't spent as much time on it as I'd have liked, but I'm very happy with how it's turned out.

De-modelling

Ages ago I had de-modelled Link for use in this project. I even wrote a whole blog post on how the process went. Sadly I came to import him today and his rig is completely off, bone weights were incorrect (even after loading two side by side views to ensure they match).
So I've had to again demake him, although this time before doign too much work I tested him in-game...


As you can see, he works! He's using the same rig again and so immediately works with all the animations again and can be up and running really quickly once done.

I've reduced the polycount drastically already. It may be hard to see but if you look at blue Link's hair it's no where near as smooth as the textured Link. I've removed hundreds of unused polys from his hair alone! His hands too, hands are one of the more complex aspects to model, here is the result of my de-construction.



As you can see theres a big difference. Even more so, if you compare the original to the N64 model:

Theres still quite a difference between my demake and the N64, but compared to the original, its much closer to what I wanted to achieve. Now to finish the rest of the model.


Thursday, 27 August 2020

Sounds

I'm currently adding sounds into the project. For some reason I always overlook the importance of sounds. I thought the project looked great as is, but adding sounds just adds a whole new dimension!

I have zero skill at creatin sound effects, so I'm using original sounds. But...
For music I'm using fan-made midi versions of all the music found in the game! The level of quality is clear, compared to a orchestrated soundtrack that is. These midi files retain their qualities but because of the downgrade they fit in quite well.

They can all be found here: https://www.khinsider.com/midi/gamecube/zelda-the-wind-waker (Thanks to whoever created them).

Wednesday, 26 August 2020

Possible Further Tool Improvements

I was thinking on how I would like to further improve my project, I mean, if I were to expand on it or even make it into my own game that is.

Since my Silent Hill project I created a means to interact with anything in the environment. This was essential for that project and it turned out essential for Windwaker too. I made it so I can easily expand upon it and because it has a custom editor inspector I could make these changes even easier to use. The effort I put into creating it was well worth it.

I do think though that it does need improving, as each project has had different needs.

For Windwaker I would like to add animation triggers for conversations mostly. Because, in the original game an NPC has different states, they typically go from an idle state to a talking loop. But, during conversations they trigger different movements to portray their dialogue better. Even for Link too, sometimes he will change his expression in relation to the NPC.

At the moment for NPCs I can set any amount of messages for the player to cycle through. I would add an individual check before displaying any new message that can trigger a new animation loop.

This would give a bit more diversity, but may be too much for now. Mainly because if I were to add it I would also need to add additional features to fully flesh it out, such as:

  • Camera placeholders for NPC & Link
  • Sound Triggers
  • Question Boxes
  • Conversation interrupting / resuming (giving the player an item)
  • Multiple-Alternative conversations (Some NPCs change dialogue on repeat interaction

So yea, this would be nice. If I get time I may implement a crude version, if anything just to add sounds.