kipslife.com

Hi folks, it’s time for my yearly summary of books read over the past year. (I know Easter is an odd time to do a yearly review, but I started doing then one year, so now I have to keep doing it at this time or my year gets all thrown off. )

Had a big year this year. Pretty sure this is the most books I’ve read in a single 12 month period. Total for this year was 38 books.

Here’s the list, in alphabetical order by Author surname:

Author	Title
Nana Kwame Adjei-Brenyah	Friday Black
Isabel Allende	The House of the Spirits
Belinda Bauer	Snap
Anna Burns	Milkman
Albert Camus	The Stranger
Peter Carey	True History of the Kelly Gang
Paulo Coelho	The Alchemist
James Fenimore Cooper	The Last of the Mohicans
Mark Z Danielewski	House of Leaves*
Nick Drnaso	Sabrina
Graham Greene	The Power and the Glory
Andrew Sean Greer	Less
Imogen Hermes Gowar	The Mermaid and Mrs Hancock
Maria Dahvana Headley	The Mere Wife
Tahar Ben Jelloun	The Happy Marriage
Jennifer Zeynab Joukhadar	The Map of Salt and Stars
Barbara Kingsolver	The Poisonwood Bible
Cormac McCarthy	Blood Meridian
The McElroys	The Adventure Zone: Here there be Gerblins
Sophie Mackintosh	The Water Cure
Kate Mayfield	The Parentations
Hope Mirrlees	Lud-in-the-Mist
Ottessa Moshfegh	My Year of Rest and Relaxation
Naomi Novik	Spinning Silver
Michael Ondaatje	Warlight
Orphan Pamuk	A Strangeness in My Mind
Sarah Perry	Melmoth
Dorothy Porter	The Monkey’s Mask
Kevin Powers	The Yellow Birds
Ransom Riggs	Miss Peregrine’s Home for Peculiar Children
Leone Ross	Come Let Us Sing Anyway
Nafkote Tamirat	The Parking Lot Attendant
Olga Tokarczuk	Flights
Oscar Wilde	The Picture of Dorian Gray
Charlotte Wood	The Natural Way of Things*
Non-Fiction
Clementine Ford	Boys Will be Boys
Don Norman	The Design of Everyday Things
Tara Westover	Educated

The * designates books that have been read previously.

Managed to get a few more books from South American authors this year, as well as a few more translated books. I’d like to try to read more translated things in the coming year. I also note that only half of these books were by non-male writers, so I probably need to put a bit more of a concerted effort into that.

I’m vaguely thinking of putting together one of those maps pages where people note countries they have visited, except I’ll use it to note whether I have read something by someone from each country.

Anyway, have a look through the list, let me know if there’s anything you’d like to try, or if you have any suggestions!

Hi folks,

The Game Awards are on shortly, and I just want to take the opportunity to wish all the best to all of the teams and game developers that are up for awards this year.

It’s been a pretty wild ride for Glitch Crab Studios since we won the Best Student Game Award at last year’s ceremony. We’ve formed a company, sought funding and publishers, exhibited at PAX Australia, traveled to New Zealand and also continued to work on Level Squared!

So: Best of luck to all of the teams that are up for the Best Student Game this year. All of the nominees look fantastic and we’re more than happy to hand the mantle on.

And best of luck to our fellow Australian team Mountains, who are up for three awards for their great game Florence.

Hi again everyone.

First off, sorry that it’s been a while since the last post. While I was busy and distracted by various other jobs and uni, I also got a bit disheartened with the blog and everything and took a bit of a break. That went on for a bit longer than I anticipated, and I got out of the habit of writing each week.

But I’m back now, and I have plenty to catch you up on!

The obvious big thing that has happened recently is PAX Australia, and we had a booth in the PAX Rising section!

(Disclosure: I didn’t take this picture. It’s from David Rayfield’s excellent article on Junkee (PAX Australia Is Video Games, Minus The Worst Parts Of Internet) go read it, it’s tops.) 

We were part of the Swinburne booth last year, so this wasn’t technically our first time showing at PAX. However, this was our first time out on a booth all of our own, and our first time dealing with all of the planning and logistics that came along with that.

