Lork

Phaedrus' Street Crew
  • Content count

    180
  • Joined

  • Last visited

About Lork

  • Rank
    FBI Special Agent

Contact Methods

  • Website URL
    http://www.justicem.com

Converted

  • Location
    Francis Lork Morgan
  1. Axon Devlog

    It's been a while, huh? If you look at the dates of these posts you might get the idea that rewriting the AI turned into a huge boondoggle, but I'm happy to report that's not the case. The most time consuming part actually ended up being fixing some mostly unrelated issues with the pathfinding library I'm using that exposed themselves in response to me paying closer attention to Sapients, but even that wasn't an excessive amount of work. Instead, most of the blame can be placed on some stuff related to my day job as well as a need to take a bit of a break after a prolonged period of intense productivity. Anyway, AI planning algorithms, right? The one I ended up settling on is called "Utility AI". The way it works on the most basic level is that you take every potential action the AI could take and give it a score based on the current circumstances, then choose the highest scoring action to perform next. That's it. Seems really straightforward, almost obvious, right? But that's a big part of why it's such a good choice - it's dead simple in concept and execution, which means I have no trouble at all understanding the entire system inside and out - if you'll recall, one of the things I wanted to avoid was creating an opaque system that obfuscates the relationship between cause and effect. Perhaps more importantly though, Utility is what's described by AI professionals as a "Designer focused AI". In the previous post I mentioned that even with a system like GOAP, the thing that's ultimately running the show is all that necessary designer supplied logic determining which actions should be performed and when - Utility is entirely focused on leveraging that designer logic as efficiently as possible, with nothing else to get in the way. The really beautiful thing about it is the way it separates that designer logic into manageable chunks. Every behavior is its own self contained little kingdom which can decide for itself how desirable it should be at any particular moment without needing to even consider any of the other actions it's competing with. As such, you can add as many new behaviors as you want and it'll have little to no effect on the overall complexity of the system. The importance of this can't be overstated! The reason why I'm able to have so many Primitive attacks is that the pipeline I've set up for creating them is very streamlined, making it as easy as possible to go from having an idea to implementing it in the game. While working on Sapients I've often thought "Gee, I wish working on this could be more like working on Primitives..." Well, the pipeline afforded by Utility is as close as it's ever going to get. So after implementing the system and porting over the logic for all the existing behaviors, all of which took no time at all, I went about cooking up some new things for Sapients to do (incidentally, coming up with new things for enemies to do is the most fun part of making a video game): The player is periodically supplied with "Recovery Pillars" which can be used to restore health, so wouldn't it be delightfully devious if Sapients could use them too? One my goals with Sapients is to create a diverse cast of enemy types, rendered recognizably distinct by their behaviors and their selective use of the weapons, skills and abilities available to the player, so to get the ball rolling I made a 'Support' class that can provide protection and healing to their allies and gave the existing 'Assault' class use of the Grenade Ability, providing some nice opportunities for teamwork: I also made good on my idea to have multiple 'classes' use the same Ability to different ends. Here's a 'Sniper' class using the Boost Ability to get away from the player: And here's a 'Berserker' class using it offensively: Needless to say, I'm very happy with the way this all turned out.
  2. Axon Devlog

    When creating Sapients, I thought a lot about how to create a compelling "human like" enemy in a shooter. This is of course a very well worn topic with more food for thought than any one person could possibly ingest, but there are certain patterns to the discourse. The most common narrative among consumers is that "good AI" is the result of advanced decision making algorithms with names like Goal Oriented Action Planning (FEAR is always the most cited game) or Hierarchical Task Networks, and the reason why we hardly ever see it is that those Lazy Devs are unwilling to invest in these technologies, or would rather use the CPU time for graphical bells and whistles (clearly they must be big CPU hogs since they're so advanced!) The logic determining which action an AI opponent should take and when is the most analogous part to what we conceive of as a mind, so it's very natural for us to attribute any "intelligent" behavior that we perceive to it, especially when the developer gives it a fancy name and cites it as the reason why their AI is going to be better than all the rest. I think of this as a sort anthropomorphism of game AI - it's something that's actually very desirable; of course as a developer you want players to imagine they're playing against an entity that is actively thinking and planning clever strategies of its own accord whether those concepts map coherently to what's actually going on or not. However, you wouldn't want your judgement clouded by such a notion when it comes time to develop a game yourself. The basis of my implied dismissal of these algorithms is simple: in every single case, what they're actually doing is using logic supplied by a designer (or an AI programmer taking on the role of one) to select from a list of predefined behaviors. Think of the last game you played with "dumb" or at the very least unremarkable AI. Was this lack of intelligence truly a result of the AI not doing a good job of choosing from its available options, or was it that none of the options available to the AI would've appeared intelligent to you in the first place? Keep in mind that actions like "dive through a window" or "kick a table over", or even "take cover" are not cooked up by GOAP on the fly - they were thought of and implemented by developers ahead of time, complete with code to define the behaviors, custom animations and sound effects/VO lines to go along with them. Even the logic for determining when the optimal time to do the action had to be supplied by a human being. GOAP's role in all this was to compare that logic to the logic associated with other actions and decide that now is the time to do this particular thing. I posit that for any given game that doesn't have a table kicking behavior, the lack of something like GOAP is probably at the bottom of the list of reasons why it didn't make the cut. It's not that GOAP and its ilk don't work; obviously they perform their intended function. It's just that I think that the importance of the problem they're trying to solve is grossly overestimated next to the far more critical problem of not having anything "smart" for the AI to do in the first place, which is where the vast majority of games that attempt to have "smart AI" actually fall down. The way I see it, a "Good AI" needs to do two things: 1. Have several distinct, recognizable behaviors that players will perceive as "smart" when they see them, and 2. Be reasonably good at determining the appropriate time to use each one. The problem is that number 2 hogs all of the glory. All that is why I decided to completely forgo the use of any structured planning algorithm (even something like behavior trees) in favor of the simplest possible implementation: IF(this happens) THEN (Do this thing). I didn't want the complexity of the system to get away from me, and so my thinking was that since I was ultimately going to be the one supplying all of the decision making logic, running it through a planning algorithm would only obfuscate that. It worked very well as I implemented the first couple of behaviors, but then the fatal flaw in my plan reared its ugly head. A series of IFs might be simple at first, but it grows in complexity as you add to it. With each new behavior type I added, the flow of logic became harder and harder to follow until I ended up with a totally unmanageable rats nest of conditionals and any thoughts of adding to it were immediately replaced with ideas to work on something else. The very thing I was afraid of in the first place! I suppose I bought in to the popular narrative as well, just in a silly rebellious way. You see, the real purpose of those planning algorithms, or at least what they actually accomplish is to provide a structured way to accommodate all of that decision making logic. I still maintain that the effect of the "thinking machine" part of these algorithms is vastly overstated, but one thing that all of the successful ones do, either as a matter of course or by design, is facilitate all that designer supplied logic in a way that doesn't become unmanageable. Next: The solution for Axon
  3. Axon Devlog

    The next big item on my TODO list: "Overhaul Sapient AI" Don't worry if that means nothing to you, I'll explain everything. Getting you there is going to require me to cover multiple topics though, and these posts seem to turn out pretty large even for a single topic. Since I'm already falling behind on my stated goal of at least one post per week, I'm going to try changing up the format and splitting this next one up into multiple installments. Starting with "What the heck is a Sapient anyway?" So, there are two basic categories of enemy in Axon: Primitives and Sapients. Primitives are the first type you see and the more common by far, as seen in all the previous gifs I've posted. Named as such because they come in the form of geometric primitives, and also because their behavior is deliberately simple. Inspired by the enemy designs in games like Phantasy Star Online and Devil May Cry, Primitives are predictable in that they follow consistent patterns like clockwork and their individual attacks play out roughly the same way every time, but unpredictable in that each one has a large variety of different attacks to choose from. Primitive AI uses a basic finite state machine, with the logic for choosing the next state found within the states themselves. They start in an idle state and wait for an attack timer to tick down, then randomly select an attack state, reset the attack timer after the attack has run its course, then return to the idle state, rinse and repeat until dead. Very simple, but not very boring, because the attacks themselves are elaborate, tightly choreographed affairs that require you to move in all sorts of different ways to avoid them, and there's plenty of variety between attacks to keep you on your toes. One of the primary reasons for this is that the simplicity of the system makes it very easy to make new attacks whenever inspiration strikes. All I have to do is make a new attack state, often by copying code from or extending an existing attack, add it to one of the lists of attacks, and I'm done. The cornucopia of Primitive attacks is something I take some pride in, and it's often at or near the top of bullet point lists of 'pros' I get from feedback, so I think Primitives worked out quite well. Sapients are the other type, and are "human-like" enemies who look and act just like you do, in theory anyway. As their name suggests, they have greater level of awareness than other enemies, making informed decisions about where they should be and when, deliberately avoiding your attacks, and all sorts of other things that you might expect a human opponent to do. By pulling from the same pool of weapons, skills and abilities available to the player, I could theoretically create lots of different "enemy types" out of the Sapient archetype. Using a finite state machine that grew out of the one used to control the player character, Sapients know how to, for example, turn to face the player and fire their weapon thanks to an AI state that runs when they're in the "aiming a weapon" animation, similar to the way Primitives work, but unlike Primitives, they need to be able to think beyond what they're currently doing at this exact moment, so in addition to these per-animation states that could be analogous to muscle memory, they also have an always running "brain" state that directs their actions on a higher level by choosing between strategic goals, like "Fire from cover", "hide behind cover", "charge", and maybe even some other ones eventually. Additionally, there are entry points for things like "use offensive ability" and "use defensive ability" that allow the files defining a Sapient's loadout to define when and how they should use their abilities, which could perhaps even allow for two different loadouts to use the same abilities in different ways, should I ever get around to implementing those loadouts. You may have noticed a running theme. Sapients as they exist in the current build are more of a proof of concept than real part of the game. Every part of the system technically works, but only at a bare minimum level. While I've made great strides recently in other areas of the game, I've been putting off any kind of fleshing out of Sapients for ages. There's a good reason for that, which I'll get into in my next post...
  4. Axon Devlog

    As I alluded to at the end of my last post, I've been working on unique behaviors for the offensive abilities I've made so far when combined with the Heat skill. I could just tack some 'heat' damage on to their normal behavior and call it a day, but that would be a let down compared to the effect it has on the Grenade ability. Heat is supposed to show off what the skill system is capable of, so it should be just as impressive when a player tries it out on a new ability as it was initially. I had to do some brainstorming to figure out how a given ability should work with an added fire effect. Take 'Tracers' (my take on the multi-lockon missile concept as seen in all your favorite video games) for example. An explosion is just a big spherical AOE attack, so it makes sense to leave a damage over time effect in the exact same shape. Doing the same thing with a single target attack becomes awkward though; an AOE produced by such an attack would need to be much smaller than the one from the grenade in order to maintain some semblance of balance or sanity, but AOEs rapidly become worthless under a certain size. I experimented with a concept where each individual 'tracer' would produce a small (and useless) AOE, but successive attacks could combine to produce a bigger one: But that didn't seem to read well to people I showed it to, and had some awkwardness inherent to it - Tracers targets each enemy onscreen one after the other, so firing a bunch of them off was as likely to make a bunch of isolated tiny AOEs as it was to make a single big one. A homing missile travels quickly along a potentially long and winding path, so what if I took advantage of that somehow? That was the basis for this idea to have them kick up a trail of fire on the ground behind them, which is what I ended up going with: Then there's the Beam ability. Its defining characteristic is that it's... long... and will pierce through any enemies in its path, so it would make sense to do something that takes advantage of that length. Hence, a firewall that spans the length of the beam: After doing all this, it occurs to me that it may have an unintended side effect. Say these effects are as impressive to a player as I intend them to be - are they being sold on the skill system as a whole, or just the Heat skill itself? I hope players don't get so enamored with Heat that they don't want to try out any of the other skills. Only time and testing will tell if that's the case. Bonus bug: In my initial implementation of the Beam interaction I forgot to properly disable the 'hitbox' for the firewall when it wasn't in use, which ended up causing the player character became hot to the touch, literally: I got a real kick out of discovering that one.
  5. Axon Devlog

    ...And the tutorial's all done. I'm sure it won't survive first contact with testers, but that's just a matter of minor tweaks and bug fixes, not major re-engineering. Speaking of testers, if any of what I've posted here intrigues you or if you just feel like helping me out, I can set you up with a link to the game; just ask. I'm in dire need of testers, particularly ones who aren't already familiar with what the tutorials are trying to teach. So now I have what is essentially an 'intelligent' version of the old tutorial. It still gets you right into the action, but it can slow down if needed, and it ensures that progress through the tutorial is kept in lockstep with progress through the game. Since I've already talked about this in my previous post and it's kind of hard to show, I might as well talk about the other half of the tutorial - the progression/upgrade system. I have to explain how it works for anything I say about the tutorial to make much sense, so uh, shield your virgin eyes from the rest of this post if you intend to help me test out the new tutorial. You bring 2 guns, 5 passive skills and 4 active abilities with you into battle, and can freely swap between any you've acquired (as random rewards for progressing or completing optional challenges) between "runs". There are only 2 rules that might not be immediately apparent from looking at the UI, both involving the passive skills. First, skills that improve your weapons or abilities will only affect weapons/abilities that are equipped to an adjacent slot (for example, the top most ability slot is influenced by the top two skill slots). Secondly, most skills can be equipped in more than 1 slot to increase their effect, potentially using up all 5 if you want to go all in on them. Not the hardest thing in the world to explain, but still important to get right. Before sending the game off to the Idle Thumbs playtester email list the skills/abilities tutorial worked like this: after completing the basic controls tutorial, players were given the "Grenade" ability and the "Charge Speed" skill (it reduces the time it takes to reload the attached gun(s)), and the next time they entered the between-mission loadout menu, they got a tutorial walking them through the process of equipping both. Only one of the 5 or so people who responded even mentioned the skill system at all, so I don't really know how well it was working, but even without feedback I knew there were at least a couple ways in which it needed to be better. The thing is that teaching players how to use the system isn't the only job the tutorial has to do - it also needs to sell them on it. Loot lust is meant to be one of the two primary motivators for long term play, so it's essential to get players... lusting... from the start. The first problem was jamming the explanations for skills and abilities together. The reason for this is that I wanted to limit the skills/abilities available to only the ones given for the tutorial to start with in order to avoid confusion, but i also wanted to get players into the loot cycle ASAP. Even leaving aside the retention implications of trying to teach two things at once, having to go through the motions of both one after the other feels just a bit too complicated. The system is designed for efficiency, giving players a lot of power and specificity with which to define their character in as few steps as possible, so the tutorial should communicate that. So I split them up - individually they're over in a flash, which gets the idea across, I think. The delay before letting players get random loot turned out to be a non issue; it should've occurred to me that from a new player's perspective, a reward is a reward regardless of whether it's picked randomly or not. As an added bonus I was able to re-contextualize the skill and ability as rewards for completing a level instead of just arbitrarily giving them to the player, establishing the loot concept right from the start. The second problem was the choice of skill. I designed the Grenade ability specifically to be an introduction to abilities, so it fills the role perfectly: familiar, obvious in its use and application, exciting (everybody loves explosions), and with a little nuance to it to suggest possibility. "Charge Speed" doesn't work quite as well. It was chosen for being the most "vanilla" of the weapon/ability influencing skills I had implemented so far, and the utility of improving your reload speed is obvious, but it's not very exciting. It also has the side effect of making the "overcharge" mechanic redundant by making the weapons recharge fast enough that it isn't needed. That's fine if the player opts into it later on, but to force the player into it by default right at the very beginning when they're still forming their opinion on when to use overcharge is very bad. Enter the new "Heat" skill, which the tutorial instructs you to attach to your Grenade. Not only does it add a new way to deal damage, but it visibly changes the behavior of the grenade: Much better! Thanks to the new tutorial structure I can guarantee that every player who gets to the skills tutorial has seen what the grenade looks like without Heat, so they'll be sure to notice the difference. And then when a hypothetical new player gets a new ability and excitedly rushes to attach Heat to it, they'll be immediately disappointed to find out that I haven't bothered to make it work with anything other than Grenade and one other ability yet... I guess I know what I need to work on next.
  6. Axon Devlog

    Despite saying all that, after sleeping on it I decided to try making a themed tutorial alongside the abstract one I've been making. After brainstorming ideas for scenarios (for example, requiring the player to destroy some number of targets in under 10 seconds to prove that they know how to reload their gun quickly by overcharging, or re contextualizing them as switches that need to be shot to open a door) and building some of them, I ended up determining that I don't like the way either of these tutorial syles are turning out. Both of them are awkward fits for the game, and this style of level design falls flatly outside of my skillset, which just makes it worse. So I'm scrapping the whole idea. Instead, I'm going to try making the existing tutorial a little smarter. The whole problem was that progress in the tutorial was disconnected from progress in the game, so what if I just... addressed that directly? In the normal game flow levels are subdivided up into "Sectors" that players must conquer one after the other, so if a player is falling behind all I have to do is prevent them from leaving the current Sector until they've reached the desired point in the tutorial. No enemies will spawn after a Sector's objective has been completed, so this will also organically give some "quiet time" to players who need it. Finally, if a player is taking too long to complete a tutorial step (none of the individual steps in the controls tutorial should take more than 10 seconds to complete if you're focusing on them), the prompt will reassert itself. In this way players who are attentive to the messages shouldn't even notice the difference while those who are struggling will get the help they need. Much better, and almost as importantly, so much easier to implement. Boy do I wish I had thought of this last week.
  7. Axon Devlog

    I understand what you're saying but even after thinking about it some more I still disagree that something like that would be a good fit for this game. First, I'd say a big part (probably the biggest part) of the reason why the tutorial in Dark Souls is entertaining is that FROM had the benefit of millions of dollars with which to make an immersive fantasy world, which I can't match. The other thing is that the structure of a Dark Souls area (that of a mostly linear action adventure game) is already optimized for delivering "naturalistic" tutorials, so when they scale it down and fill it with instructional messages it still fits right in. The existing (failed) tutorial I have on my hands is also a scaled down version of normal gameplay, but it just so happens that "normal gameplay" for Axon (pure freeform combat with next to no elements of exploration or puzzle solving) is not naturally conducive to teaching in the way that linear actions games have been since Mario. There's also the matter of where Dark Souls' tutorial fails. "Someone who likes playing around with controls can figure out the buttons without reading every message" will convince themselves that they've learned everything, but the reality is that what they actually learned was the absolute bare minimum required to reasonably beat the Asylum Demon (How to equip a weapon, do basic attacks, dodge, and use an estus flask) plus some but not all of the basic actions that lend themselves to being intuitively demonstrated by pressing their associated button (eg. sprinting, equipping and using a shield, holding a weapon with 1 or 2 hands), and none of the advanced/contextual ones that don't (eg. plunging attack, critical attack/backstab, riposte, kick). By allowing players to proceed without proving that they know these things, the tutorial is letting players down to a certain extent. Now you could argue that while it's a shame for a player to go through the entirety of Dark Souls without knowing that the plunging attack exists (a very common occurrence in my anecdotal experience), it's not the end of the world, and you'd be right. Not all mechanics are as benign when ignored, however. The experience of sitting around waiting for your weapon to recharge, thinking "Oh my god this is SO SLOW! How could the developer think it was OK for it to take this long!? If only there was a way to make it go faster." is not only frustrating for the player, but it reflects poorly on the game during that crucial first impression period. I could try to make a linear level full of themed set pieces that just so happen to require players to demonstrate knowledge of the things I need them to learn, just like you'd find in your average modern game, but if anything it would be even more contrived and out of place than the "just learn these few things okdonebye" tutorial that I'm working on now, because nothing else in the game would be like it. I think it might actually be to my benefit to play up the artifice in this case. The entire crux of the game is the concept of improving yourself (with a relatively simple rpg lite skill system, but mostly your own skill as a player) to meet an ever increasing level of challenge, so it might not be a bad idea to use the tutorial area to establish a theme of self improvement for its own sake - you're there to learn, and you start with the absolute basics, but perhaps you could go beyond that. To that end I'm planning on making it a place that you might want to come back to - target dummies with DPS readouts and so on to test your loadouts out on. I'm also toying with the idea of taking the training partner character I was going to use to teach the basics of swordfighting and allowing you to duel him in an adjoining arena. I'd calibrate him such that he'd wipe the floor with a starting player, ejecting them from the tutorial level and inviting them to come back when they're ready. After the player does come back and defeat them, this character could then improve their own skills as the player progresses through the game and periodically challenge them to a rematch - all in service of reinforcing the theme of continual self improvement.
  8. Axon Devlog

    I sent the game off to the Idle Thumbs playtester mailing list last week, and if there was one single thing to take away from the responses I got back, it's that the tutorial as it exists right now is not good enough. Here's how it works as of this post: When a new player starts the game, they're thrown immediately into the standard game flow. I did this both because I wanted to get players into the action and potentially having fun as quickly as possible, but also because not having a purpose built tutorial area is less work than having one is. As they play, tutorial prompts like this will appear, pausing the game for a couple seconds in the hopes of ensuring that everybody will read them (lol fat chance): After that, gameplay is resumed with the message displayed at the top of the screen along with the progress towards a goal related to doing what the tutorial message explains: After the goal has been reached, the next tutorial prompt is shown and we repeat until done (the "Basic Controls" tutorial shown here has 4 steps). Easy, right? Well if you're reading this you can probably guess that it's not that simple. The problem with this system is that it has no way to make sure that players read the messages. Sure, the messages will stay onscreen until the player has proven that they understand them (or at least that they don't need them), but there's nothing stopping a player from simply ignoring them and attempting to forge ahead regardless, either getting themselves killed or actually completing the first level in the process. I did put in a roadblock preventing players from advancing to the second level if they hadn't completed the basic controls tutorial, but only as a failsafe/last resort, never seriously expecting anyone to encounter it under normal circumstances. Of course I was wrong. I've repeatedly heard game designers say that as a rule, players don't read text even in turn based strategy games. I've watched streamers, I regularly consume Giant Bomb quick looks. I should've known better. I think the problem is that I'm not the type to ignore text at all - when presented with a tutorial message I will drop everything and pour over it until I'm satisfied that I understand it, even going as far as trying to re-load a game if a message goes away before I've read it. It turns out that's not the way all or even most players consume games, but it can be very hard to see outside of that headspace sometimes. Some players, let's call them the Nick Breckons of the world, have an antagonistic relationship with tutorials, almost seeming to deliberately ignore them so they can see how far they can get without the help. Others get so focused on the action that they don't even notice that there's text on the screen. Still others might see the messages and want to heed them, but end up skimming through them and missing crucial details because they feel pressured by the enemies closing in on them in the meantime. I'm forced to confront that horrible truth: The only way to actually ensure that players read and understand the messages is to stop them in their tracks until they've proven that they've done it. You know, like those hand holding tutorials that everyone says they hate... I got some pushback when suggesting that I might want to do something like this, with more than one person citing Dark Souls as an ideal to follow, but I think people tend to romanticize that game, seemingly forgetting that it begins with a sectioned off tutorial segment that explains the controls step by step and requires you to pass a "final exam" to prove that you learned them before letting you out into the wider world. And so that's the next big item on my TODO list: An introduction level to arm players with the absolute minimum knowledge they need to survive in the main game. Because it'll be a purpose built level, there are a lot of things I can do to teach more effectively, and most importantly it'll be a safe/stress free environment to learn in. There's really not that much I need to force feed to the player this way (the existing basic controls tutorial is only 4 steps after all!); a player focusing purely on the task should be able to get through the whole thing in a couple minutes at most if I do it right, so the "pain" will hopefully be minimal. So that's what I'll be doing for the next week or so. If you have Strong Opinions (tm) on tutorials in games and think I'm wrong to do this then by all means, share them! I'm a glutton for criticism, especially right now.
  9. Axon Devlog

    I might as well try my hand at one of these devlog things, so here goes: I'm working on an "Acrobatic Shooter", which is the best name I've found for the informal subgenre of Third Person Shooters that includes games like Vanquish and Resident Evil 4/5/6. Games like this are primarily about the skillful avoidance of attacks, but with a focus on the complexity and physicality of animation driven movement as opposed to the simplistic/abstract movement of classic First Person Shooters - it's all about the interesting limitations and possibilities afforded by controlling a character with a physical body, albeit an unrealistically agile one in most cases. My particular take focuses on the character action game influence that this genre has always had, giving players a sword and making the process of swapping between it and your guns as effortless as possible to encourage the judicious use of both. You have to keep moving with purpose to stay alive, but every attack limits your movement in a different way, so the game is all about deciding which move to use, and when. Here's my best attempt to encapsulate the concept in gif form: I'm going to try to do at least one update per week... We'll see how that pans out.
  10. Free Music Resource

    I picked out "Evil Automation" to go with a map/destination choosing screen in the game I'm working on (thread maybe coming soon). The track (and its less sinister cousin) kind of remind me of X-Com, which perhaps accounts for why it's the one that jumped out at me for the purposes of "Plotting your next strategic move in a hostile world". Thanks!
  11. Recently completed video games

    To continue the Hollow Knight conversation, here's what I had to say about it on the Idle Thumbs Slack: Merus' comment above doesn't make sense to me - the game is blatantly unfair compared to something like Dark Souls. It's just that the punishment for taking an unfair hit is almost nonexistent most of the time. This lenience prevents the combat from being a problem in the vast majority of circumstances, but it does mean that fighting things is never really satisfying for its own sake the way it is in say, Dark Souls or Castlevania. That's OK though, because the joy of exploration more than makes up for it. The experience of picking a direction and setting off to explore, constantly being surprised and delighted by what you find is just sublime, and no other game does it as well, or keeps it doing it for as long as this one does. I'd easily call this my GOTY.cx if it weren't for BOTW. Holy hell what a ridiculously stacked year this has been.
  12. Destiny

    Every single quest I have now is pointing me towards multiplayer content: strikes, raids, the Prison of the Elders arenas, and the patrol zone arenas (Court of Orxy and Archon's Forge). Of these, only strikes and some (not all) of the PotE arenas have matchmaking. Even then, matchmaking for strikes is hit and miss - mostly miss if you want to do a specific one instead of a random one from a playlist. The number of strikes I've completed alone could almost be considered impressive, but it's mostly just sad.
  13. Destiny

    Destiny 2 isn't out yet on PC, but even if it was, Destiny 1 and 2 are different video games and I want to play Destiny 1. Destiny is not an abstract puzzle or board game where the only thing that changes between sequels is a set of rules, which is the only situation in which the idea of a game becoming "obsolete" makes any sense whatsoever. It's a first person shooter with its own unique set of level designs, enemies, weapons, progression systems, narrative arcs and so on, and I want to experience them. I've been binge playing this game and enjoying it a lot. So far the only truly frustrating thing about it has been my inability to find anyone to play it with (my usual coop crew is abstaining from this game for various reasons) and the utterly baffling lack of matchmaking features to get around that.
  14. Destiny

    Is there anyone else here still playing this game or thinking about playing it? Everyone on Slack is D2 crazy, but I'm still stubbornly playing this for the first time, and I'm hoping there's somebody else out there doing the same thing, because the lack of matchmaking or even something like the ability to put up a public lobby outside of a few very specific activities is a bit of a bummer.
  15. Thanks to Important If True, I now understand that this Mr. Burns joke is intrinsically linked to him being an old man: