Map workflow for unity

Created: 3/14/2018 7:14:46 PM

---

Well I apologize to everyone, the approach I took may not have been optimal in discussing things and my choice of words may not have been the best. As I had said I understood that wasn't the intended meaning of what was said and I only felt that way for a brief moment before logic kicked in and made sense of it. I pointed it out only to try to get us all to be more open to ideas, I just felt from the mood of the thread we all kinda had that attitude that our own ideas were best, even me. 

I'm also fine with tabling this, for now, it is not drastically important at this point as has been pointed out. Do you guys feel like the work I have been doing with NavMesh's and Terrains shows us we can do whatever we decide to do and it will work? That is how I feel at this point. The ease of switching to a mesh from a built-in heightmap terrain just took minutes; switching the maps and colliders out and retain the NavMesh and working agents/raycasts/camera mechanics was super easy. I'm even using mesh generation for something I hope to share soon if it works and it is performant. I am hoping that it will provide something unique.

The MVP has to do with colliders and raycasts. We have those working and with those, we can do any of the options we have discussed, probably any we haven't discussed as well lol. 

---

Created: 3/14/2018 5:19:39 PM

---

Yeah, there is no need for anything special for MVP. We just need a proof on concept that it works. I would rather us focus now on getting core mechanics in place, and then improve on those into more complex solutions

For future references however here is some other cool links.

https://unitylist.com/p/kk/Procedural-Toolkit

https://unitylist.com/

https://assetstore.unity.com/packages/3d/props/exterior/polygon-mini-fantasy-pack-96800

  - Anthony Michelizzi

  - Anthony Michelizzi

---

Created: 3/14/2018 5:11:05 PM

---

awesome i agree everyone has great ideas!  But i honestly i dont think this will effect development of the MVP so for now we will just use the static terrain we have and do our best to make it work and we can revisit this another time?

---

Created: 3/14/2018 10:11:00 AM

---

Guys as a team we all have a voice and I want everyone to know I/we take ever single idea everyone has seriously so we can make a choice for our direction.  We are not shutting down any idea for the future we are just picking a starting point for us to work towards.  Once that is done we can then fit the other idea in where they seem best and do some play testing.

I do believe in setting a standard for us to work towards and above at all times so we need a place to have a baseline to full understand what we are doing and make it so we can obtain that standard each and every time.

"Tutorial maps and many of the campaign maps will not be auto generated.  The auto generated ones is for the PVP more than anything."  -This baseline for us to start at is inline with our GDD goals.

@Wallace Yes the MCU has been adapted three times for different games since it was created many years ago.  I think its like 3 or 4 years old tbh. Also I really think you have something their with the hieghtmap idea I think performance wise that it will make a difference for us.

I love all of your guys/gals passion and everyone on this team bring strengths to the table but I feel we need to start somewhere.

Thanks,
James Fleming 
Facebook
Discord

Thanks,
James Fleming 
Facebook
Discord

---

Created: 3/14/2018 7:32:01 AM

---

I vote we table this for now.  As MVP wont be finished for awhile and theres allot of work that needs to be done rather than discussing the "best" way to do maps.  Either way its going to look great but for now the MVP needs to function great not look great agreed?

Also wallace.  You have to keep in mind both anthony and myself are leads.  While that doesnt mean that people on the team should just go around bossing others senselessly im sure that when anthony spoke of himself getting the work done either he meant him and his programmers that being you or very well could be himself.  Which as a lead if its important he do something while you focus on something else he has you work on that is perfectly acceptable.  Its important to have a few focus minds driving a project and its vision.  So i dont see anything wrong with the terminology we used given we were talking about things that ultimately are our responsibility to manage.  That doesnt mean what you have to say is not invaluable and your opinions are also needed.  But to keep the core design right and to have the project properly managed we need to have those focused minds.  The whole point of this topic was to get everyone on the same page because it seemed we were not.  

I for one have not felt like this has been heated rather a passionate debate about our options.  Which is entirely healthy and important to the games development.  