For the next few weeks I’m going to write up some posts going over what we went through, what we learned and what I think we could do better if we ever do this again.

The Application

First of all, you need to apply to be part of the PAX Australia indie section. There’s a form to fill out on the PAX Australia website that covers things like team size, the game (or games) you are working on and the release window for your game. We completed this application in April 2018 and have been going through the planning ever since. I imagine if you work on a team that does a number of shows over the course of the year, you could have someone working full time just on arranging and organising exhibitions.

Once we were accepted for PAX we had to choose our booth size (the smallest) and arrange for payment. Fortunately this was offered in an installment program. We’re operating on whatever the tier beneath shoestring budget is, so the fee was a pretty hefty outlay for us. In fact, it’s been our largest single expense to date. I’ll come back to this in the final wrap up, but the fee to appear at PAX is going to be one of the big considerations in the final weigh up of whether this was worthwhile or not.

Planning

Over the six months between getting accepted to PAX and the show, we had to do quite a lot of planning and organising.

I’m going to leave aside the fact that we had to get our game into order and have a workable demo. Obviously that’s important, but that’s not what I’m going to concentrate on here. Basically, I’m going to go into all the non-game development stuff that we dealt with in preparing for PAX.

The longest lead time was ordering all of the things that we needed produced in time for PAX, things like our pins, business cards, shirts and so on – everything that had to be shipped to us. We successfully arranged for all of this well in advance and had everything arrive in time. We were pretty well off in this regard, as we had already had practice organising these things for the previous year when we had been on the Swinburne stand. In fact, we even re-used our shirts from the previous year and ordered a re-print of the same badges. So that all went according to plan.

I wrote up a small spreadsheet going over all of the bits and pieces that we were going to need to run the stand. And started to organise who was going to volunteer their gear.

In a bigger company this would be covered by the company, either bringing along their own things, or buying stuff once they arrived at an overseas exhibition. But, again, less-than-shoestring budget, so we had to use our own equipment.

Item	Number Required	Electrical tag required?
Computer	2	Yes
Controllers	2	No
Monitors	3	Yes
HDMI cables	3	No
Chairs	2	No
Power board	1	Yes
Keyboard	1	No
Mouse	1	No
Speakers	2	Yes

That’s the table that I put together to track what we needed, where it was coming from, and whether it would need to be tagged (electrical saftey tagged) once we were at PAX.

There are a few things that were left off there, I now know. things like batteries for the controllers, back up controllers (for if/when something goes wrong), spare cables and such. Also it turned out that chairs are provided with the booth, so we didn’t need to take those along ourselves (didn’t find that out til I had already lugged the chairs into town though…).

I ran into a problem with the HDMI cables as well. Our design was to have Level Squared playing on two computers facing out at 45 degrees, with a single monitor in the centre playing a looped video of gameplay footage to draw people to the booth. It didn’t occur to me in advance, but there was only one HDMI port on each of the computers that we had, so I had to get another type of cable to run the remaining screen. Luckily I have a big box of cables at home, so I was able to grab one of those and sort it all out.

Finally, we needed to work out a roster for the booth, to make sure that everyone had a go on the booth and that no one person was there for too long each day. This is probably the one time that our team being so big is an advantage. We were able to arrange it so that no-one was rostered on for more than a half day at a time, and no-one had any more than two shifts across the weekend.

But in all, our planning and organisation went pretty well and we had everything that we needed arranged pretty well in advance.

Set up

…Except that there wasn’t anyone available to help with bump-in. So I ended up having to do that alone.

Which wasn’t all bad. I didn’t have to deal with anyone else mucking anything up. Though it would have been handy to have someone to send off to get things, or to help lift some things.

But I’m not going to lie, I was feeling pretty tense. There were a lot of things that I could see going wrong and I started to get a little bit lost in all the problems that I was trying to solve without making too much advance on the actual booth construction.

BUT, there were a bunch of other developers around who were also setting up their own booths, some that I knew and others that I met there. And many people dropped by to say hello and see how I was doing and offered to help with setting up. And that was really great, and it made me very happy to be part of such a nice group of people.

So it all worked out alright. Set up took around 4 hours all up, including a trip into the city to buy speakers. And once I was done, the booth looked like this:

Now all it had to do was last through 3 days of PAX…

---

I’m already over 1000 words so I’m going to break this up into a few weeks worth of posts.

Next week I’ll go over our day to day operations, running the booth and bump out. And then the week after I’ll cover lessons that we learned and what I would do different next time.

See you then!

As I said last week, this week I’m going to go over what we do during and after play tests.

We ran another play test at the IGDA Melbourne meet up last night, so I’ve got a bit more recent data to use as examples for this post.

---

Here we are set up at the meetup last night.

Unfortunately, I only have a small laptop, so we weren’t as eye-catching as we could have been. But we were set up to face out into the room, so that people would notice the screen and be drawn over to watch other people play (and thereby be enticed to play themselves!). Ideally this would be done using a larger screen that was set higher so that viewer could see it over those playing, but the facilities last night didn’t allow for that.

However, this set up did allow for the player to be sitting down, and that meant that people standing behind were able to watch.

(This is a bit of a catch 22 for us. Level Squared is a puzzle game, so a lot of the fun comes from working out how to solve puzzles and progress. However, a person watching the current player will see the solutions and that reduces their desire to play. But at the same time, we need people to be able to see gameplay in order to be drawn in to want to have a turn. It’s a problem that I’ve never really managed to work out a solution to.)

At least, it didn’t seem to be too much of a problem last night, because there were a steady stream of players wanting to have a turn.

While people were playing, I would sit next to them and watch what they were doing, while also talking with them. I also took a bunch of notes when I saw things that needed fixing, or puzzle elements that were causing trouble, or when they said a particular thing was good or bad.

It’s super important to take notes as you watch people play. I’ve done the whole “I’m going to watch then write down my notes later” and it 100% does not work. You won’t remember stuff, you’ll lose a huge amount of feedback, and the play testing will be significantly less effective as a result.

Seriously, that’s my number one game dev tip – always have a note-book for play tests and always write down what you see as you see it.

Once I get home I enter all of these notes into a Google Doc that we maintain for play testing records. It breaks notes up into disciplines like level design, programming, art, etc so that we can allocate a team member to address it.

Then finally, we convert these notes into tasks and make a list so that we can allocate those tasks to team members to make changes to the game.

---

You can see that the second last note in the pad above says “Camera snap back is too fast”. That’s the note that I took as I saw it happening. This is referring to the way that the game zooms out while you are projecting, then returns to a regular field of view once you release the projection.

When I got home, the note I entered into the team note document was, “The camera snap back is too fast – many times players did not see where the projection was left before the FOV shifted back.”

Finally, this is converted into 2 task as follows:

• A task for the programmers – “Make camera zoom speed controls public, so that they can be adjusted to a suitable speed for play.”
• And a task for the designers – “Investigate camera zoom to find more comfortable speed for play”.

The we’ll adjust the camera zoom speed to a speed that we think is about right, and take it back out to test with people again.

And just keep doing that til we get it about right!

---

So that’s how we turn a play test into a success. Setting up properly, taking plenty of notes of what the players do, then turning those notes into actionable tasks that we can feed back into development.

It’s sort of like a conveyor belt that makes more work for us! Wait, that doesn’t sound as good as I thought it would…

So it’s been a couple of weeks since the last post. Sorry about that. This was due to 1) being very busy preparing for Open Day, then 2) being very worn out following Open Day.

I’ll talk about both of these below.

---

First of all: Open Day went really well!

  

We were set up beside the Games and Interactivity degree information booth, so there were a lot of people over the course of the day who wanted to talk about the degree. What it was like, what was required to get into it, what were the job prospects at the end, those sorts of things.

Now it’s been … a couple of years since I finished high school, so I don’t have too many memories of going to open days. It was interesting seeing the different questions being asked by kids, versus what their parents wanted to know.

There was also a pretty steady stream of people playing Level Squared. Unfortunately I was so busy talking with people about the course, that I didn’t get a lot of chances to note down what I saw from people playing.

