December 6th, 2013
As always, you can read the full blog entry with pictures, sound track and bug of the week here: http://www.sauropodstudio.com/dev-diary-seventy-three-if-at-first-you-dont-succeed-test-test-again/
Testing debugging testing
So, we implemented a ton of new things in the latest internal build, including the new Fabric sound engine. Obviously, this had a big repercussion on the game. It’s a major switch, and those never come without bugs. So, we obviously need to test this version thoroughly before we could even think about sending it to our testing team. We encountered bugs like invincible walls, Bricktrons getting stuck in their pathing because of wood on the ground, odd sound glitches, the game suddenly becoming 60Mb larger, and using and extra 400Mb of RAM.
We’re gonna finish our internal testing, and then pop it over to our testing team to find the last of the bugs. Then, as always, push this big update to Steam and Humble Bundle.
The refactoring is taking up a lot of time at this point. I know we’re repeating ourselves, but this refactoring is crucial to the development. Once the code split is complete, all of the development will start to go faster, letting us have individual branches, improve the AI, ect…
A huge amount of this process has been on François’ shoulders, and with the team growing quickly, we don’t have any option but to split the system up so that everyone can have their hands in the code without messing with someone else’s work. When we were still smaller, this didn’t really effect things because everyone was sticking to their specific part of the game. But, with the situation as it is now, it’s becoming more and more difficult to handle. Having a team like ours means that we’re all wearing many hats, and if someone was missing from the development for some reason for awhile, that could eventually become a roadblock for everyone else.
Fortunately, we’re getting very close to our goal for this part of the refactoring, and this will lift the weight from François’ shoulders and allow all the other devs to start interacting with the more specialized parts of the engine.
Fabric is now completely implemented in the game. We’ve run into a couple of issues that need to be fixed, but the stability of the game overall has still been greatly improved. While this doesn’t fix pathfinding issues and what not, it should keep the game from just crashing out of nowhere on you. At the very least, if it does, we’ll know it’s our own code that’s responsible for it.
We went through and cleaned all references to the old system out of the code, so we can safely say that we’re now purely using Fabric, which should resolve a lot of problems.
We’ve continued the investigation into the Linux crashes this week. On a hunch, we tested a build of the game from 4 months back, before we switched to Unity 4.2, and realized that this particular build seemed to be working fine on Linux. So, we know that something happened between that point and now, and we’re thinking it may be linked to some issues with Unity 4.2 and our upgrade to it. We tried to compile this older build with our current platform, and it seemed to work properly. So, we’re starting yet another conversation with Unity, but of course, this means we have to target the exact cause and recreate it in an empty project so they can help us debug the issue. To be continued…
Bug of the Week
Check the main blog for this week's bug
Soundtrack of the Week
See Bug of the Week