Saturday, November 17, 2012

The town layer

This is the persistent layer that sits on top of the Roguelike game play, added as a hub to give a sense of persistence to the user, make the game more casual friendly, and add avenues for rmt that don’t impact the Roguelike game. This post says more about my thinking behind added this extra game element. This post is focused on how the town works. I’ll do another later on how it looks.

There will be no title screen as such instead when the user starts the app they’ll come straight from the loading screen to the town view (obviously if it’s their first time there will be story/tutorial overlays). On entry there will be modal message prompting them to either continue and existing adventure or start a new one. If the player chooses to view the town there will be a persistent ‘adventure’ button.

The town view will also have navigation to get to things like global options, credits, info etc.


It uses 2 different currency types. Gold, which is created in the town and crystals(or some other unit), which will be the paid for currency, but which can also be found in the dungeon. I may also add other reagents that can only be found in the dungeon.


There will be several different areas, all performing different functions. Areas are building that all users have and that cannot be moved. They can be upgraded though. There will also be constructs, which are buildings created by the user than can be moved/upgraded destroyed etc.

Ancient cave (will probably be called something else).
This is where the players go to play the Roguelike game. Can be upgraded to access different game mode – different difficulties, plus maybe a sprint or defense mode in the future. Probably only uses dollars. If the player doesn’t have an existing adventure then clicking the ’adventure’ button take them here, where they choose their character/equipment/mode for the adventure.

Training ground (need a new name)
The way my game and power design will go the build and abilities will be dependant on the cards the player has. When a player chooses a classall they’re actually choosing is the starting cards/equipment. They start off with a basic fighter/assassin/mage selection, then as they player more combinations can be unlocked using this building. There will also be blank slots where players can create their own starting classes. These will be expensive, and bought with the pfc. I’ll also have to be very careful when balancing it so players can’t create OP combinations (though it’s only the starting decks so in the long run it shouldn’t matter).

Use this to create weapons and armor that characters start off the game with. My idea is that every time a character is sent off into the dungeon you have to equip them first. There will be bog standard weapon choices, which the user will have unlimited amounts of, but other weapons/armor combinations will have to be made beforehand. Most take money on it’s on, but some require better reagents. Again, I should emphasize that the better weapons will help the early game but will become obsolete relatively quickly.

The morgue where you can view your dead characters. I want to make it easy to export and share stats – I’m not doing a hugely intensive file, but enough to be interesting. You can also use it to buy monuments and crypts for characters which are contructs placed in the map.

Bar/general store
This is where a player can buy things. This will mostly be things like extra skins/consumables to take into the dungeon.

Hall of honour
This is the achievements and quests + record of winning characters and where you buy monuments to them. Monuments can be placed around the town.


Gold Mine:
This is a building that constantly generates small amounts of gold. The trick is that it continues to do so in real time while the game is inactive, but there is a cap on how much it can hold before it becomes full. This encourages the user to log back in frequently to collect the gold. Produciton rate and capacity cna be upgraded, with higher ranks being exponentially more expensive, encouraging rmt.
Lumber ill:
Same as gold mine but produces wood.
Steel mill:
Ditto, but creates metal.
Things to make your town look nicer. They don’t do anything, so I can make the nicer ones ridiculously expensive. Also I can slo them in as they are created without worrying about balance etc.
Monuments are a sub catergory of decorations. They’re built to honour fallen (or victorious!) characters. The grandeur of the momument is determined by how far the character got.

Thursday, October 18, 2012


Before I get going properly building the engine I want to have a pretty good idea of what it need to be able to do.

Every turn the user can perform an action. Their choices boil down to:

  • Moving.
  • Attacking.
  • Using an ability.
  • Using an item.
  • Performing an environment action.
  • Making an inventory change - this means picking something up, equiping items etc.
  • Wait.


Moving is fairly obvious. The characters move from one square to another adjacent square. I'm only going to do four way movement, both because I'm told it makes it easier for casuals and also because there may be at some point a (small) chance of me putting in animations and thats 4 less directions to have to create cycles for. Well 2 if I just flip the artwork.

I'm going to have pathfinding in there. I just need to decide how to implement it. I already have a reasonable A* pathfinder that works with tile based maps. It works fine for just the player character, but it has issues when there are lots of mobs, all heading towards the player. After reading this article 'The Incredible Power of Dijkstra Maps', I want to try to use Dijkstra maps, at least for the mob pathfinding anyway.


Attacking another character without using an ability. Can be either ranged or melee. For a melee attack the attackee must be on an adjacent square, for ranged attacks they can be further away.

