Dissonance Game Project

I’m sorry it took me so long to finally get back to you on this question, the past few weeks at work have been mentally exhausting and I wanted to take the time to answer you properly. I’ve been thinking about the IK stuff especially and I was about to start taking notes, but a few days ago, I came across this post by @minionsart : https://www.patreon.com/posts/astro-kat-moving-21343562

To be honest, this is pretty much exactly how I made the IK work. I don’t really have much to add, this is a great tutorial and the youtube link at the bottom is the reference I also used when making the system. Go check out this whole patreon page, there’s a lot of very useful info.

For the climbing and ladders stuff, honestly, it’s nothing too fancy. First, I setup trigger box colliders on both ends of the climbable surface.

When the player enters the trigger, I Lerp their position in XZ towards a predefined position in front of the ladder (to make them snap to the bars). Using the height of the bars, I can define by how much the player needs to move at each animation steps. While climbing, I split my animation into 4 states: 2 for moving up (each hand) and 2 for moving down (also each hand) and I adjust my animator to correctly cycle through while climbing (and syncing one bar climbing animation with a movement of one bar height). You’ll also need an animation for both hands to get off the ladder at the bottom and at the top, as well as an animation to get on the ladder both at the bottom and the top.

Fanart of ADA by @hushabyevalley

Sorry it took so long to answer!

So the first thing you gotta know is that texture animation data is not something that can be stored in a fbx. This means that even if you try to animate it in Blender (Maya LT for me), the animation data will be lost during the export and the animation will be gone once the model is inside Unity.

So for starters, you should put the face of your character on a separate material from the body. You will want to move the UVs around to animate the face, so if the body and the face share the same material, the body’s UVs would also be offset and the result would be terrifying. I don’t know about Blender, but in Maya, you can assign materials directly to faces of the model, and this is data that can be exported in the fbx. This is super useful because by doing this, you don’t need to have the face as a separate object from the rest of the body. Having the face as a separate object is a problem if your shader uses the normals because you will have hard edges where the meshes meet (unless you manually tweak the normals or have a normal map or something, I haven’t investigated much for this point).

Now since you will be moving UVs around, you’re really doing yourself a favor if you align your facial expressions in a grid like this:

Here I have a 128x128 texture and every expression is a 64x64 square.

UVs work with values that range from 0 to 1. Now the way my initial UVs are set up, the default face is in the upper left corner of the texture (eyes fully opened), which means that this is the face that will be displayed at offset [0,0]. If I want the half-closed eyes, I need to move in U (horizontal) by one expression, which is 64/128 = 0.5. This expression is then at offset [0.5, 0]. By the same logic but with V coordinate instead, the fully closed eyes are at [0, -0.5].

Now how to actually offset the UVs? You just call this function on your material:

material.SetTextureOffset("_MainTex", Offset);

At this point, you could create a system where you set up every facial expression using an enum to identify them and call a SetFace() function through code whenever you want (for example: with animation triggers, during dialog, etc.). 

Both can work, it depends on which is easier. For example, from a hairless head, the bun at the back can easily be extruded, no need for a separate mesh.

On the front, I actually modeled the hair separately. I started with a flat symmetrical fringe.

That way, if I use snap to vertex, I can correctly attach it to the rest of the hair. Once it’s done, I can merge both halves as a single object and curve it.

To be honest, that was actually the first time that I tried this method of creating a separate mesh and attaching it afterward. I usually just extrude from a bare head, but this was actually fun to do too and I’ll probably do it again in the future.

Oh and also: I do keep the hair as a separate mesh from the head. I just duplicate the head mesh and remove some faces (both on the head mesh and the hair mesh so that their borders have vertices snapped together). This is just to make it easier for modeling and texturing.

Shirt on or off?

A bit of progress update: I kinda hit a wall with the design of the main character, I can’t quite get it to where I want it to be. I put that on hold and tried environment modeling instead, but then I also hit a wall with the texturing on that. I’ll go back to environment soon enough, but for now, I’m working on some NPCs.

