Objects and children

So, yesterday I added a lot of AI behaviour for the Unfriendly Guy, the guy in the red capsule and it went quite ok. I had some code from my old iteration of the game that had a finite state machine in it and I copied it to the new one, with some additions and changes. When I tested the patrolling behaviour, this happened:

When I could not immediately spot it, I decided to call it a day and have a look later, because it was already quite late and I was tired, but I found it oddly regular what Unfriendly Guy was doing, so no worries. I can fix this easily with a fresh look.

So I turned on my computer this morning and this is what I saw:

Here is the problem. The fact that all was so regular and nice was because the script was working just fine. The NavMeshAgent (the green cylinder) was doing exactly as planned and walking from waypoint to waypoint, avoiding the walls. All I needed to do was make sure the guy was at the same position and rotation. The body was at a different place than it was supposed to be. So I put the Z and Z axis of the body to zero and moved the cylinder to the place where the body was standing, taking the body with me. Now it works.

So, note to self and my first tutorial-a-like thing: when you move objects, make sure you move the right object if they are connected and you want them to be at the same transform.

A friendly NPC to console me

Sorry, but I'm a bit cynical today. Today was the day my favorite team really relegated. They could get second to last, but a 0-4 loss is just enough. Having said that, I needed a friend to console me and who better to have as a friend as one you can create yourself: The Friendly Guy.

Friendly stands next to a wall, arms wide open and has a certain presence in having components in Unity. Further, I saw worse goalkeepers today, but Friendly Guy does not do anything at all. Yhe player script understands it's something to talk to, but that won't get you very far yet. Tomorrow perhaps. For now, this is my new friend supporting me in these hard times.

Other things I did today are less visible and less comforting, but useful to keep track of objects(and probably better goalkeepers too). In short, what it comes down to is that I created several short scripts to help distinguish between different types of WorldObjects. All interactable things will have a WorldObject component to make them visible in the GUI and the rest is up to those components. 

Doors have opening and closing mechanisms, weapons can be swinged, food can be eaten. That kind of stuff. I had some door swinging behaviour in the world object and I wanted to get that to a specific script so that I might not risk opening and closing apples later. Not fun, not exciting, but important to make the programming job easier in the long run. So it's good. Better than some goalkeeper, I might add.

Small GUI additions

Today, I had about 2 hours to work on my game, as we just returned from the inlaws (which are lovely people) and I tend not to take my laptop with me when going for visits to them. Thats one of the perks of Easter. The aim of Easter is obviously to work on games - or else they wouldn't have called those funny features Easter Eggs - but now I hardly had any time.

What I did do is a couple of small things. First I changed the direction markers of the minimap to make sure to the front is always upright. I used to have the markers standing upright when facing north, but that did not make sense. Now the marker will be better. I will probably make the yellow player marker a bit bigger later, but I'm not sure yet. It all depends on how it will be in proportion once I put other elements in. Whetever that is going to be, don't expect the minimap showing random elements like "red ball". I found a quote on Twitter this week. If you put vital information on the minimap, players will look at the minimap and not at the game. We should avoid that, shouldn't we?

Another thing I made was a little change in the interaction script. Things could be interacted with if they had a WorldObject component, which is probably not very flexible, so I changed that to checking for a tag. Once the tag is correct, the interaction routine will find out what kind of interactible object we're looking at and that saves getting non-existent components. Not too big of a change, but a change nonetheless. I'm probably changing that later still, when I will have classes derive from the WorldObject, but we'll see how that goes.

Lastly, I reintroduced the Healthbar. I wanted to make it flexible too, so I made a system that will be able to be introduced with enemies and other guys too. One just links a health system and it'll be able to show health and fatigue for the health system. It all happend by changing the scale of a pivot object:

The only thing I now need to do is add a health system to the player and make it calculate the values of the scale between 0 and 1. That value should be the scale of the pivot.

