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.

Tuesday, 25 August 2020

Effects and Polish

Nearing the end of the project I'm now adding final touches like environment effects, sounds, tweaking gameplay and cleaning up any code.

Code

While doing the latter, I've managed to actually increase the fps! It's mainly due to the grass; theres around 400 individually placed grass objects. Each with an enemy script for how they interact with the player i.e. cutting. So because some 400 peices are constanly checking if they've been cut or not it bogs down the game quite a lot, I think it goes from 90+ fps to nearly 40 fps, which is a huge drop.
I had an idea though, because the grass deosn't need to check their status until the player is right within their vacinity, I added another code to check exactly this and enable / disable if close enough, lo and behold it works!
The game is more that 60fps again, its still a bit slower due to the sheer amount of grass objects, but its instantly better.


The code is insanely easy, no more than 3 lines. I guess 400 objects checking their distance to the player once a frame is much more efficient than 400 objects checking their behaviour state many times a frame.

Also I added in the random Rupee code I discussed in a previous post, seeing how the grass is working in game, figured might aswell clean its code up and add random chance to spawn one.


They now have a 1/10 chance to spawn, which feels about right.

Effects

I've also been working on implementing effects throughout, such as wind streaks, waves, clouds etc.

In this scene you can see all of the previously mentioned working in tandem. 
The waves and clouds are both particle emitters and both replicate how they look in Windwaker. The wind streaks were a bit trickier, these are actually line renderers. I initially modelled the wind and animated the texture to scroll through, giving the effect it's moving. Though when I spawned them, the material was shared, so they all scrolled at the same time which looked aweful.
After many hours I asked a friend his opinion and he coded a small script creating the same effect using maths, which is beyond my skill set.

User Interface


The interface is pretty much complete. Hearts, Rupees and Swim Gauge all work. The button text is next, I simply need to change these at runtime depending on current situation and is easy enough. 

Hardest aspect was the Swim Gauge. It has many things going on, for example when the player enters water it gradually depletes, there's also a sheen that flashes over it. Then to top it off, it needs to be reset upon entering the water.
Most of this was achieved via masks, the gauge drain was done with a square mask, its pivot set at the bottom and it's height reduced over time.
It does have two more effects, which I havn't included because I don't think they're warranted and would look quite complex and out of place for the demake. These were a particle emitter firing off little spheres above it and then the whole globe would flash red nearer to death (I may include this yet).

Sounds

The final aspect of this project is the inclusion of sounds. I wish I had done this as and when I needed them, but it doesn't matter. 
A nice and easy way to fire specific sounds I found is using animation events. These are little triggers I can attach to any animation frame, which then tells a script to do a particular function.


If you look at the timeline above, near the 0:17 mark you can see I've added an event to trigger "Swim", which is as he does a breast stroke. I then have a sound manager script I made and added it to the player, which solely waits for these events, which can trigger from any animation:


Other sounds are easy enough and can be place on prefebs and triggered when needed.

Finishing Up

Once these are done the rest are just little tweaks! It's pretty much complete as is (minus sounds). I may see what else I can add in the mean time.

Sunday, 23 August 2020

Creating and transforming an Interior

As part of the playable vertical slice, all the huts on the island have interiors. Most have nothing special in them and are just for exploring. But to keep in theme with demaking, here is the process.

To begin, I use exactly the same method I do for any 3D assets. Stages / interiors are just one large model anyway, so I find an interior I need, convert it to a readable format and put it in-game:

The stage has correct UV mapping after extracting so that's a big relief. It's missing materials though, so next I'll go through all the textures and re-assign them all.

These scene is much more vibrant now. The textures are pretty crisp too... Unity by defualt imports any texture at a resolution of 2k, originally these textures are around 128x128 or lower, which is a huge difference. So I manually go through and change them all to something similar to 32x32 or lower, because this was the maximum size for most N64 textures.

Next I make the level playable by removing any collision information for the model and then whiteboxing it myself:

The scene is now playable! Now to remove the collision boxes renderer so they dont display but still retain their bounding boxes and then I'll add some props / entities to bring it alive a bit more.

Now the scene looks ready; it has things to interact with, collisions, props, skybox etc. Now because of the collision boxed I placed before the camera also works within this environment.

But, as I discussed during some of my design research, some interiors from the N64 Zelda's are static, meaning the player has no control over the camera in the scene. To accomdate this and because I have numerous interiors, I've allowed free camera movement in most and some I've placed static cameras.

For this interior in particular, because it isn't too complex I've given it a static camera, right in front of the door against the wall. I've also replicated how these static cameras work, so instead of moving, the camera will just look at the player.

Whilst implementing this I came across a bug, so I had to add code to fix it.

When starting a conversation I disable all camera and player input, after the conversation I re-enable these. Because the new static cams are the same as the normal cameras, just with their logic disabled, when a conversation is ended it re-enables this script, making any static scenes freely-moveable!

To fix it, I added a bool check to the end conversation routine:

if (cs.moveCam) { cam.enabled = true; }

I then added an inspector element to make it quicker to toggle this for any current and future NPC's dialogue.

For this particular instance though this should be set to False!

The final result:

The only thing I wish I had time more time to do would be to remodel aspects of the interiors. But... as is after analysis most of these models are close or fall withing N64 polycounts, which means originally Windwaker could have effectively been released on the N64 if some limitations were included such as fewer effects and less open-world style gameplay!

To-Do

As I near the end of my project, I've summed up the last few things to tackle:
  • Add Aryll
  • Add Seagulls / Crabs
  • Fix Wind Spawner
  • Decide what to do with Rope Bridge
    • Maybe Add Woods
  • Remodel Outset for better collisions
    • Maybe Add Link's House Basement
  • Rig Demade Link and import into project
  • Add UI buttons (A for interactions and B to attack)
  • Add Links Sword
  • Try get swimming working
  • Add Sounds to stuff!
  • Create Title Screen
I've done the majority of the project. At the begining of the holidays I got a head start with prototyping stuff and I've also been able to re-purpose stuff I've made for both Silent Hill and Rush 2049, such as scripts.
However, due to circumstances and family, I missed a huge chunk of time, weeks even. So I won't get as far as I hoped. But I'm still on track to meet my initial goals. Would have been nice to add a second island and sailing.

Interactivity


Zelda games are well-known for their smaller interactions within the environment. Being able to cut grass, chop tress and even smash pots!

Over the last couple of days I've been trying to nail down these mechanics as best as I can. So far I've got trees working, I've got grass working to a degree (my method causes a drastic fps drop simply because I've placed over 500 grass objects as theres no simple way to go about this). And now, I've got pots working too.

All of these objects share the same mechanic, in that they are essentially "enemies". As such, I've coded a means to allow interaction between them and the player based on a simple AI code provided with the engine.

In the inspector on the right I've scripted on to the existing code to allow for item spawns! This is independant too for each object. so I can set whether or not its able to spawn anything upon death and also attach any prefab I want to spawn at said time.

My code checks when the enemy is dead, if its not allowed to respawn (pots and trees cannot), it then checks to see what type of "enemy" has been destroyed. It's not exactly clear in the code, but trees in the game have a rigidbody, which alows them to topple over, where as pots are static and dont move.

So checking which is which on death the spawns and obect set in the inspector if allowed and if its a tree will add physical force to simulate a sort of jump.

You can also see a check that tells the game to spawn an item set in the inspector if its allowed to. This would work with anything, but ideally it needs to be something that can be picked up otherwise everytime an enemy is destroyed any object instantiated would just clutter the game.

So for now, I made a few Rupee prefabs, that in turn have a check I scripted to allow for them to be either statically placed or if spawned, spring upwards like they do in the game.

By default, the bool spawn is true, so that when its instantiated via the enemy death it will automatically bounce upwards. When manually placing these all I need to do it disable spawn, and then it will behave exactly as it should in the world.

So together, these provide the basis in which objects can be interacted with in game. And is easily expandable, seeing as any prefab can be spawned.

I was dabbling in random ranges as in the games it usually is by chance when a object is spawned, but for the purposes of this project it's not entirely needed. I may add it for grass, because manually setting over 500 grass objects to spawn or not spawn anything will be very tiresome.

In the enemy script it would look something like this:

int rnd = UnityEngine.Random.Range(1, 3);
if (rnd == 3 && spawnPickup)
    {
    Instantiate(spawnItem, transform.position, transform.rotation);
    }


This would give each object a 1 in 3 chance of spawning an item. I could go even further and have mutliple spawn items to choose from. So the code would reflect this:

