Mid Game Crisis news - Skein

After adding in lights to the game, I set about expanding and developing a bit more the enemies and magic/inventory for the player. I also set about creating a proper HUD to show the controls on devices as well as the player information - health, gold, the current level and whether they had a key or not (I had also made it so that certain levels are "lockable" and require a key to leave, hence the space for a key in the HUD). I'll talk a bit more about these additions in the next news update, but this week I want to talk about a small crisis I had while working on these things...

This Isn't Working

I had what I felt was a pretty solid start to my game. Lighting worked well, enemies did what I wanted, the basics for the magic system were in place and my dungeon generation was awesome... so why wasn't I happy?

One of the main things to get under my skin was how the game worked on mobile. While the controls were adequate, they felt "clunky" and I wasn't satisfied with the overall feel and gameplay experience on mobile. I also wasn't happy with the HUD, as I was beginning to feel it was a bit to baroque and attention grabbing, taking up too much screen space, especially on tablets where it looked too big. The final doubt I was having was over the FPS and vertex batches. In my experience mobile doesn't like too many vertex batches and I had a LOT - mainly due to the lighting - and when doing stress tests I found that to support low-to-mid range devices meant that I was going to have to limit instance count, and since the game required a huge number of enemies, this was another thing I was unhappy with.

What to do? I'd hit a wall in development where I was unsure what exactly to do with the game and where to take it from here, making it almost impossible to continue working on it. It was time for a break and so I went about tinkering with other projects I had on the back-burner as well as taking the opportunity to participate in the great GMC Jam - which spawned the aberration that is Little Nicolás - in the hope of clearing my head a bit and putting things back in perspective for me. I also had a trip over to the YoYo Games HQ in Dundee at that time, and I hoped that the distraction would help clear my head and get the creative juices flowing again.

Mike D. To The Rescue

While in Dundee, I had the opportunity to show the game to Mike Dailly, as he had been showing interest in the project from the very start. I explained to him some of my issues and concerns and he played the game a bit, then gave me his opinion and suggestions. The main one - and this is blindingly obvious now that I look back on the project - was "Why not just drop mobile altogether?".

Woah. Now that was something I hadn't thought about. My last two years making games have been dedicated to mobile game dev, and the idea of dropping support for mobile was just not something I had even considered. I mean, mobile is where it's AT, right? Well, no... The more I thought about it, the more sense it made, especially when looking at some of the other big GameMaker games out there, like Hyper Light Drifter or Hotline Miami. Those aren't mobile games! In fact, there are a hell of a lot of great GM indie devs that don't even think about porting their games to mobile.

Mike went on to suggest that this change would then open the door to co-op gameplay, which was something else I'd never thought about. I should have though - given the arcade roots of this project - and dropping mobile meant that I could have more than one player in the game. Sure I could have done this previously on mobile using the networking functions, but, to be honest, I hate networking and never play online multi-player games. But I do love playing local multi-player games! it's a different sensation having someone physically sitting beside you and jamming an elbow into your ribs when they manage to pwn you in a game, and I knew that this kind of thing can work very well... just look at the success of games like Towerfall!

The final changes he suggested were to expand the view in the room, and make everything brighter. These may seem like small things, but after testing, I realised that (again) they were obvious things to do. One of the selling points of the game would be the sheer number of enemies that you are up against, so you should be able to see them! This would have the double benefit of making planning and playing easier, but also give the player something to be afraid of and think about. Should they open that door, since behind it there are a hundred exploding skulls waiting for them?

Ch, ch, ch, ch, CHANGES!

After returning from the YoYo Games offices, I set about transforming my game into the new vision I had for it. The whole time I was in Dundee I'd been going over this, and although I had been determined to stick to my design doc, I realised that if I wanted to finish this I'd have to forget about some things I'd planned and add these new ideas to it. Sometimes you just have to bite the bullet and get on with it.

First thing to do was to change the view size (the base scale doubled from 160x120 up to 320x240) which was an instant hit with me. I was worried about how the graphics would hold up at this higher resolution, but I needn’t have been, as the increased size actually enhanced everything! I can't say why exactly, but expanding the view made the very low-res graphics "pop" a bit more, and they all seemed to fit together better, giving a much nicer experience. I also set the lighting to be slightly brighter and let the player actually see around them. The previous versions were very dark, and with a larger view that left a lot of unused screen space, so brightening the scene gave the player something to look at. This expanded view also meant that, as I suspected, while playing you got more tension as you see more of what's around...