So here it is, a little bit of prototyping to see how doable my ideas for the new project are. I could prototype a bit more, but most of the other stuff I want to implement I’m pretty confident I can do without much problem.

In Ephemeral, you play the role of an alchemist that tries to create and evolve his homunculus. In contrast with Dissonance, the alchemist is the only true protagonist. In the gifs above, we can see:

1- Using potions as the main source of interaction

2- Controlling a homunculus AI while remaining in control of the alchemist

3- Gaining control of the homunculus (just like in my previous project)

4- Piggyback that will replace hand holding

5- Stitching models together to have a visual representation of the homunculus upgrades

I won’t be doing that, unfortunately. I’m much too shy to let people look through my code. Besides, I’ll still be using the same code base for my new project since it will be mostly similar (movement, camera, level loading, level interaction). There’s actually very little that I will be removing from my previous project and the first changes that I planned are actually refactors that will allow the new concept to work.

I’ll start with the good part, which is a big thank you to all of you who decided to follow my progress on my game project:

I’m really glad you found my project interesting... but I’m sorry to say that I will not be finishing it.

Why?

This project was actually just an idea I had in my head for a few years, but I never got around to actually work on it until recently. In my head, everything just worked out well, but when I started putting it on paper, both the design and the story became shakier. I started working on the game with the idea that I’ll make it work. The hand holding mechanic was the core of my game, but the more I worked on the animations, the more it seemed like it wasn’t worth the effort. The whole concept is cute in videos, but it’s more of a hassle for the player. At least, for the level design I had in mind.

I wouldn’t say the game is unsalvageable, but the story, the world, the mechanics, a lot of the design would need to be changed. It’s something I would gladly do, but the game idea was something I envisioned as a whole and I don’t think I can change parts of it without affecting the whole too much. Honestly, the problem is also that I kinda lost the passion for this particular project.

Now, this isn’t completely the end

To be honest, what really killed this project is another game idea I had not long ago. It was something really spontaneous, but also it was an idea that was formed out of the problems of Dissonance with, I believe, good solutions to make it work. So it’s a different world, a different story, mostly different mechanics but...

I’ll build it upon my current codebase. It will still be an action-adventure game with 2 characters, only this time there won’t be hand-holding (but there will be piggyback riding). Since most of what I had in the project was either generic stuff or basic movement, I get to keep all of that. I guess for you, it won’t be such a big change because I mostly changed the stuff that I didn’t show yet (except maybe some NPCs and the protagonists).

What to expect next?

I’m working on a quick prototype to see if my new mechanics make sense and are reasonably doable. I might do a quick update with that soon.

After that, I really want to take a break from coding. I want to focus on the design of the main characters and some environments. I’ll try to work on the art for a while to give a bit more personality to the project before going back to the mechanics.

If you’re interested, I might do a post on why Dissonance did not work out too well and how I intend to fix its problems with Ephemeral.

Here’s Raven for #titansmarch. I’m sorry I didn’t post it on the correct day, but I’ve been working on this model for the whole month and I couldn’t wait to post it as soon it was done.

Thanks! I knew someone would point that out. To be honest, I kinda gave up on animating for now. Every time I try to make a new animation, I need to tweak the rig a little bit since it was literally the first rig I ever made and it’s still kinda wonky. So if any of the previous and future animations look phoned in, it’s because they are; I try to rush them out to implement the feature. I’ll go back and redo most animations, but that might need to wait until most of the core features are in.

I never worked in Unreal, so I really can’t help you with the specifics of the implementation. What I can say is that since what you want is simply show 2D images in sequence, you’ll probably want to use the UI tools of the engine to place a single image that is stretched correctly across all the screen. You’ll probably also need a separate xml/json/csv file to keep the useful data of the image sequence (things like image file path, image duration, fade out duration, fade in duration, sound effect maybe?). Once all that is setup, a single script could read the data and process the sequence, which is basically just swapping the image in the UI and then waiting for the next one.