However i feel like this topic has become inflated and I would like to table to topic if everyone else is in agreeance.  If people want to continue the conversation of leads and their terminology I think there should be a different forum made rather than continuing that discussion here, if at all.  I think its important that no one is carrying an air of authority even if they have it.  James does not and i feel like hes a good example to follow.  So if you do have concerns or felt discouraged @wallace absolutely feel free to voice them.  Every member of the team has that right

---

Created: 3/14/2018 1:23:37 AM

---

To break this down more. Jonathan is an artist not a coder so he  doesn't know how powerful the code is and what is can let him do. Anthony is a coder not an artist so he knows what he can do in code and and has some experiences with that. I am between the two knowing what i can do in blender as and artist and what i can do in code as a coder. (not saying either of you are not familiar with art or coding i'm generalizing) The point is, what is best?

Its naive to assume at this point we have an answer for that just by talking about it. Discussion is key for direction but now were in the realm of educated guessing. Lets put some actual work in and try a few things. Honestly why is this even a debate. We NEED procedural environments for at least the multiplayer, that is set in stone, so its not do we handcraft or not, do we generate meshes or not. We need to start doing all three and see which parts work, which parts go together well and which parts don't. 

For all we know we might wind up generating the mesh sections,  placing them and their links by hand and decorating them by code. Thats not a combination anyone has mentioned yet and it could be what winds up working. I'm hoping with this slightly harsh breakdown we can remember we are trying to have fun making games that are fun, and that no one idea is golden, nor is it the individual ideas themselves, its the glue that holds the pieces together that really 'makes' the game fun and enjoyable.

I also want to address the use of 'I' weather intentional or unintentional. Anthony said I will create it by code, Jonathan said I will place items by hand, I said I too at some point. We need to remember we are a team. It kinda got me when the only other coder on the project that i know of implied he would single handedly code all the terrain generation and item placement. I realize that probably wasn't intended, but when we are in somewhat heated discussions about the direction of the project we need to be mindful of our teammates. I know i had let some attitudes slip out as well, i'm guilty of this too. I just feel we all needed a reminder to sit back a minute and actually consider each others ideas instead of dismissing them out of hand.

@James, Its your call obviously, but from my perspective this is the time to take a minute and waste a little time experimenting before making a decision and potentially having to backtrack later. Branching this choice here and actually trying each to see what looks best, what plays best, what is most efficient, this research will yield a more detailed direction moving forward and might generate ideas that we as individuals or at this level of fellowship just are not able to comprehend (yet). I am quite certain it will make for a better, more enjoyable and re-playable game in the end when all is said and done. Also there is the possibility that some of the systems or IP we generate can be used in future projects and will not be a total loss. Please keep this in mind. I mean, Armament is great, but what is next... then after that. Start the arsenal of tools now, MCU utility wasn't created for this project was it? seems it was developed for another project and adapted for this one as well. I'm not trying to waste money developing for the future but that is often how things work and not always a bad thing. 

---

Created: 3/14/2018 12:04:09 AM

---

Seems everyone is in a black and white mood lol. The only thing I have left to say is this... We are so in a hurry to decide, such a rush to push forward. There is no room it seems to experiment and try a few different things to see what works BEST. We are all talking like we can foresee all obstacles and problems that will arise and know best even though not one of us know the BEST answer to this problem for THIS project. I understand efficiency, and production cost, there is a need not to waste money on development. However the very nature of development... the process itself is to take an idea and see what works what doesn't and find a solution to fix the problem. This means there will be some "wasted' development. Which in reality is not a waste because even if that time wasn't determined to be a solution you found something that definitely isn't a solution and that is worth something too. 

We have two or three ideas for terrain and procedural vs handpainted. So why don't we invest some time right now while it's still viable to try these few solutions rather than discard them outright? For one major point, you make your team members feel like their ideas are worth something in stead of just being shut down outright. Second, rather than assuming to know every problem that comes up ahead of time you get to see what parts of a solution work and what parts down work. Often times the result is some mutation of all the parts that do work. Just as often those results can be unexpected to all members of the team initially planning the thing. That kind of development may be too chaotic for some but it yields the best and brightest ideas, not just industry standard approaches.

