Implementing Gameplay

The biggest challenge of Zelda64 VR is implementing the gameplay. We don’t want to reinvent the wheel and recode  all the gameplay that can be found in Ocarina of Time. There are just to many big and small gameplay elements for that.  Before I get into much technical detail I will explain how Ocarina of Time works.

Every object, every character and every item has its own piece of code. This piece of code is called the actor code. The actor code contains some basic information like the model that should be used to render this actor, the scale and much more. Besides this info there is also a piece of code that runs when the actor is active. For static object this can be as small as a few lines. But for animated objects that the player can interact with, the code can be thousands of lines.

So why haven’t you seen any gameplay videos yet? The code I told you about is compiled MIPS code. It’s not really easy to read and it takes a long time to build a program that runs the code properly. Besides that the code contains a lot of calls to functions that I don’t know the purpose of. There is a small list of documented functions but that’s by far not all of them.

The way I am currently implementing the gameplay is a big challenge but will give very accurate results and save me a lot of time in the end.

Work on Zelda VR has been continued

It’s been quiet a while since I last posted about Zelda VR. Summer is here and work kept me busy. After a long day of coding at the office I just didn’t feel like coding even more at home. So not much progress has been made until last week.

With the DK2 right around the corner I started getting hyped about VR again and decided it was time to get back to the project. First thing I had to do was update to the 0.3.x SDK (let’s hope the next version won’t mess up to much). Which surprisingly didn’t take that long due to the excellent examples and libraries floating around on GitHub. Once I got that out of the way I continues work on the main goal; Loading and emulating the Zelda ROM.

People might wonder why I am using the ROM as a base instead of ripping the assets from the original game and drop them in an engine like Unity or UDK like several other projects do. Let me explain why I take this approach:

Legal issues. One of the main main reason. Ripping models, sounds and other assets from a game and distributing them is not allowed. By loading all the assets from the ROM I try to bypass this and basically do the same as any other N64 emulator. With the only difference that my game will only work with one single game and contains a lot of custom code to fancy up the graphics and make everything VR compatible. For the user this means he needs to own a copy of the ROM and place that in the games folder.

Learning something new. It’s a challenge to get all this working. Especially because I’ve never tried to do something like this before, but have always been interested in Emulators and how they work.

Amount of work. The amount of work to get everything running is gigantic. I need to be able to emulate every part of the game. But doing it this way also has an upside, once you got one part working, for example loading one map, all maps will work. So instead of having to rip every single model, I’ll have to make sure I can load one map and all of them will automagically work. The same goes for the Actor scripts (all interactive elements in a map), audio and collisions.

That’s basically it. I hope you are as excited about this project as I am and maybe one day you’ll be able to play my favorite game in VR.

DK2 and 2 more projects available on GitHub

Just got back from my holiday to the Dominican Republic. It was awesome and I’d like to go back there some day! When I got back there was a nice surprise waiting for me, just a couple of hours after I landed the Oculus Rift DK2 got available fro pre-order. I immediately pre-ordered and I am now playing the waiting game again!

There where a couple of requests to open source 2 more projects. I feel ashamed to put the source up (it’s that bad), but maybe someone will learn something from it. You can now find the source of my sco (de)compiler and the source of my Sketchup OpenIV Exporter on GitHub. I hope someone will find it interesting and can learn something from it.

Sketchup WDR/WBD/WBN/WPL exporter

(3DS Max users should not read this as the word sketchup makes them cry most of the time)

A little while ago I wanted to export some of my sketchup models to IV. I found it to much of a hassle to do the Sketchup -> 3DS Max conversion every time I wanted to export or update something so I decided to quickly write an exporter to improve my workflow. If anyone is interested in it I’ll make it suitable for release and release it.

Current features:
– Export WDR (Really basic)
– Export WBD/WBN
– Export WPL
– Export IDE (WIP)

I know there are a few sketchup modders out there so if you’re interested in this let me know.

Note: Sketchup Pro is not required because it’s a ruby plugin.