Download

Training Stream - Making a 3D Puzzle Game w/ Zak Parrish - May 10th

WHAT
Zak Parrish returns to the Training Live Stream to show how to create an awesome 3D Puzzle game in Blueprints! Zak will be starting with the core mechanics taken from the “Lights Out” game type, but adding a twist: It’s on a Sphere. If puzzles and game mechanics are your passion, then make sure you don’t miss this incredible lesson!

WHEN
Tuesday, May 10th @ 2:00PM-3:00PM ET - Countdown

WHERE
www.twitch.tv/unrealengine

WHO

Zak Parrish - Developer Relations Technical Artist - @ZakParrish](https://twitter.com/ZakParrish)

Feel free to ask any questions on the topic in the thread below, and remember, while we try to give attention to all inquiries, it’s not always possible to answer everyone’s questions as they come up. This is especially true for off-topic requests, as it’s rather likely that we don’t have the appropriate person around to answer. Thanks for understanding!

Archive:

https://youtube.com/watch?v=d7JKfbk699Q

Ohhh! This is going to be a good one.​

Zak+TrainingStreams=Bliss

This is going to be good!

Trying to picture that game redone on a sphere. Is the grid literally a 3D sphere?

Edit: ahh ok, the grid is 2D but wrapped around a sphere like a texture then?

Nice! Looking forward to this one.

Looks good defiantly going to check out…

OH! I actually forgot to mention this (sorry!) but because we used Touch to set this whole thing up, and because we’re using Unlit materials, it deploys nicely to mobile! I meant to show it working on my Android phone, but had to go.

If I’m honest, I had to pee so bad at the end of that session… Oversharing, I know. But kinda funny.

Btw, you’re welcome, Zak :slight_smile:
You didn’t even butcher the name too much, it just sounded a little strange with the -seN suffix (which is a play on the Japanese -san suffix, which is also a play on a the german cookie brand Bahlsen). And thats only because the name “BhaaL” was not available :confused:

For those interested, had BhaaL not jumped in with the solution, the next steps for debugging would have been having all the buttons print out the current value of ButtonState. If we’d seen all Falses, we’d have known the data wasn’t coming through. But if we’d seen even ONE True (which we would have) we’d have known the visual effect was not updating, and known it was the Material not being updated.

Im sure I’m being blind but is there a place to download the assets used to follow along with this? Looking forward to it!

Zak, are you going put the movie(YouTube) on Unreal’s site?

The archive is now available :smiley: https://www.youtube.com/watch?v=d7JKfbk699Q

I’m sure i’m blind too… Are these assets available to download :)?

Thanks.

wouldn’t it be better to code this puzzle as a self contained actor, which you could place into any level, of any game, and be able to play it, without changing game modes, or loading levels, or unpossessing pawns? it seems like using Unreal framework classes for this puzzle is limiting its modularity, and not adding any benefit to what could otherwise just be a prop, which you could place on any shelf, in any VR game or RPG game, like a light switch or a vehicle.

the way GameModes are tied to the loaded level seems to be designed for arena combat games, like Unreal Tournament, and putting code inside a game mode seems to limit freedom in more open world sandbox scenarios. i think mini games and puzzles should be actors, instead of games, so you can mix multiple mini games in the same level.

if you design all games from the perspective of a sandbox RPG, you really don’t need game modes or game states, you can just put all the game rules inside actors spawned into the world. even in arena combat games, you don’t need capture the flag to be a game mode, you could keep track of points in goal actors or a score board actor or the player state.

i feel like game modes and level blueprints are vestigial remnants of unreal engine 3, and they became obsolete as soon as blueprints were introduced. why tie any logic to a level, when it could be reused by putting that logic in an actor blueprint, which can be placed in any level?

i should be able to play poker, in the same room as someone who is playing a slot machine, while a third person plays roulette. putting any mini game logic into a game mode just gets in the way of that. each poker table can keep track of its own score.


also, all of your buttons could have been the same actor, reusing the same mesh, with its pivot at the center of the sphere, so its easy to rotate to any point on the surface. if 2 actors behave the same, but look different ( or in your case, look identical, but rotated), they should not be separate actor types, they should be instances of the same actor, in different states. or, it could be even more efficient, if those buttons were just static mesh components that get their materials set by the ball actor. then you don’t need to create separate dynamic material instances for every button, and you don’t even need to keep track of their state with booleans: when you want to toggle a button, you can just check which material is applied to the static mesh, and use that to select the other material to apply.

He could’ve, but he instead placed them correctly in Maya, then exported them with the appropriate rotation/location from a common center. That way, he doesn’t have to deal with aligning them properly.
But for doing that, he had to use 12 Button BPs instead (with a common parent BP that has all the logic).
If you use the same mesh, you can use the same BP; but you’ll have to position them correctly within UE4.

Good point about the game state and game modes, which to be fair Zak mentioned was kind of overkill. But having the buttons as children of a base button class, that was waaaaaaaaay better (yes, that much better) than have each button as a static mesh and having crazy amounts of repetition.

im not sure what you mean by “crazy amounts of repetition”… all the buttons do the same thing, reusing the same functions. using static mesh components owned by a single actor would be cheaper than multiple actors, and even if you do use multiple actors, swapping the mesh is not a good reason to use blueprint inheritance. all the button instances could be made from the same actor.

Make that 3 blind people. I too would like the assets so I can follow along.

Hi guys, I didn’t found the resources (as many here ;P), so I made my set. If you need, download here Dropbox - Player_Mesh.fbx - Simplify your life

When importing, make sure that “combine Meshes” is unchecked.

PS: I just made the meshes and two very basic materials. The yellow material doesn’t have “light”, but I know you can make it! :wink:

Thanks for that