Category: DevBlog

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?

The last week has been all about pulling everything together and getting our game ready to show at the Swinburne Open Day, which is the coming Sunday.

This is going to be our first big public show of LVL² so this is all quite exciting. And also a little scary!

We have three levels ready to go, and all of our mechanics set up and ready to play. We still need to do a whole lot of polish cos everything is in a very raw state at the moment.

Due to the fact that we have scrapped our previous game and started over from scratch over the winter break, we are essentially 12 or so weeks of development behind the other groups in the class. I think we’ve put in a pretty good effort to get ourselves back up to speed, but we are going to be showing a game that is significantly less polished and tested than our colleagues.

I’m going to be doing my best to keep this in mind as people play our game, but we’ll have to see how I go with that.

But before we get to that, we need to pull everything together.

Really all we still have to do is connect all of our levels together, test them, get some new audio and sound effects, make sure all of our art and assets are in place, build and implement a new UI system, get all of the menus and sub-menus plugged together and test everything as many times as possible.

Easy right?

Ahem.

The thing we’re going to have to concentrate on this week is making sure we know exactly what jobs need doing and exactly who is going to be doing them. On reflection this was a real problem last semester. A lot of times we would meet up as a group and find that various people had not done their tasks because they were waiting on somebody else to do something else, or they thought that it was someone else’s tasks, or any other number of excuses.

I’m also pretty concerned that a few people appeared to have just tapped out altogether. Now, whether this is a result of it being mid-semester break and them taking that 100% seriously, or whether it’s a case that they are just done with this project I don’t really know at this stage. Regardless, we pretty much have to move forward under the assumption that they are no longer contributing to the project and it’s on the rest of us to get everything done.

---

In other more cheery news (this under the line bit is quickly becoming my favourite) I have officially published a game!

It’s a narrative adventure that I made in Twine last year.

You can play it in your browser by going here: https://kipslife.itch.io/babel

It’s called Babel and is about an ill-fated archaeological party searching for the site of the Tower of Babel.

I also created my first ever Twitter bot. @Towns_of_Aus is a bot that tweets out facts about little known Australian towns twice a day.

It’s probably still a little repetitive at the moment, but I have some ideas about how to make it a bit better. It kinda reads a little bit like a Dwarf Fortress summary at the moment, so I’m gonna have to do some work to make it sound a bit more natural.

I made it using cheapbotsdonequick.com and it was really easy to set up and get running. I would recommend giving it a try!

OK, no more wallowing in self reflection, this week I’m actually going to talk about making some stuff!

---

This week I’ve been working on our main menu.

I posted a pick of our logo last week, but if you missed that, here it is again!

I’m using this as the basis of the games main menu, with each of the letters being a button. The first “L” will start the game, the “V” will display the game controls, the second “L” will access the credits, and the “2” will quit.

Our artist made all the parts into separate assets so that I was able to build the landing screen in Unity so that it looks exactly the same as the logo.

Then I set up each button to load the respective menu page, or to load the game or exit, or whatever. It did the job that it was supposed to, but it wasn’t particularly exciting or pretty.

One of the key concepts of our game is “Levels within Levels”. Within each level, the player can enlarge certain objects and enter them, to find entire new levels within. Basically, rather than finishing a level and entering the next, the next level is within the level currently.

So to step into this mindset, I made an animation to draw the camera into each button as it is pressed – like so:

That made the buttons feel a little more dynamic, but the info on screen was still a little static.

Here is the instructions page as an example:

This page would just appear once you entered into the “V” in the logo. This time, I decided to animate all of the icons jumping up from the bottom of the page and settling into place in a kind of cascading effect.

It ended up looking like this:

Which looks pretty nice I think.

Obviously these are all works in progress, and are likely to change before we are done, but it’s a pretty simple addition and adds a bit of pop to the game when we have people come and play and show it off.

Clearly, we still need to make the actual game. That bit is pretty important.

