Hi everybody! I’ve been very busy the last few weeks, so this update is very late. Many people are asking me about how the development of The Hum is going, and many people are interested on knowing more details about Unreal Engine 4, about development techniques I use for AI, for procedural generation of levels, materials, etc.
That’s why I wanted to start writing some articles/posts about that, and I will do it as long I have the time to do so =P.
I will start talking a little about Unreal Engine 4 and the typical things of it’s process.
Unreal Engine 4 as Engine, my experiences in these months
I will not talk in depth about UE4, but just tell you a little about my experience in developing of The Hum with it.
Basically, UE4 is great for visuals. The light rendering is great, at least for indoors. For outdoors, you will need to tweak some things, and find a way to display good godlights (because you still need to use meshes for that).
There are a lot of options and features you will need to learn about before achieving something great, but by default the effects are very good. UE4 contains a lot of options for lightning, a lot of work behind materials, a lot of work with reflections, post-processing, etc. With “a lot”, I don’t want to mean that this a messy pipeline , quite the contrary, I found that UE4 has a very good workflow with art assets. What I’m trying to say, it’s that it’s not magic, you need to know how everything works.
And, of course the engine is not everything. You always will need a great team of artists working on the visuals. But the engine allows your team to achieve really, really great stuff.
There is, still, many things that I miss from Unity3D, like camera render depth or more file format support. But everything is doable with some workarounds or custom plugins / work.
UE4 uses C++ on the programming end. It can be great for some people and a torture for most of the mortals who come in with some higher level languages. The good side is that C++ is , of course, a great language, very powerful. The bad side is that it’s a very ugly one, at least for me. It’s very understandable, of course, and things like pain with pointers are not a problem if you have a good background, but still, things like declaring headers, long and very ugly sentences/syntax, long compile times and many other “details” play against what indies want: a fast workflow and fast solutions for your project.
We are using C++ for some things like plugins for rendering, editor extensions, Blueprint extensions, or complex data types / processing logic that are not very reacheable from blueprints.
Blueprints are many things. You can think them as “prefabs” from Unity in some aspects, as containers of elements, as independent modules of logic and, of course, as a visual programming solution. A very good one. To be honest, I was never before faced with a visual solution that I liked, but I learned to love UE4 blueprints.
Blueprints are very simple to understand, even for non-programmers. In fact, they are very utilized by artists and level designers. But even as a programmer, they are just great! You can prototype and make high level logic for elements very, very fast. You can make editor tools too, using “Construction Script” blueprints.
In The Hum, we are using Blueprints for A LOT of things. Almost every element, item or interactive object works with a blueprint behind. Most of the player logic is made with blueprints. The ambientation elements like sky, weather, event distpatchers, visual effects handlers and many other things are blueprints working as a huge system. Many parts of AI are blueprints (the most complex is still C++), the animations are handled by animation blueprints, and so on.
We use blueprints for procedural generations and level generation too. For example, the buildings, the walls, the roads, the debrises and some props, are being made with construction scripts’s blueprints inside the editor and tuned up until they seem cool for us.
And, if the base blueprints aren’t good enough for something we want to do, then we just extend them with C++. It’s magic!
For interfaces, at the moment, we are making tests with Corehent UI, which looks pretty good, But I will make updates about this in the future.
Consoles and VR
At the moment, we still didn’t test on consoles. We are aiming to PS4 in the next weeks after Gamescom, but there is still too much work to do before trying a build there.
For VR, we were using a log of Oculus Rift Dev Kit 1, and we are very, very hyped about DK2, which is being shipped in the next months. Using Oculus in UE4 is not hard at all. You don’t have a custom package like you do in Unity3D, and that should be improved, but the device still works very well. There are some ugly and annoying bugs with it, but… I cannot complain about it, we are talking about a DevKit VR and a young engine as UE4.
Do you want videos?
I liked a lot of videos sharing the development process using UE4 of projects like Solus, with their Solus on UE4 videos. I was thinking on doing something similar to that every so often, so you can not only see the details of development but know more about The Hum too. What do you think?