When a player uses an attack I want the attack to be able to not only have different types or damage, apply damage over time, have a potential to splash damage over an area, but to also trigger abilities. The properties of the attack would be stitched together from the player's equipment  status effect and stats. Each attack will have a primary damage type specific to the weapon, and this is what can crit, is use in some calculations, and has combat bonuses added to it.

Using an ability

What can abilities do?
First I have to decide on what the attacks and abilities need to be able to do. I did a rough brainstorm and this is what I came up with:

  • Damage enemies, with varying types of damage (eg slashing/crushing/piercing/fire etc).
  • Damage should be able to be over a duration.
  • Should be able to add status effects* to characters.
  • Should also be able to stun, root, fear or put character to sleep (sleep is a stun which breaks on damage) for a duration.
  • Damage should be able to be delayed.
  • Should be able to decide whether or not to affect the user.
  • Should be able to reposition both the active character and the character it is used on. Not just knockbacks, but tactical movements.
  • Should be able to target the environment, as well as characters.
  • Should be able to have a radius of effect. The power of the ability should be able to change depending on the distance.
  • Radius shouldn't just be circles.
  • Abilities should be able to trigger follow on effects. This is nice as it's potentially a way of mixing basic abilities together to make different exotic ones. This could be used to do the delayed damage/effects that I want too.
  • Should be resistible depending on the resistances of the target and the power of the ability, or not resistible.

Using an item.

Using an item can be viewed the same way as using an ability, except that the item is used from the player's inventory/equipment. There will be some abilities that are only available through equipment, like town portal (if I have them), teleport etc.

Performing an environment action.

This means things like opening doors and chests or pulling levers.

Making an inventory change.

This means picking something up, dropping things, equipping items etc. I am tempted to make dropping items free.


Do no action for a turn. The most frequent use of this is in games where the characters regenerate their health over time, so an injured player can wait a time until their health returns.

*Status effects

A status effect is an effect that can be applied to a character. It lasts for a duration and affects the character. I want status effects to be able to:

  • Affect stats. This can be by percentage or absolute.
  • Do damage or heal over time.
  • Do additional damage on hit/being hit, either for or against the character with the effect. These could just be abilities.
  • Trigger abilities on hit, being hit, ability use or move. These can have a percentage chance.
  • Trigger ability on end.

Friday, September 28, 2012

Adding Farmville elements to me my game

Or Scope creep crope sceep.

I've been downloading and playing a whole load of mobile games, one of which is a Farmville lite type game called Little Dragons. It's a nice little tamagochi type game where you you have to hatch and then take care of a load of cute cartoon dragons, with great production values and a disastrously bad monetisation system (I may be wrong about, I have no stats to back this up). It has a system where you have multiple habitats that contain dragons, and each dragon is constantly generating gold, whether you're actually playing or not. The habitats have a limit on how much gold they can hold, then they're full up and the dragons stop producing. As I said, this carries on in real time, even if you're not playing, so what it does is encourage you to open up the game every few hours, just to check on your dragons and collect the gold.

It works incredibly well with a mobile game because most people have their mobiles with them most of the time, and it's very easy to succumb to the urge to just open it up, make a few clicks and have a quick play. I want to leverage this impulse for my game, to make the players feel an itch to boot it up and take a quick look every few hours, even if they're not playing a long session.

Since it's so difficult to actually charge for an app I also want to add at least some form of micro payments to the game. I don't want to compromise the main game so I was thinking about adding an extra layer to the game which I could then charge for. It makes sense and I think will work well for this layer to be the farmville style crack that will keep the users coming back to my game all through the day.

What I'm planning is for the player to have a town that is the base for all of their characters to strike off into the dungeon. My basic thinking is:

  • The town will have several different areas/buildings that can be used to create items and consumables that can be used in the game.
  • A training building where you can build upgrades that can be given to you characters on creation.
  • An embassy to unlock new classes/races.
  • There will be an actual graveyard for dead characters - I'd love to let the player upgrade gravestones into extravagant statues and tombs.
  • Square of honour, with statues and monuments to successful characters.
  • Production buildings that generate resources, that will need to be harvested. Probably wil be mine, farm and lumber forest. Each will be upgradable.
  • Make it a rule that the items created won't be too powerful. They'll be the kind of thing that can make the early game easier but will be obsolete by the time the players gets to mid-late game. This means is hopefully won't compromise the main game for the hardcore players while providing a way to make the early game easier for the casual players, who may like this game layer more anyway.
  • This layer will be completely separate to the actual game so if I shit my britches I can discard it without breaking or having to rethink too much the main game.
  • I was already planning on creating a web version of the game to drive traffic to the mobile versions, and this gives me something extra to use to differentiate the separate versions without crippling the web version to the point that it's not fun.

