kipslife.com

Following on from last week’s Level Building blog, this week I’m going to go a bit further into specific puzzle design and introducing new mechanics to the player.

A poor joke.

---

One of the new mechanics that we are seeking to introduce to the player is passive projection. In this, we have a block within the world that is able to cast a projection, and that is operated by the player stepping onto a button.

It looks like this:

 

We’ve based this idea of the way that players are introduced to portals in Portal. The gun is placed in a fixed position and sends out portals to set locations, allowing the player to understand what is going on, without giving them too much power too early.

So what I’m trying to teach the player in this particular puzzle is that standing on a button will cause the projector to fire and create a projection of the yellow square. And that the projection will be completed when the player steps off the button.

The first version looked like this:

The button is located behind the projector, and is directly in front of the player upon them spawning into the scene. However, in this setup, the projection of the yellow block ended up being cast outside the right hand side of the screen, and this meant that the player wouldn’t know what their action was doing. The fact that the yellow block is moved to the new location is one of the core principals of projection, and it is important that the player realises that this is what is happening.

So I moved the button to be between the projector and the block. But this caused problems at first, because the player could get caught in the projection:

So I adjusted the level so that the button was lowered further below the projector until the player was out of the line of effect.

No the player can see that the button has to be pressed to continue (having already learned that in earlier levels), and when they step onto the button, the projector fires, casting the yellow block to a new location. The player is in a position to see where the new yellow block is placed. And the player learns what these blue blocks do.

---

That’s a very simple run through of introducing that mechanic to the player. I’m building levels in sequence at the moment that will gradually introduce new mechanics to the player, over a five level series as follows:

1. Introduce a new mechanic in a simple version
2. vary the operation of that mechanic so that the player learns how it works.
3. Introduce a secondary mechanic.
4. Show a couple of puzzles with both mechanics combined
5. Finally, a larger challenge level where the new mechanics are used in different ways that require the player to think a bit harder about how to progress.

And then I just have to do that around six to ten times for all of the various mechanics and puzzles that we want to use. and by that point, we should have a pretty reasonable game length!

Hey folks. Development of Level Squared continues apace! The pipeline has been in full force and we’ve been pumping out new levels at a good rate. We’re in that really good place where we’re making some good progress, we’re making some good content, and it looks good and works well, and we haven’t shown it to anyone yet, so we can still operate under the assumption that it’s good!

After writing last week’s post, I felt like going a bit more in depth on the specific way I go about designing levels and then building them in Unity, to give a bit more insight into that part of the process.

First thing I start with is an overall purpose for the level. At the moment I’m still working on levels from near the start of the game, so usually the idea is to either introduce a new mechanic, or iterate on that mechanic to give the player an idea of what it can do.

So – here’s the design document entry for a level I was working on last night:

The purpose of this level is to introduce the player to the concept of projecting physics blocks – blocks that will react to gravity and fall to the ground rather than remain wherever they are projected to. It is also using Passive Projectors – blocks that can project other blocks and are operated by the player jumping onto a button. These were introduced one level earlier, so are still quite new to the player.

Usually, the first thing I do is sketch up an approximation of what I think will work. This doesn’t always end up looking like the final level, but it helps to get an idea of my starting point, and to get an idea of what will fit within the level, and what the flow of interactions will end up looking like. Now, I didn’t do that in this case, but as a general guide for how useful those sketches are here’s one for a later level:

It’s fine, I totally know what all this means…

The reason I didn’t do a sketch in this case what because I had already made a prototype version of this level earlier, so I already had an idea of the mechanics that I wanted to use. I’d made this a few weeks earlier before we had everything set up and ready to go with the level building pipeline, so it looks a bit different to the current levels.

This prototype doesn’t use the basic layout that our levels are built on, nor does it make use of many of the prefabs that we are now using to build levels. However, it was useful for me to play around with the mechanics and get an idea of how they worked and what was required to get them to work properly. For example, I learned that you need to raise physics blocks into the air when projecting them, in order to drop them onto a button. If everything is laid out in a line, then the blocks are projected inside the buttons and everything fails.

Then once I have these basic concepts worked out in my head/on paper/wherever I jump into Unity and build out the level, using a method I call ‘trial and error’. And I recorded myself building a level last night, which you can watch below (I sped it up – a lot, I am nowhere near this fast don’t worry).

Things you may or may not notice in this video:

• I forgot to turn the colliders on in the first playthrough – I do this Every. Single. Level.
• Buttons and moving walls don’t really work properly in this video – these will get fixed up in the programming pass later on.
• I do a lot of drawing in blocks then erasing them without testing. I’m kinda just freestyling this whole design, so I get halfway through trying something out then change my mind. There’s also things I already know won’t work. For example, the player needs a certain amount of head room for jumps to work. I know how big this is, so if I notice I’ve blocked it, I go back and try again.
• One thing I’m trying to balance is having enough open space within the level with having enough black space for the art design. This is a tough thing to balance and I often second guess what’s right or wrong.

So there you have it, that’s the method that I use to create our first draft levels. I’m trying to get around five of these done each week so that we have a big ol’ bunch of them to test in a few weeks.

Next week I’ll go into a bit more detail on how I think about introducing mechanics, and how I try to guide the player through what needs doing and what happens as a result.

Well, first of all – it’s been a couple of weeks since I last posted. Sorry about that. I’ve been working on assignments for uni and it all got a bit too busy to manage to squeeze any sort of decent blog post.

So to make up for that, I’m finally going to go over the level design pipeline that we are using for the new development phase of Level Squared.

---

We’re in the early stages of developing new levels at the moment, and our primary aim is to build our prototype up into a full length game.

The prototype that we have is a very simple introduction to our mechanics, introducing them one after another, then finally presenting one large level at the end where you get to use everything together.

So what we are aiming to do is to spread out those mechanic introductions a little and make sure that players are completely comfortable with each of them before introducing a new mechanic. Then after a couple of levels of the new mechanic, we will have a level that combines it with an earlier mechanic or two (depending on how many there have been obviously), then finally, we close out that phase with what I’m calling a ‘challenge level’ – basically a larger level that requires the player to pass a few more difficult challenges using the abilities that they have at that point.

Some of the games that I’m drawing on for level building inspiration are:

• The Donkey Kong Country series, which are real good at iterating on a mechanic and doing interesting things with their levels.
• Portal and Portal 2, which again, are great at introducing a mechanic and getting the player comfortable with it before making them stretch to carry on.
• and LIMBO, particularly the secret dark level, which does a fantastic job of getting the player to learn the patterns of the hazards to the point that they can be avoided by sound alone.

Now, I’m not going to claim that there aren’t better games out there. These are ones that I have played a lot though, and that I feel are a good fit for the sort of challenge we are aiming for for Level Squared.

So let’s start with the first set of levels. These levels aim to introduce the player to basic movement and jumping, as well as how death works.

To start off, I’ve drawn up a table of the concepts and design guidelines for each level:

This is obviously pretty basic stuff, and is just intended as a jumping off point.

As you can see, I’m starting off with the existing version of Level 1 that existed within the prototype (no need to duplicate already completed work!).

Level 1.2 I’ve made as a vertical version of Level 1. Basically the same idea, just getting the player to climb up instead of progressing to the right.

Here’s the early build in Unity:

This is still pretty bare bones at this stage. It’s mainly a matter of getting the level parts into the correct positions. This step involves a lot of placing blocks within the level, going in to play through, then moving blocks by small amounts to fix all the errors that I made on the previous pass.

Important things that need to be right at this stage include:

• The player needs to be able to make all jumps with a single jump. They will not have access to a double jump at this stage.
• Jumps need to be challenging enough to interest the player, but not so difficult that an unskilled player cannot make them. This level is an introduction, we need to keep in mind that players are still learning the game at this point.
• The level should start easy, but get more challenging as the player progresses. You can see this as the platforms that the player will be aiming for get smaller and smaller as they climb higher.
• There isn’t really any loss condition at this point. We haven’t introduced death or anything deadly. So even if the player does fail to make a jump and falls a great height – they learn that this won’t kill them.

Then, once I’ve built the level to the point that I am happy with, I send it across to our artist Mark. Mark then paints over the basic design that I have created and makes it look all nice.

Like this:

Something we have already identified as a problem is that this art style doesn’t present well on single lines of blocks. It relies on having a gap between blocks to apply the bright white internal areas. And there are a few places within the drafted levels that I have used single blocks, or lines of single blocks, to make more challenging jumps. So we will likely have to look into that in the coming weeks.

And finally, Mark passes the newly arted level across to Dane in our programming team, who does a pass over the level to fix all of the programm-y bits that I broke or failed to set up properly when I was putting the level together.

And then … we’ll be ready to start doing some play testing. At which point, we’ll probably have to start all over again.

One thing that I’m worried about with these new levels and the new overall game progression plan, is that it’s going to potentially be a long time before the player gets access to projection – and that’s kind of the main point of our game.

But we’re not going to know if the play length is right until we have enough built that we can get this in front of people to see what they think.

Our plan is to do a repeat of last year. We built the entire first version of Level Squared of the semester break of uni. And we’re aiming to get a big chunk of this version done over the same period of time.