Finally there were around half a dozen people who spoke to me saying that they had been watching the Game Awards last year and had seen us win the Student Game award, so that was pretty cool.

---

All-in-all we were on show for around six hours. We also did set up and bump out before and after, as well as talking to people for the whole day.

I’m pretty introverted, so it takes a fair bit of effort for me to be out and about and sociable for that amount of time. And the outcome of this was that I was pretty much out of commision for the rest of the week, hence no blog post (see I called this a post-mortem cos I was dead tired, geddit).

It really took me most of the next week to work out that that was the case, actually. I spent the next couple of days feeling really lethargic and lazy, but didn’t make the connection until around Thursday. Up until then I was feeling pretty down on myslef for not getting anything done and for not acting on any of the feedback that we’d received. Once I finally worked out what was going on, I rested up and began to feel better again.

Anyway, the lesson is to work within your means, kids! It’s all too easy to work yourself into the ground and get yourself sick, so make sure you look after yourself cos it’s going to make you more productive and healthy in the long run!

It has also meant that there hasn’t been a huge amount of progress on Level Squared since the Open Day.

I’ve written up notes on changes that I want to make to some of the levels, but I might save that to go into next week.

However, there was quite a bit of good feedback from the build that we had, as well as a few silly bugs that we really should have noticed but didn’t. But, yeah, that’s a much bigger post and I’ll write that up properly for next week.

---

Finally, we have some public appearances coming up in the next weeks!

1. A few of the team will be presenting a panel at Animaga this weekend. They’ll be on Stage 2 on Saturday from 1.00-1.30pm talking about our experiences as students and becoming a studio.
2. We’re going to be bringing a build along to the next IGDA meetup on Tuesday for folks to check out and try to break.

 

Level building has been a big part of the work that I have been doing lately. But that’s starting to wind down a little now and it’s time to go over everything that has been created and make sure that it actually works!

So this week I’m going to talk a little bit about Quality Assurance (QA), what it is, why it’s important, and how I go about doing it.

---

QA is the process of internally testing your game to make sure it’s ready for play testing. It is the process of playing through your own work to make sure it is doing what it should be doing. Basically, it’s the same as reading over a piece of writing before releasing it to make sure it’s saying what you mean, and that you haven’t left out any words.

Importantly, QA isn’t the same as play testing. They are two different processes, and they can’t be used in place of each other!

Play testing is putting your game in front of players and seeing how they interact with your game, and whether the systems that you have created result in your intended play. And whether that play is enjoyable.

QA is making sure that the systems that you have made work and have been implemented properly.

One thing I learned last year – if you don’t do QA properly, then you can’t do play testing properly. Because all the feedback that you will get is that the game is broken and that things don’t work. If you’d gone through you would have noticed this very easily on your own. And as a result, you don’t get any useful feedback on how the game makes players feel or if they find your systems enjoyable.

So, to summarise: QA is very important. QA is not the same as play testing.

---

What I’ve been doing this week, is playing through the levels that we have built and trying to catch and identify as many broken game elements as I can.

That second part is important too. Good QA doesn’t just identify that something is broken. It should really examine the problem, work out exactly how to replicate the problem and make sure that it is clearly documented so that whoever’s job it is to fix the issue can easily re-create the problem and work out what is causing it.

A well-documented QA report can save hours in bug-squishing time by narrowing down exactly where and when a problem occurs.

Here’s one of the issues I found last week. I noticed that in some circumstances, the player wasn’t able to complete projections properly. Instead of a proper projection completing like this:

It was failing to complete the projection, leaving a transparent copy where the projection should had been placed, like this:

Eventually I was able to narrow down the circumstances that would cause this to happen:

1. The player had progressed to the point that they had learned to undo projections
2. The player had died at least once within this level.

And from these notes the programmers were able to narrow down the cause of the issue and fix it.

This was something that wasn’t apparent while building levels, and yet would have resulted in a play test being totally wasted as players would have been unable to complete many levels. So it was very good that we found and fixed this!

---

So that’s a quick rundown on QA. It’s not as glamorous or as flashy as some design work, but it is 100% vital to making a good game.

