How to make an AAA game in Unity (or fail badly)

$500.00 for a game license (all exported models that are daz originals) which in games like Mass effect is chump change..

 

The first thing I did with unity was attempt to work on procedural generation.

I wanted to generate out realistic medieval landscapes, really focusing on farming land which I think is generally poorly represented. I did a pretty good amount of research, absolutely the best quality was CityEngine.

If you want to talk about serious tools and proc gen, it has to be mentioned:

Try to look past the textures, the composition it can create is absolutely amazing. If you look at the shapes involved, it's actually realistic, not the caricature you generally see in terms of what story book villages look like.

I'm not a dumb guy, I ended up finding some of the white papers these guys wrote as they were working on this tool. I'm saying, if you find learning about SSAO daunting, this is a whole different level. There are a lot of smart guys who can produce some really impressive stuff procedurally. I am not smart enough to surpass their work. Maybe you are, but it's very intense work that's been labored over by very sharp people for many decades.

I had tons of links, but I can't find any of the really good ones. Some of the stuff that guys can do is absolutely amazing. They've also been working with it for decades professionally.

 

Very, very interesting stuff, thanks!

 

Trust me, if you don't want to dig into what the parameters are on your SSAO - getting serious about procedural generation will be the end of you.

This is not a "find the secret to generating stuff better because everyone else missed something obvious" - this is an instance of immense complication, endless rabbit holes, and an extraordinarily difficult problem our brains are not well suited to solving.

 

Have you done procedural generation yourself? I have, it's pretty fun.

 

It's bad enough using maze type generation based upon set pieces of artwork, plus it removes a lot of things that make a performant game an actual performant game. For example, you can't use light baking and everything has to be dynamic, you can't bake occlusion etc. etc.

I've used procedural placement for terrains and I've also procedurally generated corridors with procedural placement in a maze type configuration. Cool for a dungeon crawler, useless for Mass effect..

 

I attempted to. I was generating road networks based of voronoi, and I did a lot of delaunay stuff. I thought that the medial axis is almost the perfect representation of how roads were generated. I still actually get pms about one of the stupid details I had a post about: generating the intersection meshes at uneven angles.

http://forum.unity3d.com/threads/procedurally-generated-road-networks-and-intersections.236113/

I gave up on the farmlands even though I'm pretty sure that voronori gets you close enough, you just need to keep subdividing. I had a ton of tools for generating topography using delanay. This stuff was very simple and very crude using well known techniques.

What I ended up with in terms of actually using can be seen here:


Talk about embarrassing! I couldn't even use roads with proper curves because it ended up generating out too many glitchy variations.

 

Cool, but lets be real, a random dungeon-basher will produce a random bashing of dungeons. Not even Skyrim would be able to use that. There's a huge difference between a tool to speed up the workflow and full-blown procedural generation. In fact, in many ways the former is more difficult - or at least time consuming - since you have to create a quality interface which is not always easy, and try to foresee all the ways that users will end up breaking your software. Plus I'm not talking about runtime generation either. Something like Blender, but alive!

 

Diablo has been doing this forever no? I donno, is Diablo AAA? It's got a top down camera, I'm not sure if that qualifies ;P

 

Well that's not true is it now? Diablo has been doing it for years (at run-time may I say) and we're only talking differences in camera perspective, also you don't need it to run realtime for all you know the dungeons could of been procedurally generated (parts of it) / placed based on their modular kits and then tweaked.

There's a major difference between full blown procedural generation and a tool that uses procedural placement or generation you say? Is there? Really? The concepts are the same.

This is where you're struggling billy, you see the concept from a 1000 ft. view without properly understanding how to put it all together and assuming what you say is correct. The only way to really know is to go whole hog and until that it's just baseless opinion. Now this thread would of been much more interesting if we had more people trying to figure out better ways of doing stuff based upon a decade of experience.

I'm honestly trying before I get back deep into things, to figure out ways to improve workflow and I have a few. But nothing that would make a major dent on a large scope high quality game like ME..

 

Maybe it pleases you to hear that I was taught that term in university just a few months ago

Although we used that term to describe software modeling tools for UML and such, knowing that the code generation capabilities would be rudimentary at best.

 

I've used an old version of nDo a little and it'd be well suited for doing normals for panels on sci-fi stuff. It's pretty clever.

Agreed. The Normandy from Mass Effect is another good example of a "clean" and coherent design. A lot of that comes from proper design, which often seems to stem from good concept art. I gotta think spending money on that would be worth it. You can talk about high quality textures, shaders, effects, meshes all day, but without having reference targets for the overall form, color, and mood that matches your theme, you're just kinda failing around.

 