Having said that, that is the bit of UI I wanted to do in the short run. After linking the bars to the player, I'll enter my first NPC, a friendly guy that will give a quest involving a red ball, probably. That'll take a lot of extra steps. I'll need a guy graphic (which is going to be very poor), a quest system, a journal and a bit of interaction between the player and the NPC. Should be enough for the week.

North, East, South, West

I already had a mini-map in my old game, but I was not happy with it, because it lacked flexibility to have other objects plug in or not. That's why i decided to rebuild it and make a camera that can only see specific kinds of things: objects with a MiniMap layer.

I put a Camera way over the player object and let it look straight down. It does not actually look for the objects on the ground, but at quad objects, flying in the air. Game development is sometimes just magic, because we're talking about three-dimensional objects that only have one side. Rotate them right and you can draw something on the top side and from the side and the bottom, you can see straight through it. Next, remove all shadow casting and receiving and remove the collider and we're good to go.

I also put NESW markers on the side of the minimap to indicate the direction the player is going. The player always goes upwards on the screen. Now that I'm writing this, I see the markers rotate wrongly. If you're going south, they will be upside down. That I'll fix later this week. 

Now It's time to go to bed. Happy Easter everyone.

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 new Unity version

Alright. So nobody into gamedev videos could have missed this. Unity is releasing a new version: 2019.1. A lot of people are excited by the new rendering update with the video that was presented at the conference a couple of weeks ago. Myself, not having scratched the surface of the current 2018.3 versions, I just see extra options that I did not know about yet.

What caught my eye was a demo on terrain creation. I have worked with it in the past, but am looking forward to the new options in making bridges, erosion and the like. I saw the video in the bus today and it sparked my fantasy vibe in map making, a hobby from high school time. Not that I made a map or something,  but I surely will soon.

I did not do much programming today. Bit failing around on Blender,  trying make a sword. For the rest, tv time is important to.

Anyway,  here's the video I'm talking about ..

Making things eternal

So, back to the Scene Manager. I kind of have the idea I'm making progress, but I'm not sure how and why, but hey, i'm a programmer and those memes somehow sometimes just are true and there's no use trying to find out how.

What I'm trying to do is to make sure some objects in the game are cross-scene, so essentially eternal. For instance, the player state should not suddenly change to him having another inventory or maximum health or anything like that, so I took that script with me. Unity then makes the entire player object eternal, which is ok with me. another one is the WorldObject, because if I pick up a ball on level 1 and go to level 2 and back, I would not expect the ball to be both where I found it and in my inventory, so I need to keep track of the position and activeness of the object. That does not yet completely work, so I'll have a look later.

Anyway, it's late and I'm to hit the sack now. New day tomorrow.

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.

Scene Management Trouble

Another technical post today, because I'm having problems again. Yesterday evening, I started trying to get the rotation right when getting through a door to another scene.I have this GameHandler singleton that controls some things that should not be lost when changing scenes. In this case, it's a door number and a rotation .

When changing scenes, the plan is that the GameHandler gives information to the player-scripts to put him on the right position (which often works) and rotation (which does not seem to work).

In short: I have two problems. 

1. First I can't figure out why sometimes the scene puts the player on the 0,0,0-position when loading and how to fix that.
2. Second, somehow I can't get the rotation of the player to work to look at the door orientation point or to keep the rotation that he had in the previous scene.

Here's my project on GitHub: https://github.com/Xrocetoxtos/RPG2

Walking down

Good morning from the bus on my way to the day job. Last week, I wrote that I was starting my RPG project over and would make sure to get the basics right from the get go and then expand.  So yesterday evening I had to scratch the majority of the movement mechanics because I wanted to add something. 

We had a player objects with a Rigidbody component in Unity and that object gets the order to move around, which does work. Except when it does not. You see, there is this thing called gravity that pushes objects down. We know that and your historian-programmer probable isn't the one to explain that. Let me just ignore the actual physics and tell what happens to the player. 

