Showing posts with label game design. Show all posts
Showing posts with label game design. Show all posts

Saturday, March 11, 2017

Presents Panic Unity 1 - Project plan

I have been trying to decide what to do as my next project. As tempted as I am to use libgdx or Haxe I have found that when looking at my CV rather than saying 'wow, this guys has lots of finished projects in multiple different engines/languages' potential employers say 'bah, I want someone with lots of experience in the one I am using'. Unfortunately apart from Flash that's not something I have and I am not comfortable with blagging. It seems Unity is a good way forward so I have decided to do another Unity project. I want it to be a small project so I will just port another of my old Flash games that I think will work well on mobile.

The game that I have decided on is Presents Panics, a game I created about 10 years ago as a mash up of Tetris, Super puzzle fighter and Same Game. At the time I really liked the game - it has depth and multiple ways you can play and win.

Of course the game has issues and it didn't set the world alight when I originally released it. I am hoping that I can keep what I view as the original game's strengths but fix or at least smooth over the problems it had. In my view the two main problems it had were the controls and the progression.

The controls: In the original version the game used both the keyboards and the mouse. The keyboard to move and rotate the pieces and the mouse to remove them once they had settled in blocks. Obviously as the creator I had gotten used to this and had no problems with them but new players often didn't understand or like them. Since I don't have access to a keyboard on a mobile I couldn't keep the old controls even if I wanted to. I will experiment once I have something running but I think it will work well with swipe to move, tap to rotate or explode. It will be simpler and more intuitive, I hope. Of course until I have a version up and running it's hard to say for sure.

The progression: The original game goes for a very Tetris style progression. You play until you lose with the game gradually getting faster and harder, whilst the score multiplier increases. It's pretty basic and unsatisfying. There are no concrete challenges and it ends up feeling like a slog. It's not just of it's time, it's of 10 years earlier and when you compare it to the scientifically engineered addictiveness of something like Candy Crush it feel positively stone age. I am not sure what I will do here, I just know that I need to do something. Some ideas I have:
  • Have discreet levels with a score players need to reach and a limit on the number of presents they get to reach the score. Maybe  predefined starting presents already present.
  • Change the number of blocks sent down from 4 in an L shape to just 2. This would mean that if I could make sure that you always get on colours present the level should always be clearable. this might make it too easy though. This would open up the types of game mode available - I haven't player Dr Mario in 15 years but I think this is close to what they do.
  • Bombs and other power ups that destroy rows and columns. Spawned when you destroy larger presents.
  • Still have a 'rush' mode that is like the old one.
  • I could go full candy and have a currency that you collect in games that you can spend on boosts/power ups.
  • Make it less Tetris twitchy and more of a strategy game. This would mean that instead of speeding it up I would give the players less blocks to achieve the objectives so you feel like it's about planning rather than just being fast.
The only other question I'm asking myself is, should I bother? I have no illusions on whether this will be popular or successful. It won't be no matter what I do unless I am willing to spend some serious time/effort on both the polish and on marketing/pr and even then I don't think it has enough to it for it to be successful. I have to look at it as being 90% a portfolio piece so maybe I should just bog a fairly bog standard version with limited additions.

The other remaining questions is how much effort I am going to expend in trying to monetise the game. I feel like if it's going to be a portfolio piece it needs to look and feel like a real pro game and that will mean extras, though probably not iaps. In the end I will probably just stick some ads and maybe if I do boosts I will offer them for reward ads. It has to be easy and quick. 

I have all the assets, though they will need some work to export them for unity. I will need to redo the ui as the aspect ratio has changed and I want it to look more sparkly. I am hoping to complete the project working part time in 4-5 weeks. If it takes longer I won't mind too much if it genuinely improves it.

Thursday, October 18, 2012

Actions

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

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

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.

Waiting.

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.



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

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.

Counterattack

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.

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.

Pros


  • 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.

Cons

  • 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.

Pros

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

Cons

  • 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.

Pros

  • 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.

Cons

  • 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.

Friday, August 28, 2009

Bug Squad post mortem




I made and release this game a month ago, but I've only just had time to write it up here.

It all started about 4-5 months ago when there was the first swine flu scare. I had an idea for a dumb game about shooting pigs and got it as far as being able to shoot circles with other circles. I then got a contract and forgot about it. After that was finished I had a bit of time off and finished it off. I decided to keep it as a dumb game about shooting pigs and concentrate my engergies on the production values.

I think I succeeded in making a game that looks really nice and has rocking music, but I'm not so happy with the gameplay. It works to a point, but I think that I may have over-simplified it. I was aiming for a combo building high-score game and it's works as that, to a point. The mistake I made was than I didn't make it short and snappy enough (check out Boomshine for a good example of this) to work as this type of game. Also it has a huge problem in that if you don't go for the combos it's possible to survive for a really long time just by being click happy, but that if you do this it's a fairly boring game.


I did put it on the forums at flashgame license and I got some good feedback, but no-one picked up on the last point, and I was too close to the game to see it myself. I only realised after the game had been released when I was showing it to my family, and I actually got to watch them play. I'm absolutely gutted about that because it would have been fairly simple to have cut down the shot speed and thereby eliminate this as a viable mode of play. This just shows the huge limits of bedroom development. I'll have to make sure I can watch people play any subsequent games before putting them out.

Given it's drawbacks I can see now why I was unable to get what I would consider a decent payment for the sponsorship, and I'll just have to take it on the chin a try to learn the lesson for my future projects.