A lovely low-poly, very Minecraft looking model pack that started this studio’s Simple series. This is one of the most popular packs on the asset store, also widely used by mobile games, including Crash World!
I’m starting this series to give asset creators feedback on how gamedev’s use their assets and what they like and don’t like.
Good starter pack, great variety except for roads. Clean optimized models, and partially atlased low-res textures make it ideal for mobile games.
The prefabs are split into 4 categories:
Please note that not all assets from the screenshots are included (pedestrians are not included)! Still, this pack is enough to get you started on a generic looking city with diverse buildings, a couple of cars and some props.
How it’s made
How low poly is it? The buildings range from 300 tris for simpler buildings up to 2500 for complex looking ones. Each car is about 500 tris, and props are generally in the 200 tris range. That’s more than good for bringing your game to most entry-level devices in stores today.
Are textures in an atlas? Well the answer is some. There are 36 textures covering this whole pack, and most of them are for buildings and vehicles. Props all share 4 textures and the environment is in 3 textures total. Most textures come in 512×512 resolution but can look decent down to 128×128.
Vehicles come in 2 varieties – with separated wheels and with merged wheels. If you use vehicles like props, and have them stationary you’ll use merged models to save a bit of CPU time on transforms and static gameobjects, but if you need your cars to drive and have suspensions (like Crash World does), you’ll use the separated meshes. Staying true to the cartoony theme, all vehicles have tiny wheels compared to their real-world counterparts, which can cause problems when simulating realistic car physics. Wheels so small can bump off smaller obstacles like sidewalks (not having enough surface area), the center of mass is a bit lower. But what can you expect when trying to make cartoon cars behave like real cars.
The meshes in general are all built with clean geometry, usually in a single mesh part with only one material. One thing I noticed is that Synty likes to save a few tris by deleting faces such as bottoms of buildings and props. This is not desirable! Back-facing tri’s get culled off anyhow, and with such low poly models, saving a few tris from passing this simple GPU filtering is just unneeded. This caused some pain as the bottom triangles from props like hydrants and lamps are cut off, which results in a see through hydrant when it breaks off and flies through the air!
dot(camera_forward, tri_normal) >= 0the triangle get’s discarded. Simple as that.
I’d love to see asset creators create collider meshes for their models! There are plenty of ways to create colliders, but with such low poly models you could provide at least a basic collider setup using boxes. Could save us quite a bit of time on setting up prefabs.
Everything pretty clean here, but then you see something like this.
Now this must be hell to UV map! How do you go with this through your workflow? For example try to change the color of only one model part that uses the color from this “lookup table”. You have to UV map it again! Break off the seams, and move the UV’s to the new color. It’s all good if only Synty had to go through this, what about the users looking to modify these models? This is a terrible way to UV map things.
Don’t get me wrong, not every asset is UV mapped like this, but some are. Maybe 2% are. But there’s always an asset in that 2% that you’d like to modify. I appreciate the though about optimizing things, but this (just like the missing backfaces) is an over optimization. If I had a game that needs to be this optimized, I’d use vertex colors.
When it comes to roads in this pack, you don’t get a lot of variety and I feel assets are missing for some setups. If you stick to what you see in the demo scene you’re all good, but that’s probably not what you want :). The demo scene is oriented towards two lane roads and 90deg turns. The sharp turns are okay, but the 2 lane roads are not. What Synty should have done differently?
- Lane markings should come separate from the road
- The sidewalk and the road should be separated
- Pedestrian crossings should be separate from the road
The roads use a grid system what works well if you have snaps on every unit (i think the roads are 10×5 units). Speaking of grids, there’s this basic problem with constructing bigger things out of smaller things (like a city from roads) – how do you approach colliders. You can just build a collider on a single road and prefab that, but then you got lots of small colliders. Even worse with these roads – the sidewalk is built in! You have to have 2 box colliders per road segment. Given our typical city part has ~150 segments, you get 300 box colliders. Another approach is to hand place colliders, which is tedious but gets you about 20 colliders. That’s a difference of x15!
Our approach was to leave the sidewalk colliders in the road segments and have a universal ground collider placed at -0.2Y spanning the whole game world. A passable alternative to hand placing colliders.
Synty’s Simple World is a great starter pack if you’re into building a low poly cartoon city. Apart from some minor technical quirks, we didn’t have any trouble using or modifying models. We even integrated car physics without any problems. Expect to hand place colliders on every prefab.