Unity Zelda64 Game Engine

[SoulofDeity]

Instead of jumping right into the dirty work, I've wanted to play around a bit. Managed to create a fairly decent rain effect. A stillshot doesn't really do it justice; in game the splashes on the ground almost make it look like there's flowing water on the ground. I originally figured out how the effect worked from watching a tutorial on youtube, but the dingus who made the tutorial created the effect rotated 270 degrees on the x-axis so the cone-shape emitters would point upwards; this hack only works in preview mode so I had to spend the next hour or so tinkering with the velocity over lifetime and figuring out how to render the particle physics in world space.

 

The difficult thing now is trying to figure out how to render it so that it follows the camera.

 

 

 

 

 

 

EDIT:

I currently just finished migrating the skybox from the old project. There's a major improvement in the rendering pipeline though. The old steps were:

• clear color and depth
• render sky
• clear depth
• render everything else

The new steps are:

• clear depth
• render sky (with writing to depth buffer disabled)
• render everything else

This takes advantage of the fact that since the skybox is the only thing being rendered on the sky layer that there is no need to worry about which order polygons should be drawn in; and because the skybox is always rendered, there is no need to clear the color of the screen.

 

 

EDIT #2:

 

For the sake of resolving my own annoyances, I fixed the rotation and scaling of the FBX model for the skybox. This allowed me to remove some of the setup code in the start function and rotate on the up-axis instead of the right-axis (which makes more sense). I also changed the "SetSkybox" function to be static and call it only once during the start function rather than once every frame. Now, if you want to change the skybox in game, you just call "Environment.SetSkybox (blend_value, skybox1_material, skybox2_material)".

 

 

EDIT #3:

 

Some notes I wrote out regarding how to optimize performance in some areas and solve a few problems:

• When exporting FBX files from Blender, rotate them on the X-axis by -90 degrees, apply the transformation to the object, and then in the export options, set it to +Y forward, Z up. This ensures that the model is oriented correctly when it's imported into Unity.
• When importing animations, use the legacy mode. My animation importer will then strip the keys for translation and scale. This not only reduces the amount of memory the animation uses, but also allows you to use the same animations on multiple skeletons.
• Almost (if not) all models should be using fake shadows, so make sure you change the "Cast Shadows" property of the mesh renderer to "off".
• Only terrains need to receive shadows, so for everything else, uncheck the "Receive Shadows" property of the mesh renderer.
• Because the game uses simplistic lighting, uncheck the "Use Light Probes" property of the mesh renderer.
• Anything that doesn't move should be marked as static.
• Make sure the format of each texture is set to "Truecolor". By default, it's set to "Compressed", which causes distortion.
• Make sure the wrap mode of each texture is set to "Clamp". Unity doesn't support separate X, Y clamp/repeat options, so it should always be done with the shader instead using the 'frac' function.
• Never use the default Unity shaders or surface shaders. They perform a ton of slow lighting calculations you don't need.

Here, you can see the use of the 'frac' function to reproduce the texture repeat on the grass; despite the fact that the texture wrapmode is set to clamp. This should solve that annoying problem with the edges on the top of mountains in hyrule field.

 

 

 

 

 

[PwnzLPs]

What version of Unity are you currently using? I ask because I have loaded the project in Unity 5 without any issues. Didn't get any errors as far as scripting went

[SoulofDeity]

I'm currently using version 5. It seems to have this neat feature where it detects when you're using old api's and rewrites your code for you.

[PwnzLPs]

Yeah. I know. That made it extremely useful for me to import into 5.

[Niosai]

Stuff like this blows my mind. Keep up the good work.

[!Tommy]

Stuff like this blows my mind. Keep up the good work.

Due to stuff lost in forum transitions, I believe some of this thread got lost and if I remember correctly, ithe project is not currently active anymore. I could be wrong but it seems to me that there were some problems that arose with development.

[Niosai]

Due to stuff lost in forum transitions, I believe some of this thread got lost and if I remember correctly, ithe project is not currently active anymore. I could be wrong but it seems to me that there were some problems that arose with development.

Ah...unfortunate.

[!Tommy]