---

So we’ll see how we go with all of that. It’s a fair chunk of work laying ahead of us, but we’ve been pretty slow to get back into action this year, so I’m hoping that this push is what we need to get Level Squared built out into the full game that we believe it can be.

Also, this has somehow evolved into a 1000+ word blog post, so hopefully that goes some way towards making up for no post for the last two weeks!

Ok, so first of all, I know I said I was going to do a ‘Level Design 101’ type thing last week, but i’m not going to do that now.

But that is still coming!

However, in the last week, a new task came up, so I was working on that instead.

I’ve spoken about how our programmers have been reworking all of our code base to make it neater and cleaner and run better, well that’s basically done now. Or at least, it’s at the point where we need some sort of game to play to see how it is working and what is needed to fix it up.

And to do that, we need some levels. Of course, we have a whole bunch of levels that we’ve built and tested and refined that made up the demo that we completed last year. But due to all of the changes that have been made, those levels won’t work within the new code base, so we need to think about how we’re going to translate them into the new setup.

And that’s what I’ve been doing.

There were a couple of potential ways to do this. Unity has the ability to package up a bunch of assets into a pack and export/import them into a game project. I tried this first and ended up with what you see here:

Now you might not be able to tell, but there are a couple of things missing from that picture. This is what it previously looked like…

So that option appears to be off the table. Or at least, to be so much additional work to be not worth it.

Second option was: rebuild the whole level from scratch. This sounds like a pain in the arse, but it isn’t quite that bad. I already had a blueprint of exactly how the level would work, and all I had to do was replicate it. In fact, I managed to get most of the architecture done in about an hour.

Here’s a quick look at the build process:

Baring in mind this is our simplest level. So others take a bit longer, but this was still less time than I had feared it would take.

And after I was done, one of the other team members took over and replaced those level pieces with our new tile mapping. This builds the level out of a single piece, rather than dropping blocks into place as we have been doing. Once they were done it looked like this:

And now it’s in a position to test out all our new code. We’ll still need a couple more levels so that we can test everything, as there are a lot of interactions that aren’t in this level, and we also want to try out our level transitions and persistent game elements that should last between levels. Clearly there’s still a bit of work to do making the levels look pretty and fitting in all the special effects, but we’re at least at the point where we can test the game play again.

If all goes according to plan (stop laughing) we should have a rebuild of our original demo in the next couple of weeks. And from there we can start building in new levels and restart testing everything!

So you might have seen this week, but I decided to have a crack at some level designing prototyping earlier this week. And hooooo boy am I a bit rusty! Turns out you kinda need to keep working at this kind of thing to stay in practice. And I have 100% not been staying in practice.

To be honest, it’s probably been a good seven or eight months since I last did any proper, in-engine game design. So it’s been a bit of a slow road back to getting anywhere near anything pretty.

For anyone who missed it (follow me on Twitter! @kipslife) here’s the screenshot I posted:

Turns out it’s pretty handy that our primary aesthetic is based around squares, cos my standard design seems to be pretty boxy anyway…

I tend to start with a simple set of rooms and work out how the player will move from one to the next. In this case, the player needs to stand on the yellow button in the centre of the screen. The passive projector at the bottom of the screen (the blue box) will then project them up and into the second room at the top of the screen. From that point the player can choose to go left or right to proceed.

Eventually they will have to cover both sides, but I’m trying to set it up so that it doesn’t matter which they choose to do first.

This is still quite bare bones at the moment, so I’ll try to finish it up over the next week and do a bit more of a deep dive into the design and build process next week (or over the next couple of weeks).

---

In other news, I’ve been working away at uni stuff as well over the past few weeks, and now I’m gonna give you the chance to see the last essay I did! (Try to keep the cheering to a dull roar please).

I had an assignment to do a self-reflection, examining a video game and my relationship to that game, using some psycho-dynamic theories. And the essay was to be presented as a video essay.

This assignment was a bunch of fun to do (which makes it a change from a standard essay) and I was pushed to really probe into how I felt about the game I examined and why.

I chose to examine Night in the Woods, a game I played earlier this year and really enjoyed.

This was quite a bit of work, so I doubt I’m going to be pumping these out (I have plenty on my plate already thanks) but if people like it I might have a go at doing a couple more of these at some point.

Anyway, that’s all from me, check out the video below to see why I liked Night in the Woods…

 

Over the last week I was in Wellington, New Zealand to attend the Play by Play games festival.

Play by Play runs over a week, with a series of events and workshops, many aimed at those looking to enter the games industry and school aged persons, culminating in a day long conference and awards night on the Saturday.

