Here's another update on my point&click game 'Finding Fifi' ... I hope you enjoy the read !
During the past couple of weeks I have been working on many different things for the game. One of the things I wanted to do, was fix the lighting in Blender. As you may remember from a previous blog, the lighting made everything look kind of flat. I don't necessarily think that's a bad thing for a simple point&click game, but I think the new lighting makes everything 'pop' a little bit more.
While I was working on the lighting, I actually came across two weird issues that took some time solving.
The first issue had to do with shadows in Blender. I would look at a scene through the camera, but without actually rendering the scene, and everything looked the way it should. Rendering the scene with that same camera and without changing anything ... made all shadows disappear.
As it turns out, this was actually quite an interesting 'bug'.
I originally used a sun lamp in combination with a hemi lamp to light my scene. The sun lamp was used to produce shadows ; the hemi lamp was used to increase the general illumination level.
So far so good.
What I had failed to realize though, is that you cannot use a sun lamp for indoor lighting ! You have to think of the sun lamp as a light source at infinite distance. So, its light (and shadows) will be stopped by the room walls & ceiling. The light can only enter a room through transparent materials (like windows).
Once I realized this, the solution was to simply replace the sun lamp with area lamps. Et voilà ! Shadows !
The other issue I had, happened when I started importing the new images into UE4.
All newly imported sprites suddenly started looking 'washed out' in UE4, while Gimp and Blender showed no difference between the two images.
The solution to this 'puzzle' came when I looked at the image properties in Windows photoviewer (of all things ... !). Turns out that the earlier images had a bit depth of 32 ; the newer ones somehow had a bit depth of 64. And clearly, UE4 did not know what to do with the 64 bit depth images ...
In case you're wondering : bit depth refers to the number of colors stored in an image. The higher the bit depth, the larger the size of the image (in my case : 460KB vs 2000KB).
I also spent some time thinking about spritesheets ... The internet community seems quite divided on this.
Some devs say you have to use them because it is much faster than loading a gazillion small sprites in your game.
Other people seem to think that spritesheets are not really that important anymore.
My understanding is, that at one time spritesheets were the way to go. But with our modern day computers it has become more a question of personal preferences (for smaller games).
While I was redoing all my sprites with the new lighting setup, I tried combining some of the smaller sprites
into a spritesheet.
UE4 has a good workflow for spritesheets : you can easily extract the individual sprites, either automatically, or manually.
However, what I found out is that I didn't find using spritesheets all that convenient in most cases. The moment you add / delete / scale / move an individual sprite on the spritesheet, you have a very real chance that your scenes will be very messed up in UE4.
So, in the end, I only used spritesheets for things like sprites in a flipbook. Not for 'normal' sprites.
The last 'vision' thing I want to talk about, is the problem I sometimes experience when I import a texture in UE4 : ugly borders !
This does not happen with all sprites, and frankly, I have no idea what's causing this ... :-(
I have tried different sprite materials in UE4, different 2D editors (Gimp, IrfanView, ...), a spritesheet, ...
Nothing seems to make a difference. Fortunately, sometimes the ugly borders get less pronounced when I adjust the 'render area' of the sprite in UE4.
I have been asking about this on Answerhub, but the lack of response seems to indicate that no one knows
what is causing this issue, or that no one is having this issue ...
Hopefully, I will be able to figure this out before I need to publish the game ...
I have started collecting some sound effects for the game.
Finding the right sounds for a game can be quite challenging, not to mention time consuming.
So far, most of the sounds have been obtained from Freesound, a great place with many free sounds.
It is very easy to use sound effects in UE4.
You just import your sound and convert it to a Cue, some sort of wrapper blueprint that lets a sound have location, volume, looping, ... etc.
You can also insert nodes in between the 'wave player' and the 'output' nodes (a mixer node to mix different sounds, a delay node, a random node, a switch node, etc.).
You then place the sound Cue somewhere in a game scene, and you're all set to go.
Because of the way my game has been set up, and since all sound effects are linked to specific objects in a room, I have chosen to add my sounds as 'audio components'. This makes it extremely easy to start and stop a sound 'on demand'.
There's really only one thing you need to remember with sound in UE4, and that's the format that UE4 can work with :
uncompressed, 16-bit, little endian WAV (any sampling rate, but preferably 44100Hz or 22050Hz).