The big, scary drawback to the idea is that this farmville layer could almost be viewed as a standalone game on it's own. It's a big job added onto and already huge job. The balancing will be difficult to get right, it needs lots of extra assets and plugging it into a micro payments system is going to require a crap load of testing, not to mention just learning to use the apis in the first place.

On the other hand it's something extra to make what I'm doing something more than just another tired Roguelike clone. It also adds some permanence to the game - something that survives even if you characters don't, and as it adds move avenues for micro payments it adds more chance that I may actually make some money from the game. I'm already mentally planning what I'm going to do.

Monday, September 17, 2012

I'm a whore

I should have predicted this, but I was recently offered a contract extension to my current job until Christmas, and despite promising myself that I would take off the end of the year to work on my game I accepted. It's really, really hard to turn down guaranteed money. I've also accepted another job at the beginning of the year so the earliest I'm going to be able to start on it properly is probably Feb/March next year.


I'm trying to look on the bright side though  - it will give me that much more time to iron out exactly what I'm trying to do and to get my ideas crystallised. Hopefully this means when I do finally get on it I'll be able to hit the ground running and get it done that much quicker for it.

Thursday, September 06, 2012

Lottery abilities

This is a follow on form my post on removing random from combat. In that I said I wanted to remove most random chance from my games basic combat. I also said I wanted to keep some positive random events that help the player and give them a 'wow' factor. I call these lottery abilities, and by this I mean abilities that have a low random chance to fire, but that are very powerful when they do. The most common ones I've seen are dodge, critical hit and counterattack.

Critical strike

A crit is where an attack causes extra damage, usually double. The first I became aware of it was way back playing D&D and rolling a natural 20, but it's in a huge number of games and it's very popular. There's just something hugely satisfying about getting the aforementioned CRITICAL STRIKE and decimating your opponent. It's also easy to produce cool visual and  audio effects to go with it. In some game is only applies to melee attacks, not to ranged or magic, to give melee attacks a boost. There can also be spells or abilites that give you an increased or guaranteed critical chance.


Dodge is simply where a character completely evade another character’s attack. It’s present in a huge number of rpgs and roguelikes. Usually whether the attack is dodged or not it worked out by rolling the old random number dice depending on the attacker’s skills and the defenders skill levels. Sometimes it will be taken off of things like dexterity or agility, sometimes there’s a direct ‘dodge’ or ‘dodge reduction’ stat.

The fact that dodging completely negates an attack makes it hugely powerful. Care needs to be taken because if a character has too much dodge it can be completely game breaking.

It also has an additional problem in that it's difficult to make it exciting, in effect it's an action not taking place. You can't really have the cool blood splatter CRITICAL STRIKE excitement when all you're effectively saying is 'nothing happened'. A critical strike can end the fight but all a dodge does is prolong it, abait in your favour.


A chance that an attack will immediately trigger an attack out of turn in revenge from the character who was attacked. This can be cool when it works but can also be confusing. Again it can be hugely powerful and almost game breaking in excess.

The problem with these abilities

These abilities can completely change an encounter when they go off. This can feel great when it happens in your favour, but on the other hand it feels horrible and unfair when it you're on the receiving end, so care needs to be taken. They can easily break pvp games, but luckily in a pve game the npcs don't mind you dodging all their attacks then critting them for half their health with a counterattack.

There's also the argument that too much random ruins fights and takes the skill out of them. Players can play a slow game just hoping for a lucky crit instead of playing tactically, then get frustrated when the crit doesn't happen or goes against them.

What to do about them

  • Soften the effects by having gradations. It's quite common for games with critical strike to have ways to either increase the damage a critical strike does or to reduce the additional damage an enemy crit does. This leads to more predictable damage incoming with less likelihood of the player losing because of an unlucky spike. This is especially important in a game with permadeath. Dodge can also have an idea of only dodging portions of the attack – glancing blows.
  • You could also add extra stats that directly counter these abilities, reducing an enemy’s chance to dodge your attack or crit or counter you. 
  • Remove the lottery element and just have them as status effects that give an effect for a duration – for example a skill that means you a have a very high chance to dodge the next X attack.
  • Make it so the enemies can't do them to you, or at the least do some very infrequently.
  • Make sure the chances to trigger the attacks stay very low. Once you get a high enough chance that you can reliably expect one of these effects to go off in a fight they stop being lottery effect. If the player is think 'shit I was so unlucky not to get a crit in that fight' I know the chances are too high.

Friday, August 31, 2012

Really basic level generation

Level generation is, in my opinion, one of, if not the most important element of a Roguelike. Different methods of level generation produce levels that feel very different, ranging from box stamping to more organic tunnelling methods. To take advantage of this I want my game to use several different methods to generate the level, giving different areas different feeling that go with their theme.

This is my first, very basic attempt at level generation. All it does is stamp boxes into a grid map randomly, with no logic. It then tries to create corridors to connect up all of the room, simply by tunnelling through from one box until it reaches another. After that it cycles through the tile and creates doors in places where there are two tile between walls.

It doesn't do the interesting things yet, like place mob, item, treasure etc. Also I'm planning on using a tile editor programme to create a load of bespoke rooms with interesting layout which will then be randomly place. Still, I'm quietly happy with it so far and I'm hoping I can add to it and make something that can create genuinely cool dungeon layouts..

Give it a play, though be warned that it's all brute force computing, completely non optimized, so if you choose a huge map with lots of small boxes it may take a long time to finish. (the text on the top left is actually a button)

Thursday, August 30, 2012

Why I'm cutting random out of my game's combat.

Roguelikes are built on the good old random numbers generator. It runs from the level generation all the way to the combat and loot. The levels are randomly generated, the monsters are randomly spawned and then when you fight them the damage and whether you hit or miss is often worked out by the equivalent of rolling a dice.

My view is that some of the randomness is really cool, and it's a large part of what make Roguelikes so interesting. It means every game is different and you'll never have the same encounter twice and it can add uncertainty to combat. I just think that for casual gamers it can be a negative experience especially when the dice roll against them several time in a row.

To give some examples:

  • In DCSS (Dungeon Crawl Stone Soup) every time you cast a spell you have a chance of spell failure, which you can reduce by increasing your skill levels or increase by wearing armour. It's obviously calculated using a random number generator. I had a slightly promising venom mage and he had a spell called Mephistic cloud, which produces a cloud of gas that confuses and damages enemies in an area. Due to it's difficulty and my skill level it had a failure rate of about 10%, so nine times out of ten I should have been able to cast correctly. Except the very nature of random numbers means that you'll always have spells where they go against you. In this case I came up against a group of orcs bunched up. It should have been fairly easy to have confused them then taken them out one by one with a different spell, except instead I miscast Mephistic cloud 3 times in a row. It meant they managed to reach me and a fighting retreat led to my death. What are the chances of that? 0.1%, in case you were wondering.
  • In Dungeons of Dredmor you can enchant your items on an square called the anvil of Krong. There's a 70% chance of a positive enchantment and 30% of a negative curse. I had a game where I had my items cursed 4 times in a row, making what was a fantastic item useless. You actually get an achievement for just 3 times.

In both cases it felt like my whole run was ruined by forces beyond my control. This isn't a fun experience and I think it's something that could really put off a casual player, or even someone who's simply new to the game. Don't get me wrong, I play table top games and I've lost them based on rolls of the dice. It's just it's one thing rolling triple ones in Risk and having a laugh with your friends at your bad luck. It's a whole other thing playing a single player game against a computer where you can't see the dice so you have a sneaking thought that maybe the computer just took offence at something you did in your last run.

This is why I'm removing most negative random effects from my games combat, and from the game in general

I still want there to be some randomness, so you players don't always know how an encounter will play out before it's happened, I'm just going to mostly keep it to cool 'lottery' abilities that help the player, with only a few minor negative effects that can happen against them. This means no spell failure, no missing your attack 5 times in a row, no enemies resisting you spells completely. I want the players to know that if they try something it will either work or not, and if it does how much effect it can have. If an enemy has a high resistance you'll just do less damage to them, but it will be broadly predictable with no wild fluctuations of fortune.

It also needs to be recognised that players remember the times where the dice went against them as 'the game screwed me', whilst when the rolls go in their favour they either take it for granted or think it's cool. I'm still going to keep some random stuff that work in the favour of the player, just not the other way round. The npcs aren't going to ragequit after the player crits them twice in a row whilst dodging their attack. Thie same can't be said of the other way around.

Friday, August 17, 2012

Warm toilet seats at the Centro Forum, Camden

I have a  memory of reading 'Boy', by Roald Dahl and there being a practise in in the posh boarding school he went to of the younger boys being forced to sit on the toilet seats to warm them up for the old boys. Well that's not needed here at the Centro Forum, part of the Centro Buldings group in Camden.

