Skip to main content

Posts

Showing posts from March, 2017

Fixing old mistakes

This weekend I made another offensive to my item equip code. It depends on the mesh assembly code, which deals with building a model from several meshes, if they share the same skeleton. To be equipped, the  item must have the same skeleton too, of course, and the widely (and only) documented method is to copy the bone info from the base skeleton to the other meshes. Simple items like weapons does not need this, as they can be attached to a bone and that's all.

But my first approach had major flaws. It required a list of prefabs that were assembled into a a model and then to a list of GameObjects, the NPCs were not visible in the map, and just recently found that destroying the switched part left me without the original part to restore it when the item was removed.

So, I sat and put my brain in afterburner mode. It didn't worked... until yesterday, when at last I figured out how to get rid of the lists of original prefabs, the resulting GameObjects, etc, and put that in a si…

First quest

Yesterday I managed to implement the first quest of the prototype, and a couple of hours later, the second. I can't say I have a proper quest system (if such thing exists), it depends on loosely related stuff.

The first quest implement involves recovering an stolen item, which requires fighting some weird guys. It is like an introduction to combat. The guy drops the stolen item, or more precise, you get it from his corpse. When you talk to the quest NPC, if you have the item with you, a new option appears in the dialog that allows to deliver the item, receive XP and set the quest as completed.

The second quest is to talk with a guy to receive another quest, the one that triggers the main storyline of the game. Pretty easy. And now that I mention the storyline, I made some work on it this weekend.

The key word when writing the plot for an open world is branching, which is easier to say, but not that easy to achieve. It means that almost every quest or NPC should be the entry point…

Mi novel available in Amazon

In case you are proficient enough in spanish, or at least, enough to read, I remind you that I keep a blog in that language too. Also, I'm happy to announce that my  book is already available in Amazon.


I put a lot of effort to make this my best book, and as usual, I ended up not quite sure about if I made it. Probably the next will be better.

The best tutorial to implement a node based editor

I had lost all hope to find a good tutorial on creating a node based editor in Unity for my dialogs. Something like Mecanim, with squares and connections. So, it waslike a shoot in the dark when I made the same search again a week ago. And guess what, I found this.

I spend the friday night following it and got a small prototype working. Not just that, I also know how to customize it and add stuff. The bad news are that I forgot most of the little I knew about old Unity UI system.

This is the best tutorial I have found about this: simple and effective.

Implementing interactions

I had a big mistake in my AI behaviour system. I added in basic bahaviours one to make the NPC approach the player and engage dialog, until I found that such idea is not very wise. Sending the NPC to mindlessly talk with the player any time it is visible doesn't works. Let's suppose the NPC has a quest to assign, what happens when such quest is completed, or in case you reject the quest? The NPC will continue to harass the player, starting a dialog in every occasion.

In this case, my approach is to use a trigger collider. I set up a GameObject with a box collider, and attach an script that makes the required verifications: does the player has the quest already? what's the status? This can be used to trigger attacks that requires prerequisites, like raiders that attack you only if your level is below some value, or if you belong to some faction.

By the way, am I the only one who is not impressed at all with the Unity GDC keynote?