Vectorball's Randomized Reward System 02/22/2015

Last week I continued working on Vectorball, a project I hadn't been working on for about four months due to other obligations. It was already quite far in development, gameplay-wise at least, and I spent countless hours playing it just for fun.

So I looked at my list of things that were still missing and decided that randomized unlockables would be a good thing to implement. I started out by making a list of all things you could possibly unlock in the game:

• Game Modes (such as Season or Tournaments)
• Challenges (basically specific predefined levels to beat)
• Additional Character Slots
• Items (that can be carried by players and apply passive effects)
• Item Slots (players start out with just one available slot but can get up to five)
• Team Buffs (which can be activated when playing a tournament, e.g. your team's goal will be a little smaller)

That's quite a lot - and I reckon that's a good thing. The more variety there is, the better.
My main motivation working on the whole randomized bonus system was to provide the necessary motivation for the player to keep on playing the game. There should be a sense of progress combined with randomization - i.e. luck - in order to keep it unpredictable and engaging.
There's a chance to get one of these unlockables each time you score a goal with one of your players as well as after each win. At this point however two issues came up: First, different events require different drop qualities and probabilities (e.g. scoring a goal should yield less rewards then winning a game or even a full tournament, simply because the latter happens not as frequently); and second, I wanted a bit of control over when things are unlocked without giving up the random nature of things. This is necessary to avoid scenarios in which a player has to play for hours simply to unlock the basic game modes or a second character slot.

Controlling the Random

Let's first talk about control. There are certainly innumerable ways to deal with this, but this is what I did:
Within the code I created a (non randomized) list of specific unlocks together with data about when they are supposed to occur (as in after how many previous unlocks) and what's the probability for them to be activated once that point has passed, as the following table shows.

So let's have a look at the first one, an additional item slot for player #1 (of course the first player - at this point there is just one character slot so unlocking an item slot for any other player character wouldn't make any sense). After four random unlocks this one is considered for the first time (hence the 5 in the third column), and has a chance of 50% to be picked. I introduced this chance simply to make sure the predefined unlocks wouldn't always show up as the n'th unlock, but still appear to be somewhat random. So in this case there's a 50% chance for it to be picked - if it is, it will be awarded to the player and then removed from this list. If it isn't, a random drop will be awarded to the player and it remains in the list and will again have a 50% chance to be picked the next time something is unlocked.
This system is obviously quite simple but combines randomization and control in a reasonable way.

Qualities and Probabilities