int rnd = UnityEngine.Random.Range(1, 3);
if (rnd == 3 && spawnPickup)
    {
    int rndnew = UnityEngine.Random.Range(1, 3)

        switch (rndnew)
        {
            case 1:
            Instantiate(spawnItemA, transform.position, transform.rotation); break;
            case 2:
            Instantiate(spawnItemB, transform.position, transform.rotation); break;
            case 3:
            Instantiate(spawnItemC, transform.position, transform.rotation); break;
        }
    }

It might not be the best way to script it, but it would work and could be expanded to add a new pickup everytime a new one was created.

Saturday, 22 August 2020

Chop Chop

Whilst finalising little bits here and there, I decided to try implementing cutting!

I wasn't going to include anything like this, simply due to lacking the assets to do so. But now it's in I'm glad, makes the overall experience feel fuller.

Friday, 21 August 2020

From GameCube to Unity Workflow (EXTRA)

(Read previous post first) Continuing on from my previous post about the process of extracting models from the GameCube to Unity, there is one more piece of additional information / process which I stumbled onto today.

Whilst exploring .arc files in the extracted game directory, I found that some of these files are completely broke or corrupted. Extracting them returns null folders / files, some of which are crucial.

In my case I was missing three types of foliage; bushes, trees and grass... These are pivotable in re-creating the overall feel of Outset Island.

After doing some research, I stumbled upon a couple of users with the same issue. In this thread, the user explains they believe they have found the .arc file containing various foliage. The use states that "Kusa.arc" translates to grass in Japanese, as with most .arc files here its safe to assume they are given Japanese names. The only downside is, this particular file is one of the few that is broke. I even ripped my own copy of the game (in my previous post I stated how I just downloaded a copy instead) to see if that would work, to no avail.

So it would seem this particular file is inaccessible with the current tools available...

At this point I realised I can use the same method I used for my Rush 2049 Remake. For Rush I used a set of tools used primarily for "ripping", these are used by modders and 3D printing hobbyists. These tools work by capturing all 3D and texture information currently on screen and exports them as a scene for 3D modelling software. I won't go into too much detail as the last link (method) goes through this in more detail.

Basically, I was able to capture a sceen in-game with all the foliage I needed:

After I cleaned them up a bit, they now look great. Originally all their normals were inverted, so they wouldn't render correctly. So I edited them and exported them for Unity.

Similar to the treasure chest in my previous post, the textures were off, so fixing these and rescaling the end result is pretty satisfactory:


From GameCube to Unity Workflow

The process of getting 3D assets from their source is rather long and pretty tedious (well at first it is). Even having gone through the process many times, its still confusing and doesn't always work.

To begin with, the original game needs to be extracted. Because I already own the game I downloaded and iso version just to make it quicker. Now with an iso of the game, its time to use an emulator, in this case I used Dolphin. Through Dolphin there is an option to "dump" the contents of the game, this is because the iso / files contained within are encrypted, dumping them allows them to be read in their source format.

Now with a dumped version of WindWaker, it is now possible to browse the files and locate what is needed.

For my particular uses, the "res" folder contains most of the assets needed. In this location there are sub-directories for stages, props and other misc assets. Browsing to just the objects is where all the 3D models can be found.

First couple of things to note here are, one: these are all "ARC" files and two: none of the filenames indicate what they contain / or are not English.

After some research I found out that these arc files are useable (thanks to the modding community), through a set of tools I can essentially browse through and see what is what. But this part is the most tedious, because again none / most are not English and another problem is that some wont work or are corrupted.

So, to begin, I will grab an arc file, in this case I shall use "Dalways.arc" (I have no idea what it is).

With this file, I've placed it with the tools needed to extract it, to make it easier for now.

To extract it or any other model, it needs to be dropped on "rarcdump.exe". Doing so will decompress it into it's original folders (very much like a zip file). Though for some unknown reason, this specific arc file will not decompress. This is because some individual arc files have additional encryption on them, as such they need to be dropped on "yaz0dec.exe" first to remove this lock, creating a new version of the arc file "Dalways.arc 0.rarc".

Now with this new un-encrypted arc file, it can now be dropped on "rarcdump.exe" to extract it.

Now with the new folder we can explore its contents!

Still the process isn't over!

This directory now contains all the information such as textures, materials, animations and 3D models needed.

  • bck = animation information
  • bldi = 3D model
  • bldm = 3D model
  • brk = unknown
  • btk = material animation
  • dbz = unknown
  • <extra>bti = textures
Thankfully there a couple of model viewers created for exploring these files!
So going into "bldm" and loading the file "boxd.bdl" (bdl is Nintendo's native 3D export file extension) with said viewer I am now able to see exactly what this entire arc file consists of.


So, it turns out "Dalways.arc" is in fact where the games treasure chests are located. In the same "bldm" folder and even "bldi" there are other chests and variations too. In addition to this, if I go to the root folder and look in the "bck" folder, there are animations that can be used. If I drop one of these into the viewer with the model loaded, it will now show what it does:


Now that I've established what this file is, that is has variations and even animations I can now move onto converting this into something native for windows, that in turn I can use in Unity.

To do this, there are three methods, each with pros and cons:
  1. The first is another model viewer named bmdview2, its much more basic than the one used above. But it does offer the option to export any loaded model and textures. Whilst this is the quickest method of exporting it does have one big downside; animations. It will not display or export them.
  2. The next option is Blender. a user has created a plugin named Blemd, based on the extraction tools used earlier (yaz0dec and rarcdump). This allows Blender to import the model file with textures and animations which then can be exported at a standard fbx. The downside to this method, is that it will just completely refuse to import on certain models causing Blender to softlock.
  3. The final method is similar to the previous one, this time we can use 3DS MAX and a similar tool named MaxBMD. Works exactly the same as Blender, this one has the same issue with softlocking, but will sometimes open ones Blender crashes on and vice versa. Both allow for animations to be imported alongside any rigging / bone information to be added.
In this case I shall use 3DS MAX. Running the plugin allows me to browse to where I extracted the "Dalways.arc", I browse to the bldm folder and open "boxd.bdl".


Once I press Import, the plugin now creates a new directory where the bdl file was. In here the plugin stores a save of the scene, the exported textures and the converted animations.
Now that it's finished the scene is loaded, the model is present and textured. A Character modifier is applied which allows any of the saved animations to be imported onto it.


Simply browsing to the new directory the plugin made (\Dalways.arc 0.rarc_dir\archive\bdlm\boxd\Animations) and selecting any will present a window to allow it to be applied to the model.

Its best to note that Max and Blender approach this differently. Blender will batch apply any and all animations in the adjacent "bck" folder and when exported can reduce the amount of files. Max on the other hand only allows for one animation per model, importing more or trying to append more will result in errors and / or a softlock. But from my experience, Max's import method is more accurate with its animations...

Now the model has been imported and it's animation applied, its now ready for export and fir use in Unity! A simple File > Export > FBX will suffice.

Now we have a Chest asset in a native windows format, one that can be read by any 3D application as fbx is the standard for 3D assets.


Once the chest has been imported into Unity, its ready for tweaking. It has lost it's material information, this is due to no textures being imported. So quickly browsing to where the MaxBMD plugin exported the textures and animations I can easy drag these into Unity.


Now that the texture is in Unity, the model has now automatically applied it to itself. Depending on the model it may look fine, but usually this needs editing. The texture's properties are more often than not usually incorrect too.
WindWaker uses a lot of mirrored textures (see the MaxBMD importer screenshot, 4 images above) to save on storage space, so when imported to Unity the textures will look out of place:


This happens because Unity automatically sets any imported texture's wrap mode to "Repeat", this is so that the texture will be tiled if stretched over a large area. But in this case we don't want it to. So changing the Wrap Mode to "Mirror" will fix the issue and display the texture as intended:


Finally, now the material / texture has been fixed, it's time to look at the animation.
On the Chest's inspector window, browsing to the animation tab will show it has one animation, the animation I manually imported in 3dsMax via the Character Assembly modifier.


As you can see, the animation is playing in the preview to the right. If you also look at the top of the preview is the animation name "boxopenbox". If I browse back to the original arc folder I decompressed, in the "bck" folder is said animation!

The final in-game result:


To conclude, the process is very long and tedious. I've mastered my own work flow to be as efficient as possible. But still, it takes a long time because none of the original files express what they contain. How does "Dalways" translate to "Chests"?

Given enough time, it would be possible to explore and catalogue all the files properly into a spreadsheet for easier browsing. At any rate, this is my process, maybe it will help some modders out in the future!