3.5Cats_AndHalfAFish

Note : Godot 3.3, Blender 2.83, Gimp 2.10.18.

I've been finding it increasingly hard to concentrate on game development, with all the stuff that's been going on in the Real World. Most of the time, I'm feeling restless, antsy, and my brain has a hard time dealing with this fundamental uncertainty, the question of where things are headed for us all ...
Anyway ...

No real progress on the project ... =/
I'm at that point (again) where things don't look and feel the way I had pictured them in my mind, and I feel disappointed with myself, the engine, the world ... blah, blah, blah.
Not a nice place to be in, but so far, it has happened with every project I have worked on. It's just a matter of getting through this phase.

So. This is what I have spent my development time on :

Scale.

Something that has been bothering me for a long time is that the castle felt cramped, even though it was based (very loosely) on measurements of real castles.

As you may remember, earlier on (well, a long time ago) I had problems with the doors looking and feeling too narrow even though they were wider than real doors. I perhaps should have realized then, that the door problem was more than just a door problem. In-game cameras really do deform the game world quite a bit !

About a month ago, I finally bit the bullet and scaled up all my assets 1.5 times.
Yes, that's quite a lot. But the spacing feels much nicer now.
At the same time, I also made the collision meshes for the castle walls and all the assets much bigger/thicker (which in retrospect I probably shouldn't have done - see 'camera').

Since I have quite a number of rooms and assets, and rooms are split up into different export files in Blender, it took me some time to get all of this done. Unfortunately, I needed even more time to fix everything in Godot.

I've noticed this problem before : sometimes (not always) when you re-import existing assets, the location of some of the MeshInstance nodes is wrong (image below : the door mesh should be inside the arch mesh).
The only solution is then to manually copy x, y, and z values from the glb file into the scene file. Often, Godot also forgets what MeshInstance was selected in a scene ... so, that's a lot of clicking to do !

Other things that needed to be fixed manually were the size and location of Area nodes for hotspots and all kinds of effects (and yes, I already had a lot of them in the game).

Camera.

As I was checking out the scaled up castle, I started noticing this :

And this :

I know all game cameras have distortion, but goodness ...

I have spent a fair amount of time trying out all kinds of combinations of camera height, camera fov, camera rotation, asset scale and placement (rotation), ...
All to no avail.

In despair, I even fired up an old version of Unity that's still on my computer and imported that same scene into the engine. I couldn't get a character controller to work properly (without spending too much time), but I managed to set up the camera similarly to how it is set up in Godot.
Long story short : Unity seems to default to a vertical fov of 60, but the resulting view is about the same as in Godot with a fov of 70.

I also asked on social media, and I got some good advice from the Godot Discord channel : "There will be less deformation if the player cannot get too close to game assets (walls, trunks, ...)".

As I had recently scaled up all collision shapes in Blender, I thought I had already taken care of that ...

... but, as it turns out, there was something else I could do with the player setup : move the camera back (relative to the player capsule) :

I realize this camera position is probably a bit extreme, but since there's no wall clipping when the character is standing with his back against the wall, I'll leave it like this for now.
As an alternative, I also considered making the collisionshapes even 'thicker', but then you lose so much walkable area that it's just not a realistic option.

Some time later, I also got some information from Markus (' mw design' on Youtube), who is doing the most amazing things in Godot.
He basically confirmed that distance between the player camera and the game assets is the main thing in preventing very obvious deformations. His player collision capsule has a radius of 1, whereas mine was much smaller ...

One other thing I decided to try, was to add a vignette to the player camera. I was hoping that darkening the edges of the view would make edge deformation less visible :

Of course, if you really focus on the chests, you can still see the deformation, but I think it's a bit less 'in your face' now.

Hotspots.

I've talked about this topic many times already (eg. here, and here).
This isn't really surprising, since mouse-hotspot interaction -is- the main mechanism in point&click puzzle games.

In point&click puzzle games, interactable objects are often placed at eye-height, rather than on the floor. This makes things a bit more tricky, because a player could inadvertently interact with an object that is placed on the other side of the wall (in another room).

There are several ways this can be prevented, the 2 most obvious ways being :

• a mouse script that detects mouse-over events for both areas (hotspots) and static bodies (collision shapes eg. the wall).
  When the mouse moves over a wall, the event is disregarded (do nothing) ; hotspot areas behind walls are not discovered. For this to work, walls need to have collision shapes that go up all the way to the ceiling.
• a mouse script that detects areas (hotspots) but ignores static bodies.
  For this to work, additional areas have to be placed in the scene to set a perimeter for where the player is allowed to interact with the hotspot. That area node needs to be linked in a specific manner to the hotspot node (eg. linked by name).

Both methods have pros and cons.
If you use the 1st method with static bodies that are wider/thicker than the wall mesh, (as in my project) you have to make sure that area hotspots stick out enough. If they are completely inside the wall static body, the player will never be able to interact with them. An obvious advantage of this method is that nothing extra needs to be done to make it all work.
The second method is more flexible, because you can define the interaction zone precisely. There are no rules for the area hotspots. An obvious disadvantage is the requirement for additional area nodes in the scene + the code to link perimeter to hotspot.

Up until now, I have been using the second method in my game ...
Since things have started to look a bit cluttered, I have been thinking about ways to switch over to the 1st method. So far, I haven't found a good way (meaning : a way that doesn't complicate things even further) of implementing this.

Git.

I have been using git as an online backup, in addition to backup copies on my pc and an external hard drive.
But it suddenly occurred to me that there are better ways to use git, especially now that my project is getting bigger. I really wanted to start using 'dev branches' for whenever I needed to experiment with / implement new features without making the rest of the project unplayable.

I found this really good overview of git and TortoiseGit. It's short and to the point, and I can recommend it to anyone that's a bit fuzzy on using branches and other day-to-day basic stuff.

Todo.

After watching "Just make game - S1E1: Pre-production and planning", I (rather belatedly) decided to try and make a planning for my own game.
As I quickly noticed, it is almost impossible to do, because how can you decide how much time you're going to need to design (= invent) and implement all puzzles in the game ?

So, instead, I decided to make a list of all the thngs that still need to be done, but in -very broad- strokes. This is it :

Yup. Still some way to go.