I mentioned before that certain events, such as scoring a goal, winning a match or winning a tournament cause potential rewards, but based on different probabilities. I started off simple by defining somewhat arbitrary values for these cases: 5% for scoring a goal and 35% for winning a match. Winning a tournament can yield up to three rewards with 150%, 100% and 75% probability respectively.
You might wonder now 'why 150%? That doesn't make any sense!', and while you're certainly right with that, there's a catch: The probability is first multiplied with a factor that's based on how many unlocks were granted already. This factor is defined as 0.98^{#previous unlocks}, so starts out as 1.0 and gets reduced by 2% after each unlock. Consequently after 50 unlocks you'll have only ~36,4% the chance for a reward that you had in the very beginning.
This behaviour very simply is supposed to keep the motivation curve high in the beginning while avoiding reward inflation in the long run. Later on, you want (and have) to work for your rewards.

These probabilities are used to determine whether a reward shall be awarded at all, at this point we don't know yet what kind exactly. If the player is lucky and is given a reward, at this point the table introduced earlier comes into play: if any item from the table is picked, it will be given to the player and that's it. Otherwise however, a random reward will be generated.

Random Reward Generation

We start out determining which kind of reward it will be. Again I used probability values that seemed to make sense without putting too much thought into them: 10% for a new item spot, 5% for a team buff and 85% for an item, although these values are in fact a bit more in depth and item spots get less likely the more are already unlocked, and team buffs can only be unlocked if there are any left, of course. Afterwards the type and attributes of whatever is generated are picked more or less randomly, with a tendency for weaker values however. That means items are not equally distributed regarding their quality, but you'll get goot items much more rarely.

Conclusion

There really isn't all that much to it - after a basic understanding of the system's requirements it can be put in place quite quickly and without complicated algorithms. This very basic system described above combines a variety of useful features that surpass basic randomness:

• there's an element of control, I can make sure certain unlocks are picked early on
• the amount of unlocks steadily decreases which hooks the player early on without giving all the unlocks away too soon
• unlock quality and quantity vary depending on the event causing them

Despite about 12 years of game dev experience, this was actually the first time I implemented such a system and realized how useful it really is. It's absolutely worth the effort. Although I, being player and developer in one, could technically unlock all the items and buffs with a single line of code, I actually keep playing the game in order to earn the progress. Time will tell if actual playtesters find the system similarly engaging, but I'm reasonably optimistic and would recommend anyone to consider adding a reward system based on controlled randomization to pretty much any game, as it does make a huge difference.

Reviving Doyle 02-23-2014 As I described in the last blog post just a few days ago, I spent some time revamping Lab Rush in all possible ways. While doing that, it occured to me that there was another game in existence, that deserved a similar degree of attention.

I'm speaking of GTFO, Moon!, formally known as Doyle 2, a puzzle platformer I worked on a few years ago. So, naturally, I spent my last Sunday reviving Doyle, who may or may not be the protagonist of the game. I worked on the usual things - making sure the game runs equally well on all common display resolutions, improving the game's assets, fixing bugs.. things like that. And it turned out pretty well. However, the contrast of how it looked before and how it looks after the transformation is certainly not as striking as it was with Lab Rush. This is how it looked two days ago:

And this is how it looks now:

It doesn't even look better at all, but that's sort of an illusion: The old version was running at 960x600 pixels, which made it looks very blurry on reasonably big screens. The new version on the other hand is clear and sharp, which looks much better on high resolutions and sort of meh on low resolutions. But who's playing games in "600p" nowadays anyway?

I also worked on the game's level editor a bit, there's probably still sort of a learning curve, but I personally can work with it pretty efficiently. The level you see in the video above was created from scratch within about 30 minutes, which seems quite reasonable to me considering I improvised everything and didn't start with a clear concept in mind.

Now, let me just close this blog post with another video. One of the game's great strengths is its flexibility in regards to gameplay and level design. For instance, I made a level some time ago that's basically a homage to VVVVVV (that 8-Bit style gravity engineering Indie game), with most of its gameplay elements and parts of its puzzle design. Unfortunately the level isn't ready to be shown to the public yet, but I've got something else, even if not quite as nifty. This level, which is demonstrated in the video below, provides a quite different perspective on the game by making use of a mostly static camera. The level consists of seven individual interconnected rooms and the player has to solve certain puzzles or survive tough situations to proceed.

So that's about it. Thanks for reading and stay tuned - sooner or later there will be news on GTFO, Moon!, just as on all the other games that are currently being worked on. :)

Reinventing Lab Rush 02-20-2014 If you've visited the lower regions of the Games Section, you might have noticed a small entry regarding a nice little action game called Lab Rush. It was developed by a friend of mine, Thomas, throughout the course of several years (not fulltime though, obviously).

Recently he decided to finally finish it - programming-wise, it was pretty far developped, and the level design was mostly done as well, so there really wasn't that much left to do. However, if you have a look at this screenshot:

...you might notice that, graphicswise, there was a lot of room for improvement. Also, the game did not support multiple resolutions as they would change the player's field of view. Challenge accepted! So we spent about four hours on this project today, and guess what? It was quite worth it. The game does support multiple resolutions now, the game's camera is able to not only zoom but also rotate (allowing for some fancy effects), all sprites are rendered with anti-aliasing (which is really a big deal, considering the game was developed in Dark Basic) and there's a Motion Blur as well as a Bloom effect.

Although I kind of have to admit... it doesn't look much worse when the effects are turned off.

However, despite the big progress we made today, that's not it yet. Daniel agreed to work on improved assets for the game, such as the tileset, enemies and particles. Long story short: After many years of development, just a few days of focussed, goal oriented working are moving Lab Rush to a new level. :)

New Video 02-20-2014 Yesterday I decided to upload a few videos of my unfinished projects and prototypes. So I sat down, reinstalled Lightworks and did my best to present three of my former (or kind of current) projects in the most appealing way possible.
Starting with a short descriptive video of how my Lab Rush 2.5D prototype implementation was meant to work, followed by a quick demonstration of Twofold in its current state - which is rumored to stay its current state for quite a while, as I'm moving on to other projects for the time being.
And finally, there's a three minute compilation of a tech demo I wrote a while back, combined with scenes from The King's Profit and Animal Liberation Turbo. And here it is:

2013 01-01-2014 So, 2013 is finally over. A year with ups and downs, many more in fact than any of the years before - at least for me. After moving to my new flat in late 2012 and making the decision to develop video games for a living, I finally started working on the first few games during January 2013.

One of my first project was also the biggest one to date: Flow Motion, a game that started out as 48 hour project but kept me busy for almost half a year. And while it did turn out just the way I hoped to, it was far from a success. Very few people played it, and the ones who did weren't very satisfied. The first in a row of disappointments, but a great lesson. Apparently playtesting is much more important than I initially imagined, since the game's controls weren't intuitive enough and off putting to many potential players.

I spent many weekends of 2013 with game jams, such as Ludum Dare (which spawned such games as 360, Forever Alone and Desperado), the Global Game Jam (Hear the Living), Asylum Jam (Flatuphobia (yes, I actually made this... don't ask. I was desperate. :D)), BlandJam (Press Any Key), Indie Speed Run (The King's Profit, which even made it to the finals) and Charity Game Jam (Animal Liberation Turbo, which actually is one of my favorites).

Finally, I created this website and fleshed out a lot of game design concepts that I haven't started yet. There's just too little time to work on all those ideas... which results in many promising projects never being made. However, the ones that are being made are certainly worthy of our attention. Luckily enough my path crossed with that of Daniel Falk, who created the beautiful soundtrack of 360 as well as the soundtrack, visuals and most of the story and writing of The King's Profit, and we now teamed up to create a few highly interesting games, among them the small story based platformer Twofold, a yet to be named rogue-like underground RPG centered around terraforming, and a few small apps for the mobile market. Make sure to subscribe to our Newsletter below to stay up to date!