Week’s been full of watching tutorials and trying to setup a neat workflow for the Terrain creation. The last 2 years (including the long pauses from games dev), I’ve probably invested at least 4 months researching & developing terrains for our big project Kalima. I was (still am) seriously obsessed with Deserts. At some point I even found a program that simulated dune formations. Target was to create a realistic and “living” dune desert. It’s still far from it BUT we’ve come a looong way and that’s thanks to Houdini. It helped us more than we could have ever imagined. Thankfully, last year we won our first Game Jam of Epic Games and one of the prices was Houdini. I jumped right into it and found the solution to everything.
Recently, and after a long break, I’ve started using it again in order to create the landscape for our first level. First attempt to create a desert failed miserably (pre-houdini era). I created several dune meshes (based on satellite imagery) and tried to combine them on a terrain inside Zbrush (or even retopologize whole chunks put together in 3ds max). Now that I think of it, World Machine could possibly do that by importing the Displacement Map of each Dune (but the overall process could have been extremely time consuming). So, the issues were countless and performance was one of the primary ones.
On the other hand, Digital Elevation Data wasn’t detailed enough for me to create the result I was hoping to achieve (for dune deserts). As far as I remember there are paid services that can provide ya with high-quality DEM of specific locations (we could try it out later in the future).
So, about the Desert Level itself…
1. Find 3-4 (no more) pictures/concept art to use as a moodboard. Each picture could be translated to 1-2 key elements on the landscape. I tend to get overwhelmed with ideas when I fill the moodboards with countless pictures.
2. Create the block out meshes for these elements. More specifically the Mesa, Tall Pinnacle-Cliffs, Buildings etc.
3. Sculpt the landscape inside Unreal Engine. Add some simple detail like rivers and hills.
4. Add some Points of interest before going further.
1. Create an HDA to establish a loop with ue4’s terrain and houdini. For example, I would want to be able to adjust specific spots on the landscape (in Unreal) in order to create a Road, without losing/destroying the changes from houdini. By exporting data from one software to another (in fbx format) is time-consuming and besides this, I might even include some extra features in this HDA.
2. Import the Terrain in Houdini (that part was and still remains a bit tricky, still trying to figure out the Houdini Engine and how it connects with Ue4 properly).
3. Create a randomized Dune System
- One that spawns Dune meshes alongside a spline/curve. I used this technique to create the small Transverse Dunes that are generated on the sides of the main large dune (and less sandy) spots.
- One that spawns Dune meshes on specific areas (for example based on a painted mask). These would be a variety of sandy hills that follow the wind towards a specific direction or have a randomized rotation.
4. Populate it with vegetation (this one needs further research). Haven’t yet advanced it further.
1. Import in UE4 …to be continued!
In the next devlog, I will get into more detail on the Dune system as well as include all the amazing tutorials that helped me to create the (hda) loop with ue4 and houdini (might even create a quick-n-simple tutorial myself). Besides this, I will dive deeper into the vegetation system and complete phase 3 as well.
There is still one issue remaining… Let’s say I want to add extra tiny details on my Ue4’s terrain. I import it from Houdini, bake it and voila, time to sculpt… What if I want to change some stuff inside Houdini again, but retain the new sculpts after I baked it?
One guess is to just import more nodes via the HDA, so as to be able to make such changes inside Unreal, the other is… well I have absolutely no idea… back to R&D!
Code cleanup and being tidy with good commentating can go a long way. This doesn’t mean that I don’t comment at all, but there can never be enough explanation and context for your future self and possibly other people. You don’t want to come back at a piece of work you did a long time ago and scratch your head for too long, if only your past self could avoid that for you! ;D
Some fine tuning to the weapon’s functionality has been done, with the addition of two new sounds, picking up the weapon and when the magazine is out of ammo. I am far from finished, yet I think its core operations at the point of usability, are done. Now I just have to come back once in a while to end it.
The bullet had its turn this time around. Before starting coding it, I separated its functionality into two chunks of thought. What it must do, and what would be fun to have for future possible gameplay. Subsequently, at the point the bullet gets liberated from the weapon’s chamber, leaving its trail behind, to the moment it impacts, handling the damage and ultimately spawning sounds, particles, and decals are considered, as what it has to do. But it would also be fun depending on our gameplay if you could be able to deflect or grab and throw those incoming enemy bullets back. X-D
Mechanics Design: (Rico)
General purpose items, weapons and its extras (attachments, magazines) need some sort of holstering or storing in your inventory, for when the time comes that you need to move around. I had to come up with a usable design, something that would work as a good prototype for our early stage of development, however, it must be extensible and futureproof, using the same logic, it should be easily implemented in the final version on a full body. Not wanting to delve too much into detail about holstering. What is expected out of it though, is simple, depending on the objects type, volume and weight, you will be able to holster them only on specific locations (hips, back and/or belly…).
The inventory is another complicated system by its own and the way I want it to behave, it’s a matter best discussed another time, but the overall idea is settled.
In-Game Asset: (Rico)
Since I was going to need more than just pots to test the bullets’ behavior, I created a shooting target. This and the weapon is by no means a final representation of the look and feel we want for the game and considering the amount of work I put on coding, it would be impossible to produce a quality asset.
Social Media: (Autocrator)