A whole heck of a lot happened this week – so there’s going to be a fair bit to cover here…
The main event of the week was the first public demo of LVL2 at Swinburne Open Day. I’ll get to that in a bit though, first I need to cover all the stuff that we did to get ready for that.
First of all, we needed to get our game into a playable state, and that meant we had a lot of work to do to make sure all of the systems that we had made were playing well together, that all of our levels linked together properly, all of the puzzles within each of the levels were solvable and that all of the other stuff like UI, menus, audio, particles and so on were in place and working properly.
This pretty much just boiled down to playing through the game a whole lot, and noting down everything that we noticed as broken. Then we’d go and fix all of those things and play it a bunch more.
But throwing a massive spanner into the works of that process was some sort of problem that was causing the game to fatally crash both within Unity and within a .exe build. This cropped up on Thursday and Friday immediately before Open Day.
Pretty much the worst thing that we could have happen at this point.
And just to add a degree of difficulty to fixing it, this would only happen to two of us. The other tester did not see this problem at all.
So: Sleuthing time. We had two initial candidates:
- On Wednesday, one group member had accidentally been working in a newer version of Unity than the rest of us. We would expect this to cause some problems, but not really anything of this magnitude, and not without causing any other problems.
- Also on Wednesday someone’s computer powered down in the middle of pushing a commit into our repository. Again, this shouldn’t cause this sort of problem, but we had isolated the problem as starting immediately following this commit.
So we spent a good couple of days trying to work out what was causing this crash, and how we would work around it. If we couldn’t fix it we were going to have to revert to an earlier version of the game, and lose all of the work we had done over the days since.
And then, we decided to look at what had been added to the game in that commit. There were a bunch of art assets, an animation, and a trail renderer on our player character.
So we turned the trail off – and the problem was gone.
And there was much rejoicing. Though we lost probably a whole day of testing and fixing to tracking down this one problem.
So – we returned to our proper schedule of playing the game a lot, then fixing what was broken.
And it was about 6pm on Saturday (aka, the day before Open Day) that we discovered that exiting the final puzzle of the game would cause you to spawn inside the ceiling.
Like so:
Now this was not what was supposed to happen. And seeing as how this only happened right at the end of the game – and only if you played through the entire game, it took a while to notice – and a long time to test any solution.
This one turned out to be related to the way we were recording and recovering position data on level transitions.
Basically our game works by travelling from Level 1 into Level 2 (which is a small space within Level 1), then down again into Level 3, then back up into Level 2 and then Level 1 and exit.
In travelling from Level 1 to Level 2 the game would record the game state of Level 1 so it knew where to return you to later on. But when you went from Level 2 to Level 3 the game would overwrite the Level 1 data with the Level 2 data. Then, when you returned to Level 1, the position and game state data were gone and the game would panic and throw you into the roof.
But we worked it all out, and by 2AM of the morning before Open Day we had a stable build ready to go!
And then Open Day went really well!
Plenty of people played Level2 and I manged to record a bunch of data to improve the game.
Probably the most important facts I took away were:
- People played all the way through to the end, regardless of skill level or how difficult they found it. This was really great to see, as it meant we had the difficulty/frustration level at about the right point. No-one just breezed through the game, but no-one rage quit after only a few moments either!
- And flowing on from that – our test build was way too long to play through. As a single player game, we couldn’t host multiple players at once, and with everyone wanting to play all the way through to the end, we often had one person playing for more than 10 minutes. And when we get to PAX that just isn’t going to fly.
- But our levels and puzzles are mostly pretty solid. They still need work, but it’s the sort of work that makes existing puzzles better, not the sort of work that requires entirely rethinking your puzzle creation philosophy.
- And always double and triple check all of your cables and screens and computers and audio and have spares of everything (we had a faulty data cable on our setup which had to be replaced before we could properly set up).
So we still have some work to do to get this to a place that is ready for PAX – but we are in a much better position than we were heading into the mid-semester break.
Because right off the back of Open Day, we started back at Uni Monday. So we have something like 80 days to get this game ready to fly at PAX and show off at one of the biggest gaming conventions in the southern hemisphere.
But, people travelled around the world in that long, how hard can it be to make a great game? Right?