My 2 cents. I personally am not giving up on any of my ideas until I prove to myself they are not viable. I will continue to test things and try things because hey its volunteer time and that don't matter to anyone right? How else do you push yourself to improve and come up with new things? This is game development not enterprise application development, its suppose to be fun for those of us making the game and those playing it. Let's not get lost here. The best ideas are accidents.. remember that.

---

Created: 3/13/2018 11:20:36 PM

---

@Jonathan In closing the tutorial maps and many of the campaign maps will not be auto generated.  The auto generated ones is for the PVP more then anything.

Thanks,
James Fleming 
Facebook
Discord

Thanks,
James Fleming 
Facebook
Discord

---

Created: 3/13/2018 10:45:41 PM

---

I dont agree with black and white.  There are always many ways to do something.  The end or not its a matter of making the best decision for the game.  However like @james said we dont really need to worry about it until later though when that time comes we could do a more in depth look at it.  I dont think right now whatever we end up doing will change what happens for the MVP since we will just use the static terrain we have now.

 

Okay well im glad we discussed this i think unless anyone else has something to add we can move on from this topic?

---

Created: 3/13/2018 9:51:48 PM

---

I agree I think we need to explore the hex map generation idea.  After play testing we can see if it's a viable option or not.

However like I mention until we have the MVP we will use the terrain we already have for testing.

Thanks,
James Fleming 
Facebook
Discord

Thanks,
James Fleming 
Facebook
Discord

---

Created: 3/13/2018 9:25:06 PM

---

This is black and white. There are two viable solutions.

1.  You hand create every map.
   
   
2. I generate all the things.

The End.

I already mentioned the "Custom Scenarios" that would need hand crafted from the base terrain. That's as far as I think we need to budge with the generation engine for maps.

  - Anthony Michelizzi
  - Anthony Michelizzi

---

Created: 3/13/2018 8:53:29 PM

---

Yeah and i 100% get having variation like that and i think we can achieve that a great deal using trees and even large landmarks like mountains.  But i think we could generate the terrain like this it looks great but i think we should have a little more control over the maps.  The world would not simply look the same if your procedural generate everything.  but we could still achieve the same amount of variation making say...5 maps from one base map.  We could change environments and props and the player wouldnt even pick up on it.  

 

My fear is losing the soul of the world to the code.  Yes im aware we can do much but an artist hand would go so much further than keeping them in the code.  There are still restrictions that you could do your best but the world would still seem bland boring without a soul.  Thats why id like to make this suggestion

What if we procedural generated them and then gave the map to an artist to sculpt into the final product.  I dont know anything about networking thats for sure but if we are able to do this then anything the player will see would reflect the world and the character of the game.  I strongly suggest we mold the map before releasing it.  Regardless of how it starts.  

---

Created: 3/13/2018 8:40:53 PM

---

@Team Dynamic maps will be user in Armament just for the fact of replayablity.  @Anthony You had the same idea I controlling it by a database setting.

Thanks,
James Fleming 
Facebook
Discord

Thanks,
James Fleming 
Facebook
Discord

---

Created: 3/13/2018 8:30:46 PM

---

Quite possibly similar amount of labor. 100% more dynamic playing experience by procedural generation. 

Other benefits would be I could tweak the generation engine via the server without pushing a client update, and test updates in real time. Hand brushed maps would require a client update.

  - Anthony Michelizzi
  - Anthony Michelizzi

---

Created: 3/13/2018 8:14:59 PM

---

Im not 100% sure im on board generating levels 100% from code.  Some dynamic things like trees ya im on board with you but the entire map?

---

Created: 3/13/2018 8:11:23 PM

---

So the maps will be randomly generated?  Why not just go with manually creating the maps?  If its for a cheaper workflow i think the same amount of labor would go into making the maps wouldnt you say?

---

Created: 3/13/2018 7:57:38 PM

---