This thread has devolved into way too many words and way too few images. If we're going to make it to page 8, I want to see more friggin screenshots.

Whats good, whats bad, what can we copy, what can't we copy?

 

I was playing around with something very similar that generated a simple grid of roads with uneven angles at the intersections. I thought a bit about it and then decided "I really don't want to deal with this right now. Worst case I'll just put a big enough circular mesh over the intersection to hide the messy part."
Seeing how long it took you to solve it, I'm quite happy I didn't dive into that rabbit hole . Good job figuring it out!

I remember seeing cityengine during my own research. That was very expensive though, right?

 

LOL! Yeah man, that's the worst part. I spent close to 40 hours working on those stupid intersections just to realize that I really needed to stick big red dots on top of them and I ended up not even bothering with the center mesh! Not only that, but the camera needed to be so far away and I needed to show so many road segments you couldn't see all the work I put into that dumb shader. I refused to use a different better looking material because that shader took so much work. Look at how terrible those roads look in that screenshot!

I guess I learned a lot, but honestly, I don't remember anything except "man, I don't want to do any of that ever again".

 

+1

 

Well, folks, here's a little something for you, I did an all nighter wrestling with the spaghetti monster so I hope you find it slightly fun to watch.

It's a little terrain generator that I worked on for a while at one point, haven't looked at it in over a year and I think I left it in a 'debug state' i.e. full of junk. Erosion wasn't working at all that's what took a while to fix.

It creates several layers of noise (Voronoi or Perlin) at different scales for lowlands and mountains and blends them together, makes a snappy slope-based texture, and erodes it a little bit. The erosion implementation I used was meant for a gpu but I never got around to it - at the time I didn't know a thing about shaders so maybe that's why. In any case it is slow as a snail, I made a gif on a 128px heightmap for you, nothing too spectacular ..the texture is just two blended colors as texture tiling was having some issues and I couldn't be bothered to fix it right now.

Here's the paper I used for the erosion algorithm if anyone is interested.

 

You obviously haven't seen my 'Inspirations' folder! I make good use of it too, whenever I'm a bit lost as to how to go ahead on something I flip through it for a while. Couldn't do without it.

I watched a video by an artist who said that your art is only as good as the mental library you have of things you've seen and stored away. I totally agree.

 

Looks good. Better then my last attempt at a terrain generator. You can still see the prelin. But it's a good start.

 

Definitely cool!

That said, I use the excellent Erosion Brush tool: https://www.assetstore.unity3d.com/en/#!/content/27389 It's one of very few things on the asset store that's well written in terms of the code and complete in terms of how it's presented.

I am really a big believer in the 'brush' approach to applying rule driven composition. When working on stuff, you need to be very selective on when and where you want to apply some set of logic. For instance, mapping terrain splat to height and slope is great. When you use it the first time, it will save you a ton of time, but after you apply a bunch of hand detail to an area, you don't want to overwrite it. So you need control to apply these rules to controlled areas.

Right now, it seems like "Gaia" is all the rage on the asset store. I guess this makes sense cuz you can click a button and get a surprisingly good terrain to run around on. But I can't really see it as all that useful in terms of actually making a game (other than the stamp tool, which can be used on the fly).

The best tools can be used with little or no commitment. Using the 'brush' model is really a great example of how to do that.

That said, I also strongly prefer 'tools' over 'frameworks'. I don't want my software libraries to dictate how I work or think, I want them to empower me to accomplish what I need to accomplish using whatever workflow I want.

 

@BoredMormon thanks! Yeah it was only ever a start. The erosion is very basic in features, it doesn't see any difference in material density (i.e. sediment over rocks). There's no texture generation for sediment itself which makes eroded mountains look so nice. And most of all it is so slow that I wasn't able to tweak a decently sized example. And there are still weird things such as (I think) crazy oscillations in the water cell transfer if too much rain is added.

@frosted, although I think erosion is something the comp should take care of itself, I agree with you, in my dream terrain generator I talked about being able to brush out flat/village areads, draw roads etc. But that doesn't mean the computer doesn't have a lot of work to do! The brush IMO should transfer a minimum of information, basically the 'intent' and some constraints, and the computer should do all of the detailed work of creating a feature, blending it with the terrain and creating a natural transition.

But for erosion and rock placement and trees and grass and stuff like that, it's cool with me if it makes its own choices, as long as I can change things here and there as necessary.

 

If you go with DAZ, you'll still be able to use Mixamo animations - especially if you use gen 4 models since Mixamo actually has V4 and M4 as options. I use a simple script that "conforms" a figure over the top of the Mixamo figures, so I just download the animations as FBX for Unity and no further editing is required. Set up two AI (one male and one female) and I can simply swap bodies this way and have tons of ready to go unique characters.

