HiveMindStudios

Creating great software, one line at a time

Blog

view:  full / summary

Reward structure in Axe of Kings

Posted by Rowan Powell on October 16, 2016 at 4:30 PM Comments comments (0)

When working their way through a game, the player generally wants some form of payoff for their time and effort investment which can come in a range of forms depending on the game and the player;

 

  • Resources (Health, Strength, Currency)
  • Options (Abilities, unlocking something, combinations of effects)
  • Non-Mechanic rewards (Character outfits, story content, cool view)
  • Novelty (New abilities, enemies, area)

 

Axe Of Kings primarily draws from Novelty, Options and to a small extent Resources. This is because the core engagement of Axe Of Kings is Mastery of the system - knowing how to beat the monsters, maximise the effectiveness of the abilities and 'beating' the game. So the game needs plenty of fresh concepts to master fighting against (Enemy mechanics) and using (Items, Abilities) and constraints to consider (Debuffs, terrain, resources).

 

The player also wants the reward to be roughly proportional to the time or effort invested into getting the reward (The classic example being getting common loot from a raid is rather poor design), but at the same time is trying to maximise reward for investment and will attempt to identify which elements of your game have the highest ratio. One issue with this, as roguelikes and MMOs have shown repeatedly, is that players will do content they really don't enjoy just because they have the highest ratio. So the trick is having the fun content being the rewarding content, or reducing the 'price' (Time/effort) for the less fun parts.

 

The other issue I've been working on is the reward structure overall; having a range of different rewards, sizes, durations and so on. Let's take a look at the game's reward curve from the start of development, just floors of the dungeon and enemies to kill with no particular mechanics to each enemy.

A standard engagement curve looks a bit like the image below, with cycling intensity building to a peak and then tailing off.


Whereas the curve for AxeOfKings near the start of development looked a lot more like this;

 


 

As you can see, it's fairly monotonous and after only a handful of enemies the game will get pretty dull. And so it was, players got bored very quickly and stopped playing, often before clearing a single floor. The issue is once they've seen the full set of rewards, there's not much to work towards and each reward is less meaningful. So let's take a look at what the player's theoretical reward curve looks like with varied enemy health, gem rewards based on that health and the ability to complete the dungeon.

 


 

Better, but not great. Players would now sit down and play maybe a floor (Lack of good introduction to the game contributed heavily to this issue), which is no where near enough to make any of the later-stage content worth building - if they're never going to get there. To help resolve this a bit better, I sat down and thought about the immediate, short, long and overall goals the player would have and broke those down into how they applied to my game.

 

* immediate - dealing with an individual monster or clearing a room

  • short - getting to the next visible reward objective (Chest, Exit, ect)
  • Medium - Clearing the floor, levelling up
  • Long - Getting the resources for the boss, clearing the boss, beating the dungeon
  • Overall - 'Beating' the game, unlocking all the novel content

 

Anywhere that the above reward structure didn't feel varied or was simply lacking, I designed new elements to keep the player engaged at these frequency intervals. To compliment this, the reward structure;

 

  • immediate - getting gems, killing a monster, healing
  • short - gaining gems/items, getting buffs, trap novelty, exploring the rooms
  • medium - new ability, powering up, dialogue, new dungeon floor
  • Long - Beating the boss, reward screen/gem bonus, next chapter & characters
  • Overall - New dungeons, new characters, game progression and completion


 

Now the curve looks a bit more like this;

 


Much much better! There's a lot of content now to be egaged with and a good mix of frequency and intensity and the way the 'alerted' mechanic works means that the player gets frequent rises and dips of challenge, which keep adding up untill ~50% of the monsters are engaged and then it starts to taper off and monsters are cleaned up and the loot that couldn't be delt with during the fight can grab the player's attention again, but in a relaxed setting.

 

