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.

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.

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.

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.

Publicity

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.

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.

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.

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.

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.