I'm going to randomly generate all the things. There will be some values that can be edited for different results for the user. Other than that, the control will 100% be in code. If you want different colored or seasoned maps, I will need an array of textures.

There will be a whole engine designed to create the levels as fair as possible, and the engine would be tweak-able.

There will be certain cases (scenarios) where I can get you a generated map to customize.

  - Anthony Michelizzi
  - Anthony Michelizzi

---

Created: 3/13/2018 6:17:37 PM

---

disregard my comments for the hex vs cube.  Uh ya i like it but like i said i still think some level of control like a brush stroke would be a really powerful tool.  random generation of things like props i think will happen in some way or another its kinda a standard now, but things like elevation and larger structures i think should be hand picked if that makes sense?

A giant mountain asset can be made and placed into an already generated scene right?  especially with the art style that would be achievable.  but if you could paint me a picture as to the workflow that would be really helpful.

 

My understanding is like this.  A programmer would generate the terrain then someone would go in and place the decal right?  For instance large permanent things like a mountain would be hand placed but like trees and rocks would be sort of "brushed in" based of density right and then the system would "jitter" them on post processing right?

I really like the way this looks just want to know what level of control would be where?  If that makes sense

---

Created: 3/13/2018 2:44:45 PM

---

The same theory should work whether it's hexes, squares, etc. Hex mapping just happens to be what I could positively show something for.

I personally like the hex for the mountains and valleys compared to squares/cubes. I think it looks more like a valley/mountain than the cube, while still retaining the low-poly look.

We should also be able to make a tool that would allow someone to generate a map, and then paint or change things about it.

As for painting/creating the mesh, the mesh is already built into unity. No need to recreate it. It does however use 2D textures to "paint" the map, and those would be something we would want

  - Anthony Michelizzi
  - Anthony Michelizzi

---

Created: 3/13/2018 2:20:57 PM

---

Honestly though I really do find it hard to objectively argue against hex mapping.  It does seem like its best for the project 

 

On top of that this really does eliminate human error so we can get buildings and things like that stacked where they need to be.  So its a really good idea actually.  But what could we do to allow for a more brush stroke approach?  

---

Created: 3/13/2018 2:19:36 PM

---

Okay so above i slapped a demo together.

Okay so as you can see from the renders and images ive been producing as well as the art direction this would be roughly what a mountain would look like.

Cubed and blocky.  So that being said theres no reason we couldnt make one giant base mesh, which would simply be the locations of land and water.  Then generate everything else.  

 

Im interested in hex mapping but my biggest concern in all of this was this.  The workflow needs to allow us to bust out maps like crazy given this is an RTS and maps are one of the main points.  However I am very particular about human touch.  

 

I understand roughly how random generation works.  Dynamic random it doesnt matter pulling from a stack of assest randomly still doesnt sit well with me unless i have full control of the generation if that makes sense.  

Lets say i start on map A .  First thing i do is decide how the map will flow.  If i manually create and place every asset on the map that gives me full control to deliver on the experience I intended on giving.  Currently I think i could make a base mesh and designed the model out and ready to place "stuff" on it in less than an hour.  For 50 maps thats well over a work week.  

 

Id like to stop talking about height maps now if possible.  Think its been decided we wont be using those and i feel like our time would be better spent moving on from that.

 

However for MVP we dont need more than one map do we?  Im finding it hard to understand why we cant use the one we have?  I would like to make a map specifically for the new design since that map we have does have a few issues and was made quite some time ago though im not sure we need to do that for the MVP 

 

@anthony if we would to generate the terrain assets i for sure would like to make base meshes at the least.  As well as being built of having access to tools that would allow me to "paint" the assets on dynamically if that makes sense?

 

As for the hex grid that seems honestly the most powerful and effective method we could use.  Looks nice I would simply want to see what we could do to make it look less hex and more cube though i suppose the detail could go into the tile.  Though that hex shape bothers me a little

Now thats looking at it objectively.  Im 100% any effective shortcuts we can use but that really rubs my artist hairs the wrong way.  Theres many ways to create something and using data and numbers makes me extremely uncomfortable as an artist.  Not something i will get used to either.  Personally i would like to go with what i suggested which is base map made and the mobilized so that way assest could be dynamically placed but also by hand.  This would add the variation but keep the control in my hands.

 

