Thought I'd keep doing some blueprints, and I heard that GameDev got a new course out, so I got it. First little project is a little physics based game where the PL controls a board with a maze using the mouse, and try to get a marble into the goal as quickly as possible. A simple little game. 

I did a quick exercise in BP communication off a tutorial i found you YouTube... In this example, the Powerup BP communicates with the PL BP and temporarily changes PL speed. It works, but I think a better way is to to have all available powerup-effects (such as speed/jumpHeight/Health/etc.) in the PL BP and have the power-ups send events to the PL BP instead of having the logic in the powerup BPs themselves.
I'll set up a system like that next!

Been ironing out Pac-Man bugs. And I also did the flaming chair BP quickshot, because why not?

Implemented a simple AI that wanders around the maze, killing the player on overlap.
Not as advanced as the original Pac-Man AIs but I'm not making a replica of that game, just learning Unreal 4. 

Implemented: 

• Player death
  • Respawning PL at designated respawn position
  • PL death animation
  • Stripping PL of all powerups on moment of death
• Random respawn of fruit power up
• Pellets everywhere!
• Teleporting player in the warp zones

Effects look like crap, but that's because they are butchered versions of the Infinity Blade effects. When I've learned Cascade I'll replace them with something better. First functionality then polish!

Continuing the course, and thus continuing the Pac-Man project.

• Player movement, controls and animations implemented
• Game camera position and animation
• Logic and functionality implemented for: 
  • pellet
  • power pellet
  • bonus fruit
  • speed boost 

I want to try to build a simple carnival-game in Unreal, and I settled for a skeeball-style game. And after some time on forums and youtube I finally got the pick up and throw mechanic to work.

• PL picks up the ball by pressing and holding the right mouse button.
• Releasing the button drops the ball.
• Pressing the left mouse button throws the ball away.

Fun stuff.

We have a full level, materials, enemies, audio, pellets, power-pellets and lots of component blueprints.
Time to implement some game logic.

I keep going at it with blueprints and UE4... To get more skills and become even more familiar with UE I've enrolled in a course, the point of which is to work with different aspects of Unreal 4 and to create a simple arcade game. So that's my goal now: Pac-Man from scratch. Complete with AIs, HUD, Top Scores, Load/Save games, effects etc.... I'l chronicle how it goes. The playing field is starting to take shape

After lots of struggles, my good friend came over and helped me figure out how to handle the elevator blueprint interfacing with the button blueprints and vice versa... It's handled like this. The Button BP has has an exposed variable that allows me to set what floor it's on. The blueprint interface got an input where I plug in that floor, which it then feeds to the lift blueprint. Meanwhile the lift got an array containing all the floor vectors (in order) which it uses to cross-reference the incoming floor number. Floor 0 got index 0 which points to a specific vector, floor 1 got index 1 and so on.

There is also an alternative version where the lift got a map variable, allowing each button to send a name, like "Bottom Floor", "Armory", "Lounge" etc. That one looked like this: (the purple node in the FIND) node would be plugged in with a "CalledFromFloor" variable. 

And the blueprint for that use the vector array looks like this

The button blueprints look like this

The next step is adding internal and external doors, lights and the logic that goes with them. And at some point I will have to deal with the fact that the elevator is going to its location in .5 seconds, which means an inconsistent travel speed. Until next time!

I've been trying to create an elevator in blueprints, incorporating the generic button and blueprint interfaces that I learned. It's a good exercise but man is it hard to get a hold on it

Here's the design (I've marked the points I'm aiming for in the first version of the elevator)

• Elevator that goes to 4 floors.
  • Floor 0, Floor 1, Floor 2, Floor 3, Floor 4
  • Each floor got a "Call Elevator" button, which tells the elevator to go to that floor
• The elevator has 6 buttons in it
  • One for each floor, an emergency STOP button that stops the elevator and an OPEN DOORS button that opens the doors if the elevator is not moving.
    • If PL chooses to go to the same floor they are on, the doors will open to let PL out of the elevator
      • Same goes if PL is outside the elevator and calls the elevator to the floor the elevator is already at.
• When the elevator has arrived at a floor there is a "ding" sound and the doors open to let PL in/out
  • After X seconds the doors will check if there is something in the way
  • If there is nothing in the way they will close
  • If there is something in the way they will remain open for X seconds and try again
    • If something is in the way while they are closing they will open again and wait X seconds before trying to close again
• When PL picks a destination floor the doors close (they do the same checks as above) and the elevator starts moving to that floor.
  • If PL presses other buttons during elevator travel, it will stop by those floors based on these rules:
    • If the elevator is moving and the floor is on the way to PLs initial destination the elevator will stop there to let PL out, then it will continue to the other destination which it has queued up.
    • If the freshly input floor is in the opposite direction of where the elevator is going, it will first reach the initial destination and then go to the opposite direction destination

I've tried to establish at least the marked functionality but I'm kind of stumped at the moment. I have a hard time getting the button blueprints to tell the elevator which floor the signal came from, and then let the elevator compare its current location to that info and act accordingly. Gotta keep grinding. It's fun though

Last week my good friend introduced me to blueprint interfaces, and I got a really thorough primer on what they are, how they work and the potential and power of them. Whenever we have those sessions I try to recreate everything again just to cement it in my mind, but I kind of hit a wall. Been a few days, I've been experimenting and researching and FINALLY I got it to work. 

This is a generic button blueprint that sends out a "Player has interacted" type signal to an array of actor blueprints, and each one of those interpret that signal differently. For one light it may mean turn on/off, for another it may mean change light color, for another it mean move to a new position. The nifty thing is that you can have many instances of the same button blueprint in the level and they would all have different interfaces and do different things. Fun exercise and I learned a lot.

Here's the button blueprint. It contains no reference to any specific blueprints or actors. Sweet.

And here's the thing in action

Another mine blueprint, this time a lot cleaner than the last one. Plus there is a little gameplay element. A friend of mine suggested I'd recreate the mines from Abe's Odyssey, so I did. The mine cycles through an active/inactive state based on PL proximity, and then cycles between an armed-non-defusable and an armed-defusable state. If the player does the correct input at the right time the mine is defused and rendered harmless. It was a fun exercise! Learned a lot more about using variables, as there was a lot of things that needed to be checked at each state.

Been poking around with blueprints a bit more, this one is a bit more advanced than the first one. 
It's a landmine that behaves like so:

• if PL approaches the danger zone it checks if mine checks if it's armed
  
  • if so: warning lights turn on and warning beep is played.
    
• If PL keeps walking into the kill zone it explodes, applying a force around it, spawns effects, sounds and destroys everything except some lingering smoke which is destroyed later.
• If PL presses Z while in the danger zone, it checks if the mine is armed
  
  • If so: the mine is defused, a sound is played, light turns green and a lingering smoke effect is played for a few seconds. The mine becomes harmless.

This was a fun little project! Learned a lot, especially in regards to variables, branches and manipulating effects and sounds that are not part components of the specific blueprint. The graph is a bit messy though, gonna clean that up later when I recreate it. I wanna go over everything again just to cement it. 

​Twas fun! Might try a bouncing betty next time.