An update?

So it's be a chasm of time since  I last updated. I had to put this project on hold while one, I picked up a dumb amount of hours at my day job to fund an upcoming move; and 2, worked on other projects that could be added to my portfolio at a faster rate.

The move basically is a milestone... a culmination of me letting go of certain things, people (one of them being me and some attitudes I had) and places that have been holding me back. It's been an uncertain time. Ten hour shifts at said day job haven't helped.

It's been a crazy year 2015. It hasn't left me a lot of time to work on things I care about and my main focus this year will be on getting a level design position. I've been obsessed with principals of level design. Slowly digesting books on the topic. I'd like to start a blog on principals of level and set design but if I'm honest I'm not really in  a position to get a lot done right now. I'll post a link here if I find the time.

Rest assured that one day I'd like to return to The Afterward, with more time, confidence, and experience to to leverage against it's completion. When that day comes I'll launch a new website and resend this one.

Talk to you guys later.

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.

Happy New Year

Happy new year from The Afterward Developer Blog.

December was Interaction Actor month, and a more thorough update is in the works. Holiday traveling and other issues have seen to it that not as much was done on The Afterward this month as I'd have liked.

Rest assured. In a few days I'll update what progress I have. They'll be pictures. And though it won't be the complete feature you'll get a look at how I pseudo coded and planned this feature to be somewhat scale-able and useful in a variety of situations.

I will also honestly report any hiccups I may have had.

Until then my friends.

Micro Update

I was a little chagrined by my last update so I wanted to post the improved Camera Actor in action. Here's a video.

You'll see the transition back to the template controller camera is no longer an issue, and you'll see that the  player input rotation is changed from volume to volume. I was trying to create the player turns a corner scenario found in adventure games where you want the player to stop moving down the same axis and start moving in another direction.  You can see test level screen captures after the video.

You can see by the screen shots I'm now using an independent set of trigger boxes that talk to the camera actors. And that I need to set those input axis indicators to "Hidden in Game".  I'm now thinking that I may want to get the change input axis functionality into the volume so that I can have more control of axis change without having to change cameras.

Up Next:

December will be Interaction Actor month. I've got some preliminary work done on it, by way of trace functions, but I'm having some trouble with having the little icons that indicate other actions existing as Child Actors.

 

Camera Actors and Input Axis

The first update! Well, -- the first update beyond the initial introductory update. This update is all about Camera Actors. Specifically the ones I'm making for The AfterWard.

The Custom Camera Actors and  an early test configuration.

Why are camera actors important?

I'm trying to capture the scene to scene mechanic and aesthetic of old adventure games, and more recent TaleTale Game entries into the genre. So a simple  follow camera isn't particularly interesting to me.

 Additonally, an adventure game (especially in 3 dimensions) isn't a painting that a player pawns moves on top of. The player moves through it. And sometimes it's useful to change the axis of input to create an ambiance, or encourage player movement in a particular direction or to even just have a pleasing and logical viewpoint.

Looking at The Wolf Among Us there are instances where the camera is behind the character as he moves down a hall way and shifts when he approaches a door.  Thinking back to Biggby's apartment you start in the kitchen and exit, and the input axis shifts slightly when you enter the main area. Hitting the W key  no longer moves the player along the same vector (which was away from the camera in the kitchen, specifically that dingy window) but now moves the character towards the new point of view at a logical offset from the kitchen exit.

I spent two to three minuets one night moving all over one area trying to see the shifts in input, and to the credit of the designers most of the time they are subtle and intuitive and guide the player in a general direction.

   

Things I would need:

I would need a trigger area for the player to enter to trigger the switch in POV to the camera actor.

I would also need a way of communicating a new input axis (a rotator) to the player controller depending on information I'd stored in the camera actor. 

So, I prototyped these in blueprint.

The Camera Actors.

The basic components are a camera, a trigger volume, a rotator set in level, and some functions that talk to the player controller. I even tried to be clever with construction script in that I wired up a system to let me scale the trigger boxes. 

Moving them around though became a problem and not wanting to create a brand new camera actor for each shift simply so I can go in and custom move the components seemed unappealing. So, I decided to make a volume actor that talks to the Camera Actor. 

Creating the Bug

To have fun and test this I wanted to create a bad-design bug. I wanted to enter a camera volume that would change my view point, and , while continuously hitting W, Enter an adjacent volume which would switch my view point and my axis by 180. If I were doing as I said, and continuously jamming that W key, I would soon find myself back in the original POV, but only for a moment as my W-key-habit would see me back in the second POV again with my input axis flipping back and forth.  

Here's a video with the bug and some other tests. Note: at the time of this video's creation I had the camera shifting back to the controller camera when the player wasn't in a volume. This makes the transition look really rough. Chances are by the time you're watching this I've fixed it. I just wanted to get a video up  because video.

Up Next

I want to refine the new independent volume class, but you can expect the next entry to be about interaction Actors. Another important part of an adventure game is interacting with things. Here you'll see my try to scale it to a functional, and flexible system.

See you then.