Note : Godot 3.2.1, Blender 2.83, Gimp 2.10.18.
Last night, as I was settling in for the night, a thought popped into my head :
"Maybe, making a free-roaming puzzle point&click game where the player can explore an entire semi-realistic castle
wasn't such a great idea ..."
In case you're wondering why I might think such a thing :
1) It's A LOT of work to create all the assets (a castle is a big place, and you can't
exactly have an empty castle either...). And when these (background) assets are done, I still need to create
all the gameplay : design puzzles, create interactive objects, code an inventory system / game load and save / ...,
do sound and graphical effects, and finally, make the whole thing 'fun to play'.
2) Non-narrative driven puzzle point&click games are a bit ... niche. Meaning : there isn't
a crowd of people 'eagerly anticipating' the game. In other words : a small ROI (return of investment).
So, 'why am I still going ahead with this long-term endeavour', you ask ?
Good question ... 🙃
Anyway.
Since the last blog post, I've been finishing up work on the stairs (for this particular level).
It's amazing how much can go wrong ...
I've also put in some ladders
going up to the top floor of the castle, but they aren't functional yet. Figuring out how to code this
will be fun (?).
And I started putting in rooms.
As the castle levels are becoming more detailed, I had to adjust my workflow a bit.
Instead of exporting an entire location at once (eg. castle level 2, left wing), I
now export it in multiple parts (eg. collision shapes, outer walls, inner walls, etc.).
This not only results in quicker exports, but it also makes the Godot scenes more organized.
And finally, another small workflow change. It's something that I found out by watching a
tutorial (silly me never figured this out) : it's perfectly all right to export -without- materials (as
long as you create the empty material slot(s) in Blender). Duh !
Problem 1 : after putting in a ladder, I became aware of a problem with my currently implemented player movement code.
Almost all modern-day first person games have the player camera follow mouse movements.
This has a lot of advantages : instant change in player movement direction, everything in the environment
is visible, and the player can easily interact with what he sees.
But it also gives me motion sickness.
I actually quite like the gameplay in pre-rendered games (where you click arrows on the screen
to move to the next location). I find it ... peaceful. It promotes slow play, with time to pay
attention to details (and make maps !).
Of course, the problem with that is that player movement is very limited : you can't look around,
so a big part of the world is invisible and cannot be interacted with.
So ... what would be a good middle ground then ?
Well, the code I'm currently using lets the player move forward, backward, left, and right (sideways),
as well as turn in 90 degree increments. I also have a 'look around' mode implemented through mouse drag.
I've been kind of happy with this, but ...
... can you spot the problem ?
The moment you let go of the mouse (look around), the view snaps back
and you can no longer interact with anything below/above your view level.
This means I have to rethink how I'm going to combine a fixed cam while moving with a free cam when standing still ...
Problem 2 : I also noticed some weirdness
that seems to happen when the player is close and oblique to a shadowed wall.
I'm not entirely sure why that is happening ... or if it even is a bug. But I do
know that I don't like the way it looks.
So. Time to put in some more rooms ...