New Interaction Hub Class, Plus some info on the Save Structure I've been building up.

A day late I fear. Anyhow this is what I've been working on. As I discussed earlier I have the interaction actor swapped out for a new class, an interaction hub. Instead of separate class for each button-- as I had initially set out-- I now have meshes connected to scene components serving the same function. 

You can see the hub's open and closed state works we'll. The actions associated with the hub, flagged in editor by a series of bools will become un-hidden and have collision enabled when the central mesh is clicked. 

Here you can see the enumeration's which feed into the Event Dispatcher that goes to the level blueprint. Where I have a switch statement triggering events from there. I will keep fiddling with BP communications because I'd like to have scaling classless that register events on their own. but for now I'll push forward. 

Now I'll talk a bit about the save structure. I have a class of save object called a slave slot and I have a "Defaults" save Object that will save the active save slot and rerecord it each time the game is launched.

The below are from the Level Blueprint on what will be the Main Menu Level.

I believe below is the sequence that branches to the creation of the save slots after "Then 0" position and "Then 1" position goes to a branch that verifies the existence of the "Defaults" and if it finds none creates it and sets the first save slot as the default save that will load when the game starts.

Bellow you can see where I have meshes in the main menu level register clicks and designate which save slot as active.                                     

I'll point out now the save structure as of this writing isn't fully implemented but by later this evening I"ll have it loading levels and saving and loading test variables. 

And here is a look at my trippy looking place holder main menu level. 

What's left to do? A metric Tonne. For example I'm still not happy with the IA hub as far as placement of buttons. I've attached them to scene components so they can be moved around. 

I also have to go back to the camera actor and implement a method of moving the camera while the player is moving in done direction or the other. 

Next month I'll start working on that conversation engine that I've been chomping at the bit to make. Remember I'm using unreal 4.2. So, no UMG for me.   See you next time.

Blueprint Comms in a Content Driven Format.

So, lately I've been busy. It's true, but also I've been banging my head against a fundamental problem with the interaction actor. One that lead me to build the whole thing a new. Instead of having interaction buttons, which were in and of themselves their own class, I've elected to have possible actions represented by meshes that will fire event dispatchers on clicked to the level Blueprint.

This isn't as elegant or scalable as I'd originally designed, but it overcomes some immediate hurdles that had become something of a time sink.

For example the old button class was a devil to get any kind of recognition on mouse over events. Easy enough with the trace function but when the button is assigned as a child actor component of the Interaction Actor getting it to register events and communicate, became problematic.

This may be a problem I'll go back and revisit at some point in the future, but for now I want to advance the prototype and circumventing my lack of experience with Actor/child actor class communications seems like the best way forward.

Of course this also has me thinking about storing player/story variables. As variables will need to be checked to gate, and fire events.

I'm starting to realize that this project, being an adventure game, is going to lean heavily on Level Blueprint scripting instead of just making beautiful, elegant classes that do everything I could hope for. Is there any reason it can't be a little bit of both?

Either way you learn something from every project you work on.

Expect an update on the 28th to show you what I've got.

After the Break: The Proto-Interaction Actor

I lost a month as far as updates preparing for a job (interview/test)  and I'm a bit behind.

I'll walk you through what I've had and what features the interaction actor will have.

The first one was easy to implement. An interaction actor has a state known as active controlled by a bool. If it's not set to true, then no other part of the interaction actor will fire.

The interaction actor like, the intractable elements in a TaleTale game will have a kind of opened and closed state where the base icon will highlight and expand when the cursor moves over it.

Upon clicking a highlighted interaction actor the available actions are displayed.  I call them Interaction Buttons. I've built them as a separate class, because I believed it would help me in scale ability. It's essentially a plane with a bill boarding material.

My decision to make the button a separate class has been kind of a problematic one as having the Interaction Buttons created as components of the Interaction Actor during the construction script has been a cinch but having them function off the scripts in their own class has been kind of iffy. 

I attach the buttons by spawning them in an update button function. I attach them to components I've placed around the Interaction Actor itself. You may note that I'm using enumeration to determine button type. Talk, Use, Take, Force, are items on this list.

You may recognize the bauble from the Soulus project tutorials. I needed a quick mesh I could prototype with so I yanked the mesh from there. And of course the materials on the buttons are from the UE4 editor.

Here's a look at the function for changing the Buttons Material, a bit of it anyway but it's replicated across the different button types.

Have a video. 

In the current build they the interaction actors  don't swell up quite that much. 

What I want to accomplish in the next update.

Well, as I've said. I've eaten a bit of a delay. But I'm back on the case. Though I won't have the fundamental features down by February, as I'd ambitiously hoped the following are features I'm going to implement into the interaction actor this month.

I'll have the buttons executing scripts appropriate to their class.

I'll have the usable bool determine the rendering of the overall actor, and embarrassingly easy fix.

I'll have button visibility set when the actor is in an open state and when it is clicked.

I'll have the player turned to face open actors that the player has clicked on.  And that should see me busy for a couple weeks. I'll get back to it. I've got a bit of work to do before I catch up. 

Until next time.