Trying to look at it objectively but maps are just another 3d asset.  And a tank and a map would take me about the same time and energy to complete. 

 

I dont know what do you guys think?  Am I making sense or am i just to close to the project?  But I am NOT a fan of using data to sculpt if that makes sense. 

---

Created: 3/13/2018 9:16:10 AM

---

@Anthony For auto generated mapping that look like maybe the direction we should go.

Does anyone have objection to the hex mapping after the MVP is done? 

Until we get to the MVP we will use @Jonathan terrain map.

Thanks,
James Fleming 
Facebook
Discord

Thanks,
James Fleming 
Facebook
Discord

---

Created: 3/13/2018 9:05:14 AM

---

Using the hex grid, this is the final outcome of that tutorial. I feel like it's already low poly. I don't know that you'll be able to rid all the hexes in this pattern. though we can probably do some magic with the map to either wrap the edges, or straighten the edges so you don't get that hex pattern on the end.

  - Anthony Michelizzi
  - Anthony Michelizzi

---

Created: 3/13/2018 8:48:43 AM

---

@Anthony With the hex map two question for us to use it would be can we make it low poly like the video @Wallace put up and can we edge it so it does not look like hex map generated map.

@Wallace Thank you for the video nice to see Unity will handle our terrain as well.

Thanks,
James Fleming 
Facebook
Discord

Thanks,
James Fleming 
Facebook
Discord

---

Created: 3/13/2018 12:47:49 AM

---

I'll give up on the unity Terrain for this, I was just trying to explore the limits of that system for my own knowledge in the future. I still think premade sectinos in blender that can be combined with code to make a large varying map are best. They can then be painted(colored) and decorated in various ways so no two are ever identical. The way I'm thinking of it we would have like X amount (say 50) different sized and shaped terrain pieces, a number of those say a dozen can be added and combined into a single map, which can then be painted to represent different seasons, various decor can be added, resources, it would be extremely modular. The elevation of each section can be adjusted depending on mountainous or plane-like regions. we can basically give the look and feel of any environment by combining a bunch of premade components. Like building a jigsaw puzzle that can be assembled in many ways. Just my opinion.

---

Created: 3/13/2018 12:30:02 AM

---

I've mentioned Unity's terrain for any kind of procedural generation, is not the way to go. I did this in "The Last Stand"

The only two real viable, in my opinion, are

1. A single or variation of a pre-made map(s), with changing resource/item/structure/spawn locations.
2. A procedurally generated mesh. (My personnel preference)

I think maybe considering the hardware that we want to target, #2 might be the best idea. I'm going to link a couple really awesome tutorials too that cover alot of the random mesh map generation, as well as many many RTS components that would be useable (and match the art style) of the game.

http://catlikecoding.com/unity/tutorials/hex-map/part-1/

here is the main page, if you navigate down to 1.5 you can see the large amount of features that go with this tutorial series, including units, biomes, ai/pathfinding.

http://catlikecoding.com/unity/tutorials/

  - Anthony Michelizzi
  - Anthony Michelizzi

---

Created: 3/13/2018 12:00:17 AM

---

Here it is: Jonathan's Terrian

---

Created: 3/12/2018 11:34:58 PM

---

Going to take longer to upload the video then it did to import Jonathan's terrain, add a collider, bake a navmesh, and have a working scene. I'll post link when its finished.

---

Created: 3/12/2018 11:10:04 PM

---

I would love to use Jonathan's map and I believe we can use the model, a collider, and Navmesh to get the same result. Jonathan had mentioned to me being able to make a heightmap form the model in blender. I would be interested in experimenting with that on my own time to see if the low poly style can be achieved with unity terrain systems. If so it will save time on level optimizations in the future as the terrains are automatically chunked. Also, multiple terrains could be in a scene at once and make for the same procedural systems I was talking about in previous posts. Note I'm not stuck on Unity's terrain I'm just chasing that thread as far as I can to see if it would work or at what point it prevents us from using it. Part of understanding the tools in our arsenal, and their limits.

