Snap

Where I am now: continuing with Act 1. I did another round of resizing buildings and props, mostly in the city portion.

Manual trams: I’ve switched from an automated tram system to one that the player can activate.

I started with an automated one as I wanted this to represent a real-life tram system, which runs on a schedule. Since I want most objects in the game to be metaphors or representations of objects in the real world, I was fine with this, despite having the player wait to catch a ride.

But after more playtesting, I’ve found it’s not ideal. Some players get confused when there’s no tram at the station, but mostly the waiting doesn’t  really add anything to the game. It does mimic the same wait a person has when waiting for a train, but it seems that’s too real and doesn’t mesh with the other mechanics going on in Act 1.

So for now I’m going with a manual system. The front tram of both stations will now be open and ready to receive the player. Upon activation, the tram system sends both the player’s tram and the front tram at the other station on their way, making sure the stations remain synchronized.

Snapping…ugh. In previous attempts to lightmap the city section, light seems to seep through seams between the sidewalk, ground, and road tiles and creates lightmap errors on these surfaces. I found this odd, since I used Unity’s vertex snapping to place everything adjacently, so what’s the problem?

Apparently, Unity’s vertex snapping isn’t pixel precise. In fact, neither is its grid snapping. See the following pictures:

no seams

The sidewalk tiles in this picture looks perfectly flat and adjacent with no seams.

Upon closer inspection:

seams

Seams! I’m fairly certain this happens when trying to snap objects at dirty floating point numbers, resulting in rounding errors. Snapping a tile at 56.38405 + 2 will eventually result in a decimal that’s not .38405, making a seam between 2 tiles. So this should be fixed by only using whole numbers (56, 58, 60, 62…), but I’ve found that when grid snapping using whole numbers sometimes I get a 49.99995 instead of a 50. It’s sorta rare, but the solution to this is to manually go through all snapped objects and make sure they’re rounded off. It’s a pain, but I don’t see a way around it.

Though I have seen something like ProCore 3D from the asset store, and makes me want to try it out. Fast level building, and I think it merges tiles together to create seamless surfaces. When I move past temp art I’ll definitely give it a serious go.

Resizing, round…3? More resizing! This time it was the trams, tram stations, and city area. Both of these were in dire need of resizing as the player’s move speed was lowered in the previous build yet these spaces remained huge, and to temporarily compensate for the city portion I increased the player’s speed as they entered the city, but no more! Here’s some nice comparison shots.

Tram statiom before:

tram_old

and after:

tram_new

Waaaaaaaaay better. All that extra, useless space gone.

City before:

downtown_old

and after:

downtown_new

Despite the player model being there, the size difference may not be readily apparent, so I made an old / new orthographic view of the city:

downtown_sizeComparisons

That should give a better reference of just how much more compact it is now.

Now I just need to re-place all the stone people and rickshaw props, which should take too much time. After this is done…I’m not sure what I’ll work on next. My white board has a list of high-priority sticky notes, each with its own task. Guess I’ll need to pick and choose the right one.

Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *