Category: Development


I swear, this thing might kill me. I’m still plugging away at Corrosion and the combat mechanisms in particular. The pathfinding is done, it works, but it’s anything but fast. Limiting the searches to about 200 tiles or so seems to help with the speed and makes the game slightly more playable, but it creates strange situations where pursuing enemies break off the pursuit through a corridor when they find their path blocked by their friends. I think I’m going to have to find a reliable way where they ignore their friends in terms of finding a path, but respect them in terms of getting in line. That way they’ll continue pursuit but never overtake their friends until a space in the corridor opens up.

Why is it going to kill me? Well, these musings keep my preoccupied throughout the day. Whenever I have a free moment, there’s only so many topics that my mind wanders towards, and Corrosion is on that list. (Together with finding a possible place for a friend when she arrives back in Amsterdam soon, my soon-to-be-unemployed sister and her financial situation, my work, my Shadowrun game, Jiu Jitsu, etc.) So today, while I was walking to work, I nearly got myself run over by a bus because I had been preoccupied with figuring out this pathfinding problem. The adrenaline dump of a near-death experience quickly brought my mind back to reality, but simultaneously drained me of a lot of my energy. Funny how that happens.

Pathfinding, A*, Motivation and Progress

As you might have concluded from my last journal post, I got demotivated when I hit a snag in my self-devised pathfinding algorithm based on the A* principle of pathfinding. I knew that A* was going to be a simple, straight-forward and decidedly stupid way of finding a path, but I wanted to understand the principles of it before I migrated on to adding “costs” to the logic of the algorithm and making it smarter. I was shocked to see that with the relatively simple map that we had created, roughly 34×58 tiles large, finding a single target from one side of the map to the other made PHP run out of its allotted memory. And so, it took a few days for me to pick up the deving and figure out what was going wrong.

It turns out that when I started to examine the path that was returned for a relatively short example, that there were some mistakes. It returned some tiles as part of the path that weren’t supposed to be. Then I took a look at the examined tiles and there were way more than I thought there should have been. It turned out the algorithm wasn’t ignoring blocking tiles as it should be. When I had found the problem and fixed it, I found the load was cut by more than 50%. That was good, but it’s not good enough. I’m going to examine it some more soon, but it means there is still progress to be made before I start implementing the costs structure. Perhaps when I’m no longer able to streamline things, I’ll show you guys what I came up with.

Anyway, reinvigorated motivation FTW.

What Have I Started…

Corrosion has been my baby for the past four months now, starting out as an idea that was born from an evening of hanging out with my brother and mostly due to my brother’s enthusiasm and creativity has turned into a somewhat more complex game than I had initially thought it was going to be. At first I thought it was going to be a simple statistical crunch game, but then we got the idea to make the combat engine a tile-based game, which meant Line of Sight algorithms, path-finding algorithms (A*, breadth-first, etc.) and slowly but surely it’s becoming more and more complex. I’m slowly getting to the point where I start wondering if this is ever going to be finished, but then I look back at what we’ve accomplished already, and I feel better.

Currently, the game is not even close to finished. You can make a character of any race, mundane, a shaman or a mage (no adepts yet) and we have weapons, armor, drugs, spells and cyberware that you can purchase. Important things like rigging, decking and conjuring haven’t been implemented yet, but that’s a matter of time. Drone rigging is going to work similarly as conjuring, where you basically have a companion that fights along side you, or, if that turns out to be too complex, that acts as a buff to your own attacks and capabilities. Of each category (spells, weapons, armor, cyberware, etc.) we’ve only added a few items so that we can teach the overall mechanism that governs them, and we moved on. Weapon accessories are going to be important, as are various electronics that should be able to use during combat.

Just thinking about all the things that still need to happen make me go a little funny in the head, but luckily I’m having a lot of fun and I’ll keep plugging away until it stops being fun. It helps that I’m not the only one working on this, even though I have to do the majority of the work. So yeah, hopefully next week I’ll have some time to introduce path-finding and tweak the stealth/perception mechanism that currently exists (I don’t like it, it’s too crude.)

I guess one of the things that I struggle with is whether or not I’ll just be doing this as a way to keep myself occupied, or if this is actually going to be something that other people will enjoy and play. Also, what would I rather have, really?

Dice Pools

We decided to not implement the idea of dice pools into Corrosion for the simple reason that it’s a complex mechanic to maintain. Combat Pool, Magic Pool, Karma Pool, Hacking Pool, Control Pool…I’m not looking forward to implementing that. At first it seemed like that wasn’t much of a problem; the lack of dice pools just means that the progression through the game gets controlled a little bit since it means fewer dice to roll and thus less successes on your test. A case could be made to implement the Spell Pool, as it’s dice that usually get split between the Sorcery test and the Drain Resistance test. You could assign them fifty-fifty, or with whatever division you’d like to apply. Combat Pool becomes harder, since it’s situational. People will generally keep some dice back in order to assist dodge rolls or Damage Resistance tests when needed. Corrosion needs to be quick and you don’t want to have to decide how many dice to assign to one test and to the other between one round and the next.

So we chucked them, thinking that the lack of situational modifiers like visibility, movement and range would balance each other out.

Action Points

Yesterday, right before my brother fell asleep mid-conversation (okay, that might not be entirely true), we discussed how many actions a player can take and what mechanism governs how much you can do. We have to limit a player’s actions, if only to keep the pressure on our webserver to a minimum and slightly distribute the amount of play users put in.

At first, we thought we could govern that by using the stun monitor as an indication of a character’s fatigue. So instead of the possibility of taking damage on a player’s stun monitor, all damage would be physical and the stun monitor could be used to keep track of amounts of actions left. Over time, say every 15 minutes or so, you’d get an automatic 1 box of stun wiped off the stun monitor. Unfortunately, that would break from the SR3 rules we’re looking to implement, and it would mean a limitation on gameplay – no more stun-dealing weapons and spells, for instance, no target number penalties based on stun damage received, etc.

However, we came to the conclusion that another stat was needed – action points. If all damage was physical, there’d be no reason to not cast spells above your magic rating, since drain was going to be physical damage anyway. You could cap it by not allowing any spells with a force higher than your magic rating, but that would damage some of the versatility of a mage or shaman. Weapons or spells that dealt stun damage would by and large have a far more dangerous reputation than the ones that deal physical damage, since the amount of actions you have are the most valuable commodity in the game. This would mean that during PvP people will start using stun weapons just to fuck with each other and I am not too keen to have to start dealing with grievers. It’s one thing if you lose some life (essentially some nuyen since you can always get patched up) rather than losing your ability to generate some money and experience.

That and more made is re-evaluate our decision to use the stun monitor as an indication of action points. Now we’re still looking into how many action points someone gets. Currently set to 10, perhaps we’ll have to turn it up to twenty if it turns out to be too little. Also, we still need to firmly determine what will and what won’t cost an action point.