Category: Development

Shadowrun: Corrosion – A Tough Decision

Since starting development on Shadowrun: Corrosion I’ve had a tremendous amount of fun watching it manifest into something that people actually seemed to enjoy. I never actually thought that what started as an educational project for my brother and I would eventually attract more than 250 players.

One of the challenges was trying to stay true to the SR3 rules. We thought that if we just kept on trucking and kept expanding the foundation and implementing more material, we’d eventually get there. We made a few changes in order to standardise a few things because the rules have so many exceptions that it was going to become impossible to keep track of all those exceptions in the code. We built a fairly flexible foundation in which we were able to implement almost 95% of all the rules fairly loyally.

For all the things we did right, we also had a lot of problems — problems we unfortunately were not able to overcome.

The first problem was the performance in missions. When we first started out, things were jerky, but it was acceptable as an alpha because we thought we would be able to come up with some performance enhancements in order to improve upon that.  Unfortunately, we never did and in developing the options further, the performance just suffered more and more. We never did find a way to boost the performance.

The second problem was the fallout of implementing PvP. There was quite a backlash from the players because it was implemented too quickly and without a good understanding of the consequences. For a long time we were looking for the right way to offer PvP options without people getting ganked right, left and center.

The third problem was that the more we developed, the better we understood what we did wrong and what we had to redo to keep up with the curve. A good example was our shop mechanics.

The fourth problem was that despite several offers for help, I wasn’t able to set up an infrastructure for code sharing, testing, quality control, etc.

All this created a situation where we had a hard time keeping up with the demands of the players, creating some friction with people like Rockso, ShadowDragon, etc. As we kept developing, we kept falling behind further and further and it became clear that the project was collapsing under the weight of itsown ambition. Adepts hadn’t been implemented, let alone the matrix or the astral realm. No complex behaviour trees for opponents like I wanted…

I can go on, but I won’t because, well… no use crying over spilt milk.

The death blow came with the latest problems with lag. What is causing the sudden bursts of lag is still somewhat of a mystery. It’s likely that our server is being brought down by the large number of queries. It’s not a beefy server, but one that I would expect to have more than enough resources to cover us. Having set up a test environment on my rather bad ass box at home, I can safely say that there’s no lag here, confirming my suspicions that it’s our server.

So we had a choice to make; either we were going to move to a different server — perhaps something a little more professional — and start paying, or figure out a way to lower the load on the database. Unfortunately, the latter option means we’ll have to make some seriously fundamental changes to the framework. In hindsight, we over-extended ourselves and were too ambitious.

So as of right now, I am ceasing all development to Shadowrun: Corrosion. My brother has moved on to other games, mostly developing stuff to earn his degree while I have several small projects going on. I also have some ideas on different games that may or may not come to some sort of fruition.

Luckily for all of us, there’s an RPG in development as well as an ambitious MMO. Check it out on www.shadowrun.com.

It’s been a great experience and I’ve had a lot of fun chatting with all of you. I’ve also been amazed at how loyal most have you been and your advice and suggestions have been invaluable to me. You’ve taught me a lot.

It’s been real.

Map Generation, Land Allocation

Leaps and bounds! After yesterday’s breakthrough with the Voronoi polygon generation, I’ve made significant improvements. One of the things that I was getting stuck on was the proper distribution of landmass using a Perlin noise library. I ended up stumbling upon a clue hidden in the code of someone else who had been doing something similar, which incorporated the noise with the distance of the polygon to the center of the map, combined with a factor of the land vs water ratio. I couldn’t easily incorporate what I had found into my own script, but once I stumbled across it, it was like inception, it was only a matter of time. Take a look below at an example. These are 4000 random polygon sites on a 1024×768 canvas, looped twice through the Lloyds relaxation algorithm.

Voronoi polygons run through a Perlin noise generator. 4000 polygons on a 1024×768 field.

I’ve been able to identify land, water (ocean) and water (lake), and I also have elevation down. Many people suggest that I shouldn’t let elevation depend on Perlin, but let it depend on the distance to an ocean, but for now I’m going to go with the randomly generated noise and see where that takes me. If it doesn’t work out I can always come back to it. Hopefully tomorrow I’ll be able to use that elevation and generate a moisture variable for each polygon and combines those into different biomes.

 Momentum and forward motion is everything with projects like these, so hopefully I’ll have more tomorrow. :)

Map Generation, Voronoi Debugging

After a solid week of debugging and reworking a php library I had found that generated a Voronoi diagram, I finally managed to hammer out the last kinks. It turns out that the two itterations of the Lloyds relaxation algorithm I used were sometimes coming up with sites that lay outside of the bounding box, which ended up causing all kinds of trouble. I now finally have a Voronoi polygon generator that a) I understand, and b) is performing fast enough for me to continue with.

Recreating Randomness
In order to properly debug the problem, I had to be able to recreate the problem properly. Initially, I used the PHP rand() function to create 1000 random points within a 1024×768 canvas. Each time the problem came up and I reloaded the script, it would come up with another 1000 random points, different each time. After first coming up with a half-arsed solution whereby I also outputting the coordinates for the 1000 points, I found out that you can set a seed with PHP’s srand() function. This allowed me to either generate a random number based on the system time, or just supply a number of my own. I made a little form that allowed me to generate a diagram based on a supplied number or generate one randomly and display the seed for that diagram. That way I could flip through random diagrams until I found one that was broken and simply keep generating that same diagram with the given seed. That made things much, much easier.

In the meantime, I also incorporated some code that wrote all the relevant information for the diagram into an XML file with which I could also once again recreate the diagram, without having to calculate everything again.

Up Next
Now that I’ve finally been able to find the flaws in the PHP library that I was working with and the code that I was using to call the library, I will continue exploring the finished code a bit, seeing if I can make some tweaks and do some cleaning up. I will also try to post the finish product of what I ended up making, perhaps with some more interactivity (the ability to set the canvas size, adjust the number of random sites, and perhaps also the amount of Lloyd iterations it does) so that people can play with it.

Then I’ll start looking at using a Perlin library to start creating a rudimentary shape for the map that I want to eventually create. Once I’m happy with that, elevation and moisture will come into play, which in turn means we’ll be able to make individual biomes.

I’m sure there’s still much more to do, but I have to say that even though the going was tough the last week — to the point that I was even dreaming about Voronoi polygons — it’s really rewarding to achieve breakthroughs and to persist into success.

Anyway,  I’ll try to get my script up tomorrow.

Shadowrun: Corrosion is Broken

The mechanics of Shadowrun: Corrosion are broken and I don’t know how to fix it and I’m starting to suspect it can’t actually be fixed. Or rather, it can’t be fixed in a way that would still remain somewhat true to the old SR3 system. It rarely happens that in the table-top version of Shadowrun, you end up playing a 1000+ karma character. But it happens rather “quickly” in Corrosion. Currently, you are able to make about 30 karma a day if you really dedicate yourself to it. (I’m not entirely sure how feasible it is, but theoretically, you could do two missions and about 20+ duels, and then I’m not counting what you can make in the arena.)

Once you’ve got your attributes maxed out, which is relatively soon, and you’ve lowered the costs of improving your skills, you could quite quickly and quite easily jack your pistols/smg/unarmed/edged weapons up to around 20 skill points, at which point it becomes a game I’d like to call “D or be D’ed” — essentially, you do deadly damage or you get deadly damage, depending on whether you win the initiative roll or not.

This makes for a fairly boring game. Very few duels or PvP fights last more than one or two rounds. And the game starts to revolve around who can chuck the most drugs and still be effective in combat. I think it’s inherent to the game of Shadowrun. The lethality makes the table top game so great and suspenseful, but if you’re doing it as a browser game, it becomes very boring in my opinion. I’m wondering how Shadowrun Returns is going to deal with that.

A game that revolves around hitpoints, generally, makes it a little more easy. You can scale hit points together with damage resisting qualities, damage dealing qualities and you can even play with critical hit possibilities. Gear will simply scale with your progression through the game. I’ve heard people say that you’ll start out with a weapon that does 4 damage while your enemies have 10 hitpoints and after a year you have a weapon that does 400 damage, while your enemies have 1000 hitpoints. In the end, it all remains the same. I suppose that in a sense that’s true, but when the hitpoints always remain the same; namely the 10 boxes on your stun and physical monitor, things become dull.

It’s really bugging me. To the point where I don’t see any reason to continue expanding upon anything else in the game until I’ve figured it out. If I don’t figure it out, and I continue adding new content or fixing bugs, I just have the feeling I’m decorating a cabin on the Titanic; a little pointless in the end.

In the mean time, I’ve had some ideas for other games that might work much better and I’m wondering if it’s not better to cut the game loose and move on.