And Half A Fish Games.

And Half A Fish
Games

Finding Fifi. Sep 15, 2015 - Writing code in UE4 ...

I have been knee-deep in code, these past few weeks. So this update will be small, mostly about code (UE4 blueprints), and maybe not that interesting to most people ... I'll just talk a bit about what I've been trying to do, and how that has been going ...

Mockup of inventory system. I managed to cobble together a small inventory system for the game (mockup on the left). The inventory has a fixed number of slots that are visible in the game at all time. There are also 2 buttons to scroll through to slots that contain items, but that are not currently visible. I also have a button that renders a detail view window for some of the inventory items.

An interactable. I have set up a system for items that you can interact with in the scene. When you click one of these 'interactables', it disappears from the scene, and the correct icon is added to the next available slot in the inventory.

I'm now trying to finish up the detail view window functionality. Some of the detail views can be interacted with, eg/ leafing through a book, or clicking a button. What I still need to implement though, is the ability to skip some of these interactive views when they are no longer relevant. For instance, if an item was unlocked with a key, the detail view should never again show the item in the locked state.

Detail view : a locked book. Detail view : an unlocked book. Detail view : leafing through the book.
Detail view : locked book > unlocked book > leafing through the contents.

The other bit of functionality that is still missing from the game, is items interacting with other items ... Kind of a big deal in point&click games, wouldn't you say ? :-)

...

About working with UE4 ...

This is my first time creating a 2D point&click game with UE4. As always, when you're coding things, there's different ways in which you can accomplish these 'things'.

blueprints : the OOP way. I have chosen to go the OOP way. For those of you that are not programmers, that means I create classes and objects (indepentent pieces of code) for almost everything in the game : an object for the inventory, an object for every possible icon in the inventory, an object for every 'interactable' in the scene, ...
You get the picture : lots and lots of blueprints !

Now that's all well and fine, but I've found that things quickly become very confusing with blueprints. The code inside a blueprint (class) is split into different views : a view for the 'visible stuff' (sprites or 3D models), another view where you can initialize things (constructor function), a third view for events such as gameBeginPlay, mouseOver, etc, and finally, a separate view for -every- custom function you write !

Blueprint view : viewport. Blueprint view : constructionscript.
Different views inside a blueprint : sprites & constructor.
Blueprint view : eventgraph. Blueprint view : custom functions.
Different views inside a blueprint : events & custom functions.

This made me wonder if it wouldn't have been easier to use a more 'procedural' style of coding : one large 'slab' of code in the UE Player Controller blueprint, or in the UE Level blueprint. That, combined with 'raw' sprites (not wrapped in a blueprint) ... I don't know ...
And, no, I'm not going to start over so I can find out ! :-)

For me, this is definitely one of the weaker points of blueprints : you quickly lose track of where things are ... Another weak point, in my opinion, is the inability to comment out nodes. Commenting out code is a valuable tool for debugging, or for quickly jotting down ideas that you can flesh out at a later point.
In blueprints : if the code doesn't work ... you either fix it, or you remove it !

Access Denied. Something I was struggling with a lot in the beginning, was how to reliably access objects (blueprints) from other blueprints. And related to that : at what point do objects become 'available' in the game (when do they exist) ?
I'm sure there's some kind of system there ; I just haven't figured it out yet ...

The way I've solved these problems for myself, is by having blueprints 'register' themselves to the PlayerController blueprint when the game starts playing, or when the blueprint gets instantiated. Since the PlayerController is easily accessible from all other blueprints, this system seems to work fine for me ...

All in all, I'm still pretty happy with Unreal Engine 4, and even with the blueprint system ... :-)

Although, I did have one MAJOR SCARE ... I was trying to open the project that I had been working on the night before, but this immediately crashed the engine. It also produced a HUGE log file (17 GB ! Yes ! GB !) that was completely useless because no editor would open such a monster file ...
The future of my project seemed bleak ...

In the end I did manage to somehow solve the problem (AnswerHub is great, and so are the UE admins !). My project had some reference errors (still clueless as to why that happened in the first place) that were easily fixed with some copy/paste actions in the Windows Explorer, and some small tweaks in the UE editor ...
All in all, it cost me a day, but strangely enough, I also felt much more comfortable using UE4. If you can fix a problem like that ... you will most likely be able to fix any future problem ... (knock on wood).