Notice how the gameplay doesn't just feed into progressing through the dungeon (Healing, improving stats and such) but also tries to focus on the two key draws of AxeOfKings - Mastery and Improvement. The game doesn't give much mastery reward if all the content is obvious from the get go, so having lots of novelty is important - new enemy mechanics, new objects and level structure are vital for the player to feel like they have something left to 'beat'. As for improvement, the game actually doesn't really let the player improve their stats (Which is very unusual for a roguelike!) but instead gives them strength through the gameplay options and the knowledge they get about enemies makes them easier to defeat (Knowledge is power!). Having items that are all consumable allows the player to keep building up the power of their character and having that extra strength at a key moment, but also the AbilityLevel system allows for a more long term feeling of progression.

 

Reward structure and pacing is absolutely vital for keeping players interested in playing the game to get to the next element of the game, but it's really worth understanding that rewards are not just in-game rewards of numerical changes. Particle effects, story, exploration, domination of an opponent, the feeling of elitism of achievement are all other valid approaches to rewarding a player. You need to sit down and understand what draws the player to your game and what the core desires your game feeds into.

First experience putting a game on GooglePlay

Posted by Rowan Powell on October 10, 2016 at 2:40 PM Comments comments (0)

Sun & Sky was my first experience making a mobile game, outside of small prototypes and tech demos and as such I made quite a lot of mistakes, which is exactly what I wanted/expected!

 

The first thing I had to deal with what making marketing material for the Play Store. As much as I have confidence in my art and design, marketing material is something far outside my usual remit, so not sure I did a great job with the work I did for that, though it seems passable enough to get people from the app page to the download button.

 

Big mistake #1

 

I tested the app out quite a lot on my personal phone before releasing it, but I didn't think to expect any major differences on other phones! The resolution differences meant that the UI scaling was unplayable and turned off many users after politely trying to squint at the UI for the first few levels...

 

The other issue this created was that the intro to the game was horribly low resolution, which made the game look really low quality!

 

The solution turned out to be really simple - just a changed setting in the publishing window!

 

Big mistake #2

 

I did absolutely no marketing or promotion about the game, a common problem for developers - we get focused on the game and not on the business! Unfortunately this obviously meant I had very low downloads (18 as of this post, most of which were me encouraging people to download it face to face!), but this was very easily preventable. I could have;

  • Posted these blog posts on facebook, reddit/r/devblogs reddit/r/gamedev and for AxeOfKings reddit/r/roguelikedev
  • Posted gifs to twitter and tagged bots
  • Told my journalist friends about my game!
  • Run an advertising campaign
  • and so on...

 

Successes

 

I got a lot of feedback from people early on about difficulties understanding the controls, the story and watching where they stopped playing. This was really valuable and I took advantage of it as much as I could. I also had really good workflows and made a huge amount of progress on the game in a short amount of time and it will be extremely easy for me to add more content down the line. I feel like a built a pretty solid and enjoyable game, it lacks in polish though and a few cases of lack of effort on my part really hurt it's success.

Level structure in Axe of Kings

Posted by Rowan Powell on October 8, 2016 at 2:35 PM Comments comments (0)

During early playtesting for Axe Of Kings, I was looking out for how the players engaged with the various elements of the gameplay and given that I had revised the level layout before (As seen in an earlier blog post) I thought the maps were in a good spot and I could focus on the other parts of the game during testing. As it turns out, this was not the case.

 

The levels were now much more compact and meaningful to navigate given the pace of the turns and interacting with the movement mechanics of enemies was much more meaningful due to the constrained movement, but it was the same set of interactions over and over again, even worse was that it was now hard to work out where you were in the dungeon!

 

So the dungeon generation needed to be revised again;

  • Maintaining the pace through the dungeon
  • Maintaining the rate of interactions
  • Improving the number of novel situations
  • Improving the considerations of interaction with terrain

The pace of the dungeon is generally the same, though a little faster in open areas and slower in cramped areas, the interactions tend to follow the same pace, though a little faster overall due to some new additions in map objects that spawn. The number of novel situations is vastly improved and the terrain now plays a much bigger part in how the player chooses where to go. The solution I came up with are very simple and solve the main problems I was having, though I think it can be improved further, fortunately this is very easy for me to do with this new system as I can just add new room structures.

 

The game now generates some slightly different room structures but also will merge open or dougnut rooms together to further mix up the structure of the levels.

 

]

 

