Testing Despondency

Created with Sketch.

Testing Despondency

I’ve heard that to be a good game designer, you have to be able to look at work that was done and then throw it all out. Still, it doesn’t make it feel any better when you actually have to do it. The images listed at the right (—>) are all pieces that I built with the intention of teaching the player how to do things. Yesterday I even began to do some scripting using a little scriplet of code that I had written previously. It was all going well. The levels – or so I thought – were well put together and they use new abilities one at a time to help the player come to grips with the abilities and move on. The screens were designed to do just that and, I thought, were doing just that.
– That was how it was supposed to work anyway. I let a tester look at it and give it a play. This tester of course being my lovely wife Jessie (who I’ll put in the credits now). She knows how to play games reasonably well, and I felt that she would be a good case for the opening tutorial styled level. So she goes plays for a little bit, and she does 2 things I wasn’t expecting.
First of all, she messes around with the controls and manages to figure out the Dash earlier than expected. That was nice I found, since she never quite got a handle on the Double Jump as she never got that far. Since she was using moves the levels weren’t designed for, she of course did them in ways that I wholly unanticipated. So that was really good I think. It was some of that emergent gameplay that I find so nice. I mean, I figure out a level, and plot out how to finish it, but other people clearly find other ways to do it, that work just as well. That’s really nice and great.
The second is that she managed to break the game on no more than 2 separate occasions. I mean, she found bugs that I hadn’t run into, since she did the levels in ways that I didn’t think you could do them. But, I suppose that’s a good thing.

-So back on the first point again. I realized early on, that the players would find out how to use the different moves if I do something about them or not. I mean, I could lock the moves down until you get to that tutorial, but that would piss people off I think. What I need to do, is introduce them earlier with a full tutorial, so the player knows what they are and what to do with them. This of course means that I throw out the levels and restart them. This is what I am doing now. I suppose it’s for the best, as I went in all cavalier thinking that I was the God of Level Design (chilli) incarnate and my first levels in my first project would be a gift from god. In the long run, I think the new levels will be better and the game will be better for it.
Of course, I’m not totally throwing them all out. Some of the designs are pretty decent overall and work well. But they tend to be in the wrong orders and I want to cover things in a certain – new order. The Old Tutorial Order was:
Jump(climb), Fight, Double Jump, Dash

The New Order needs to be:
All of the movement stuff – Jump(Climb), Double Jump, Dash, Fight.

Putting the Fighting at the end allows me to really focus on that bit first. Since the Fighting is an important bit in the game. After all, the levels are completed by Fighting (well, except for one that I have plotted) a boss. I even figured out in the Script the full Tutorial for the Fighting. So in terms of the order, I need to put that in a spot where I can really bring it forward. The movement needs to come first, and the player needs to be able to experiment with all of the movement at once. Then they need to learn to fight. I mean, for real. Otherwise every guard will be a nuisance and they’ll have nightmares about the Knights. I really want the player to be able to fight and be challenged, but I do want them to win in the end. So, in the long term, to do that I need to restructure the levels.