You can see from that image that I could also cram more enemies than ever onto the screen and maintain a decent framerate! Yes! I was getting that feeling of tingly excitement again, and in my head things were starting to click into place for what to do next.

Making the game two player was actually easier than I thought it would be... I just cloned the player object and made a new parent which I assigned to both, then changed all references to the player to reference the parent instead. I also made it so that my dungeon generator scripts would spawn one or two players based on a global variable (which would be set when I eventually got around to making the main menus). That left me with making the controls for the player, which was going to be a bit more complex.

GamePads

The current control scheme was based on mouse "touches" and virtual keys, but if I was now aiming at desktop (and maybe consoles? I can dream...) then I was going to have support gamepads too. I've done gamepad stuff for other people, and I've made tutorials and things on using them too - like this tech blog - but I've never actually had any need to incorporate them into my own projects, so this was going to be interesting!

As it turns out it wasn't too difficult to add them in. I created a couple of global variables to hold the connected pad index value, one for each player, then used this global variable to check the pads themselves for any button presses or stick movement. I also added an async event to my room controller to catch any pads being disconnected while playing so that I could show a message to inform the player. At the same time I converted the virtual keys into actual keyboard checks and ripped out the mouse control (I did play with using the mouse for movement and shooting Diablo-style, but it just didn't feel right).

I also had to adjust the view to accept two players. At first I tried limiting the player movement so that if they were at opposite sides of the view, they couldn't go any further until the one or the other players got closer, but this was a horrible experience for the player I felt, as they were getting attacked from enemies that they couldn't see. Instead I constructed a "SSB" style view, which expands and contracts depending on how far away the players are from each other. This proved to be an ideal solution and leant a certain dynamism to the gameplay.

Phew! After that flurry of action (and a few heavy debugging sessions) I finally had my game looking better than ever, and now with two players!

The Name Of The Game

With my project back on track and my desire to complete it renewed, I felt that it was time to give it a name. Currently it was being saved as "Roguelike_3", which just wasn't good enough anymore! But what to call it? My first thoughts immediately went to some derivative of "Gauntlet", but there's not really any other word that conveys the seem meaning, and I wasn't sure I really wanted to make such a close connection with my game to that classic. Let other people make the connections, good or bad!

I also didn't want to go for the generic titles, so made a conscious decision to avoid words like "rogue", "dungeon" or "labyrinth". However those words did make an excellent base to start searching my trusty thesaurus! That turned up some great words and had me thinking about names like "Onslaught", "Vault Warriors" and "Skirmish", but none really felt right to me. But when I looked up labyrinth, one word struck a chord... Skein.

On the surface, the word has little to do with a game about killing undead in a dungeon, but as a metaphor I loved it! Basically it means a tangle of something, like yarn, but it can also be applied to passages in a building, or even words. And since everything in my game was going to be procedurally generated and the player would not experience the same game twice, I felt that this wan ideal name. It also sounds nice (to me), is short (important!) and easy to remember, since it's not a common word. Time to open up Photoshop and mock up a logo...

Logos

For me. creating a logo starts with a font. I search around for a font that I like then experiment in Photoshop with different formats and designs, often changing the individual glyphs to suit an idea, until I get something that I think is workable. In this case, after a fair bit of searching, I found a font called "Endor", which I liked a lot when used for the name I'd chosen, so I polished it up and came away with this:

Hmm... I really wanted to get away from that baroque look, so, although I liked this, I decided to not use it and started again from scratch. This time I found another font that I liked which was called "Barbarian". The sword effect wasn't quite what I wanted, but I loved the glyphs... although, maybe a sword effect with it would be a good idea? As a lover of Adventure Time I knew just what I had to do!

With that, I was finally happy. The logo looked good, I loved the intro animation, and I had a (new) plan on where to go with things. So, it was with renewed vigour that I set about expanding my game... which is what we'll talk about in in my next news update!