I’m currently in the process of prototyping a City Builder game. I have 15 years of programming experience and am comfortable with both C# and C++. The questions I have are more on functionality of Unity rather than specific scripting errors. While my programming background helps me understand how to model the simulation I have zero experience with Unity and rendering engines in general. Also, I plan on using Unity Pro for the final product.
I have done extensive reading on these issues and can’t find one solid direction or answer, so I look to the community.
My first question revolves around assets. I understand when making an FPS game that the levels and content is static, however that is not the genre I am making. Much of my game will have to be moddable and extendable with addons by my company or fans. These can will mostly be building assets, and depending how extensable the system is I want to support the creation of as much content as I can. So can I make a standard ZIP file and have my own ZIP archive classes infuse the game with the content contained therein? If the next time I run the game and there is another ZIP file, can I integrate that into the game?
Everything I’ve read so far involves assets and asset bundles, however the customers who play the game shouldn’t be required to have Unity to create these assets. I want to include a “Building Editor” with the game that loads the building model and textures and lets them set up the metadata specific to the game and save it as a ZIP. The game would then have to be able to load it at runtime. Is this possible?
The second concern is threading. Naturally my game will have many simulations going on in the background. I’ll not get into their details at the moment, one example is I need something like a pathfinder to run in its own thread to prevent the FPS from dropping. And most important of all is the method the threads are able to talk to one another. Once a path is found for Citizen Y I need to tell the primary game object a path was found and the nodes and links associated with that path. Furthermore, if the player places a new road I need to be able to update the pathfinder with the new nodes and links availble to it. The traffic simulator will need to take the path usage data and set congestion/timecost values to the pathfinder. This process won’t happen every frame but once every game month, probably every 5 to 10 real minutes.
Since rendering is where I lack the most experience I’ve done extensive reading on the matter. I do have a couple questions that are important.
When rendering something like a building what exactly is the pipeline for that process? I’m aware that polycount is important, but what triggers a drawcall? Would UV mapping the building be beneficial or detrimental? I plan on having at least 3 LOD levels for each building. The LOD0 up close view being the most detailed. I want to be able to support normal, specular, and bump maps at this level. The more distant LOD1 would only support one of these maps. These would be buildings several hundred units away from the camera. (I’m planning on 1 unit = 1 meter at the moment.) LOD2 would be very far away and require very little detail.
At LOD2 the camera would be very high up. The crux of that is there would be hundreds of buildings on the screen. Even with these low LOD levels am I then limited by drawcalls? Would it be better to lock the camera at these altitudes to a certain angle and simply render the buildings as billboards? Wouldn’t that require just as many drawcalls? Can meshes be combined and split dynamically? Lets say a neighborhood has 100 houses and the player zooms way out, those houses are now LOD2, but there is still 100 of them.
One other huge area of concern are shadows. I need to include a day/night cycle. But I know dynamic lighting and shadows are a huge burden on rendering. How could I approach a solution that looks good and performs well? At LOD2 levels and the distance of the objects the shadows wouldn’t need to be very detailed, it’s just the sheer number of objects that is my concern. Am I correct in my understanding of shadowing that the scene is basically rendered from the lights position and shadows are calculated from what is hidden?
The inclusion of night time demands city lights. And I want to include in the “Building Editor” a way to add lights to the buildings. The user will need to be able to select a window polygon and set a flag for night time, thus making the polygon use (at night) a self illuminated texture to simulate a light is on. Other lights would mostly be directional lights. These lights would be used at LOD0 detail, LOD2 lighting would need to be baked into seperate self-illuminated textures while in the Building Editor. Thus when viewing a city from a distance would give the illusion that lights are on but not actually need to calculate the lights in real time.
A lot of this game will require pulling the fun of making a world within Unity into a game in and of itself. Aside from the game exe and Building editor exe I will also need to make a Region Editor. I’m already talking to a few people who’ve done some amazing things streamlining the process of making terrains, what I’m wanting to do is take the process of setting up terrains, splat maps, foliage, and water and make it its own application. The tools would be streamlined enough where all the user would need to do is select a tree family and use a brush to place them on the terrain. Terraforming, splating, etc would be handled the same way. Rivers would be created using a similar node-link system as roads as I’ve seen in many downloadable add-ons to Unity, only they would need to be done in my Region Editor.
I understand this is a huge project and have already gotten financial support from some very dedicated fans of the genre. Once I complete the prototyping I plan on getting funding and help from other developers and artists. Unity has an amazing community, but I’ve seen enough FPS/MMO/platforming games to last 10 lifetimes. I want to show that Unity is powerful outside of these genre’s and will put every effort into proving it.
Thank you,
Nick