I had avoided to put in some kind of smoke in the grenade explosion because the smoke "overwrote" the other effects. Then my friend just told me to move the smoke a bit behind the stuff and I felt pretty dumb for not even thinking of that. Doh! So I added a bit of smoke and also tweaked the curves for other effects to make it more dynamic and less static and boring.
I re-created the grenade explosion, using some stuff I learned while making the bullet impact. Screen algnment: PSA velocity is pretty useful for creating sparks and real sharp shrapnel. I also realized that I thought I could not use size over life for the bullet impact, but that was just me being silly. So I need to revisit that too.
Continuing poking around in cascade using the primitive shape materials. This time, I attempted a bullet impact. Again, learned a lot while poking around with this one.
To familiarize myself with cascade I attempted a grenade explosion limiting myself to the square, circle and triangle shaped materials. I am also limited to only using these in cascade:
Acceleration > Acceleration Drag
Color > Initial Color, Color Over Life
Lifetime > Lifetime
Light > Light
Location > Initial Location, Shapes
Rotation > Initial Rotation
Rotation Rate > Initial Rotation Rate
Orientation > Lock Axis
Size > Initial Size
Velocity > Initial Velocity, Velocity Over Life, Cone
Might not look much to the world, but I learned a lot poking around in Cascade. Will attempt bullet impacts next.
My good friend gave me a material/cascade primer, so I will now attempt to create a few effects. However he restricted me to use basic shapes and materials to begin with. I also have a restriction on what functions to use in Cascade. I think that's a great idea since it makes me focus on the movement and the effect itself instead of flashy eye candy. Looking forward to familiarize myself with cascade and upload the results. This is a completely uncharted territory for me. These are the shapes I will use.
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.
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.
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.
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)
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:
Twas fun! Might try a bouncing betty next time.
I've heard a lot of good things about blueprints in regards to rapid prototyping. I've always wanted to dive in to BPs but never really had the time. But now I'll make an effort and actually find time to do it. I've just started with UE4, so I am trying to get my bearings on the engine and blueprints in particular. Right now I wanna figure out how they work and what they are capable of.
This blog will mainly be a chronicle of my progress, I'll update it now and then, mainly to incentivise me to keep it up, plus I want an archive where I can go back and look at the progress. Nothing motivates me more than measurable progress. Plus I have an awesome friend who is tutoring me, he's been immeasurably helpful.
Anyways, here is my first blueprint. Simple stuff.
Player walks in to a collision box, it plays a sound and changes the light to a random color. When the player exits it again changes the light to a random color
The blog of Aydin Afzoud, Senior Game Designer at MachineGames.