Project CX - Zelda Modding About To Get Real

[SoulofDeity]

Right now, I'm working on one of the biggest projects I've ever written; which will probably spark a whole new life into the Zelda modding community. This new project, dubbed "Project CX" is an easily portable, lightweight, cross-platform engine for creating Zelda or Zelda-like RPG games.

 

Unique to this engine is that it is designed specifically with the intention of being modded. All quests, scenes, models, effects, fonts, user interfaces, actors, sound banks, music, and so forth; that is to say anything that is not specifically related to the core of the engine is configured via a very simple interchange format that I've designed. Furthermore, the game will connect to a configurable list of repositories that lets you download new content in the form of mods. The goal of this project is to breath new life into the modding community by lowering the barrier of complexity.

 

 

Architecturally, the engine revolves around a quest system. Quests are a series of temporary or persistent events. Events can be used to execute scripts, load scenes, play cutscenes, or start and stop other quests. Scenes are a set of entrances, exits, paths, and cutscenes, associated with a map and a collision/navigation mesh. A map is a set of rooms associated with a set of models, events, triggers, and actors to be spawned. An actor is a script (lua) associated with a model, status, inventory, and controller. A controller is an abstract interface that can accept input from the user, a pathfinder, a script, ai, etc. The controller's job is to generate a sequence of actions that is processed by the navigation / animation / physics framework. This vastly simplifies the task of creating new enemies and npc's for the game.

 

In addition to the engine itself, I'm also writing a new tool called z64rip that extracts models (objects/maps), scenes, music, and soundbanks from the Zelda64 games into my engine's interchange format and a blender import/export script for my model format. You can expect within a few weeks from today (12/7/2016) to be able to see practically all scenes and maps from OoT and MM imported into the engine.

 

Progress wise, z64rip can already dynamically decompress any zelda64 game and locate the scene and sequence pointer tables in their code files; the next step there is iterating through the scene table to construct models and saving them to disk. On Project CX, I've recently finished designing the interchange format and writing the module loading system, which includes the initialization of the transparent graphics interface that can bind a camera to move through a scene. I'm currently working on the code for loading and rendering models.

 

I can't put an exact date on how long it will take. Some days, I'm much more productive than others; but I have a very good feeling that I will have something to show sometime between now and mid-January. I'll be keeping everyone up to date as progress is being made.

[sairugoth]

Sounds awesome man; cant wait!

 

God knows the community needs a good spark right about now.

[SoulofDeity]

So, I've been thinking a lot today about the graphics capabilities of the engine, and I think that we shouldn't limit ourselves to light n64-style graphics, but merely make them fallbacks to meet hardware constraints. Why? Because N64-style graphics are perfect if you're trying to target mobile devices, but if I'm going to play the game on my PC, I want it to look like this:

 

 

I doubt that any of you will disagree. Now, the question is, how do we reach THAT? Well, there are several special effects he's pulling off here if you look closely. It's a combination of bloom lighting, global illumination (possibly radiosity or a lightmass), heat wave distortion, motion blur, a wind zone, particle systems, and volumetric fog.

 

Bloom lighting, heat wave distortion, and motion blur are all simple (well...intermediate I should say) post-processing effects that can be performed with shaders.

 

Global illumination is a bit painful to implement, but basically allows for extremely realistic lighting by having light bounce off of objects.

 

Particle systems and volumetric fog are both controlled by the game's physics.

 

 