I've also added a few extra objects such as locked chests and floor traps that turn out to be useful for orientating the player in the level as well as mixing up the pace of the game a little. You can see all of the new structures in the image below and how each room now tends to have something fairly identifying.

 


 

If all else fails, the game now has a map in the menu, with icons to show which rooms contain at least one of the main party members.

Why am I here? Why am I fighting this fight?

Posted by Rowan Powell on September 15, 2016 at 5:30 AM Comments comments (0)

There's an interesting psychology in how players approach certain genres of game due to their core motivations for playing those games. Fast paced cathartic shooters don't tend to invite much of a story (Though some do try to offer something up) as the player isn't looking for a narrative, just a setting to enjoy the mechanics and power fantasy. Strategy games demand an explanation of the setting, but once it's established often leave the player and the mechanics to fill in what is 'happening', calculated destruction or tense wars of attrition are often decided by the player's skill than a predefined narrative. A dungeoncrawler or other rpg often provide a running context and *other people's* stories, but leave who you are fairly open to interpretation, which I feel fits perfectly into why I play these games - I want to explore being someone else and defining a character.


 

Notably, some games go about this from unusual angles that don't fit my 'theory'. The main example that comes to mind is Elder Scrolls: Skyrim. At first look, Skyrim has all the mechanics that screams 'RPG' and the self-defining blank slate that I love in RPGs. But playing through the game didn't give me that feeling AT ALL, which in hindsight is quite revealing of how the game is presented. The game opens with you being neck deep in someone else's story - you were adventuring somewhere else and have returned home, captured and now facing execution. Skyrim is an RPG no doubt, but you are playing *someone else's* role and given that most RPGs only tend to tell a story explicitly if they are not the player Skyrim states clearly to me that the game is not about me, quite opposite from the RPGs I normally play.

 

Thinking about this can be useful when deciding how much story you need to put into your game, though notable examples such as Dark Souls and Guild Wars 2 offer huge wealth of lore material around the game for those it interests, and many people clearly are. But I've actually found it's even more useful to use the reverse conclusion: rather than 'X genre needs Y amount of story to satisfy players', I've listened to how much story the players are expecting or wanting from my game and that has been helping me understand the implicit feeling and genre of my mechanics!

 


 

When I was working on Sun & Sky, I threw together a rough intro to the game and focused on the mechanics primarily and one of the comments I got back is 'I don't know why I am doing this/fighting this' and it made me pause. My game felt like a puzzle game. There were no long-term strategic choices to be made, the tactics were minimal and all the mechanics pointed towards 'put the pieces in the right place', which if my game had been more abstract may well have not needed any story at all, but I had chosen to represent the puzzles and zones with 'turrets', 'fungal' and 'planets'. As it turns out the game therefore felt that it should fit into the strategy genre, at least to some extent. An opening cinematic of sorts seemed to settle concerns about motivation (Fitting what I theorise about strategy games! If they had wanted more development of the story I would have rethought this again as clearly the players would be expecting to journey through the narrative of the campaign to reclaim the galaxy). A player also commented about wanting longer term choices and unlock options, again not the usual expectation of a puzzle or tactics game where the resources reset for each level as mine does - but perfectly fitting for a strategy game!

 

I have resolved this conflict between mechanical-genre and feel-genre somewhat with the addition of the intro and outro sequences and I'm planning to go back and add some long-term choices (Perhaps between which planet to save!) but it was an interesting insight into how players percieve the game.

Sun & Sky

Posted by Rowan Powell on September 15, 2016 at 4:25 AM Comments comments (0)

I worked on a small mobile game called Sun & Sky from mid July to the end of August over the summer, based off an old tactics based idea for a game that had been bouncing around my head for quite a long time now - reclaim the worlds from.

 

The core concept is inspired from a webgame I played as a teenager called Creeper World, essentially a never-ending flood of 'creep' pours from certain areas of the map and you need to hold it back while you push towards certain objectives located on each world, managing your infrastructure and energy consumption. I modified this idea somewhat, removing the pylons that you needed to move the energy around and instead focus on a smaller scale of engagement - dealing with a small handful of turrets and combating terrain issues as much as the enemy itself.

 


 