But to close – here is a GIF of everything added together:

Disclosure: I am not a UI designer and haven’t had any specific UI training. This is just a record of my bumbling through the process and learning to make something that looks good. Feel free to take whatever lessons that you want from this, or to quietly scoff at my amateurism.

---

Whew – feels nice to actually be talking about making something.

So, if anyone has looked, I had a bit of a boo-boo over the weekend, and the last post has been lost. (If anyone is downloading and saving posts as they read them it might be recoverable? That’s probably not happening…)

Anyway, I now have an SSL certificate installed and have set up some security measures as well as automated backups.

Kinda learning/making this blogging thing up as I go, so it might be a rocky trip but we’ll end up somewhere…

Hey, so I did some messing around with the site over the weekend and managed to lose last week’s post completely.

BUT: the site now has a proper security certificate so I’m gonna call that a win.

I can’t really remember what I wrote about, but I do recall that there were links to the new website and twitter for our group’s new game, so here are those links again if you wanted them:

LVL²

Twitter: twitter.com/LVLsquared

Web: lvl2game.com

 

The last week was rough.

(And I know this is a bit of a theme of late, but this one was particularly rough).

We’ve been plugging away trying to come up with a new game idea, following the failure of our previous effort. There have been some interesting mechanics floated, and there have been some good efforts from some group members to find a new path forward, and that has been great.

However, during our time at The Arcade this week we spoke with Ken Wong, who has been tutoring us this semester.

Ken was interested in the mechanic that we had, but pretty much tore all of our game ideas apart.

And this really knocked me for six.

Hearing Ken say that we were again heading down a road to a rubbish game just left me questioning everything that we were doing. I was basically unable to do anything productive for the rest of the day, because I was just left unsure that anything that we were doing was any good.

And that’s pretty much where I have been all week.

I’m not sure that the new idea that we have is super solid either, but we don’t have any time to work through any other ideas. So we just have to hit this one as hard as we can and try to learn from this whole experience I suppose.

---

Now that that cheery reflection is done – what’s coming up for the next week?

We need to get our web presence up and running again. This is going to need a whole new website, as well as twitter and facebook accounts.

We need to really bed down our new design documentation, and work out precisely what is required in order to have a proper game up and running for open day at the end of July. This will include artwork, mechanics, levels built and tested, new UI, menus, the lot.

Time to get cracking.

I’m going to talk a little bit about what we are focusing on this week, as well as some things that I think our team needs to think about over the longer term. I guess these could also be looked at as things that need to be considered when forming a team, but that we have not done up to this point.

---

This week: We are continuing our mission to break everything into component pieces and try to find out where our fun elements are. Early contenders are moving various pieces of the world around to solve puzzles and allow progress.

Up to now we have been building a fairly basic platformer in which the player moves through the world and avoids bad things and so on. Think Mario Bros, Donkey Kong Country and those sorts of games.

But with our new thinking, we end up with a game that has more in common with Monument Valley or Echochrome in which all of the elements of the world are there to see, and your mission as a player is to manipulate all of these elements into the correct positions to allow the character to proceed.

This style of game is potentially more at home on a mobile device than a PC, and that will be something that we will need to discuss if we end up following this path.

All of this is still up in the air of course, this is just my latest thinking.

---

The other thing I wanted to discuss this week was defining group roles and using that as a way to convey ownership.

So far we haven’t had much of a structure within our group. As I have discussed previously, I took on a decision making role, but that was the only real defined(-ish) role that we had.

This coming semester, I’m keen for everyone within the team to have a role and title that they can take on and clearly state that that is the part of the project that they are responsible for.

There are two reasons for this:

1. I think it will help to have each group member to have ownership of a particular element of game production.
2. It will take some of the load off me!

OK, that second point is a bit of a laugh. But, I think we will be better off if there is more than one person making all of the calls in development, and having a go-to person for different elements will help, I hope.