As for the map he's using, the way the walls protrude tell me that he's not using a terrain generator. Most likely, he sculpted it in a tool like zbrush, baked some bump and/or displacement maps, and decimated the mesh to reduce the polycount. Now, I'm not saying it'll be easy, but the only things that I think will truly be difficult to implement here are the global illumination and volumetric fog (mainly because I'm not very familiar with the techniques involved). It mostly boils down to creativity and imagination when it comes to these things. I can assure you that the same set of tools in a different pair of hands might not have looked even half as good.

 

 

---

 

 

The quality of graphics aside, another thing I've been thinking about is the implementation of extreme weather. Because I honestly think my heart would explode out of my chest if I saw something as epic as a tornado ripping it's way through Hyrule Field. Especially if it was in that UE-style graphics.  >_>

 

Well, aesthetically, you guys now have idea of the kind of scalability I'm hoping to achieve. The engine should be compact and fast enough to run very well on an embedded platform, but it shouldn't stand in your way if you want to make something that covers computer monitors in grey matter.

[SoulofDeity]

Just something to note about my previous post regarding game aesthetics; the one reason I refuse to use the Unreal Engine is that...I can't...Literally. On all of my computers, the engine is completely unusable; with terrible graphics glitches and an average of about 1 FPS. Rather than trying to use the latest and greatest features out there, expecting people to have $1200 SLI rigs just to play games, I'm interested in finding alternative means of implementing the same graphics effects without incurring the huge amounts of overhead.

[psychoman87]

Maybe you could make the graphics look like something from the OOT/MM 3DS Graphics engine, but slightly more realistic. Maybe you could compare it to the Tech Demo of Wind Waker.

[SoulofDeity]

Maybe you could make the graphics look like something from the OOT/MM 3DS Graphics engine, but slightly more realistic. Maybe you could compare it to the Tech Demo of Wind Waker.

 

OoT3D/MM3D-style graphics are also a possibility. Really, you can do anything. What I'm interested in is the physics and special effects that polish that game and make it look amazing. Basically, I want break down the special effects to understand each individual piece, find the most optimal alternative possible, and then put the effect back together. Eg.

 

For the gerudo valley video, one of the things that I mentioned was the heat distortion effect. OoT and MM for the n64 implemented this effect in Death Mountain Crater by jiggling the frustum of the camera; it's not as great of an effect though because it lacks the refraction you see in the UE video.

[psychoman87]

Well, I think it's good to polish and update on a game's successor in order to make it look more graphically improved. I still think the idea of the WW Tech Demo-styled graphics sounds like the best idea cause although Twilight Princess already used that, it looked a bit too dull imo. I like the idea of using a gamecube-esque styled graphics. Just my personal preference.

[SoulofDeity]

These are just some personal notes I've been taking on the special effects in the games:

 

 

Shadows

   - Spot shadow, used for anything other than the player, or when the player
     is in the air to make it easier to predict the landing spot; it's just a
     horizontal plane drawn at the character's feet

   - Foot shadow, used only by the player, has a length and direction that
     depends on angle between the player and the light source; each foot will
     have a separate foot shadow for each light source

   - Real shadow, unused. it requires a stencil buffer and thus is expensive

Stars

   - Stars are only seen in majora's mask and are  rendered independently of
     each other; the north star is red, stars that make up constellations are
     various shades of blue, all other stars are various shades of gray or
     white that 'twinkle' in and out of visibility when the camera moves

Rain

   - Splashes are emitted independently of rain on a 'splash plane', drawn at
     the same level as the player's feet; however, the size of the plane is
     dependent on the resolution of the screen

Trails

   - Used by the player's footsteps, deku-link spins, and sword slashes. The
     footsteps and deku-link spin trails never clip through the floor like
     shadows; so it's possible that they're implemented by a stencil buffer

Coronas

   - Coronas, drawn around most point light sources like torches and fairies,
     are occluded via raycasting from the camera, but drawn over everything
     else in a scene (except gui stuff like menus and text boxes)

Heat Distortion

   - Heat distortion, like you see while in the death mountain crater, is
     implemented by 'jiggling' the frustum of the camera

Skeletal Animation

   - In OoT / MM, skinning (binding vertices to a skeleton) is performed via
     a technique known as 'linear blend skinning'. First, forward-kinematics
     are applied. This entails converting the local-space transformation
     matrix of each joint into world-space by traversing the hierarchy of the
     skeleton from the root node down to each of the terminal leaf nodes.
     Second, any necessary inverse-kinematics are applied. This is used to
     do things like correct the placement of the player's feet or make a
     character turn their head to look at something. It entails traversing
     the hierarchy of the skeleton backwards from the terminal leaf nodes up
     an arbitrary number of limbs.

     It should be noted that, while OoT/MM does use linear blend skinning,
     which has been standard in the game-design industry for many years, that
     double-quaternion skinning is ~2.5x faster and has less artifacts.