This means that the game ultimately is more of a puzzle game than a tactical one, despite my original designs and motivations. The 'enemy' is a fungal that spreads across the map from hives and the edges of it's domain, which means that it's 'attack' is fairly unsurprising and you don't need to react in most scenarios, given that you've planned properly - with the exception of more advanced management of power toggling your buildings. This means that for the most part the 'challenge' is finding how to lay out your buildings in a way that they don't get overwhelmed and can make the most efficient progress.

 

The enemy types then help to cement this idea of careful placement over all else; the rapidly growing clusters will quickly reclaim ground where any mistakes leave an opening in your lines, long-range spores will cause issues behind you if you don't have the ground appropriately covered, clusters will punish you for leaving a flank exposed by launching attacks that can quickly pick off nearby solar panels (The core resource generator in the game). I'm very happy with how these 'enemies' worked out to play against as I didn't design them to 'do' anything strategy-wise except provide a new set of challenges and the level design allowed me to capitalise on where those mechanics were the most interesting. The reason this makes me happy, rather than simply having designed a good mechanic, is that I often see people theory-craft new concepts and roles far too extensively, thinking about how each little scenario plays out. Not to say this is purely wrong, I theory craft all of my designs to some extent, it's important to think about *why* you're adding something to the game, but people often get caught up in details that don't matter or mechanics end up interacting in ways they don't expect.

 


 

The turrets and terrain are where the puzzle elements of the game really start to show through though. The game starts the player off with a basic Flamethrower (Short range but quickly clears any nearby tiles) which serves the player well until they meet water tiles. Water tiles cannot be built on and Flamethrowers are too short range to shoot across them, so the tutorial quickly offers a new solution - the longer range AntimatterBioCannon (ABC for short). The second level allows quick-thinking players to take advantage of the longer range to tackle the level much more efficiently, but the Flamethrower still has it's strengths available here. The third level really pushes home the play between the two buildings available to the player, some parts of the level are simply inaccessible to the player without grasping that ABCs can get you over gaps and Flamethrowers can quickly clear a 'landing' area.

 

My favourite mechanic by far actually crops up a little later into the game (Level 7, the first map on the third planet) which is the Dehydrator. This building has absolutely no combat functionality and drains energy alarmingly fast, but offers a solution to a problem posed from here on out - two or more water tiles are between you and the next island of dry land. ABCs can't shoot that far, but Dedhydrators can turn water tiles into dirt, allowing for buildings to be placed in range of the tiles you want to shoot. But by doing this, you create even more terrain for you to defend (A dehydrated tile is often quickly met with an incoming barrage of spores trying to infest it!).

 


 

The game also features a simple set of achievements for each level (Lose no buildings, use less than X resources, use less than Y buildings) which helps reinforce to the player the goals needed for playing the game well as well as provide a nice set of shiny gold medals for those who like to hunt down 100% completion of a game. They also unlock extra bonuses for the player if they get all the medals on a planet.

Designing Engaging Dungeons

Posted by Rowan Powell on April 21, 2016 at 6:30 AM Comments comments (0)

I've been making a lot of progress on Axe Of Kings, adding lots of new content and getting players to try it out so I can try to gauge what's fun and what really should get an overhaul.

 

The original level designs for Axe Of Kings used the algorithm from the AI demo with some tweaks to allow it to make bigger levels, which gave some really interesting results and are enjoyable to look at ... but not very fun to play. The issues with this sort of level design stems from the fact that AoK is a turn based game, so moving down long corridors consumes a lot of actions, doesn't really give much interaction or reward for progress. You can see in the image below that the player would spend a lot of time moving around and not really doing much (Compounded by the issue of having 3 people in a party!).


 

The new levels are much, much more compact with small rooms being connected to each other by very short corridors, which keeps the mixups between having wider areas to kite back enemies but also choke points to take fights or cautiously move through. There are some problems in the larger levels of having the rooms all be a bit too similar (Which is less interesting due to the novelty rate, but also can end up with you getting a little lost, not ideal!).

 

The tree stumps and bushes also got removed, they ended up just being action-sinks which didn't really feel rewarding to destroy, they just got in the way of the interesting parts of the game, though pots take on a very similar role.


 

