The Hit, The Miss and the Ugly: Spellbinders

I’ve been playing a lot of Spellbinders (iOS version) recently, and wanted to do a post that I hope I will repeat; Hit, Miss and Ugly. I’ll pick one thing I like, one thing I think I could improve, and I thing to remove from a mobile, free to play game, and discuss them in some detail. 

Here we go.

The Hit: The Weekly Leaderboards

Spellbinders isn’t the only game to use Weekly Leaderboards (Miniclip uses them, Game Center uses them, for example). However, I don’t think I’ve seen it done better, and I don’t think it is done enough. Your first win every week triggers the weekly league, whereby you are surrounded with fourteen other players of a similar skill level.

Spellbinders implementation of them is really strong, for two reasons:

CCGs Retention Model

Introduction

I play a lot of digital card games. When I was working on Runescape Chronicle, I played that, as well as Hearthstone, Duelyst, Faeria, Magic Duels, Elder Scrolls Legends, Infinity Wars, Gwent, Solforge and, most recently, Eternal. Recently, from a professional point of view, I’ve been fascinated with the different ways that these games run their free to play economies.

Hearthstone, of course, set the benchmark for generosity and card acquisition rate. It’s interesting to see the different ways that these games approach the problem of getting cards and currency to the player. Some run a similar setup to Hearthstone (Elder Scrolls), whereas games like Eternal are trying to innovate (offering players a mode where they draft cards, then keep all cards they draft).

One thing that strikes me is that, in general, these delivery mechanics seem focussed on the velocity with which players earn cards, rather than creating the core retention loops seen in games such as Clash Royale. I know that this was something we came up against when working on Runescape Chronicle. We had a very clear picture of card acquisition rates, but ended up leaning on Daily Login bonuses as a means of encouraging players back.

Dimension Shifting Platformer

Ever since I worked on my 2D teleporting prototypes I wanted to take the idea into 3D. However, I didn’t just want to copy the mechanic into 3D. I wanted to take it, tweak it, and work on some new Blueprints for the 3D implementation.

I decided to make the teleport less of a teleport and more of a shift between dimensions. I loved Legacy of Kain and wanted to make something inspired by that game, but still make something that was obviously a platformer. This is what I came up with.

Image converted using ifftoany

C++ Flaming Object

In the final post of this mini-series I’ve moved on to a more intermediate piece of coding. This was actually my favourite project of all the C++ tutorials. Visually it was the most interesting, and actually implied a cool little game. I quite like the idea of designing Burning Monkey Ball Deluxe. It’s a higher stress, higher risk version of Monkey Ball with dire consequences for failure. Another day, maybe.

C++ Camera

I think that Epic continues to do an amazing job with its tutorial content for Unreal 4. The C++ tutorials are as good as any I’ve used and offer some really interesting tasks to sink your teeth into.

This tutorial builds an interesting camera systems which allows players to rotate around and zoom into a static mesh. It’s very much a third person game camera, but just using it evokes the feeling of an adventure or detective game, where the player is moving through an environment, searching for clues, and zooming in on areas of interest.

Introduction to C++

Having spent a good deal of time in recent weeks working with Unreal 4’s Blueprint system, I now feel like I have a pretty solid handle on the basics of that system. Also, by looking into the guts of Advanced Turn Based Tutorial (LINK), I feel like I’m getting a better understanding of the potential of that system.

However, I wanted to get a better understanding of how C++ works in Unreal. This desire came about for one main reason; in a professional setting it is not possible (and not sensible) for me to rely on blueprints all of the time. It is important that I’m able to, at a minimum, be able to parse code and make changes to key variables in order to tweak and tune my prototypes.

Over the next couple of weeks I’m going to post a few times about C++. My aim is to complete some available tutorials, then play with variables in order to see what effect I have and further understand the way that C++ classes work in Unreal.

Returning Inside (to the Zombies)

This is going to be a short post that relates to some of the experiments I have been doing recently with an indoor zombie level and an outdoor zombie level.

Long story short, the first experiment was the indoor level, where the zombies were massively powerful, both because their inherent stats (health, damage, etc) and because the nature of the level (tight corridors and short sight lines) gave the melee heavy hitters a huge advantage.

To compensate for that, I made an outdoors level with enemies spread further apart, with longer sight lines and a variety of low walls for the player to use as cover. The thing is, that didn’t help very much.

Outdoor Zombies

After my indoor zombie experimentation, where the ranged player characters were overwhelmed by beefed up melee enemies who could take advantage of short sight lines and swarm the player, I decided to take the action outside.

There was two reasons for this;

1. The new level design would have the immediate, but somewhat tough to measure, effect of rebalancing the game in favour of ranged heroes who can now use the full benefit of their greater range.
2. With the game already rebalanced in favour of the player I now have a better space to start tweaking range/damage/health variables to get the levelling behaving as I want.

Using the Turn Based Toolkit

As I mentioned in a previous post, I’m going to be using the Advanced Turn Based Toolkit (available in the Unreal Marketplace) as a base to prototype out different mechanics of my turn-based zombie game.

I know at this point I must sound like a salesman for this particular toolkit, but I just love the way it is put together. The best aspect of the toolkit is just how easy it is to customise. I wanted to put together a small, basic map to see how the different characters (a ranged character and melee character interacted).

First, I set out a hex grid and placed a couple of characters. See image below.

 

Interlude: The Upside and Downside of UE4

This isn’t the blog post I promised but, whilst starting to put together my turn-based idea, I stumbled onto something that made me think about one of the big differences between UE4 and UDK.

When I used UDK, the Content Browser was a faithful friend. It wasn’t overstocked with meshes and objects but there was enough there to let you throw together an aesthetically interesting level without too much trouble. A far from profound, but certainly noticeable, adjustment to using UE4 is the bare cupboard of a content browser.  It took me a while to understand that, simply, the free content from UDK’s default content browser had been replaced by a shop.

My default reaction, predictable, reasonably, was to be a bit put out. Swapping my free things for expensive things hardly seemed like a good deal. As is often the case (and with the help of a friendly “thank you subscriber, we’re free now” voucher) I was able to see the benefits of the new marketplace.