Dropping and the big drop

It took me some frustration and two days not working on the game, but it's working, the dropping of objects from the inventory. It was actually quite easy, but it was not something I expected to happen. You know, destroying children (which is only admissible in a software development context), it has some peculiarities if I understand it right and I needed to learn something new in Unity to find that out: The debug mode in Unity. I looked at this video and it helpen me on my way. Just wanted to share this one and others from Unity3DCollege which you should check out.

What seems to have happened if I understand it well, is that stuff happens in another order than I expected. I destroy and object and then check the state of things. Well, that was too soon, probably, because after the Destroy-command, the object sticks around for a while. Took me some time to find that out.

Now the sollution was not difficult in this case, because instead of object 0, which was the one supposed to be destroyed, object 1 was the one I needed. In the end all I did was change a digit.

And then I dropped the objects and tried to save one of them... In vain.



By the way, I think I'm going to use my YouTube channel more now. Gifs are all nice for a couple of seconds, but a longer video is better to show bigger pieces of the game's workings. For anyone interested, you can follow me here.

Do I have this or not?

Alright, before my wife gets to go on the computer, a little update. Yesterday and today, I made some progress in the Inventory GUI. I put quite some thought (and YouTube tutorials) in it but it took me a day to be where I were in the earlier iteration of my game. Now that I am there, let's build.

Like with the dialog/quest boxes, I learned it is easier to keep GUI and mechanics separate, but now that I'm working on the inventory, I see the disadvantages too. Just have a look.



The inventory screen (which needs some visual changes of course), it contains two major parts: the list on the left and the details part on the right. The list part simply lists the inventory, which contains all the objects that the player picks up, or nothing. The part on the right is going to be more flexible, but what it should have now is either nothing(if there are no objects in the inventory), or the top object in the list (if there are). The buttons in the bottom are going to be Use and Drop (or equivalent, like Equip, Eat etc. That's why they don't have text yet).

It seems the display objects have a hard time communicating with the objects themselves. There's dropping mechanics in the actual objects that place the object in front of the camera and remove them from the inventory, but then... Somehow the game does not yet understand which object to work with and when to update the view.

It'll all be fine, but this is not ready by far. I'm probably making a thinking mistake, but you know how it is with thinking mistakes? You're thinking wrong, so they're especially hard to spot. I'll be back working later. Hopefully with a fresh look and it I'm lucky, I immediately see where I botched it. Wouldn't be the first time and certainly not the last either.

Very specific rocks and rats

So the weekend is here and I get to have time to work on my game. My wife is off with friends and family and the football season has finished, so hardly anything to distract me. This week's been a busy week, but I did make progress in the quest system.

I already had some gathering quest mechanics. Now I also have movement quests. Furthermore I added a way to start and finish a quest. The only way to do that was to talk to an NPC. Now moving to a designated location can also trigger the quest.

Finally, I implemented something to have completing a quest make other quests available. While this is not finished yet, I could be used to guide bigger story lines. For instance, an NPC might send you on a quest to go somewhere and that location will trigger a gathering quest or another move quest. It still requires some work to finish it, but it's starting to work a bit and, like the enemy AI, to me it kind of feels alive already, which is a good thing. I do need others to share that feeling, because such things are deceptive.

Another thing: a gathering quest is now about gathering a specific object. That's fine when I need to fetch the Special Unique Sword of So-and-So, but when I need to gather a flower or a rock, I should not need to get that one unique one. A flower is a flower, so what I'll add is that a gather objective can either point to some specific object, or one of more objects with certain characteristics, like a tag or some information about the object.

Same will be with killing objectives that i'll add later. I can be asked to kill a very specific knight or a monster or something, but it can also be that we need to get rid of a rat. Rats are not unique, unless we're talking a special one. Once I have my combat system, I'll make sure that killing a generic enemy like a rat or a guard will trigger something else than killing a special character, like that one knight,

Also, There's the matter of marking where to go for a quest. Especially now that a quest could turn another quest from unavailable to available, there needs to be some sort of recognizable thing to tell the player a certain NPC might have a quest or a certain location might. For that, I'll probably use some marker near the quest giving object like an exclamation mark or some particle effect that I never worked with.