The pots in the current build block the player and enemy movement and can be destroyed (Much like the old tree stumps) but only take one hit to do so and give a big explosion of gems when they're destroyed which feels rewarding. They also have a chance to drop items which are very useful for your progression through the dungeon.

 

They key thing in the new builds is that there's always something directly nearby to engage with and gives the player a next task to follow which helps stop them finding a point to stop playing, the gem drops from the enemies, pots and chests help them feel rewarded for making progress through the dungeon. These (Along with some other factors i'll talk about later) have helped take the game from a stage where players would engage for maybe 30 seconds as they figured out the controls and got bored to now where the players will happily sit and play through many levels. The next thing for me to focus on is to give some more rare and interesting events in the levels, to keep them feeling fresh. I'm personally a fan of rougelike's odd hidden alternative victories such as making your way into a special section of the dungeon or bringing an item to a location, which helps for adding a bit of replayability.

Code alone won't make a game

Posted by Rowan Powell on December 31, 2015 at 2:20 PM Comments comments (0)

So something that I've always struggled with, simply because it requires a bit of perspective shift from my default state, is that what is fun to create and let lose as a programmer, isn't always fun to play with as a player.


This may seem obvious to a lot of people, but there's a subtely to it that's important, many times I've found that the very clever and useful bit of code I wrote into a game, the player simply would never notice without being told or just doesn't care about. I've written complex AI to challenge the player, which are not found exciting and intricate level generators which the player just breezes through.


The concept that becomes clearly more important (When you want your games to be more than an idle hobby), is the idea of code that interacts and talks to the user, rather than to itself. Tiny, simple code snippets that make elements of the UI bounce and shake, or tilesets to convey how a level will play out (more on this later!) have had a significantly bigger impact on the way users are engaging with my content.


I'm in a rather unusual position of being able to create acceptable art alongside being a professional programmer, which gives methe logical and pragmatic mindset of code to pull the puzzle pieces of a design together, but also the absolutely vital ability of an artist to realise the feel of a composition of components, beyond just the technical aspects behind it.


One of the most recent reminders of this has been my recent work on Puzzle Slide and AxeOf Kings. Puzzle slide was a very quick and dirty cobbling of some clever code for puzzle generation polished up with some cute art, informative UI and basic sound. And it was one of the most popular games I've ever made, reccieving far more praise than Anya'sQuest in it's behemoth glory, a heap of code, hard work and duct tape. My old art teacher would often encourage me to step away from trying to precisely line in the little details and just paint freely, where I was strongest and most uncomfortable. This is a lesson I need to bring to my work on games, to step back from the neat lines of code and add some broad strokes of properly engaging content to my games.

A deeper complexity to puzzle generation

Posted by Rowan Powell on September 1, 2015 at 5:45 AM Comments comments (0)

So in my most recent project I decided to make a puzzle game, but rather than just hard-code a whole ton of puzzles I decided to make the computer attempt it for me, with mixed results.


