My goodness, the last post was in April. How lazy I've been.
In my defence, quite a lot has happened since then. In May I started the full-time crunch/panic appropriate for the end of my degree (actually that started quite a bit earlier, but playing games and writing about them is a pleasant form of procrastination), and then in June I got married. July was mostly spent on my honeymoon, and now August has passed while I sit at my desk, calling strangers and asking them for a job (or rather, another job; I've been employed for the last two years as a writer/editor/VBA developer by a law-publishing firm but it's getting rather dull now). However, I have not been completely idle.
For example, this blog now has more draft posts than published ones. Why? As usual, there's someone who can explain that better than I can:
Anyway, I've been dallying with the idea of working all these little problem-solving exercises into full posts, but I can't quite bring myself to do it—partly because it would represent hard work, to which I am ideologically opposed, and partly because in hindsight the solutions are so obvious that I'd feel like a right muppet admitting that I'd had to think about them at all. On the other hand, it may well be that there are some people out there as stupid as I am (unlikely but theoretically possible), and so someone, somewhere might gain some small benefit from my conclusions. As a compromise between dignity and mistaken do-goodery, I'll make mini versions of each post, summarising the problem and my particular solution. Two will do for now and future ones may get their own posts. Enough waffling.
Aspect Ratios
Problem: Not everyone's PC monitor has the same aspect ratio. Most (players) have 16:9, but many still have 4:3 or others. The usual solution to this, at least with FPSs and similar, is to make exactly the same game but reduce the field-of-view or camera angle for the narrower screens, reducing the amount that you can see on the screen at once. My game is a top-down turn-based team-strategy affair, and I want the entire arena to be visible on-screen at once without having to scroll/zoom, so this camera-based approach isn't going to work.
Solution: Do a Hearthstone and build the arena and UI for 4:3, shoving a few extra strips in on the side in lieu of black-band-letterboxes for 16:9.
Note: While this is more-or-less the only solution given my self-set constraints, it does raise further problems. For example, when designing for 16:9 I had originally intended for the arena to be 'square' (or rather, a regular hexagon) and completely symmetrical, with a vertical panel to the side for the UI. However, in 4:3 this panel-on-the-side is ridiculously slim and feels rather difficult to use (I wonder if Japanese players, more accustomed to up-down text than their Western left-right counterparts, would find this easier to use?) and so a different approach is called for. The arena is no longer perfectly symmetrical and is now wider than it is high, with the saved height going towards a new UI panel along the bottom.
While having a wider, shorter game area may not appear to be much of a change compared to a round one, it does make a difference when it comes to things like the range of abilities and mechanics such as kiting. After all, an ability that can only reach a small way horizontally across the board could cover most of it vertically, making it much more powerful than it would be in a regular hexagon. I bring this up as an example of how even quite mundane, pragmatic aspects of design, based purely on necessity, can have an effect on balance. See also: hitscan v projectile weapons and how servers deal with them in multiplayer shooters.
Skill Trees
Problem: Ensuring a high degree of player choice while not requiring all abilities/talents to have equivalent power levels. This is a topic that could easily fill a whole post on its own so I'll keep the explanation brief. I'm going to assume that you all know what skill trees are, because you're reading a blog about game development. For those who don't, they're things like this (that's an old WoW talent tree); a system whereby players can spend points that they've earned over time in order to improve their abilities or learn new ones. There are three main ways of doing this (that I can think of):
In my defence, quite a lot has happened since then. In May I started the full-time crunch/panic appropriate for the end of my degree (actually that started quite a bit earlier, but playing games and writing about them is a pleasant form of procrastination), and then in June I got married. July was mostly spent on my honeymoon, and now August has passed while I sit at my desk, calling strangers and asking them for a job (or rather, another job; I've been employed for the last two years as a writer/editor/VBA developer by a law-publishing firm but it's getting rather dull now). However, I have not been completely idle.
For example, this blog now has more draft posts than published ones. Why? As usual, there's someone who can explain that better than I can:
‘My problem is that I’ve now reached the stage where I really can’t work out what I think unless I write it out; the process of writing is now so intimately connected to my broader processes of cognition and judgement that I can’t really do without it. I’ve got those writerly blue-on-blue eyes now, and without my regular doses of ecriture ‘Melange’ I’d be in a parlous state’ - Adam RobertsIn short, I've been writing posts to work through various game design problems and then, having reached a conclusion in my head, gone away and implemented that solution without writing the rest of it down. Without the need to work through an argument on paper/screen, the post withers and dies like the grass and the flowers that fade, while the word of the LORD stands eternal. Sorry, not sure what happened there.
Anyway, I've been dallying with the idea of working all these little problem-solving exercises into full posts, but I can't quite bring myself to do it—partly because it would represent hard work, to which I am ideologically opposed, and partly because in hindsight the solutions are so obvious that I'd feel like a right muppet admitting that I'd had to think about them at all. On the other hand, it may well be that there are some people out there as stupid as I am (unlikely but theoretically possible), and so someone, somewhere might gain some small benefit from my conclusions. As a compromise between dignity and mistaken do-goodery, I'll make mini versions of each post, summarising the problem and my particular solution. Two will do for now and future ones may get their own posts. Enough waffling.
Aspect Ratios
Problem: Not everyone's PC monitor has the same aspect ratio. Most (players) have 16:9, but many still have 4:3 or others. The usual solution to this, at least with FPSs and similar, is to make exactly the same game but reduce the field-of-view or camera angle for the narrower screens, reducing the amount that you can see on the screen at once. My game is a top-down turn-based team-strategy affair, and I want the entire arena to be visible on-screen at once without having to scroll/zoom, so this camera-based approach isn't going to work.
Solution: Do a Hearthstone and build the arena and UI for 4:3, shoving a few extra strips in on the side in lieu of black-band-letterboxes for 16:9.
Note: While this is more-or-less the only solution given my self-set constraints, it does raise further problems. For example, when designing for 16:9 I had originally intended for the arena to be 'square' (or rather, a regular hexagon) and completely symmetrical, with a vertical panel to the side for the UI. However, in 4:3 this panel-on-the-side is ridiculously slim and feels rather difficult to use (I wonder if Japanese players, more accustomed to up-down text than their Western left-right counterparts, would find this easier to use?) and so a different approach is called for. The arena is no longer perfectly symmetrical and is now wider than it is high, with the saved height going towards a new UI panel along the bottom.
 |