In the next week, I'm going to work on the GUI again. I would like to have my GUI for journal entries, inventory and quests first (in no particular order). Furthermore, I would like to refactor some stuff in my worldobject class. That'll make it more flexible and easily implemented, especially for the inventory. Here I also want to prevent the GUI to show "Flower", "Flower",  "Flower", "Flower" and "Flower" when I actually just have 5 flowers. An object is unique or it isn't. If it isn't, We shouldn't spend too much space on showing them.

This'll be useful for things like arrows too. I don't want the player object to keep track of 2000 individual arrow objects. I just need the game to understand this particular object is an arrow so that it will be stored as an amount so that the game might pull arrows from a pool. But that's for later.

Video: So Far So Good

I did not have too much time to work on my game, so I thought It'd be nice to show some game footage of me playing whatever it is that I do have. I know it's not perfect and you'll see a couple of bugs, but it's starting to get interesting, if I can say so myself. 

`

Sorry about the video quality. I'll try to fix that later. There's a little letter pinned to the wall that I can read. It's all placeholder graphics made in Piskel to have anything to serve as a letter. It'll be replaced once I make the graphics or have someone else do that. not sure yet, so I'll focus on the mechanics, GUI and the like.

Looking at letters user the same mechanics as picking up things, opening doors and talking to NPC's. There's an interact script to do things with objects, depending on what kind of object it is. Is it an interactable, like a letter, examine it, is it an NPC, talk to it, etcetera.

Well, if it's a door, open or close it. Behind the door, there's the blue Friendly Guy that wants a red ball from me, and a red Unfriendly Guy that wants to walk towards me in a buggy fashion. Talking to the Friendly Guy reveals a quest that he has. This one is easy to complete, so I do that and return the ball. Turns out out friend does not have enough stuff on him to reward me. Usually, I'd be angry, but he, this is a public video, so I'll let him go.

I might have more time tomorrow and Wednesday. Hopefully I'll be able to complete the quest for movement quests too. There are - for now - three kinds of quests (or rather objective types; a quest can have a number of different objectives to complete): Gathering quests, movement quests, and defeat quests.

The defeat quest will have to wait before I have combat mechanics, which is not my first priority right now. That'll be movement objectives. Movement objectives are mainly meant as helper objectives to get the player to a place to have him receive further instructions. it should be quite easy to implement. That's what I'll do next.

Furthermore, I plan to make GUI for inventory, journal and quests. Later there'll be trading, equipment and player stats screens. There will probably not be based around the dialog window that I use for examining and dialoging.

This opens doors

Today I've been practising with opening and closing doors via the Animator in Unity. I got rid of all the DoorScene stuff that caused me all the grief because changing Scenes was buggy and I rebuilt a Door object consisting of a pivot and a cube, plus an empty object Orientation for later use. What I wanted to do is just like in the older version, which is opening and closing it without major bugs, so I added a couple of animations:

I find myself having a strange talent in making things that are kind of creepy in their just-not-rightness, like the old Creepy Guy that turned to watch your every move. I don't know what is creepy about the doors really, but they are, in some way.

So I needed to plug the animations in an Animator component. Then I replaced the doors by the prefab I was working on and voilà, doors that actually work:

 Doors are now just objects with a type Door and a name to show on the UI when looking at them. Depending on the type, the UI also shows a message to press E to pick up, open/close, interact or whatever one can do with certain types of objects. Pressing E then changes a flag in the door object and triggers a parameter that controls the animation to run. When the door swings open, the player can walk through, because the collider of the door moves aside. Just like in real life.

Another very related thing I did was with the red ball. I can now really pick it up. Earlier I announced that I could, but yesterday I saw that adding the ball to the inventory object did not really add it. I don't really know why, but I managed to fix it by letting the Inventory class derive from MonoBehaviour and then connect it to the player.

Next I'll add two basic elements to the screen, the major healthbars (health and fatigue) to the bottom left and a minimap to the top right. Not the nicest thing to do, but I'm trying to get the basic UI out of the way as soon as I can because I can then focus on the game mechanics like NPC behaviour, quests and combat.There'll be enough GUI stuff to do anyway.

Just idly looking at the code

It seems that sometimes, one does not produce any new lines of code in a day and still feels productive. Maybe it's me, but usually, those are key days for me, because those are the days ideas just happen.

Today, I was thinking about objects in my game and how to interact with them. Had a little conversation online about destroying and deactivating them and in the future, arrows will be pooled and deactivated,  while money'll be destroyed.  Furthermore, I will have the inventory class derive from monobehaviour, so I can add it to the player directly,  because why should I instantiate it manually?

Those doors have been a torn in my side too long, so they'll be gone and replaced by something else that I will build myself and not take from a tutorial.

Funny thing about failure and idleness is that it gets under my skin and that brings the will to conjure up solutions.

Am I already some modern day Confucius?

A lot of small victories

So, last post was kind of a cry for help and while I did get reactions on Twitter, I have not yet been bale to have the scene management my way. I'm going to let that rest for a moment and revisit that when I feel like it and focus on some of the other things I need. More specific, I focussed on the health system inventory and the inventory for characters.

For the health system, I dreamt up a simple class that tracks current values and maximum values for health, fatigue and oxigen. There's a couple of methods to get the values, edit them, and make calculations to find out how far the respective bar should be filled when I implement it. I have the code for the bars on the shelf from my older iteration of this game and I'll add the oxigen to the mechanics for when the player is under water (so later). 

It is nice though to have a little thing under my belt after the scene problems. It makes the project go on. Always nice to have things that you know are going to be alright to keep the pace and help motivating, because I might not look it, but I'm human after all, and that is what seems to work with us.

Another thing that I made is the framework for the inventory system that I can use with both the player and NPC's (and maybe even things like chests and cupboards). Any inventory holds only two fields: an amount of coins and a list of objects. That's what a certain inventory can be. It then has a number of methods to control the amount of coins and to add, remove and find objects, plus a number of methods to exchange stuff with another inventory, like selling, buying and finding out if either of the inventories has enough money to buy an object that the other one may or may not have.

While that all is kind of theoretical, I wanted to implement something practical, so I got the inventory to get to work.You see this shiny red ball right in front of you? Take a look at it and see the crosshair focus and change shape as you get closer. When you get close enough, there'll be a message that you can pick up the ball and when you press E, you pick it up. That entails adding it to the inventory, setting it inactive in the scene and showing some message in the GUI. 

Now that I picked up the ball, and I am able to pick up other things (I'll wait a bit before I implement other interaction types), I can start working on the inventory display to show that I have something. Another thing is implementing the healthbar and fatigue bar and then I'll start working on the minimap. If I have that, I'll have most features that I had in the older game, but then better structured.

Glad to have something to cheer about now. I'm sure I can fix the problem I had this weekend.

Inventory is difficult but rewarding

Sometimes they say you only know what you have once you lose it. That is not true. I strongly object you know it when you try to show it on the UI. That's how the saying should go. It's been a couple of days now that I'm working on the inventory for my game. Because I'm still a noob, I'm letting myself be guided by an excellent tutorial that I found. Thank you, Craig! This tutorial helped me a lot and taught me the basics of keeping UI and the items separated and somehow I learned enough to get my own spin to it, which is most rewarding of it all.

What I have now looks kind of like the screenshot I shared the other day, but with some differences:

The first difference - and the main one - is that the UI actually reacts to the inventory that is there in the game itself. I have a sword and some coloured balls to pick up in this development scene and the UI reacts nicely to picking them up, so that it nice.

Second is the picture and info to the right. Obviously, that could use some font sizing, but it looks alright and I'm pretty pleased with my home-made sword sprite-placeholder. What it does now is that it finds the first item when building up the list on the right and using the same mechanic to show info of the object, but in another configuration (if that's correct English).

Later, I'll have it react to clicking on the list to the left. The pictures on the top will filter certain kinds of objects (e.g. Weapons or Food which mostly have very different uses, while apples might be inefficient projectiles too). The kind of thing that is selected will also influence the button the bottom right. Swords can be wielded, keys can't. Apples can be eaten, shields can't.

Next, I'll have the UI react to the clicking and refresh the panel to the right. Furthermore, I'll try and implement dropping objects like in Skyrim. I'll probably save the actual usage of objects for later.

What have you got?

A quick update from the car (wife's driving). The last couple of days were quite busy, but yesterday night I found some time to start work on the inventory panel.  It looks quite nice. I am having trouble positioning the stuff in Unity, that's why I needed to tweak some things in the inspector to show the screenshot.

It is kind of based on the screen in Elder Scrolls IV Oblivion. Most of the images are probably placeholders and nothing is interactive yet, but I'm glad it populates alright. More work to do.