The algorithm that I built for this is fairly simple and is based of simulating a player 'solving' a puzzle that doesn't exist and building a solution to that effectively random wandering.

 

  • Pick a direction to move (Ideally not where we just came from, but sometimes this can't be avoided if we get trapped in a corner)
  • Move some random amount that way
  • Try to put a rock down that would have stopped us at this point, if this wouldn't have been a viable stop point, keep moving until we hit an edge or we can put a rock in front of us
  • Repeat this for a desired number of moves for this level
Ideally, this produces something that looks a little like this process;

but sadly, because the computer is walking somewhat randomly and because of the nature of ice sliding puzzles, it's very very easy for the algorithm to make solutions that either have the goal at an edge or that can be reached much more quickly than expected. Though this can be accounted for using While(isEdge(previousPoint)){keepMoving()}, but this solution can lead to infinite loops if the algorithm cannot find a new place to stop. So the process tends to end up looking a bit more like this;

A more well thought out algorithm could try to enforce that the next step is more steps away (Pathfinding) than the previous one by exploring a graph of nodes around potential stop points. This could be quite costly however, especially for bigger puzzles, and would take a more complex algorithm than a randomwalk approach does.

Ultimitely the result for this game was a sucess, the algorithm creates a huge amount of fairly simple 2-step to 6-step puzzles and the difficulty can be bumped up by asking the player to do some other puzzle solving alongside it. For example the extra modes in this game are Moon levels (Where each alternating step, the board is blacked out, so you need to memorise the next step) and by hiddenBlock levels (Where all the blocks are hidden until you bump into them) which extends the lifespan of the game somewhat.

Initial playtesting shows that people will play about 20-30 levels, but then will bore of the lack of difficulty and no new mechanics to learn.

 

Quick level generation algorithm

Posted by Rowan Powell on July 18, 2015 at 5:00 AM Comments comments (0)

For my AI demo I needed a level for the player and the AI to face off inside which met a few simple criteria,

  • All places on the map can be reached from any other point
  • The map has a variety of open and more cramped areas
  • The map is complex enough in navigation that items have a reasonable distance between them and it's engaging to the player
After a bit of messing around with various approaches I was inspired to making something akin to this rougelike dungeon generator http://journal.stuffwithstuff.com/2014/12/21/rooms-and-mazes/

So the algorithm I made has the following stages;
  • Generate some Room objects
  • Move them apart from each other so that they don't merge into larger rooms
  • Find rooms that overlap on an axis that don't have rooms between them that a connection would cross through
  • Make a connection between those rooms roughly in the centre of where they overlap on that axis
  • Put items and other decoration into the level
The creation of rooms and corridors naturally gives some smaller areas as well as any larger rooms, which works well for the type of level we want to create. but it is important that the rooms take up most of the space of our level, large empty gaps might mean we end up with unconnected rooms if they don't line up with any others. Rooms too spread out will also mean that the corridors become very long, which might work for singleplayer adventures but don't work very well when trying to find and engage in a 1v1 battle.


Using Java to develop an application using public libraries

Posted by Rowan Powell on July 9, 2015 at 2:15 PM Comments comments (0)

As part of my efforts to expand my ablilties, particularly with Java, I developed a small application in 6 hours over two days. The application uses freely available libraries on the internet to create a system that can recognise what a user is saying, check it for key search words and phrases and also search for relavent words around the spoken terms to find out if it's reasonable to flag the user up for further investigation.


The first part of the application is the hardest and least reliable as it's a problem that's been in the process of being solved for a very long time - speech interpretation. For my application I tried using IBM's Speech-To-Text service avaiable through the bluemix platform, but the system proved to be very difficult to use and had little in the way of guides for how to put together an application to make use of it. This was unfortunate because the service appears to be a lot higher quality than others on offer. I ended up working with Voce, which could be implemented as a .Jar library through Eclipse, significantly simpler. Unfortunately the Voce engine has some real issues in reliably detecting words and doesn't automatically use a dictionary.


The second part involved saving a log of what the user said to a file, whichwas fairly trivial as I had created a class to do this for a previous project (The client-server auction system needed a persistant data log).


The third part was trying to find if keywords matched sections of a body of text, this was also a really simple thing to implement as I had also already written a pair of functions that would check if a word could be made by insertions or deletions on the other word which can be found on my gitHub at https://github.com/Xaoka/Public-Demo-Code/blob/master/TextCorrectingContains which I've extended to take into consideration a maxmimum allowed edit distance, here I've just used 2 as a default value, but this could be easily made so that the function checks if the edit distance is less than 25% the length of the word or some other function. In my application I also disregarded words that were less than 4 characters as almost any word could be corrected to them.

The final part of the application required an analysis of google search results from a given term, this was made massively easier than it could have been by two factors. First, the analysis of the google search results could be done by applying the keyword contains functions I had used earlier. The second point was that a publically avaiable library GSon could convert JSon files into a readable format. Trying to read a normal google page is difficult as the results back tend to just be the display code for the page, not the actual search results. Instead a custom search engine was created (I actually used someone else's link) which returns all results in a JSON format, which could then be parsed by GSon and read by my program.



This was a really fun and challenging project to put together and really helped me to branch my skills out further, exploring the options available through public APIs and the various Libraries people have put together.


Rss_feed