Well. I can't believe another month has gone by since the last blog entry ...
Where has all that time gone ???
Unfortunatly, there's not that much that I can show here ...
Most of my time has been spent writing code and creating temporary art for the puzzles. I have about 60 blueprints now, which seems like a ridiculous amount for a simple point&click game ... And not all of the puzzles have been added to the game yet, so that number will go up.
Some of the puzzles were actually quite tricky to program in blueprints ...
In a 2D-game, you have multiple layers for the various assets (like you have in Photoshop or Gimp).
And assets can be of various types : a single sprite, a flipbook of sprites, an actor, a child actor component, .... You get the idea (yes, a bit like Flash). All of these assets have their own special ways of knowing when they are visible, or when they can be interacted with.
It actually took me a while to figure out how to make blueprint components invisible AND non-interactable ... And of course, accessing components from other blueprints is still tricky ...
I also try to organize my code as best as possible. That's why I have 'chunks' of reusable code ('base' or 'parent' blueprints)
that I have named BP_Room, BP_Icon, BP_InteractableObject, etc. These 'base' BPs only contain code and components (sprites etc.)
that I can reuse in the child BP's ('real' rooms or icons). So, nothing too specific.
UE4 lets you easily create a child BP based on a parent BP. So, I created BP_Room_Livr_Fpl (fireplace in livingroom), BP_Room_Livr_Monk (painting of monk in livingroom), etc. These child BPs automatically get all the code that is inside BP_Room.
"Well, " I can here you think, "I can do the same thing just by making copies of BP_Room. Why do I need this complicated stuff ?".
Good question !
If you later on decide you need to change for example, the way you navigate inside a room ... you
will have to change that code in ALL of your rooms ! I, on the other hand, will only need to make a change in
BP_Room ... and all the child rooms will automatically be changed too !
Could be an interesting trick, don't you think ?! :-)
As you can see in the previous image, BP_Room already contains some sprites : a background sprite 'bg' that I can easily swap out in the child BPs, and 4 navigation sprites (L, R, U, D) with the appropriate code already present. These 4 sprites need to be in a layer above the background (or else you won't be able to see them of course). The navigation sprites just need to be set to visible/interactive depending on the room I'm in. Easy ! :-)
The child BP in the image also contains 2 'child actor components' : 'mirrorBtn' and 'catsFpl'.
Child actor components refer to other blueprints (here : BP_IA_Simple_MirrorBtn and BP_IA_Magnet_CatsFpl). You can use child actor components to easily position actor blueprints on a background sprite (by dragging them around).
As you have probably guessed, 'BP_IA_Simple_MirrorBtn' and 'BP_IA_Magnet_CatsFpl' are child BPs derived from 2 other parent BPs.
'BP_IA_Simple' represents an object that you can interact with in the game (something you can pick up). It
already has the code to remove itself from the scene (when clicked), and show the appropriate icon in the inventory.
'BP_IA_Magnet' is a 'hotspot' (a place where you can put something). It has the code to recognize the correct item, and make the appropriate icon disappear from the inventory.
All children of 'BP_IA_Simple' & 'BP_IA_Magnet' now 'only' need to be 'tweaked' to add the more 'specific' actions ... (I wish it was really that simple ! :-))
So. Now for some non-code stuff ...
My conclusions about my 2D-game workflow : I think that in the end, this workflow is not really suited
for me because of the way I create games.
Some people can sit down and create an entire game with just a sheet of paper and a pencil. When the 'creative process' is finished, they know exactly what kind of assets they need to create, and how the code will need to be structured.
My brain refuses to work like that.
I need to see the environment, walk around in it, get to know it ... and only then will the inspiration for the puzzles come to me ... That means : rendering the same background view many times, each time with some small change in it. Fortunately, rendering is really quick in Blender, with such simple graphics ...
What's still on my todo list ?
Way too much, if you ask me ! :-)
I still have to include about half of the puzzles, fiddle with the lighting setup in Blender, render the final sprites, find sound effects to add to the game, and create the startup screen. This will also be the first time I try distributing a game with UE4 ... So that might turn out to be an adventure in itself ...