Don't forget that you have to buy the models as well. They do have some free ones, but certainly not enough to justify $500.

 

My reply was in response to a comment you made about procedural generation being useless for mass effect, and I was basically saying "Yeah, it is useless, that's why I'm talking about creating tools that use a little procedural generation, rather than full-blown runtime generation". I think it's a key point.

I think it's cool that you made the dungeon creator, I'm trying to make something similar at the moment (creating a building from tiles) and it isn't as easy as it looks. But you said yourself runtime dungeon (or corridor in this case) creation was useless for a Mass Effect type game, and I was agreeing with you.

There is a big difference between run-time large-scale procedural generation and an editor tool that used proc gen. Yeah, they both use proc gen but one of them is a lot more controllable than the other, it relies on a lot more input which makes it a lot more useful but more time-consuming. The trick IMO is to find out what you really need to communicate to a computer in order for it to create something, such as a terrain, under certain constraints.

Contrary to the idea a lot of people got, I'm not talking about creating something to displace artists but rather to enhance the connection between an artist and a computer, make the transfer of information more efficient, and most of all, remove unnecessary workload by using procedural generation here and there where the artist is not particularly concerned with the outcome as long as it is quality, for example cosmetic stuff such as blending a rock into a terrain, or creating a transition from a well-worn road or track to wildnerness.

 

The ultimate point being, that most tools are out there already and big developers already take advantage of them. Like AAA outfits have their own tools team that custom build these so the artists can get through it on the silly deadlines they're given.

Quite contrary to how this thread is turning out, I am actually here to help. It seems we're looking at a similar path and I started this venture because I believe there isn't enough games out there like Mass Effect and Dragon age. Even at a tenth the size and quality..

So it'd be cool if we can trade some thoughts, ok on my travels today I saw "Houdini Indie" which is free and seems to have a lot of "procedural" artwork tools in it.. I must admit I'm very much interested in it.

http://www.sidefx.com/index.php?option=com_content&task=blogcategory&id=244&Itemid=399

 

Wow, looks cool!

I tried to find some good procedural modelling videos but they were all very simple objects and it seems like a clunky way to work. I'm not sure how useful it would be for that. But for particles/destruction/animations it seems really good.

 

Yeah plus the last time I used Houdini, it looked like a Unix program that I couldn't fathom.. Then again I didn't spend THAT long trying..

I am trying to find tools that don't require "dependant" workflows, i.e. can support mass scene expansion and doesn't require stuff like root vector animation (for events). It's so much easier when you can just export a massive scene, set up materials and do bits of code to animate in engine without having to go back into the bloody 3D tool 50 times to tweak stuff and export.. (Which I always end up doing)..

Pupeteer and IK based animation solutions for pro / non bipeds would be nice too, as much as I like Mocap.. It's not always that necessary (for generics)..

Or always have to find faffy ways to get around issues.. That's what takes up a fair chunk of my time "faffing".

Vertex (smoothing) seems simpler than it was in Modo 9XX, but still using Maya for animation (I find it far simpler).

I have to admit I spend an awful lot of time UV mapping as well, making beveled sleak meshes with some sort of hard surface modelling detail overlays isn't that difficult. Hell a lot of it you can do in NDO, but UV mapping uhh.! It's not really the complexity of the mesh either that's the issue, it's projection axis.

Most of the time I end up un-wrapping and hiding seams, which I'm sure most do but even then it can go awry a lot and need a lot of tweaking. It'd be nice if I could just go "crazy" though and not have to worry about UV mapping it later.

