Hello Unity Community,
My wife and I are working on our game since December 2014. And we are proud to announce that we are still married and that our debut game MarZ Rising hits Steam Early Access soon! 
Check out the steam store page for more information about our game:
STEAM
We would appreciate any kind of support!
MadeWithUnity
IndieDB
Twitter
Facebook
And here some actual ingame screenshots from our game, hope you guys like it!
We are super excited to announce our release date!
MarZ Rising will be available on Steam Early Access on September 26! Turn on your speakers to 11 and watch our brand-new Early Access Gameplay Trailer!
Spread the news, share the trailer and support us by adding MarZ Rising to your Steam wishlist!
Only one week! We can’t wait!
Just pushing it a little. Two days until launch!
Finally! After more than two and a half years, MarZ Rising is now available on Steam Early Access!!!
We are very proud and happy! Now everyone can play our game!
Thanks to everyone who supports us!!
edit: looks like gifs aren’t supported on this forum
The closeups animations I saw on twitters look good too.
I just read this bit and for that fact alone, I hope your game makes loads of money. And on top of that I think it looks very good, how did you two split the tasks?
@laurentlavigne Thank you very much! That’s really nice of you!
My wife is responsible for the UI/UX design, game design and level design. She also does PR & Marketing and all the other business stuff. I did the whole programming, as well as all the environments and some additional sounds. Thankfully we have some great friends who helped us in their free time with modeling, texturing, animation and concepts.
Both things are pretty impressive. Congratulations! I’ve heard of a few (married) couples working together on a game and while I see how that could be a good experience to share that burden together, I could also imagine a ton of ways for how it could go wrong. Mad respect for everyone who can make that work! Did you two work fulltime on it?
I really like the look of your game and would like to ask how you made the terrain. Are you using deferred decals at all, and if so, is it a store bought solution and how do you solve masking decals to affect terrain only? I’m trying to go for a kind of terrain that looks pretty similar, and I’m on my 4th or so iteration. This time around I’m going with a custom shaderforge shader and terrain meshes built from 16 bit heightmaps, exported from worldmachine. I’m using one global color-, normal-, and splat-map each, and different normal maps to differentiate rocky from sandy parts. I’m also playing with using a global rendertexture to bring different types of damage to the terrain without using decals, because none of the decal solutions that I’ve tried really worked well for my usecase.
Would also love to know how you’re doing the terrain. The whole game looks incredible!
@Martin_H @Billy4184 Thank you! Indeed, it’s challenging and not always that easy. We’re working full time on it. So everything is about the game, it’s basically our baby. It’s also a good relationship test 
The game grew over time, we never thought that it’s going to be this big, but it’s like a good wine it got better and better 
All in all we’re loving it. And we really hope that we can continue that way.
Regarding the terrain:
First I create a greybox mesh. Like a really rough mesh which defines the mountains, paths and craters.
Then I bake a greyscale heightmap from it so I can import it into Worldmachine. → awesome tool with ugly UI
Inside of Worldmachine I add some cool erosions and additional perlin noise details to it.
Then I export the mesh, normal maps and the splat maps. I reduce the mesh using a free tool called MeshLab. It handles also batch processing which is nice when using multiple mesh tiles.
In Unity I’m using a custom Shaderforge tri planar splat map + normal map shader. So each RGB+A values from the splatmap gets a texture. For our blood decals we’re using a tool called easyDecal from the AssetStore.
One of our very first blog post was dedicated to the terrain workflow:
Thanks a lot for the in depth info! I originally tried to export meshes, but didn’t like the workflow because importing them into Unity takes forever and I had no good way to batch decimate them. I’m aware of Meshlab, but don’t have experience using it. Good to know it supports batch processing. Currently I just store an 8 megabyte big 2k resolution 16bit greyscale heightmap per terrain and build the mesh from that at runtime. I also can use the heightmap to make quick terrain height lookups directly from the texture that way.
I have a question about the normal map that Worldmachine generates and your mesh. As far as I know the worldmachine normalmap node creates a tangentspace format normal map that only gives correct shading if either put on a flat plane, or if put on a terrain mesh where all normals are forced to point upwards. I originally tried to force all the normals upwards in my generated meshes, which has the added benefit of hiding mesh seams well. But the problem is, that now there is only one scale of terrain height that is “correct” for the shading created by the normalmap, and I like to experiment with the height scale for the runtime generation of the mesh. The other problem is that it’s harder to propperly blend other tangentspace normalmaps onto a global normalmap that has extreme surface angles.
What I ended up doing for now is triggering a recalculation of smoothed normals for the mesh and in worldmachine I don’t feed the heightmap into the normalmap node, I feed it the difference of the heightmap and a blurred version of the heightmap. That’s like using a highpass filter on the terrain I think, it only preserves smaller surface details.
Have you done anything to solve those shading issues or were they just not noticable? Or did you add another step of baking the normal map from the highres mesh to the decimated mesh? That would likely give the best result but could take a while - too long for what I want to do.
In this screenshot I could have sworn the rubble on the left is a combination of different meshes, but with well enough hidden seams and maybe some decals. Is this all just one terrain mesh? It looks great either way!
Our November update is out! Enjoy two new challenging missions, great new features and huge optimizations. Check out the complete update log here:
@Martin_H Sorry for the late reply. I didn’t saw the forum notification.
Regarding the normal maps from WorldMachine: I’m not quite sure about what you mean with: “only one scale of terrain height” But in our case i used the exported mesh from WorldMachine which does not have any shading issues in regards to the normals. Or they just weren’t noticeable.
To make the landslide in one level I have cut a big piece of mesh out of the “original” patch manually and then cut this piece further into smaller pieces. I just had to make sure that the UV’s were kept intact. Of course the hole in the original patch was then closed with additional geometry.
Love the tile texture! HL2 had that in their not-so-official release
What did you do to optimize the crowd?
Yes the tile texture is inspired by the HL2 prototype level
It’s basically our test level where I can test new things for MarZ Rising.
Some parts of the crowd simulation had physics calculation dependencies which were quite heavy. I managed to get rid of these completely. Which you can imagine, gained us a lot of performance boost.
You’re not using unity navmesh avoidance?
no, it’s a custom crowd/flocking simulation based on alignment, separation and cohesion. The units simply move along waypoints. I’ve made a lot of testing and experiments with different pathfinding solutions and always had bad performances as soon as there where more than 100 units moving. At that time, the Unity navmesh pathfinding wasn’t very good either. I don’t know how it is now. But I decided to use a custom flocking system which allowed us to spawn hundreds of enemies. After the update now even more
here’s an old blogpost about the flocking system with some additional links:
http://www.doorfortyfour.com/marz-rising-devlog7/
And boids thread very nicely.
How do you have enemies gather around targets? local attractors?
I read your blog, seems you were using A* pro. Back when I benchmarked the unity nav system I got 200 units without breaking a sweat, by throttling to low quality, it was in 2013.
As for the enemies we do not use any pathfinding, they move along predefined waypoints that’s it they only get attracted to crew members which then would change their current waypoint. If there’s a building in their way they will attack it and move along to the next waypoint.
We only use pathfinding (Apex) for the crew members, because they have to be “intelligent” and avoid buildings.
I like that you didn’t try to shoe horn all the functionalities in one solution. Why Apex and not unity nav?
The main reason was that unity back then didn’t supported dynamic obstacles avoidance. Luckily this has changed, and I’m already thinking about replacing our current solution with the new unity nav system. I already did some tests and they were very promising, really dig the simplicity of it.
btw. I just checked out your game. Did you made it all by yourself? Great job!