The Rise of Dagon: Week of May 24

Blueprint's in Unreal Engine 4

This week was an interesting exploration in to the Blueprint capabilities of Unreal Engine 4.

If you've used PlayMaker for Unity 3D, or any visual graphing style scripting tool then you will have an understanding of what Blueprint in UE4 is about.

If not let me explain in brief.

Essentially what Blueprint is is a way to visually design your scripting of almost anything that might happen in your game including behaviors of objects, sounds, the player, or the environment.

The cool thing about visual graphing systems like this is that you can very quickly (once you learn the system) script out a solution.  The visual element can be very important as it lets you see the flow control theoretically better than in code.

In UE4 I would say the flow visualization is definitely better in than in code because the blueprint animates as it executes (if you have it open) so you can see exactly what its doing.

So my first task was to do a lot of video tutorials to learn about the blueprint system and I found this set of tutorials very helpful:

https://www.youtube.com/watch?v=cRhWc2kAhqI&index=1&list=PLZlv_N0_O1gaG5BW72It4chjhypxIO9ZB

I watched the full introductory set and definitely recommend it.

Afterwards I decided to work on creating my movement script for the player in the game.

The basic Movement code utilizes WASD,  for directional movement and Q/E for looking left/right.

So after completing the Blueprint tutorials I was able to get the following movement blueprint together which worked perfectly:

The next evening I undertook to add in the left/right looking with Q and E and found that it was not working.

Specifically I was using SetActorRotation ; and was having problems so I also tried the very similar SetActorLocationandRotation -- which also didnt work.

Neither SetActorLocation or SetActorLocationandRotation appear to work at this time.

Obviously when I say I 'tried' it I tweaked it, removed it ,re-did it. I changed all the axises, tried one at a time and all those troubleshooting things you do when something doesn't work.

I also figured out how to select my player actor while the game was in game mode and inspect the rotation variables ; and saw that it was not working properly their either.

So I began searching for any issues or help and found someone was having a simliar problem in C++ style code, but since I was using the blueprint system I went ahead and posted a question on the UE4 Answer Hub  https://answers.unrealengine.com/questions/46385/setactorrotation-setactorlocationandrotation-issue.html  but the most useful thing to come of that so far is to find someone else has the same problem.

I'll admit I'm new to UE4 blueprints and I may be doing it wrong - that's a real possibility.

I decided to try a C++ approach instead as I definitely want to be able to use both C++ and Blueprint designs in my game. I've programmed 5 games in C++ using a library called AGK and I enjoyed that work quite a bit so I was looking forward to see what the UE4 approach would look like.

Also if it worked in C++ this might give more insight as to what was going wrong with the Blueprint? 

I started off with  https://www.youtube.com/watch?v=Q3AvZmZEPyc , and found that I had not met the pre-requisite's which is you have to pull the source from Github.

So I watched this video:  https://www.youtube.com/watch?v=usjlNHPn-jo

And I started running in to some potential concerns about using UE4. 

I want to stop here for a moment and say that I knew when I started trying UE4 that eventually I would come to a 'stuck' point -- it happens in every project that I do that I get stuck .  I'm not afraid of being stuck -- being stuck is when you learn the most, albeit very painfully usually.  

So I was (and am) willing to undergo learning pain but I also have to stop and realize: I'm a lone developer. choosing my engine has to be as smart of a choice as I can make. I have to do the code, make the models, texture the models, make the levels, do the AI, create an inventory system, create and put in the sounds, create a class system, create a procedural loot system .. the list goes on and on.  I have enough things to do that I need an engine that's going to do a fair bit of the heavy lifting for me!

In other words -- I don't need a library; I need a full featured engine!

Once Again Unity vs Unreal 

So now I got my first stuck point I have to stop and take stock of what I know about UE4 and Unity and attempt to make a choice about which one is going to be the smarter choice for me to create The Rise of Dagon with.

The first  thing I learned is I would need to pull the source code and create my own branch to develop in C++ with UE4. Whenever Epic updated the source code I would have to merge their changes in to my code base. 

Don't get me wrong I've worked in an environment with multiple code branches where merges occur and I have had to resolve changelists often enough but the thing is I'm not the one who has to manage all that most of the time at my work, there are two guys who do that full time.

In UE4 I'm concerned about the amount of maintenance and technical debt that I could incur - or alternatively force me to not take updates because of that debt.  

In the Unity world they do a lot to lower my concerns in this area. For the most part the scripts I write don't break in between Unity versions.  It's possible when Unity makes the cross between 4.x and 5.x that I could incur some technical debt but this should be a one time issue - the level I'm willing to deal with.

The second item is Blueprint in UE4 had a mediocre to poor showing for my first attempt.  Sure its powerful, very cool and shiny ; but it also appears to potentially be either buggy or young and still in need of polish?  

There's a fair amount of risk to my perception if Blueprint is not what it strives to be; this will mean constant problems for my development.  How far do I go dismissing Blueprint problems before I find myself really deep in Unreal and with a crippled product? Will I end up six months along and find out that perhaps these things aren't going to get addressed?  

I have no idea at this point but all of a sudden the price difference between Unreal and Unity start looking a little less important than knowing that my time is going to be spent making a game .. rather than finding bugs in Blueprint and not having my game work??

So I end this week feeling very mixed about what the right decision is. I don't want to give up on Unreal as I really like the engine, I feel like its a more technically accomplished engine ..  but I'm starting to feel like its also a little less 'super small indie' friendly.  

What are your thoughts about Unity vs Unreal at this point?