---

Finally: back on schedule for this week! Not a whole lot of actual game stuff to discuss, sorry, I seem to be focused more on team dynamics at the moment. I’m going to try to have some proper game news for next week.

I see that there are people looking over these, which is cool. If you have any feedback, disagreements or just want to make fun of me for writing a development blog, feel free to hit me up on twitter @kipslife.

First of all – an apology. Clearly I wasn’t able to get a post done at the start of the week. I was thrown off by the long weekend, and I’m still trying to get a proper rhythm going with these things…

---

That said, our game alpha has been submitted, and Uni doesn’t go back until early August, so there’s nothing really going on now, right?

Well, not so much.

It would be fair to say that we are not 100% happy with the game that we have built to date. While there are elements that work well, the game isn’t really … fun.

Which is not ideal.

So we are going to use the first few weeks of the break to really tear the whole thing apart and try to work out what we can do with it.

A problem that we had last semester was that we never had a lot of time to play around with our mechanics. We took a long time to get them up and running, and as a result pretty much had to build the first idea that we had, without much iteration.

Here is a little example of the alpha that we submitted:

You play as a young girl who can shift into a shadow and then interact with shadows as if they were solid. she can also change into various animal’s shadows.

Our basic problem was that we over scoped. *Cue no-one in the games industry being surprised at all*

And the result of this was that we never really got anything working particularly well.

So we’re using the break to right back to first principles.

We had a discussion with our tutor yesterday about the feedback that he had, and we realised that we really needed to pull all of the guff out and try to find the fun mechanics, then rebuild around that.

So out go the girl, the animals shadows, the shifting.

Now our game looks like this:

And the next few weeks will be rebuilding and rapid iteration.

Let’s see how that goes…

 

As you might have guessed from the (totally original and almost certainly never used before) wordplay in the title – this week we did some play testing of our game.

Last week we’d had a pretty rocky play test with our class. What we learned from that was that our game was a long way off being properly ready to test. Movement was janky, levels hadn’t really been tested, and a lot of the ‘juice’ was missing.

To add to the problems. we didn’t really manage to set up very well, or run through our game properly before getting anyone to sit down and play. As a result, sound wasn’t set up properly, there were a number of bugs that we didn’t know about, and basic things like controls were different to what we had expected.

So that went about as well as we expected.

Following that, the rest of the week was a pretty hard slog by a few of us, to get into a position that we were actually happy to show to our peers.

Credit to two of our programmers, who put in a huge effort to implement an entire new movement system, and sort out a whole bunch of bugs, and our level designer, who built three serviceable levels without being able to play through them.

The reason for all this extra effort was the planned play test for Tuesday of this week. We held a play test session at The Arcade (http://thearcade.melbourne/) – a collaborative workspace for indie game developers, and invited the resident developers to check out our game and give feedback.

I took some time off work to go into the Arcade early and run some levels before the play test. There were a few little changes to make to get everything in order, and I wanted to make sure we had our sounds and controls set up properly. (I then promptly changed computers without pushing my changes to the repo and lost them all, but you can’t win them all…).

Anyway – in the end it all went pretty well! we had three levels that could be played through from start to finish, and nothing was stupidly broken. A real improvement over the previous week.

We got some really useful feedback from the developers who played through the game, and they all seemed to not hate it, which is good, right?

Since then, we’ve been going through the feedback received, and getting everything ready for our final submission on Friday.

We had a team meeting on Wednesday and talked over everything. There had been some negativity following the previous test, so we took some time to highlight some wins that we had, just to make sure that we acknowledge good work and keep people feeling positive.

I think we are in a position to submit a reasonable alpha version of FourShadow at the end of next week. I don’t know that I think it is the greatest game ever created, but I do think we have some interesting mechanics that we can turn into an interesting game with a bit more effort.

As Andy (our tutor) said this week: Semester one – make the game. Semester two – make it good.

Bring on semester two…