LVL² was selected to be a part of a games exhibition in the Wellington Museum, and was also nominated for an award – the “That Game From Across the Ditch” Award which was open to games from Australia (all other categories were for New Zealand developed games only).

I had heard some great things about last year’s Play by Play from those who attended, so I was already keen to attend this year. And when LVL² was nominated for the award, that sealed the deal for me.

I was in Wellington for five days, and met up with a bunch of people, both from the New Zealand game development community and from Australia who had travelled over for the festival. I spent a lot of time wandering around the city which is of such a size that it’s really easy to pretty much just walk everywhere in the central city. Someone described Wellington as a city made up of just the laneways of Melbourne, which was pretty apt I thought. Almost every bar had different beers on tap to try and everyone there was really friendly and welcoming. I had a great time.

The conference on Saturday was a single track series of talks of 15 to 30 minutes and covered a wide range of topics including text formats, consent in games, nostalgia and studio culture.

I heard a little bit of criticism that the talks were a bit ‘light on’ in terms of technical detail and evidence. But I think that the conference was more aimed at those beginning in the game development industry rather than those who had been working in the industry for a long time. And seeing as that describes me quite well, I quite enjoyed most of the talks. But I can understand that criticism as well.

And, because there were so many game devs there, a lot of the conversations that I had were about game development (surprise!). I noticed a change from the last conference I was at. Previously, when talking about LVL² it was treated like a student project. But at Play by Play we talked like fellow developers, with people asking about development plans, what our release plans were, what we planned to do afterwards, and how our studio was run.

So that was a combination of “this is really cool!” and “Oh god I hope they don’t find out I have no idea what I’m doing!”. If anyone did they didn’t say anything though, so that was nice.

Then, at the awards ceremony on Saturday night LVL² did not win an award. Instead we lost to Florence by Mountains Studio. Which is fair enough really. It’s an excellent game, developed by very talented people and thoroughly deserved the award.

---

Anyway, I had a great time at Play by Play and would definitely recommend attending in the future!

Well It’s official!

Glitch Crab Studios Pty Ltd is incorporated and registered. We’ve officially formed a company to develop Level Squared into a full release.

The last couple of months have involved a pretty steep learning curve as we worked out how to go about incorporating, what it involved, and what it meant for each of us in the team.

There was a fair bit of discussion required to work out who was going to act as a Director for the company, and be held responsible for day-to-day decision making and record keeping and so on. Then we also had to decide who wanted to be a shareholder in the company – effectively who wanted to be the owners of the company – and who was happy to not join the company, and to just be part of the team for the development of Level Squared.

On the bright side, no-one was totally opposed to forming a company or continuing to work on Level Squared, everyone was keen to keep going with development.

In the end we have probably ended up with too many of us joining the company, and that’s going to make it difficult for us to be sustainable over the long term.

But that’s something that we are going to have to address as it crops up. I didn’t feel comfortable making a company if it involved jettisoning the people who had worked on Level Squared up to this point. I guess that probably makes me a not too good business guy. And I think I’m OK with that.

So now it’s done. We’re small business owners, we’ve signed up for Liberal Party memberships and started lobbying for tax cuts to help the economy is some unclear but still very important way…

ahem.

So now we’ll be moving forward with the development, in a bit more of an established position, and a bit more secure in our ability to engage with other companies and funding bodies on a more equal footing. And also start to transition away from referring to ourselves as student developers and instead as game developers.

---

 

On a more personal note, Given the establishment of our company and my pending trip to New Zealand for the Play be Play conference, I thought it was time to update the ol’ business cards.

Got a bit more info to put on them nowadays, and a bit of a more official sounding title too.

I’ll have these with me for Play by Play next week (holy shit next week!) and I’ll be handing them out pretty liberally!

Oh no! I was busy working on level design stuff and forgot that I had to write this post.

Sorry folks, very bad on my behalf.

So, as John Oliver says, just time for a quick recap of the week…

We’ve been working on new test levels to try out the new mechanics that I spoke about last week. I was really hoping that we would have some new things to show off at Play by Play in a couple of weeks, but it doesn’t look like that’s going to be the case. We haven’t got anything built to the point that we’re happy showing it off yet. So we’ll be showing the same build that we used for PAX Australia. This is a bit disappointing, as we were hoping to have something new, but a lot of the work that we have been doing is on behind the scenes stuff, that doesn’t lend itself to easy display.

We had a quick team meeting this afternoon (well, 6 out of 8 of us did) and we discussed some of the problems that we are having with keeping working in situations where we aren’t able to meet up. So we’re going to trial online meetings and task allocations in an effort to communicate better and stay on target for development. Hopefully this will help us to keep development moving as we transition into a post-university phase.