One thing you need to watch out is to make sure that it works at any resolution (or more precisely, at any resolution you allow in the settings). If your image is in 16:9 and you allow 4:3, you don’t want the image to be squished horizontally, but you got to make sure you don’t lose anything important by cropping.

I think there was a misunderstanding here. @theonian expected something different from what I had designed so he was rightfully disappointed when I went in another direction. He might prefer platformers over puzzle games whereas you might feel the other way around and that’s perfectly fine. I wasn’t trying to justify myself to him in my last post, I simply wanted to share my thought process on the issue because it’s something I was thinking about since I implemented the block puzzles (and because I like game design in general). Besides, in game development, you kinda need to overthink pretty much every aspect of your game, so everyone bringing their opinion to the table, whether it’s him, you, me or anyone, can only be good. The worse that could happen is me saying that I already thought about the issue. And at the end of the day, this is not a committee, this is a personal project, so I get to chose how the design goes.

Also, since you brought up the subject of puzzle games, I want to reiterate that what I’m doing is definitely a Zelda clone. This means that the gameplay will (hopefully) be in equal parts exploration, combat, and puzzles. The game might also be a bit story-heavy. This might not be your ideal game and this might change your perception of my project, but I’m glad that at the moment you care enough to follow me.

That’s a good point. To be honest, I haven’t made a decision for that yet. There’s two way to solve the problem: either use the “Action” button to initiate the jump or use the movement velocity (i.e. if the player pushes the joystick far enough in the direction of the ledge).

In Zelda, both are used. The velocity is used for normal ledges, but when you go to a movable block, you need both movement and an A press to get on it. Pressing A without movement would make Link grab the block.

So I want to share a little bit of reasoning/game design about that because removing the jump was not an easy decision to make and it might not even be final.

My game has a central theme and I want the theme to be reflected through gameplay, story, and music. The hand holding stuff is one of the central mechanics that really work in that respect. Jumping/platforming simply is not an extension of the theme, but that doesn’t mean it can’t be present in the game as a navigation tool. However, I can’t half-ass it, I don’t want to put a jump in because “it is expected of a game to have a jump button”. Having a single jump button is not enough to justify a platforming game. I need more depth, things like a high jump, a double jump, a wall jump, a long jump; anything really, as long as it gives something to the player so that they can master it.

The big problem with that is that this doesn’t really work well with the hand holding mechanic. To be more precise, I don’t feel like I could make it work because it is out of my league. Having multiple jump options would mean that they must work in tandem with the hand holding, meaning that both characters would behave logically when jumping together. This means that if I want the jump to be reactive, I can’t spare time for the second character to reposition herself. Since platforming is simply skill-based navigation, this case means that precise jumping would simply not work.

There are a few solutions to this. First, I could simply make it so most jumps are only available when the characters are played alone. Right away, this goes against the theme since I want the characters to have more options when they are together, not less. The other solution would be to transform this game into something more similar to Banjo-Tooie, where you can have the characters be alone or together, and they have more abilities together. To be honest, this is kind of my fallback option. There’s nothing wrong with it, but I set out to make a Zelda clone with humanoid characters and the Banjo-Tooie playstyle would not work with humanoid characters.

In the end, I’m really making a Ocarina of Time/Majora’s Mask clone, maybe to a fault. Platforming is a tool of navigation, not a gameplay goal, so this is why I opted to make jumping contextual. It’s still slightly skill-based, the same way it was in OoT/MM: you need to orient yourself correctly and time your jump (okay, not the most skill-based, but it is still possible to fail compared to a simple button prompt). This won’t be the only navigation tool, there will (hopefully) be items to find that will create both environment interactions and character interactions. With this design in mind, it feels more realistic to me to make most interactions contextual so that I can properly position both characters before such actions.