I will work on bringing Jonathan's mesh in and making it work in the meantime. Jonathan if you could get me that heightmap or explain to me how to make it if you have time I would like to experiment with that a bit.

---

Created: 3/12/2018 10:58:21 PM

---

@Wallace Thank you for the video.  I do want us to try to use the blender terrain that Jonathan made so we can do the low poly like he has it.  Can you do that video with @jonathan terrain as well?  If so let me know and I will create an agenda for it.

2. We use blender model for terrain because I think in the end you will end up having to export that like @Jonathan said to match our art style.

Thanks,
James Fleming 
Facebook
Discord

Thanks,
James Fleming 
Facebook
Discord

---

Created: 3/12/2018 10:47:40 PM

---

This is what I've done with the Terrain systems as they are. As well as using NavMesh's and NavMeshAgents to move units. The nice thing here is the Navmesh components can be used with whatever type of terrain system we decide to use. 

Testing Scene

---

Created: 3/12/2018 9:39:02 PM

---

So I just noticed this image on the Armament game page. 



If this is the style we are looking at then the answer, in my opinion, is to do like I said in the last post and make sections, then control the placement of those sections and the links between them (aka bridges or other environ features). Jonathan could start making modular pieces then we can start building the systems to assemble them. Pieces kind of like these but many of them, with lots of variations, different bridge styles, so on and so forth.



With some forethought in design, these same pieces can have different base colors/textures and decoration sets for seasons/locations. We can start level generation by choosing a theme and locale. That will control how the pieces of terrain are positioned relative to each other, which color set/textures are used, and what decore/vegetation is used to populate the scene. It is a lot of logic but the end result could be very rewarding.

I have personally been working on object pooling systems in Unity with my personal projects with great success. One instance I created a pool of 10,000 game objects with rigid bodies and colliders, then spawned them in the world in waves ranging from 10-1000.  Obviously, the later had a noticeable performance hit but it showed me how to create pools of objects that can be initiated when the application is loading then placed in the world at a far less significant hit to performance then if those same objects were created as needed. This could be useful for level building mechanics. pooling terrain,  decorations and vegetation and placing them as needed when a level is loading to speed up the procedural generation.

Not to look too far ahead but the base system can be so versatile that it is useful in other games of varying genres as well. Different terrain meshes, textures, decorations but same core world building mechanic. It could make for a good procedural FPS level generator, or RPG level generator just as easily as it works with Armament. The NavMesh tools unity has available on GitHub; which should be in public release soon, will really make this an easy thing to do. Link here: Unity Systems - Runtime Navmesh Generation