| On the left, the old 16:9 design; on the right, the new 4:3 with a squatter hexagon and more wasted space. Can you tell I got a first in my Technical Drawing classes? |
Skill Trees
Problem: Ensuring a high degree of player choice while not requiring all abilities/talents to have equivalent power levels. This is a topic that could easily fill a whole post on its own so I'll keep the explanation brief. I'm going to assume that you all know what skill trees are, because you're reading a blog about game development. For those who don't, they're things like this (that's an old WoW talent tree); a system whereby players can spend points that they've earned over time in order to improve their abilities or learn new ones. There are three main ways of doing this (that I can think of):
- List. Simply present a list of all the abilities to the players and let them choose which they'd like. Not many games have this; Divinity: Original Sin has something similar with their perks and Wildstar with its abilities.
- Categories. Allow the player to choose one or more abilities within certain categories. An example would be the current WoW talent system, in which one ability can be taken per tier. The same principles are in play in more-or-less every shooter with a loadout system (you can carry one rifle, one pistol, one grenade, for example).
- Trees. This is by far the most commonly used system; the aforementioned example is directly descended from Diablo II, which introduced skill trees to non-RTS gaming. Here, ability choice is limited by what abilities have previously been taken, with various dependencies required for certain choices (for example, to unlock ability B you must first have taken ability A, or have spent a certain number of points on abilities in a certain category).
The trade-offs in all these systems are player choice and balance—or rather, between player choice and how easy it is for the developers to balance the game. The list system gives the player the greatest choice but is difficult for the developer, because it requires that all the abilities have roughly equivalent power (if there are abilities that are noticeably more powerful with no downside then players are obviously going to choose them). While this kind of internal balance can often be enforced by fiddling the numbers - increasing cooldowns and reducing damage, etc. - doing so runs the risk of producing rather bland abilities. Furthermore, the developer must also make sure that the various combinations of abilities are balanced, a difficult task considering that the list system allows the player to create a dizzying number of combinations (that's the downside of 'emergent gameplay' - it's rather difficult to balance something you haven't thought of).
The tree system solves this problem by providing a source of external balance - having some extra-powerful abilities in there is fine because players will only be able to choose a limited number of them. The problem of excessive combinations for the developer to balance is also reduced, as the specialisation required of the player to access the most powerful abilities means that the combinations become more of 'variations on a theme' instead of unique compositions. If that sounds like a downside, that's because it is: the problem of so-called 'cookie-cutter' talent choices will be familiar to any TBC/WotLK era WoW players. While the trees above appear to offer hundreds - thousands - of ways to invest the 60-odd points on offer, the reality is that the requirement to specialise and invest a certain number of points per tier to access the mandatory powerful abilities means that the number of actual choices is much lower, and the number of meaningful choices (i.e. options that aren't Wand Specialization) is lower still. In short, tree systems can make it too easy for the player to calculate the 'optimal' solution and then stick with it to the detriment of diversity.
The slot system goes some way to solving this problem: while the total number of choices is much lower than that provided by a tree system, the number of meaningful choices is potentially much higher. In the screenshot above the player can only pick one talent per row, with the rows sorted by 'type' of ability - the first row is a mobility option, the second a damage reduction, the third a control, and so on. The abilities don't synergize particularly well, meaning that 'optimal' decisions don't emerge as readily: whether you've taken Presence of Mind or Blazing Speed or Ice Floes doesn't really affect your decision on whether to take Temporal Shield or Flameglow or Ice Barrier. Of course, this is also a disadvantage - if all the choices are equally valid and don't impact each other then what's the point of having them? Also, the layering of abilities by type reduces player choice fairly dramatically - while it makes it 'idiot proof' in the sense that it's impossible to construct a truly useless build, it also means that players are restricted to a pre-set template of how they 'should' play (if I want to shun all survival options in order to maximize damage, for example, I should be able to).
Solution: What should be obvious from this rather lengthy explanation is that there's no obviously 'right' option in the same way as there was for the aspect ratio problem. Each option has its own advantages and disadvantages and strikes a different balance between player choice and ease of balance. Currently I'm favouring the list solution as it grants the player the most freedom, and trying to impose some level of external balance upon it by pricing each of the options - effectively creating a tree system but without any specialisations or dependencies. This seems to work fairly well, as it creates a nice balance between power and flexibility; players can choose only the powerful abilities, sinking all their points into a small number of options, or they can choose to diversify and pick a larger number of cheaper abilities. The downside to this approach is that it requires the number of abilities a player has access to to be flexible, but that's a coding rather than a balance issue.
Ok, that was rather longer than I intended, but hopefully it gives you some idea of the design process. There's quite a fun little problem involving Spell Reflect I'll probably cover next.
~Roxton.
P.S. My aim from now on is to do a weekly update (regularity being much more important than flexibility) every Saturday morning. I don't know if I'll be able to stick to it, but hopefully saying it will make it so.
Solution: What should be obvious from this rather lengthy explanation is that there's no obviously 'right' option in the same way as there was for the aspect ratio problem. Each option has its own advantages and disadvantages and strikes a different balance between player choice and ease of balance. Currently I'm favouring the list solution as it grants the player the most freedom, and trying to impose some level of external balance upon it by pricing each of the options - effectively creating a tree system but without any specialisations or dependencies. This seems to work fairly well, as it creates a nice balance between power and flexibility; players can choose only the powerful abilities, sinking all their points into a small number of options, or they can choose to diversify and pick a larger number of cheaper abilities. The downside to this approach is that it requires the number of abilities a player has access to to be flexible, but that's a coding rather than a balance issue.
Ok, that was rather longer than I intended, but hopefully it gives you some idea of the design process. There's quite a fun little problem involving Spell Reflect I'll probably cover next.
~Roxton.
P.S. My aim from now on is to do a weekly update (regularity being much more important than flexibility) every Saturday morning. I don't know if I'll be able to stick to it, but hopefully saying it will make it so.
No comments:
Post a Comment