I’ve booked accommodation and flights to New Zealand and will be in Wellington from Thursday 19th to Monday 23rd April. So if you’re going to be there, let’s try to meet up!

There wasn’t any uni over the Easter break, so I decided to take it easy and learn how to use Yarn Spinner (a narrative system for games) cos I don’t have enough to do already. So I’m making a small walking sim style game based on this very creepy SCP Foundation entry – SCP-087.

 

See you at the bottom of the stairs folks…

For the last few years I’ve challenged myself to read a wider variety of authors. Essentially I’m trying to read more books by non-white, non-male, non-English-language and non-straight authors.

And as part of that, I’ve been posting a list each Easter on Facebook of what I read that year, both as a bit of a brag, and as a conversation starter.

But this I have this blog just sitting here waiting for content, so I figured I’d put the list here and be able to have a bit more room to discuss some of the books.

So, without further ado, here’s the list (in Alphabetical order, by Author surname):

No	Author	Title
1	Naomi Alderman	The Power
2	Michael Chabon	The amazing adventures of Kavalier and Clay
3	Wu Cheng’en	The Monkey King’s amazing adventures
4	Claire G Coleman	Terra Nullius
5	Timothy Conigrave	Holding the Man
6	Jennifer Egan	Manhattan Beach
7	Gustave Flaubert	Madame Bovary
8	Mohsin Hamid	Exit West
9	James Joyce	Ulysses
10	Eka Kurniawan	Man TIger
11	Min Jin Lee	Pachinko
12	Jon McGregor	Reservoir 13
13	China Mieville	Kraken
14	Haruki Murikami	The Wind-up bird Chrnicle
15	Nnedi Okorafor	Who Fears Death
16	Ruth Park	The harp in the south
17	Laline Paull	The Bees
18	Sarah Perry	The Essex Serpent
19	George Saunders	Lincoln in the Bardo
20	Lutz Seiler	Kruso
21	Ernest Shackelton	South
22	Vivek Shanbhag	Ghachar Ghochar
23	Ali Smith	Autumn
24	Kim Stanley Robinson	Shaman
25	Jesmyn Ward	Sing, Unburied, Sing
26	Josephine Wilson	Extinctions

Probably my favourite read of last year was Terra Nullius by Claire G Coleman – because half way through there is a very slight change in context, and the entire book up to that point changes. It was really well done.

Exit West was a great escape story about all of the other times during an escape when you aren’t travelling. Extinctions was an interesting examination of aging and reflection. Holding the Man left me crying in the pub as I finished the last few chapters.

But really, there weren’t any books there that I wouldn’t recommend checking out.

There’s a pretty good mix in there of new books and older “classics”. Some award winners, some obscure ones. Translated texts and books form a pretty wide range of places.

Though, on that last one, I’m going to try to read a few more books from the global south this year. I’ve had books from a wider range of places in past lists, and I dropped off a bit there this year. There were no books from African or South American authors, for example.

Anyway, have a look through and let me know if there is anything there that you’d like to know more about, or suggest anything that you think I should try to get to in the coming year!

Hit me up on Twitter (@kipslife)!

You might have seen a gif that we shared from our twitter account yesterday showing a new mechanic we’ve been working on.

In case you didn’t…

What have here is a mechanic we’re calling Passive Projection.

The idea is a twist on the projection mechanic that we already have in the game. Instead of the player casting the projection from themself, the projection is cast from a stationary block, and can be used to project the player to a different location.

This is essentially using the mechanics that we already have, but twisting them just slightly to open up some new ways of making puzzles.

And this actually gives us two new mechanics. We can create a block that can project other blocks when the player presses a button, as well as a block that projects the player when they are in a particular position. Players can use this to get past solid walls for example.

It’s pretty cool that we are still finding new ways to use the mechanics that we have, and build them out into more complex systems. This is something that we are going to have to do if we want Level Squared to be enjoyable over more than a twenty minute play session.

We have a couple more mechanics that we are investigating at the moment, so hopefully we’ll be able to keep this drip feed of new stuff going!

---

And in some super cool news: We’ve made the list of finalists for the Play by Play Festival!

Play by Play is held in Wellington in New Zealand. We are a finalist for the “That Game From Across The Ditch” Award, which is open to games made in Australia.

The other finalists are Florence by Mountains, Rumu by Robot House and The Gardens Between by The Voxel Agents.

This is pretty daunting company to be in for our team, so we’re simultaneously excited and a bit overwhelmed.

I’m going to be heading over the New Zealand in April for the conference and the award ceremony, so if you’re there, keep an eye out for me!