New Release Blues

You can get the new build at http://energyhookgame.com if you don't already have it. This build has gear customization (adjust the speed of your jets, the parameters of your energy hook, and more); new animations (hold X+Y to get at the third midair trick now); and leaderboards, so you can throw down. For now, you can grab whatever screen name you want, though I will be resetting things later when we get closer to Done. 

With the latest release I wanted to not only get every stretch goal to a first draft state but also polish glaring issues - janky animation in particular. (Especially since James Zachary has been doing some work and there's no excuse any more.) 

It's taken all week! I started cleaning stuff up on Monday, sweeping up dead leaves, so to speak, and have finally gotten to the point where I can push a release that doesn't suck.

This last glitch that I was cleaning up today was one for the books. The lighting in one of my levels looked really blown out - but only when I played the build, not when I played it in the editor. After much experimentation, I realized that if I went to the level from the front end, it had the problem. After looking at various lighting and camera and graphics settings and wondering what could be bleeding from one level to the next, I got fed up and started deleting objects from the front end, hoping it finally would go away.

The offending object? ParseInit, the object that handles the leaderboard API. 

But it wasn't Parse's fault. At some point, I somehow accidentally dragged the front end's directional light into the ParseInit object. Which is persistent. So the directional light was in every level. (It looked a little bad in some of the levels, but was particularly painful in the Misty City.)

Whew.

I'd also discovered that my lighting and shadow quality had ... drifted. Just didn't look as good as it used to. Maybe I applied some changes to a light prefab, or the camera, or something. Don't know.

All in all, I think Unity could use some way to lock your objects and prevent them from being changed once you have them at a state where you feel they're done. Sort of like taping down knobs on a mixing board - you don't want to accidentally bump them and mess things up just a little, because you might not notice until much later and be at a loss what got messed up.

And, just for giggles, this is the checklist I follow when I'm trying to get a build together:

Release Checklist

1. Does anything need its lightmaps redone?

2. Check log and update version number +1. Apply changes to prefab.

3. Set quality to normal.

4. Save project & exit Unity (just to be safe.)

5. If currently using NGUI Easy, delete and switch to NGUI Pro

6. Build windows

7. Test:

   1. PC

   2. Oculus

   3. 1st & 3rd person modes

   4. registering for leaderboards

   5. mainmenu leaderboards

   6. level coverage

8. If testing fails, fix & go back to 3

9. Once testing is solid, add changes. Commit changes

10. Build linux (universal)

11. Change Input for Mac: InputMac -> Input

12. Build & test on Mac (have to build from Windows so we have the lightmaps)

13. Switch back to Windows OS

14. Zip separately and share with Humble on Google Drive (this portion takes me hours because of my slow upload speeds - good to do at night)

15. Wait for them to get in there

16. Announce to: in-game news page, blog, forum, mailing list, facebook

 

Comments

[Happionlabs]

After writing this, it occurs to me there is a way to "lock" those inspector values - at least for your own classes. Move the values back out of the prefab and into the defaults for your script and make them private. I might well want to do this for my character's movement parameters...

[Chris Chapman]

For locking things down: I found text scene files and extensive use of prefabs pretty good for spotting rogue / accidental changes. I.e. partitioning off bits of content you know are fine by making them prefabs, and maybe also leaving copies of them in a separate scene (or ideally referencing the content direct from that scene). If you then open up that scene later and it needs resaved, you can go look at it in source control and see if the changes made (maybe because a prefab was changed elsewhere) are all expected. Often I saw accidental restructurings, parameter changes that were leading to trailing / dead references, etc., that would manifest themselves as badness in the live build.