Z-brushes way of doing stuff is cool, where you just paint textures on a mesh and of course you can bake out color maps and use substance painter to do the same thing (although based on UV's). But it'd be nice if their was a more "all-in-one" art solution.

But as they still get lots of money out of Mari, doubt that'll happen any time soon.

 

You mean Marvellous Designer mainly ? There is also new clothes rendering with advanced shaders like UE4 is doing.

 

No as in AAA (company's, an outfit (or set of companies).. Not specifically clothes ..! Suppose it's a "slang" term, we say outfit meaning a company..

P.S good to know though..

 

Marvelous Designer is pretty amazing, I just watched a little video. Crazy what that can do.

This is a guy building tools in unity to quickly view variants. Thought of this thread when I saw it - didn't post cuz I spent too much time in this thread ;p

Even though the tool he's using is pretty neat. Once again, the real work is in putting together all the variations and setting up the content. The tool itself (or similar tools) are themselves pretty easy to build.

Some of his other videos are pretty interesting also.

 

I found the article I'd read about procedural animation, it's from 2012 but it has a nice overview.

UV unwrapping - hmmm. I had a go at making my ship with a fully modelled workflow - no bakes - and well, the bevels were pretty time-consuming to unwrap. I gave up after a while as I wanted to use a 'repeating panels' texture and straightening out the UVs just became a major pain. In Star citizen they use 'clean' textures so probably you could just make some decent seams and unwrap it and a little distortion won't matter. But for grungy/detailed textures it gets very tedious to make it look good. I will probably use that workflow in my game, but making a ship for other people's projects I'll just stick to the traditional way with bakes.

 

This tool can fit some small game projects. But using modular prefabs (premade walls variations and roofs ) with some placement tool allows you to work quicker, while this tool is dealing with detail work instead of level above lmodular pieces.
You will be slow making an entire city using such detail work steps instead of using pre made modules variations.

 

I bet UV unwrapping is one of the most dreaded and boring tasks in 3D asset creation for every artist. The way I try to spend the least amount of time on it is to adjust the rest of the workflow to not need great UVs. For all the renders I've recently posted I did the absolute minimum of UV work, most of it is just defining seams and using blenders auto-unwrap. But I do make a full highpoly mesh for baking and I use substance painter with triplanar projection for many materials. That does a good job of hiding seams, something which DDO wasn't capable of, last time I checked. An advantage of that workflow is, I can relatively easily go back to the lowpoly, change the mesh and just auto-unwrap again without having to throw away manual unwrapping work that I did before.

This might not be a good workflow if mobile is your target, because UV seams usually increase the vertex count. Also if you primarily texture some assets with generic tiling textures that e.g. have hard surface detail, then you won't get away with the auto-unwrap result. You might be able to use Substance painter to use triplanar projection with your tiled textures, but that potentially introduces an otherwise unneeded program to that specific part of the pipeline and throws all the advantages of reusing tiled textures out of the window. So... probably a bad idea.


@Billy4184 I'm not yet entirely sold on the whole idea of midpoly + decals for ships. Compared to a kitbashed, auto-unwrapped bake with procedural textures it would take me a whole lot longer to make the midpoly model in a way that shades correctly and get the UVs right for tiling textures and decals.
The reason where I would start trying your approach out vs trying my approach first, would be if a ship is so big that I can't bake it on a single sheet.

 

Unity should bring a modeler in the editor like CryEngine Designer tool, perhaps some more faster to use with 3D screen context menu like Maya does. It is advanced really and takes care of UV for you, i think you could make all your modular prefabs using it.

For a lonewolf indie here is the best tools that would help them push further games :
- 3D character system like mmos, fully modifiable in game and in the editor with a good library of characters presets, simple to use.
- In editor modeler Designer tool with context menu Maya like
- Complete voxel terrain and vegetation features and shaders
- Road , water flows editors
- Easy tools to align and manipulate prefabs quickly to make a quick modular level design
- In editor scattering tool to paint prefabs also using rules if you need (houses , fences , rocks )
- AI beahviour for characters npc day and night navigation and activities (blacksmith rises from bed and go to work)
- General AI for ennemies using Agent navigation with Avoidance system and some custom AI rules (perhaps a visual behaviour tree?)
- Time of The Day and weather component

This would help a lot i think having that out of the box. Anyway there is still lot of work like Dialog Tree ,Lypsync, Quests and sub Quests system, loot system for items and a basic XP system, skill tree, customizable inventory, inventory crafting.

 

Neither am I, to be honest, but considering that my game is going to be 3rd person inside the ship I would have to approach it as a level, so it might be a good workflow in terms of stuff like texture resolution for most of the environment and vehicles. For characters, weapons and small objects though baking would probably be easier.

Apart from unwrapping, getting the shading right is pretty easy for me...not sure how you're doing it but it's absolutely necessary to do face weighted normals, othewise you would need an insane amount of bevels to get a crisp transition to flat areas.

This isn't featured in Blender, but here's an add-on script that I use ... you'll get errors unless you use Blender 2.74 or below though
Edit: works on versions above 2.74.

 

Thanks for the link! Custom normals still really are not well implemented in Blender. I try to stay away from 3rd party scripts for the reason you mention - they often stop working with blender updates. I'm not aware of bigger api changes since 2.74. It's probably not going to be too hard to fix. Just check the console window for the line numbers that the errors point to. Adding a button to the UI also is rather easy (I read a comment on that in the linked thread). Just check out any example script that registers an operater as a button to the UI.

 

Yep I read the console and opened the script, it has to do with a bpy.ops.mesh.customdata_custom_splitnormals_clear() operator that could not be found.

I've never programmed blender but soon enough I'll get around to fixing it, when I do I'll post it here.

 

I tried script v 1.1 from the OP of the linked post and it works without errors in Blender 2.76b windows x64.

I took the liberty of trying it out on a cube and modified it to discard really small linked faces from the normal calculation completely:


For the cube test case that makes sense to me, because otherwise the normals are still "wrong", only less obvious. You can see it in the viewport shading. Top one has a very slight gradient, bottom one is flat shaded like it should imho be.
Word of warning: I did test no edge cases at all, this may or may not break under real-world usecases. Feel free to experiment with the magic number that I used to discard normals of neighboring faces in the calculation. It could rather easily be given an input field that will appear at the bottom of the tool shelf like other operators, to tweak on the fly.

 

Never mind, I've had my shortcuts mixed around! I've been using 2.71 when I though I was using 2.76...

The script should work anything above 2.74.

@Martin_H nice work!

Edit: tried your modification, yep looks better!

 

I would highly consider Modo or Maya LT, like in Maya you just select whether it's hard surface or not and that's about it..

If we're talking time saving and all ..

 

You guys are on a whole different level for 3D than I am so this may not help with your use cases but wanted to throw it out anyway.

Many years ago just a few years after first started dabbling with 3D I looked for easier ways to do clean UV unwrapping and found Ultimate Unwrap3D. It made everything much quicker. Has been updated over the years and is still my tool of choice. If you haven't seen it maybe check it out. It's cheap for Pro Version and a bit less for the Standard version.

 

How many grains in a pinch? 1, 2, 5, 10, ... ah hell, put 'em all in!
Gigi

 

When I switched from Maya to Blender, this was one of the differences between the two that infuriated me. Since I'm still against going back to Maya, I stuck with Blender's way of doing things. Not ready to give money back to Autodesk yet.

That said, I still have Blender 2.74 installed and that's what I shipped Horde Rush with. There's a nasty annoying Knife Tool bug in that version. I need to upgrade to get rid of that bug.

 

What's stopping you? I'm quite happy with 2.76b.

 

Nothing at the moment. However, at the time of ship, I had run into an export bug that I didn't have time to bother investigating. I'm at a good time to upgrade, but I'm focused on porting Number Crunchers to iOS, so no need to upgrade right now, since that game is in 2D.

 

Yeah modo is looking good for hard surface. For the usual high/low baking method it has a bevel shader that bakes apparently. I will try them all out at some point but watching Tor Frick at work is definitely inspiring!

That said, the simple script add-on for blender does a pretty good job on everything I've tested it on so far.

 

Issue with Modo, it's ridiculously powerful (more so than Blender) but it's far from easy to use. Even the workplane methodology gets on my nards (as useful as it can be (sometimes). But the results speak for themselves..

Blender is a no-go anyway, they're dropping .FBX support and well Unreal doesn't support Collada.

 

Source?

I stopped following the development of Blender closely, but last I heard, they were working on improving .fbx. support.
I actually can't imagine why they would drop it if they are intending to support game developers better (which they still seem to be intending to do from all I have read recently).

 

There is none because it's not happening.

http://lists.blender.org/pipermail/bf-committers/2016-February/046710.html

 

(Edit: @Murgilod had more information than I did. But I already had written my post.)

From what I read into the available info the guy maintaining it so far is fed up with continuing to implement new versions of the format. It doesn't mean the existing functionality is going away in the next update. It also doesn't mean there is definitely not going to be someone else who is willing to maintain the importer/exporter instead of whoever has done it so far. That's the beauty of an open source project. Anyone can contribute. I don't see a problem in the next 1-2 years coming from this. Till then a lot of things might have changed. Afaik the plan was to find another general purpose format that is better than FBX. I don't think the industry as a whole is hellbent on insisting FBX is the only format worth supporting. Autodesk might disagree, but FBX being their format is part of the whole problem in the first place.

I'm pretty sure that Epic and UT have an interest in blender being capable of exporting properly to their engines. Worst case they'll have to hire someone to make future contributions to the FBX module themselves. This isn't anything that money can't solve, I think.

 

Didn't Epic and Valve once sponsor some development of Blender's .fbx exporter?

Blender is such a popular tool with many people who don't feel like spending a ton of money on a modeling application (or are simply not able to...I wouldn't be able to do what I am doing without Blender) that I can't imagine any of these engines willingly allowing Blender to drop support for them.

Edit: Valve Corporation still is a main sponsor of Blender.