Today I was adding some new GameObjects(GOs) to my game scene, some of those GOs were Item Pickups, some small components that have a trigger to identify that the player has found them, a component that implements an interface to identify that the player found something that can be picked up, a property for a ScriptableObject that represents an item and a Sprite to show the look of the object inside the scene.
But after placing the Item Pickup I ran into a small problem, the item and the environment have the same color pallete, giving the chance for the player to completely miss it.
Not difficult to fix this, just add another trigger and a script that kicks in when the player character is close enough to the item and it flashes, that would easily do the trick.
This post assumes that you have knowledge about finite state machines, for a good understanding of that subject follow this link or use your favorite search engine to find more about this topic.
Recently I had to add additional functionalities to one of my game characters, at the time the character’s actions were only idle, running and jumping, but I had plans for actions such as rolling, ducking, walking and ledge grabbing.
The problem was that adding additional functionality was becoming not only an unpredictable bug hunting but also was opening holes for new ones to come in, and when this happens it’s clearly a sign of a bad design.
For my first Unity3D custom editor I chose to make a quest editor, most simplified as possible for my needs but as much customizable as possible to make quest creation and editing simple for non programming developers.
This is the required example of quest code for this post:
You will eventually regret any use of Euler angles.
His name is John Carmack, and today I can say that I couldn’t agree more with him, why? Let me tell you why.
The next step of my game development project is to develop an animation tool, since I’m not that good with art I always though that it would be better to create each separate part of my characters and animate them separately, instead of creating the different sprites for each animation frame they had, all was going well until I stomped on a huge rock, which was that? Transformations without matrices!
My initial idea was to develop simple tool for a simple game with certain components for the development tool, one of those components is a skeletal animation tool, which on my project is called Puppeteer. I wanted to do this in a way that I could avoid the use of matrices, instead using vector and float data for translation, scale and rotation, this was going well until the problem of the skeletal animation showed up, it’s much more difficult, if not impossible, to achieve a good skeletal animation avoiding matrices, and once the mathematical principles behind this are understood they proved to not be so difficult as they seemed, instead of carrying the values of translation, scale and rotation on 3 different properties and trying to reinvent the wheel combining them with dodgy equations it’s much better to have them stored in matrices and using the standard approaches that people who know much more than I do developed.
Let me give you a brief explanation on how the matrix transformations work in a simple skeletal animation
You see those pointy objects with a short orange side and a long blue one? Those represent the bones of the character.
Each one of those bones can contain one parent and can contain multiple children, the bottom bone for example is the root bone, since it contains no parent, and is the parent element of two other bones, that will be the parent of other bones and so on.
Each bone contains a matrix to represent it’s transformation in the world, and the reason for the relationship between them is that the parent transformation influences the children transformation, every time the parent rotates, scales or moves that will be reflected on the children.
Here’s an example of what happens when a bone is translated and rotated
As you can see al the children were moved, but still have their origin in the previous bone end.
To have this effect we require a simple matrix multiplication, so let’s assume we want to calculate the matrix transformation applied to a second bone on the hierarchy, the calculation would be:
The “ChildBoneLocalTransformation” would be a simple matrix formed using translation, scale and rotation, while the “RootBoneTransformation” would be the same matrix, with the roots data, and an extra value added to the translation component of the matrix, given by the bone length, without this detail all the bones would overlap each others.
On my next post I plan to show a video of the animation tool in motion and the steps to attach images to the bones showing how a character animation can be created. Unfortunately I didn’t get the time to prepare a more presentable demo of the editor, and it’s better to divide these posts into smaller parts.
It has been one month since my previous post, since then some major design changes have been made, but I won’t go into details about what changed, but about what has been added.
First of all, like I stated on my previous post I’m using WPF to build my editor’s UI and using MVVM pattern to bind data between the UI and data models, it’s amazing how both WPF and the MVVM pattern fuse together really well to create a UI without much complexity.