Thoughts? (I haven't played with low res heightmaps yet not sure if that would be a possible option to get the square poly look) On a side note, Jonathan and I just ran down this procedural level generation rabbit hole for a game jam and wound up at the same result. We make premade pieces and chose one at random as needed. It was smaller scale and very rushed, but it's the same idea, it worked, and it was the best way to do it for that project. 

---

Created: 3/12/2018 2:21:52 PM

---

I apologize for getting ahead of everyone with the terrain. I was excited to use unity's terrain because after dealing with XenkoIi was thrilled at how the terrain collider is updated with the heightmap and i thought we could play with lowering the heightmap resolution to get that low poly effect. I've never used the terrain or navmesh system in unity and have been playing with them this weekend. Also based on the map Jonathan created I had assumed we were hard modeling the maps not looking to create them dynamically.

Dynamic, not random! Random generation is a misnomer. Often time the most successful 'random generated' games are not generated completely from random. Pieces are built by hand, then rules are set up to place those pieces in the world without conflict with other pieces. This is most likely the best approach for us. A combination of handcrafted parts and random placement/decoration will always lead to a better procedural generation system. 

As far as the nav-mesh system in unity it works by default with the terrain in unity but that is not the only way and it is NOT required to bake it beforehand. Unity has a feature coming soon that is available on GitHub now in order to generate nav-mesh dynamically at runtime, they can be attached as components to objects and rotated and scaled and translated in real-time. Using the navmesh should be a non-issue at this point.

A combination of using the new Navmesh components, blender cerated sections, which we can decorate procedurally then generate navMeshes for with complete obstacle avoidance. Then we create rules to drop those in the gameworld procedurally. 

---

Created: 3/12/2018 2:07:35 PM

---

Based on what I've seen I like two ideas out of this.

1. We go with a plan and just generate the assets onto it for a given map.  This will take care of auto generation for game play.

2. We use blender model for terrain because I think in the end you will end up having to export that like @Jonathan said to match our art style.

With this said for now I think we should use the blender terrain as that is more likely the way we will do the first option.

Does anyone disagree with this?  Going for number 2 right now for MVP.  But will work towards number 1 once the MVP is completed

Thanks,
James Fleming 
Facebook
Discord

Thanks,
James Fleming 
Facebook
Discord

---

Created: 3/12/2018 10:53:23 AM

---

First off i just want to make sure everyone is on the same page just in case.  Please take a look at the GAD if you havnt in awhile because im going to reference the art direction heavily.

first where exactly are we with procedural generating the map?

Because like @anthony said we could just have a big mesh and have all the props be generated like he said.  We could paint the props on in that way to be honest. 

But also because of the current art direction take a look at the character design.  That design will bleed into the world.  Not just low poly but cube geometrical shapes.  Because of this with a little effort we could create mountain assets and have those be generated too.  So really we could go allot without having to worry about where the assets come from.  Because if they are all made and we find a way to organically generate varied levels.  Start with a base model and change things a little with the code?

 

Either way i dont think we need a height map.  With the current art direction i feel if you could get a unit to collide with a cube it will collide with the environment.    just with some tilt some times.  

 

touching on unitys terrain editor in order to create low poly landscape you would need to export the model anyway and edit it elsewhere and im not a fan of those kind of short cuts.  That being said if we were to work with the art direction we could spin it but that would be a huge conscious effort in design going forward.  And  i feel like the current direction weve been taking this works really well.  

thought?

---

Created: 3/12/2018 10:36:28 AM

---

I think this 100% depends on many many factors and really would just require a use case test. It also depends on the work we want to put into the AI and random terrain generation.

Unity has special optimizations for their own terrain, but overall it's pretty limited to height maps and splat maps, not to mention baking terrain for AI on runtime is a nightmare. To get around the baking issues, we end up having to wrap up our own logic for navigating the mesh for the map.

If you create all your terrains in say blender, and then port them to Unity, you pretty much lose the random generation of terrain, though you can randomly place anything on the map. While the terrain heights and features remain the same, the resources and positions and control points don't have to. You can use unity's built in navmesh agent for ai and players (click to move). Rust uses a similiar approach in this regard as the physical terrain is the same, but everything (trees, rocks, plants, etc) are all randomly generated to give a new "terrain"

Finally there is mesh generation. This is probably the most malleable of all 3 options, and probably the most optimized for really large maps, this also takes a bit more logic though for randomly generating the terrain. At this point we are building everything from code. Most RTS games use this type of generation. A couple games to look at would be Civ 5/6 and Crashlands.

All 3 options work fine with the physics engine.

I have no physical knowledge of any games that use unity's terrain system for randomly generated terrain, though there are a number of tools that also accomplish making the terrain engine more robust, and I'm sure there are some games that do use it.

  - Anthony Michelizzi
  - Anthony Michelizzi

---

Created: 3/12/2018 9:34:21 AM

---

I think i have a solution ready to demo but i wanted to hear everyones thoughts first 

---

Created: 3/12/2018 9:32:38 AM

---

@Team Let talk end goal objective first here of what our project expects from the terrain.

• Able to create terrain dynamically
• Easy to use physic on
• Scales easy
• Must include Water/Sea/River etc elements

Thanks,
James Fleming 
Facebook
Discord

Thanks,
James Fleming 
Facebook
Discord

---