I really like the company I'm working for at the moment. The people are great and the work is interesting, even if it is AS2 (in 2012, I know!). However the office building is nothing short of a disgrace. Five floors with one incredibly slow lift that break down with worrying frequency. Four of those floors are occupied by tech companies, including the one I'm working for now. There are four toilets, 2 for the men, 2 for the very few women (fun fact, the room I'm in has about 40 mens and no women. tech companies, ya know), with 2 cubicles in each men's plus urinals.

The toilets have always been fairly inadequate and squalid, and it was a frequent occurrence to have to wait in the dingy, cramp toilets for a cubicle to become free. This became even worse earlier this year as there were a string of plumbing problems, leading to overflows, blocked and overflowing toilets and more queues.

I'm guessing, largely due to this the management started on refurbishing the toilets at the beginning of July. They closed one of the mens and one of the womens and began ripping them up, leaving only one toilet apiece for each sex. Cue queues.

Cue waiting outside the cubicle in July heat for someone to finish because you know that coming back later is pointless and it will be exactly the same. Cue coming in to sweaty, warm toilet seats and bundles of hand towels overspilling the bin because of the sheer amount of people using a toilet meant for a fraction usage. You even had people talking about going to the gym or  a restaurant at lunch because they need a shit.

This was supposed to last two week, then they would start on the other toilets. Instead it took them over a month.

They opened the new toilets at the start of August, and yes, they're much nicer. Dyson airblade dryer (there's something very amusing about watching people who don't know how to use these try to try their hands), huge extractor fans and a lighter decor. Yes, they did have a leak that closed them for a day almost immediately but that just seemed par for the course.

We're all now praying there won't be further breakdowns because they've close the other set of toilets to redo them. The new ones are being used almost continuously and there permanently someone stationed out the cubicles waiting to get in. The new toilet is more pleasant as a place to stand a read the web on your mobile while you wait but I don't think this is how it's meant to be.

The sad thing is that even when the other toilet is finished, and even if they've fixed the plumbing issue, the toilets will still be sadly inadequate for the numbers who work here, and the lift will need replacing at some point. this building just isn't fit for purpose.

Tuesday, August 14, 2012

Who's turn is it anyway?

I'm building a reasonably traditional Roguelike so it's going to be turn based. That sounds straightforward but there are different ways that turn based can go.

Different models

Player then mobs

This is probably the easiest way to go. The player takes their turn, be it movement or action, then the mobs or npcs take their turn.


  • This has the huge advantage that it's very straight forward for the player and easy to keep track of.
  • It makes AI pathfinding easier since the mobs always know where the player is when they move.
  • It gives the player an advantage over the mobs, since if they player can kill the mob in his turn, the mob won't have a turn to react, because it will be dead.


  • Difficult to simulate different speed of movement or attack, since it's very binary. Adding extra actions in a turn is hugely powerful and potentially game changing, as Baldur's gate/Icewind Dale players will remember when their fighters got multiple attacks per round.
  • If the player moves next to a mob one square away, since it's the mobs turn next the player will be attack with no chance to defend. This happens in Dredmor and it's very annoying. If a mob is one square away I find myself hitting space to wait a turn and let the mob come to me, which feels like cheesing.

Movement then action

First everyone moves, then they perform their actions.


  • Again fairly straightforward for the player.
  • Feels fairer than players then mobs.


  • Again can't simulate different speeds easily.
  • Slightly more complicated. Mobs don't where the player will be until he moves, so needs some logic. Ditto for players chasing a fleeing mob.
  • Possible for a character to make and action and die on the same turn.

Character speed based

The best example of this kind of system would probably be Final Fantasy. Imagine each character has an individual timer, and they can only perform and action when that timer finishes, then with each action it resets. Different characters have slower or faster timers to make different characters feel faster or slower.


  • The most flexible and the most 'realistic'. It means that you can have faster characters moving faster and attacking more often.
  • More avenues to build your character in different ways. Do you want a fast character and to use a kiting strategy or maybe a slow attack speed high damage build.
  • You could have different actions take different amounts of time, which could be part of their balance. For example spell which take longer to cast but are much more powerful.
  • Actually could be easier for pathfinding since instead of everyone moving at the same time there is a definite list of who moves when and only one character will move at a time.


  • A bit more difficult to understand for newer players, and even for for seasoned player might be more difficult to plan around. This could maybe be compensated for by having most characters in similar attack speed at the start and to ease the players into the concept.
  • Much more complex to implement, especially with many different mobs, all with potentially different speeds.
  • Balancing would be more difficult as speed is just another factor to consider. I dislike how in any turn based game with haste, haste always becomes the number one must have spell.
  • It slightly breaks the whole turn based thing. If a player can take more than one action a turn is each action a turn? What should I call it? What if I want to make a scoring element turn based?

My intentions

I would love to do the speed based. It just opens up so many different options for builds and abilities. I'm just worried that it's another layer of complexity on top of what is already a very complex project.

In the end I'm going to experiment with the movement then actions model, which feels nicer to me than player then mob. I'll see if I can get it to work well, then if I get problems I can fall back on the player then mob model.

Thursday, August 09, 2012

Features and creep

Given my time and resource limitations I’m going to have to try to be strict with myself as to what I’m trying to accomplish and what features I’m going to try to include.

One of the reasons my previous attempt at a roguelike stalled early on was because I tried to do too much. I was trying (and failing) to play Adom and I was really impressed by the open world feel of it, so also influenced by games like Baldur’s gate and Morrowind I tried to make an open world/dungeon crawling sandbox. Cue lots of bloated design documents and a model/data object directory with over one hundred different objects. It’s didn’t go very far.

To avoid this fate I’m going to try to keep a tight rein on the list of features I can support.

This is a list of some of the features I want to include in the game.
  • An easy to use, casual friendly interface. Gameplay should also be simple enough, at least initially for players who have never played a roguelike to understand and enjoy the game. This is the number one, non-negotiable feature.
  • A tutorial to get new users into the game.
  • No open world. It will be a pure dungeon crawling game, though I would like there to be some route branching.
  • Levels will be randomly generated, but I want to use several different methods to give different levels different feels.
  • Traps, chests, teleporters, switches, keys.
  • Auto explore. This could be a biggy, but I believe it will make a huge difference, especially in a mobile game.
  • Multiple different play styles and build paths possible, even if they’re just variations on the standard rogue/wizard/warrior builds.
  • Abilities that can reposition or add status effects to characters, to add tactical choice.
  • Card based abilities/stat system.
  • Tile based art. I’m thinking more DCSS than dredmor. I don’t have the time/funds to have animation but it has to be more immediate and intuitive than asci.
  • Cool items and equipment with different stats and abilities that make the players make a choice – no best items. Also some abilities target tiles with traps/status effect/dots etc. 
  • Only basic potions and scrolls – mostly ‘oh shit’ crutches.
  • Enough different monsters to be interesting and varied.
  • Monsters that don't either just come up to you and hit you, or stand back and shoot you.
  • Different damage types, with corresponding resistances and themes.
  • Must have some pathfinding, since it will be in effect mouse controlled.
  • Some kind of online scoreboard system.
  • No religions/races etc - another thing to balance and I'm already so low on time.
  • No crafting.
  • I would love to have multiple languages, so I'm going to try to build it in a way that would make this possible at some point without too much pain. I'm not planning on have more than English in my initial build though.
Actually, looking at all this, I'm clearly crazy. I probably can spend 2-3 months on this full time before I'm going to have to start whoring myself out for freelance work, and this is a list that I wouldn't feel comfortable promising a client given double that time. When you add to the fact that I haven't done much mobile work before and time for testing/balancing etc I'm going to have to cut this all down drastically.

I think what I'll do it carry on with my spare time planning and groundwork so that when my contract finishes and I start on it full time I have a running start, then see how I'm doing 4-6 weeks in. Then I can make some difficult choices and try cut it down to something I can actually finish. 

I hope.

Sunday, August 05, 2012

What kind of Roguelike am I trying to make?

And who is my target audience?

In my 'what is a Roguelike?' post I briefly wrote about the different types of Roguelikes there are. More or less I am aiming to make a fairly traditional Roguelike. A turn based dungeon crawling rpg with experience and character progression.

In terms of how hardcore and complicated it is my decision was probably made as soon as I decided I wanted to make it easily portable to mobile. Making a game playable on mobile means no keyboard commands and much smaller screen space for information, feedback and controls. This means for it to function the game needs to be relatively simple, and that pretty much rules out a super-complex hardcore Roguelike, which to be honest is probably a good thing anyway since I don't think I would have the time or resources to build something like that anyway.

This all lead to the fact that I'm looking to make a decidedly casual Roguelike. By this I don't mean something dumb or with no depth - it's definitely got to have more to it than your standard bump to attack 7 day rogue. I just mean that you have to be able to play it without reading a manual, and all the stats and information you need to be able to understand it need to be accessible within one click, or two clicks if it's not core information.

I also want there to be more instant gratification, from items and increase in power, than in most Roguelikes. I want players to think 'Wow loot!' and 'Ding!, level up!' and for it to be exciting and really cool, something that doesn't happen so much in a lot of traditional Roguelikes, which tend to have flatter power progression. This is great for getting people initially hooked on your game but could have implications later on for the longevity of the game. We'll see how it goes.

So, the answer is that I'm making a casual, small to mideium size, high power curve Roguelike without the complex systems seen in many games, and with a simple, easy to use interface.

This will almost certainly alienate some hardcore players who are looking for something deeper, but the success of casual Roguelikes like Dredmor, 100 Rogues and Cardinal Quest show that there are enough casual players to make up for it. As long as you make something good.

The answer to who my target audience is, is someone who enjoys classic Roguelikes but who sometimes finds them often overly obscure and difficult to play. Someone who loves games like BG, FF and Diablo, plus fast paced combat and strategy focused games like League of Legends and DOTA. Basically, my target audience is me, and if I can make a game that I enjoy I'll be happy, and I'm sure lots of other people will enjoy it too.

Wednesday, August 01, 2012

Why I'm doing it in Flash

I'm planning on creating the whole game using Adobe Flash, with the mobile versions being publish with Air. I may even do a downloadable desktop version, also using air.

I would be lying if I didn't admit that a major reason I'm using Flash is because I'm a professional Flash developer, so AS3 is a language I'm completely comfortable with. I know that I can build complex engines with it and I know it can take it.

The other reason is that I'm using Flash, and a reason why I personally think Flash it one of the best choices for building apps, is that I can produce an android, ios, web and desktop version with the same unified codebase. I'll obviously have to do some different UIs for the mobile vs the normal size version, but hopefully nothing too onerous as long as I enforce some strict apis. For me this is a huge deal. Even if I spent the time learning objective C or java, like lots of people have suggested I should 'for when Flash dies' there's no way I'd be able to do multiple versions in different languages. Flash means that for the main game elements I can develop for the flash version then just rebuild the other version without having to worry about getting all the changes carried over, because there will only be one codebase.

The only thing that remotely worries me about doing the game in Flash is the saving the game aspect. In theory it should be easy - I can use sharedObject, which should be able to save whole complex data objects. In practise in a previous project I've found sharedObject to not be %100 reliable. I managed to fix that issue by converting everything to primitive data type before the save, then back again, but it's not something I want to do if I can help it, and I'm hoping the issue has been fixed (it was infrequent enough it may have just been one flash player build.)

I briefly toyed with the idea of learning, then doing the it using HaXeNME, but in the end I decided I'm probably already biting off more than I can chew, so best not compound it by adding in a new language, especially one that's so niche and new. If I run into problems I'd be worried about finding answered, and anyway I don't see myself getting more work on the basis of knowing it.

Monday, July 30, 2012

Why am I writing this blog?

4 main reasons:

To solidify my thoughts.

I’m having trouble ironing out some of my systems/ideas and putting them down in blog posts is a way of getting them in order and to sort them out without actually having to do the huge step of actually putting them into the game and making them work. I find it’s also good to just write down your reasoning for your decision to be able to look at them from afar. I find this is even more important if you’re looking at them from more than a week or so’s time difference.

Improve my communication skill.

I don’t do much writing and if I am genuine in my desire to move away from the Just A Programmer thing I do need to improve my ability to communicate. Writing more is a very good way to do this and I’m hoping I can clearly communicate what I’m trying to do and why I’m making the decisions I make.


At the moment literally no one reads this blog. That’s cool. It’s not something I’ve put any time into and I don’t regard it as an avenue to get work or talk to clients. However if I am serious about trying to make an indie game and actually do something with it I need somewhere to talk about it and make announcements, etc. Once I decide on a name I’ll probably create a site, but it will link to this blog and this will be where the major info goes out. (unless at some point it’s not). I’m also going to have to start actually using my Twitter account, though I’m sceptical about whether I’ll have anything interesting to say.

I also think that if I’m even mildly successful there will be people interested in my creative process and thinking. One thing I’ve learnt is that no matter how bad your game is there will still be someone who thinks it’s amazing, gets obsessed and spends hours playing it. If this is you, ‘Hi!’.

To make it more difficult to quit, then skulk away

In a similar way that getting up in front of all your family and friends and proclaiming your love for someone makes it less likely you’ll split up when the going gets tough, I’m hoping writing a public account of what I’m doing will make it more difficult for me to just quit and go and do something else. This blog is like marrying my roguelike, even if to carry on the metaphor, at moment no one has shown up for my wedding and I’m going to have to pressgang/hire some people off of the street to be my witnesses.

Wednesday, July 25, 2012

What am I hoping to get out of it?

What I would love is that in the end I’ll have a great game that is good enough for me to be able to charge for on the app store/google play, and that will sell enough copies to justify me taking a few months out from contracting. I'd quite like to look into trying out some form of micro payments if I don't charge for the app, so some sale that way if I do this would be nice.

This may be unrealistic so I’d like at least to have a finished, decent game that works, and that I can put out on google play as a free download, and that it will interest a few people, and a flash version that will get some portal interest.

It’s important for me to get the mobile app version because this is an area I can see a lot of on-going growth, and an area I don’t have any experience in. I want something that I can show prospective clients that will make them think ‘this is someone who knows how to code and design for mobile’. The market for browser focused flash is still pretty good but the writing is on the wall and I realise I’m going to have to move onto something else. I've had a few recruiter ask for people with mobile experience, so hopefully getting some mobile stuff under my belt will help me get work. If I can see this through I'll definitely learn some new skills and get some better perspective on mobile/game design.

If it’s even mildly successful I’d like to leverage that to get more indie game work with less of the boring ‘pays the bill’ work I seem to end up doing so much work of these days. Maybe even some pure games design work. Wannabe games designer are 10 a penny, people with finished products under their belt are much rarer.

Sunday, July 22, 2012

Why a roguelike?

Why am I making a Roguelike game, as opposed to some other type of game?
  • I really like roguelikes. This in itself is halfway to being a good enough reason to do one. 
  • I’ve wanted to do a roguelike for a long time. I have the beginnings of one that I started >5 years ago sitting on my computer so I don’ t have to start from scratch.
  • As I said I want to do something that will work on a mobile and a roguelike is ideally suited to playing on a mobile device since it’s turn based and therefore can be paused/restarted at any point. Since having a baby I've become a big fan of games that you can turn off immediately without losing any progress.
  • Roguelikes are generally very data/code heavy with minimal art and animation, and that means I can do most of it myself. I’m not bad at design and fairly decent at art but my core is the coding, and I’d like to think game design. This means I can concentrate on what I’m good at. I want to do it in Flash as an air for mobile app. Air seems to work pretty well even on low-mid range smart phones but it’s worth planning something that’s not going to be too graphically intensive.
  • There are several big communities of people making Roguelikes, so there are lots of resources I can access for help and in some situation for actually code for specific problems.
  • Roguelike have some really, really interesting decisions to make, and I have some of what I think are great and new ideas that I haven’t seen before in the genre. I think I have something to add.
  • There's lots of things you need to do for a roguelike that have use in other game types, so it will be nice to get a version working and to understand them. I think I'll learn a lot! Examples: pathfinding, level generation, line fo sight, ai.

Saturday, July 21, 2012

What is a roguelike?

Wikipedia says ‘The roguelike is a sub-genre of role-playing video games, characterized by level randomization, permanent death, and turn-based movement. Most roguelikes feature ASCII graphics, with newer ones increasingly offering tile-based graphics. Games are typically dungeon crawls, with many monsters, items, and environmental features. Computer roguelikes usually employ the majority of the keyboard to facilitate interaction with items and the environment. The name of the genre comes from the 1980 game Rogue.’

There are Roguelikes in many different genres, from fantasy to sci-fi to crime and realism, though fantasy is by far the most common. I toyed with the idea of doing a space marine themed game, but in the end decided on fantasy, largely because I want to make a big deal out of magic and that makes more sense in a fantasy setting. I was also told that there is a bigger audience for fantasy than for sci-fi games.

Frequently all it takes is for a game to have one or two aspects for people to call it a roguelike. I’ve heard Terraria, The Binding of Isaac and Diablo called roguelikes because they  feature randomly generated levels with at least the the option of permadeath. I guess this would mean that my really old (AS1!) game Doomed could be considered a Roguelike since it plays like a low rent version of binding of Isaac.

My game Doomed has randomly generated levels, character progression and one life.
It's a Roguelike!

For me the critical aspects are the randomized, tile based levels, the turn based gameplay, the character progression and the permanent death. I’m not going to have asci art, though my art will be functional and it’s got to be entirely mouse driven, since it has to go on mobile which has no keyboard.

Thursday, July 19, 2012

My Roguelike indie project

I’m a flash developer with more than 10 years experience making web games and other rich web application type stuff. Previously I’ve been able to find time to create my own games in my spare time but in the last couple of years I’ve been too busy to do my own stuff, due to work/family commitment, plus also playing too many games when I do have free time.

This has meant that more and more I feel like I’m being defined by what I do for my job, and though I do get the occasional games project where I get to exercise some creativity I’m increasingly finding myself doing jobs where I am Just A Programmer. It’s kind of depressing, and also it leads onto more of the same dull technical work.

I know quite a few people who are doing indie games and it just seems much more interesting a fulfilling and long term I really, really want to move in that direction. I just need to find the time to do some of my own work and the mental toughness to turn down freelance work when it gets offered. As much as now may not be a good time, what with a new baby and the expense of living in London, I’m can't see when there ever will be a good time, short of winning the lottery, and I’ve been putting it off for years. I’m allowing myself to coast until my current contract finishes, trying to do some groundwork in my meagre spare time, then I’m hoping to take 1-2 months off to try to get something done, with more time allowed if what I’m doing is promising.

I’ve been weighing up which project to go forward with and I’ve decided to go with a Roguelike, specifically one tailored to mobile devices using Abode Air to publish it. I’m also planning on doing a cut down pure flash version for the web, mostly to try to drive traffic to the app versions.