- New navmesh for AIs to prevent them from cutting corners
- Hunter-type AI that tries to eat player
- Ambush/Wanderer type AI that wanders around
- Spawning in AIs and deploying AIs after they have been eaten by PL
- Start and reset conditions for music
- We have a HUD!
- Intro animation
- Lives counter + animations
- Score counter + animations
Been making a lot of progress with the course and the Pac-Man game. We now have a proper working game with win and lose conditions! Additions include
And here's a demo of the game so far. Still got some distance to go though
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've always liked DOOM and the aesthetics of it. The logo itself is one of the best game-logos out there. It's massive, heavy and immovable. Plus it tells you something about the game... The ancient pyramidal shapes mixed with the high tech circuitry, the contrast between old and new, scifi and hell, tech and demons. The logo is intriguing.
Anyhow, I wanted to test out that style so I wrote my name in it. It was a lot harder than I thought, but I succeeded. Made with Photoshop.
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
The blog of Aydin Afzoud, Senior Game Designer at MachineGames.