It is because it was really looking good. I only wish I could remember what the actual issues were with it. It had lots of promise because you wouldn't have the actual limitations of the OoT engine.

[Niosai]

I also am wondering what the issue was. Making an engine that works identically to OoT doesn't seem like it'd be too problematic and would open the way for fan games/mods that can exist entirely outside of the confines of N64's limits. I wish I knew how to code and such because this is something that I've always dreamed of doing.

[Vexiant]

Well, he left due to conflict with other scene members. Had that not happened, he'd probably still be working on it.

[Niosai]

I don't understand that. honestly. Why let other people on a forum dictate your own actions, you know? But I don't really want to get into it. It was a cool idea. Sad to see it die.

[Vexiant]

Well it was, subjectively, entirely his fault. I say subjectively as he can argue his case (read: He was starting fights with people often for trivial reasons). Anyway, that's enough discussion pertaining to personal matters as that's none of our business. Not even mine since I wasn't a victim of stated/accused actions.

[Niosai]

Interestingly, he did leave the source up. So if someone interest and skilled enough decided to have a go at it, they theoretically could.

[Vexiant]

Interesting indeed. I've neglected to look into the project, but I have started to take up programming outside of low-level MIPS in recent times. I'm rather busy though, so I don't think I'd be the one to take up such a project. Perhaps someone will though

[PwnzLPs]

I might do a little bit of work on the scenes that are in the engine so far. Namely, since this is a recreation of the Zelda64 engine in Unity, I'll set up framerate limitations. Don't know how much work I'll be able to do on this alone though. I'm personally terrible at programming. I just sorta bodge everything together.

 

Edit: I also forgot to mention that I'll be making a clone of their repository. Any changes I personally make will be made to my cloned version, and the README.md file will simply be used to keep tracks of the changes that are made every time I update my repository.

[SoulofDeity]

Um. I didn't leave because of a conflict with other members, I just lost interest in modding in general for a while. Also, this project is as alive or dead as you want it to be, I started it fully with the intention of it being a community project (which is why the source code is on git hub).

 

I personally stopped working on it because Unity doesn't integrate well with github, and I was spending more time rewriting other people's code to play nicely with each other than I was writing my own code; and it was becoming a bit too tedius for me. Also downloading commits was a nightmare, because Unity wanted to recompile all of the audio files each and every time...

 

 

Currently, I'm working on writing my own Zelda64 game engine from scratch that doesn't share the same weaknesses as Unity and is designed from the ground-up specifically to be moddable. It uses a custom text-based interchange format I've designed to do things like:

• Quests - A quest file is a series of events that can execute scripts, load scenes, etc.
• Scenes - A scene file is a collection of entrances, exits, paths, and cutscenes associated with a collision/navigation mesh and one or more maps
• Models
• Actors - An actor file is a lua script associated with a model, inventory, and controller that can perform actions managed by the game's navigation / animation / physics framework
• Soundbanks - A soundbank file is a collection of instruments associated with keymapped multisampled stereo sounds with volume envelopes; used by music sequences

With the exception of images and sound, you will be able to replace or extend any content you want in the game using nothing but a text editor. I'm also working on tools to work with the interchange format and better extract resources from the Zelda64 games (eg. a tool to extract actual entrances, exits, paths, etc. from scenes in the games)

[psychoman87]

I approve of the idea! In fact I've been meaning to get into that as well by reversing OOT/MM completely from scratch to do what you're doing! Maybe you could try collaborating with the team members of the Izou project since they've been meaning to do the same thing if you didn't know and hey, maybe I'll do the same but that's just a thought, though I feel like I'm running it on a different scale, so...

 

If you do this though, you might wanna keep the publicity low since Nintendo is well, understandably but unfortunately a bit too protective of their IP and all so maybe as time flies by after it's completion, you could ask Nintendo if you can release it and doing so would give them a lot of money like the Super Mario Maker but idk, I'm just rambling on now.

 

I've been sort of looking up the C language and don't have full on knowledge of programming and reversing a game yet, it's just something I've been working on privately so nobody knows about what I'm doing but maybe I can learn a little bit more when I observe your project? Lol sorry for all the rambling! I really would like to see what you're doing! I'll follow along whatever you post.

 