And I can tell you that it can feel super satisfying to finally work out exactly what is causing your game to bug out at some point and pass on a really good bug report to your development team. And they will appreciate being able to quickly identify and fix a problem too! So everyone’s a winner!

Just going to do a quick post this week. Some of you may have seen during the week that I tweeted this:

Here's a tweet I sent out 1 year ago yesterday. Happy anniversary @LVLsquared You've certainly had one hell of a first year! https://t.co/pR5LaLIiJD

— Kip Brennan (@kipslife) June 22, 2018

It’s a little tough to pin down when exactly we started work on Level Squared, but it’s probably around about this time last year.

So, to celebrate, here’s a little selection of pics and highlights showing how the game has developed over time

---

First prototype:

First announcement:

We're excited to announce our redesigned game will be LEVEL SQUARED. Please follow for our progress as we get closer to PAX! #lvl2game 🤩 pic.twitter.com/7GIvKwYmKS

— LVL² (@LVLsquared) July 7, 2017

Our first #Screenshotsaturday of the new layout:

#screenshotsaturday Building levels and testing gameplay elements today. Getting ready for a public playtest next weekend! #SwinburneOpenDay pic.twitter.com/frcXurraX1

— LVL² (@LVLsquared) July 22, 2017

The initial look:

The transition to black:

Our design style for PAX last year

And how we are looking today

---

So there you have a very quick overview of how Level Squared has looked and changed over the last 12 months. We’ve put in a heck of a lot of work to get to where we are now, and we’ve had a lot of help from a lot of people as well.

Looking forward to finding out what the next 12 months brings!

This week I thought I’d go into a bit more depth on the level and mechanic design that I’ve been doing over the last few weeks. This will be exploring in-depth the design ideas behind one of the new levels for Level Squared, the problems I’ve been looking to solve with the design, and the issues that I’ve been designing around before sending it off for play testing.

---

The level I’m going to be looking into will be Level 4.2 of the new progression. (You might remember from last week that there are five sub-levels within each larger area, so this is the second level within area 4).

This level is the second level where the player has gained the ability to cast projections themselves. They have been run through the mechanics of projecting, and had a chance to cast a few projections themselves. The idea behind this level is to give the player a lot more projections to play around with, the ability to project the same objects a number of times, and to get to know the limitations of projecting a little better.

But at the same time, they have not yet learned the ability to undo projections. This is a bit of a barrier. It means that I can’t make any of the projections vital or too precise. There’s a good chance that the player will project a block up against a wall where they won’t be able to interact with the block any further. If that block is required to proceed, then the level is blocked and the player would need to restart. I need to avoid that at all costs.

So those are our parameters. And here’s a view of the entire level:

The player will spawn at the bottom left, and exit through the green square at the top right.

You can see that the first thing that the player will encounter are the three yellow blocks that are blocking any further progress. The player has already encountered these types of blocks in previous levels, so knows that they are projectable. From the central platform, every projection angle will result in a successful projection. However, it is possible for the player to move to an extent that the projection is not possible. In this case the projection lines will turn red. As shown below:

(Eventually the camera will zoom out to show where the projected block will land. It’s just not up and running yet.)

Once the player jumps up to the next level, we can see that it is possible for the player to block their way forward with one of their projections. However, there is plenty of clear space beyond to ensure that the player can project again to clear the block out of the way. In addition, the player can climb to either the right or left side of the level, so even if they block one side and don’t think to project the block away, they can still climb on the opposite side.

And you can see that this is repeated the whole way up the level. The player always has multiple paths forward.

Another consideration is the use of the blocks as stairs.

The player can cast the yellow blocks into a set of stairs that they can use to leap up to the next area:

However, I have made sure that all of the jumps within the level are able to be completed by the character without requiring that the blocks be used as steps. If the player projects the blocks too far away, or into the wrong position, they will definitely still be able to progress. And if they cast the blocks into stairs, they can use those to jump up and feel very clever for solving the stair puzzle!

Finally here’s a video of me playing through the level in a pretty inefficient manner, making sure I can’t break or block anything and still make it all the way through – enjoy!