When coding a project, you can over-optimize too early, and do yourself no favors. There’s no sense in optimizing something that isn’t hogging the game down too much. Good coding habits can prevent a lot of issues. Well, it certainly isn’t too early to look at the Unity profiler now that I’m well in the weeds with Season Mode and the Xbox One port of SSDT.

But first look at this fancy new menu layout!!!!

not really
Fance de la Pants

The giant list of buttons look has been bugging me for a while, and I wanted an arrangement that emphasized Season Mode as well as split the games into 1-3 and 1-6 player varieties. Now back to the boring stuff!

I noticed the game hums along at 60 FPS, with occasional spikes.

while profiling
I noticed

This one looked pretty nasty, so I took a closer look. Strangely, it was collision code with my “out of bounds” boxes.

maybe a hypercube
Not a hypercube

These giant cubes live all around the 3D game area, and in case anything ever “falls out of the world” these boxes will reset the game objects back into play. Well what the heck could be colliding with these guys?

The roof of lies

It turns out I had put one of these boxes right on top of the ceiling. Who knows, maybe a ball got up there once? I saw there was a spot in the code where it tries to get a component from whatever it is colliding with. Upon adding some Debug.LogWarning calls in any situation I’m not expecting, sure enough the culprits appeared.

Whoops my bad

Aaaaand it was the walls. And the goalie walls. And some of the score areas. They were constantly colliding, and the code was looking for a component that wasn’t there. Now I just return immediately if I run into anything on those layers, which was a quick fix.

A few more bug fixes here and there were made, and everything was running well enough to make a new build to test on the Xbox One. Work continues continuously!  Until next week, or sooner, or possibly later.

Add a Comment