We're standing on top of a ramp or hill and that red ball at the bottom sure looks alluring, so let's go there. You take the first step forward and gravity pulls you down. Then the next.

This sounds alright, but it is not. This makes for a series of bounces, because, contrary to actual humans, the player does not really step up or down. He walks forward and gravity does the rest.

Now I am not a anatomy expert either (blogging is a humbling experience) but I figure I need to have somthing resembling stepping down and blocking and controlling gravity or something to support gravity so the player does not walk ahead and fall, but actually experiences the down force while walking.  I know from walking downstairs this morning that we use our legs to catch the gravity, but I'm picking option B.

Long story short, because it was a hours job causing all kind of weird problems.  I now have a CharacterController component replacing the Rigidbody and that one shoots down rays to find out how they reflect on the floor. If they go up, no problem.  If they go backwards, we're walking uphill and that goes fine anyway. If we're going down, there is an additional force down pushing the player to the floor. Quite pleased about it.

Now I kind of have the movement finished. I do need to have something to make sure that a player does not get stuck when standing up from a crouching position in a confined space. Today however, I'm going to the football game anf and I'll be home late. Maybe tomorrow.

For this week, I hope to be able to have the crosshair react to distance to an object and have the GUI mention the object.  Hence the red ball. Furthermore I want to enhance the scene management to work from the door itself and make sure the player does not look at the door after entering. Should be possible.

Crouch!

Alright, an update from the bus. Yesterday, I made some adjustments to the deep water mask because I got some feedback from a colleague who thought it was not watery enough and it looked more like fog. I might change it again later. Besides, maybe I'll have the opacity change from code to reflect the player being deeper.

I also dropped a red ball in the scene and named it Red ball. Nothing much happens here. Idea is that the player can look at it with the crosshair and have the GUI show the info.  Later I'll implement picking it up. I need that for interacting with objects. The door script now just triggers on being near the door and pressing the key. I need the player to look at the door directly for it to work. Doors are just other kinds of balls, so if a ball works, it's a small step to make the door work. 

Lastly, I made something that my old game did not have yet: a player state script to keep track of what the player is up to. Now it only tracks if the player is running or not and if he's crouching. This datascript will be referenced from different scripts, most notably the game handler and the movement script. 

The first thing implemented is basic crouching.  It's not finished yet, but for now it just makes the player smaller and the camera lower when pressing Ctrl. Next time on Ctrl, the player goes back to the original size.

This works, with a little drop when getting smaller. It does not, however change the size of the collider and I want the camera to clamp differently when crouching, so that'll be work. Now to the office and earn money first.

Deep water

In the previous version of my RPG I had this too, but it was implemented in a PlayerInteract script and the color was not really all that awesome, so I decided not to copy it from the old version, but to rebuild it. We're talking about the Deep Water Mask, a blue glow across the screen to notify the player he's below the surface of the water. When the screen in blue, it means special physics are there (which are not implemented yet) and there will be trouble once you're out of oxigen.

This is our test scene without DWM:

And this is the same scene with DWM, so below the surface of the water:

Another thing I implemented is that I put the crosshair in the center of the screen. It does not do anything yet, but the script understand that it's a special object it might want to reference and modify in code. 

All in all, this was just a bit of tinyness that needs to be done, but does not take a lot of time. The script behind the things is not implemented yet. The crosshair will have its parts move to the center when pointing to something near and wide as it is in the picture, when pointing to something far away or not pointing to anything at all. the mask will be activated when the player is below the surface of the water, as explained in my earlier article on Drowning.

this week I'll finish the scene management that I was working on yesterday, as well as the implementation of the crosshair. For that, I'll be introducing some objects to interact and a script for the player to interact with the objects (starting with looking at then and gaining information)

The Choose-a-door-dilemma

Yay, I did what I set out to do. I got myself a working Scene Manager. Idea is that I have a singleton object that'll keep track of a couple of things that I'm not going to like being renewed when swapping between scenes. That GameHandler script will remember what door I'm passing through and any door in Scene 1 will have its nemesis in Scene 2, so whenever the player gets through door 1 to another scene, the script is able to find the corresponding door and place the player in front of that. I tested it with a couple of doors that make the playes go to another scene and find a specific spot there. That works.

Now I only need to adjust the rotation of the player to get through the door and not look straight at in, but have it at its back. That's for tomorrow,

The other thing I did was implement some running behaviour for the player and make sure walking backwards is not as fast as walking forward.

Starting over

So, scary title perhaps and I can almost see the individual shivers running down the spine, but I feel good about starting over. I'm not tossing out the project by any means, but I am going for a major code cleanup, so I'm reimplementing the features that I already made.

This weekend I was working on a system to move from scene to scene via doors and I found that many of the things I needed were all over the place in scripts that I needed to copy to the other scenes. Next I needed to find a way to influence the position for the player on return.

That kind of stuff is inevitable when you are learning to work with Unity, but it makes for terrible messes. Now I think is the time to start over and overthink the projects buildup more. I need a new feature, then I need to think about what implementation it gets. Now that I have my Github set up, I can go back, but it'll preferably be to a good basis.

Today, I reset the walking mechanic and the looking around. Next, and I will plan better, I will  implement changing scenes in a generic way. Looking forward to making it better.

Ideas about design

Making a game is actually more than making a game, even if that sounds contradictory. Being a programmer, I know that the trick often is not in the algorithm or the user interface, but in finding out what to make exactly anyway. In games that's even more than in the day job, because there's nothing much creative about calculating interest or about making a secure connection. It just has to be correct.

Games, on the other hand, those are different, because they need to be compelling. The game I have right now, it might be mostly bug free for now, barring stuff I didn't implement yet, but that does by no means make it a good game yet.

When the forest guy sees me, it'll say "HELLOOOOO" on the console and that's intended. But it's not fun. It does not trigger me to go and get seen or to avoid that. In my posts on AI I discussed this before.  The guy needs to do something related to the seeing to make it stand out and that is not finished yet.

What is he supposed to do then? Well, I don't know exactly yet. Zombies will mindlessly attack and kill or get killed, that's easy. Quest givers will ask for attention and give a quest. But there must be something to distinguish between different characters and settings to make them be their own thing. That's design.

I don't have much experience with that, even though I consider myself a so-called idea guy in some sense. Problem is those ideas flash by and need to be caught and processed. The processing takes time and effort and that's fine, but it takes the pace of the project and that feels strange.

No problem though. With all this rambling and ranting going on, one needs to remember that sometimes inspiration lies right before your eyes. Just ideas waiting to pop up. The church in the town I work in, it has a weird tilting tower, they found a Roman boat in the park near my house, the busses at the station always get in each other's way, a couple of weeks ago, me and my wife visited a castle with nice gardens. I found a website with example medieval city planning ideas.

All of them possible games to be made or ideas to make games better and more actually mine. Assets are all nice and shiny, but these things make a difference. Now back to work and stop the crap!

I can't draw

Well, it's not like this'll be a surprize to anyone, but no, I can't draw and that's why I make due with primitive shapes for my AI agents in the game. I'm well aware that humans are not capsules, but pretend they are.

Having said that, I recently got a tweet about a game jam for people like me, a game jam for people who can't draw, starting in just over a week. As I most certainly qualify, I'll most likely give it a try and I'm thinking of a battle royal game in the top-down style of the early Grand Theft Auto games, but with idiotic weapons. I need to find out how network stuff works in Unity, but I have time. It'll be fun, I hope.  Never did anything like a game jam, so...

In the meantime, my 30 minutes Unity for yesterday were in making sure the minimap in my game views enemies in red and non-hostile NPC's in green, from code. And I'm still reading the AI book.