Month: August 2017

So we had our big public play test at Bar SK last week. And it all went really well!

We went the whole night with a single build of the game running. No restarts, no crashes, no game breaking bugs. I was really happy to see that, especially with how poorly our very first playtest for FourShadow went back in April.

There weren’t any particular problems with the game either, no-one got hopelessly stuck anywhere, nothing happened that we were completely surprised by and no-one managed to pull off any moves that broke or short circuited anything.

Basically, I’m saying the playtest went really well, and most of the findings that we had were for small improvements in the game that we have rolled into our work program for the coming weeks.

---

Speaking of our work program – what is on for the next few weeks leading up to PAX?

We are feature locked now, and last week’s playtest proved that our game is stable and playable from start to finish. So this leaves two things for us to do:

Polishing and Playtesting!

That’s right, we’ve got a pretty full program of public playtests over the coming months, and between that we are going to be working away to make sure that the games looks absolutely the best that it possibly can.

---

We heard a talk at uni this week from Cam Rogers on legal matters relating to game development.

It was mainly focusing on what would be required if we were considering forming a studio following uni and the matters that we would need to keep in mind.

But there were also some things in there that are more immediately of concern. Namely, who owns the game that we are making right now, and what rights the group and each member of the group will have going forward.

At the moment, it’s all kind of a mess. No-one really has sole ownership over anything, and if there is any sort of falling out, or someone goes missing, we’d be hard pressed to do anything further with the game without some serious overhauls.

So I’ve been looking into drafting a sort of contract for all of the team members to sign to cover the following matters:

• Monetising.
• Publishing.
• Using the game in a portfolio.
• Doing further work on the game following the end of university.
• Continuing to work on the game if not all members want to do so.
• Continuing to work on the game if members become un-contactable.

This is just going to be a very basic document that will go over all of the matters. I have no doubt that it wouldn’t stand up to a serious legal challenge, but it will at least ensure that everyone is on the same page for the rest of the semester and beyond.

I have to admit, that this has also been prompted by being caught out by this to an extent. A game we made last year – Light My Way – is not able to be put up on itch.io because we are unable to contact one of the team members any more.

So this will hopefully prevent anything like that happening this time, and people will be able to play LVL² once we are finished with it.

 

This week we have been pushing away at getting a build ready for play testing and displaying at Bar SK, where we will be part of the Work in Progress Wednesday this week!

It’s pretty exciting to be having our first public showing, and the whole team has been putting in the hard yards to both get everything working and to have the game looking as pretty as it can.

So today I’m going to give you a sneak peek at some of our new looks to show how far we have come since we started out waaaaaaaay back in … July.

So here are some screenshots of the levels that we put together for our first play test in late July:

 

And here are some shots of the build that we are getting ready to show on Wednesday:

So as you can see, we’re trying to keep our design quite minimal and basic, with just a few colours and shapes to communicate to the player what is going on. You can see that there is still a bit of text present within the game, to let the player know what is going on and what they are able to do as well.

But altogether, I think the aesthetic is coming together well.

 

---

And to wind up, I’m going to acknowledge that a lot of the issues that I identified in earlier posts – to do with roles and responsibilities and clearly working out goals and tasks and so on – seem to be working out a lot better now.

Part of this probably comes down to me feeling a lot more positive about our game in general. But it also comes down to us having actually gotten together and put in the effort to get all of those things worked out.

What this means is everyone now knows what they are responsible for, and who to go to if something needs doing.

Which seems to have flowed on to a much better pace of development. Though, again, this might just be down to me feeling better about where we are heading!

Well we are well and truly back to work now. Unfortunately that means I don’t have any grand event or story to tell this week. We’ve pretty much just been working away at the game without any major milestones passing.

What has been going on is a whole lot of planning for the rest of the semester and the lead up to PAX.

So this has seen me not really doing any actual game design at all. The rest of the team are working away getting our levels and puzzles and sounds and everything in order. Instead, I’ve been working on Design Documentation, production timelines and task management.

And, it’s actually been pretty great.

Our main tasks this week was to present our release plan – this is essentially a reflection on the last semester and our plan for the coming semester.

First of all we went over what we had learned from our play tests, then how we had re-scoped our project for the rest of the year.

Due to our group having scrapped our game and started an entirely new game over the break, we had to approach this a little differently. Most of the playtest data we had recorded wasn’t really relavent any more.

However, we had managed to learn quite abit about how to approach and prepare for a playtest. Our first playtest had been a bit of a disaster. Our build was not stable enough to run, our computer did not have functioning sound and our UI instructions did not work properly.

So one of my tasks this semester is to write up a proper play testing strategy, so that everyone knows what we are doing with each playtest, and everyone knows what we are trying to learn from each playtest.

And finally, I have been mapping out a timeline for us.

One of the other producers found a really useful tool for creating gantt charts out of task lists in Asana. Massive thanks to @RubyDev_Lin  for finding this great resource and bringing it to everyone’s attention.

So here is our timeline:

 

So our plan is to have a lock on all of our mechanics and puzzles very soon. I’m very keen to ensure that we have as much time as possible to polish and refine, rather than continue to create more new stuff.

There is also about a month before PAX where there is nothing in particular booked in. This time is reserved to make sure we have the best build we can, and also just in case there is some sort of emergency and we need extra time.

But, yeah, as you can see, we have plenty to do, and not a whole lot of time left!

Just a quick post this week. Sorry it’s late, but (as I will soon explain) there is a good reason for it!

---

So we are back at uni now. And we’re jumping straight into development. As our lecturer explained it: Semester 1 – make a game; Semester 2 – make it good.

Strangely, I have found myself doing almost no game development at all this last week. I’ve been totally taken up with documentation and scheduling. Part of this is due to assignments for uni, but also we have let our documentation slip a little over the break, so there is a bit to catch up on. It’s not as fun as game development, but it’s pretty important stuff, and letting it slip is not really in our best interests.

I’ve also worked out a timeline for our production this semester, including lock dates for features and levels, a rough testing schedule and major milestones.

I’ve set our major milestones around public play-testing opportunities. And that leads into the reason there was no post last night – we were running a play test at the IGDA Melbourne meet up.

We set up our latest build of LVL² on a table and let a bunch of game developers loose on it. This was a very different experience to the Open Day play test. Game developers bring a different mind set to playing and observing games, so there was a lot more effort put into breaking things. And there were quite a few things that got broken…

On the one hand, this is great! We found out a bunch of stuff in our game that can be exploited or broken if the player does something that we hadn’t expected. Now we can go back in and try to mitigate that. On the other hand, we didn’t really manage to find out if any of the changes that we had made in response to the Open Day play test had worked, due to the different play styles of the testers.

But overall this was a very worthwhile experience, and we’re going to try to go along again as many times as we can before PAX.

And our big news – we’re going to be in the Bar SK Work-In-Progress Wednesday event for August!

So if you’re keen to check out where we are at, and maybe give us some helpful play testing data, come down to Bar SK on 23 August!

 

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 LVL² 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:

1.   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.
2.   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 Level² and I manged to record a bunch of data to improve the game.

Probably the most important facts I took away were:

1.   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!
2.   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.
3.   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.
4.   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?