By the way, if you're still going to make that game set in Hyrule and Termina after the game engine's been made, I can take part of the story since I actually have a similar idea of what you have in mind! Just like to bring that out.

[SoulofDeity]

Well, you can do whatever you want as far as the game is concerned. The engine supports a text-based interchange format for all the assets by default (note: the graphics api is still flexible enough to write your own model loaders if you so wish).

 

As far as reverse engineering goes, I'm working on a new tool called z64rip that basically does a shitload of black magic to find as many assets as possible in the games and rip/convert them into manageable assets. The scripting part of the game engine has been a bit of a pain; enough so that I've considered just going back to unity, but I think that ultimately I'll just stick with making my own engine.

[psychoman87]

Well, thank you for the information! I'm really looking forward for further updates which I know are on another forum (Project CX) if you're asking me. I'm studying my own research on the language but I'll follow the project so that I can learn a little more from you as well cause I think you're more experienced than I am. I'm a noob! xD

[SoulofDeity]

Well, in light of some recent realizations, I decided to drop the idea of using my own game engine and go back to Unity3D. I usually prototype my ideas in it anyhow, and I'm more productive that way. Besides, Unity5 seems to make a couple of things easier...

 

 

 

Ignoring the 'Ethan' standard asset model in the middle of the screen, Unity5 allows you to attach a Skybox component to a camera to override the default skybox. The skybox is just a material, which in this case uses a ShaderLab shader that interpolates between a 'clear day' and 'clear dusk' skybox. Since the skybox uses an orientation that's independent of the camera, I can parent the sun, moon, and stars to the 'Sky Camera' and rotate it to simulate a moving sky.

 

This is a much cleaner way of implementing custom skyboxes than what I was doing before. It's going to take a little time to get things back to the more impressive state that the project was in before, but it'll be worth it in the long run. I can still make it moddable like I planned with Cx, by generating assets at runtime, but that's not high-up on my todo list.

[SoulofDeity]

Unity5's new canvas system is making it really easy to make GUI's that scale to different resolutions. Here, you can see 4:3 and 16:9 aspect ratios.

 

 

 

 

 

 

 

~Pixel Perfect

 

[psychoman87]

Guess creating your own engine was too much work for you?

[SoulofDeity]

Guess creating your own engine was too much work for you?

Too much, effort-wise. Creating a custom game engine is really complex, especially when you start getting into audio and physics. But even beyond that, you still have to write tools for creating scenes and converting resources before you can even think about getting started on making the game itself.

 

I had completed the module loading system, completed the actor loader (for both native code and lua scripts), written the OpenGL mesh renderer, and was a good ways through writing a new tool (based on a fixed version of one of my prior tools, z64dump3) to rip models from the game in fbx format.

 

Maybe I'll continue working on it in the future as a personal project, but for now, I just want to be productive.

[Mallos31]

That's totally understandable. I'm working on a simple 2D game (to get back into the swing of things on the programming front) and making an engine for that is hard enough let alone physics and the like. I look forward to seeing you progress on both projects! 

[psychoman87]

I understand. It would take several years to make. Right now, all I can do is just write fanfiction & novels and by the time I can get my computer fixed up and updated, just make random mods and fiddle around with stuff in order to get the hang of the roms (Referring to both OOT, MQDR and MM) before making something big.

 

Maybe if possible, I could learn to make a mod that whom and as I always say; would consider it to be the equivalent of Super Mario 64 Last Impact in Zelda OOT and/or MM.(If either one is compatible) with customization like enemies, bosses, items, etc but that's just a pipe dream for right now so don't expect anything to come from a noob like me who is obviously not the only one who has that dream. Still gotta learn coding and the engine's data. XD

 

But nonetheless, I look forward to what's to come! Starting off small is always the best direction to take when making a mod or even a standalone game or in this case; a game engine. You can definitely start off with unity and maybe just use updated graphics but keep the rest of the assets like in the 3DS games if you desire, but then after it's complete, you can make a whole new game engine from scratch.