Showing posts with label Mechanics. Show all posts
Showing posts with label Mechanics. Show all posts

Friday, 5 September 2014

Back to Work: Aspect Ratios and Talent Trees

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:
‘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 Roberts
In 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.

Tuesday, 13 December 2011

Aggro-vation

While my (as yet untitled) game is designed largely with PvP in mind, I do want there to be a single-player campaign, and a good one too; not some MW3 rubbish. AI in general is probably too broad a topic for this post, so I'd just like to focus on aggro; that is, how, and more importantly when enemies react to the presence of the player.

There are a number of different options available. The simplest of these, which can be seen in a huge number of games from the creeps in LoL to absolutely everything in Skyrim is attack-on-sight: the mob sees the player, and attacks it. There may be cases where it is slightly modified; for example, there may be a range check, or a timer triggered allowing the player to back away before a confrontation is initiated. This is the system used in the majority of FPS titles, and it works fairly well. It's also extremely easy to implement. The only major problem with it occurs when you introduce multiplayer elements to the mix. When a wolf sees two players charging up fireballs at it, which does it attack?

One solution to this problem, which will be extremely well-known to players of pretty much any MMORPG, is the implementation of a threat system, with the mob in question attacking the player with the highest threat. Threat isn't normally linked straight to damage, though of course there is a damage component; often different attacks or types of attacks will cause more or less threat, and some classes or players will have talents or items or whatnot that increase or decrease the threat they generate. This system tends to produce tank-type roles, and while it works relatively well in an MMO setting, I have a number of problems with it. First of all, it produces tank-type roles, and I hate tanks. I really do. They're boring and uninteresting and horrible to balance, and while I'll admit that they have a kind of a place in PvP, I wish they didn't. So that's one reason. The others are perhaps more rational: a threat system is a large and complicated addition to the game; I don't plan on having a class-system, and certainly not a tank-type role; and even if you did want to make a tank, this is a game about spell-casters, and I have no plans for a melee combat system for the player.

So how else could a mob choose between targets? Well, it could be based on some basic AI - always attack the weakest player first, for example, or maybe just target the closer player. Both of these have some merit, but again, I have problems with them. Targeting the weaker player first is likely to result in one player always being targeted and having to run away while the other does all the work, and that's boring for both players. A similar problem is going to arise with targeting the closest player; while this is perhaps the most intelligent thing to do, it is going to mean that one player becomes a tank.

At this point we're running out of options a little, but there's one left: target whoever hit the mob last. Now, at first glance this may appear to be the most ridiculous option thus far, because the mob is going to end up spinning round and round in between two players who are exploiting this for all it's worth. However, to my mind this is exactly what should happen. This is a game where all the players are casters; fragile and unsuited to taking heavy blows to the face. The usual method of combat for a single player will be kiting and avoiding damage rather than healing through it or soaking it up. With two or more players, careful timing and disorienting the mob will be a way of keeping it at bay without requiring a tank or a dedicated healer. And it will require skill. Everything in this game is a skill-shot; spamming spells is generally inferior to taking the time to line up a good one; and there is full friendly fire. Provided that the last-hitting target is only decided by direct attacks, and not DoTs or lingering AoE attacks, I think that this could be a viable alternative to the more commonly used methods. I'll let you know how it goes.

~Roxton.