Prototyping

During my time at Paladin I worked on a game for Blind Ferret Entertainment based on their hit webcomic Looking For Group.  It’s been the biggest game I’ve worked on and it was a lot of fun, even though we eventually ran into problems that stopped it from going into full production. I wrote a few blogposts about the proces of turning this comic about a game into a game about a comic.

Building a new game always requires some forethought. Before you can start dressing up levels with explosive barrels you need to think about ‘what do I consider a level?’ and ‘how much exploding should explosive barrels do?’ That is why we build prototypes.

For Fork of Truth we had to start with the basics – movement and camera.

You may have a mental image of the way something should work, but by building it you often discover that there are things you haven’t thought about. For example: having a fixed isometric camera and a character that follows your mouse cursor sounds like a fine system, but if you then walk downwards on the screen, your left and right directional buttons are inverted. So we had to correct the movement to be relative to the camera, independent of the character’s rotation.

Upon seeing the above prototype one of our programmers remarked “it’s funny to see the difference between a programmer’s prototpes and an artist’s prototypes.  I mean you’ve got the vignette and the dynamic shadows all up in there and stuff, really cool!” Heh. They are unnescessary frills but they make the prototype just a bit more pleasant to look at.

Now, Isometric cameras are usually orthographic, but we found much nicer results with a perspective view. Then we tried zooming, and this worked very nicely to show the characters up close, but made it impossible to see or fight anything standing ‘below’ you, since our camera does not rotate. So we could either make the camera rotate, which we didn’t want to do because it would triple the work we had to do to make the level look good from every angle, or we could adjust the camera curve so it never zoomed to a point where this became a problem. All these considerations I could not foresee when typing up the game design document.

The control scheme we went with was very similar to a third person game with strafing and mouselook etc, but unlike a third person game our camera does not rotate, so now we had the matter of a character walking one way while facing the other. Does he turn his head? How far can he turn? Does he walk backwards at some point? Do we need a different animation for that? What happens if he attacks?

Now we cross over into the territory of animation blending, a topic our Technical Director Niels did some stellar work on using Mechanim. These are all things we needed to think about before we started building our systems so that they were as flexible and modular as possible so we could easily extend them if we thought of new features down the road.

Once we liked the feel of the controls we added in attacks, enemies, and built a little level around this. And again we discovered things to think about: if a player goes behind a house that obscures the camera, do we turn the house transparent? Does the camera zoom way in? Do we outline the character so you can see it through walls? Do we redesign the level so this never even happens?

Every prototype raises questions that we can then investigate in a new prototype. And it’s important to make it a NEW prototype, so you can look back and compare, salvage what works and throw out what doesn’t, so you end up with something that has been tested and improved upon even before it was properly built.

And then with all these systems fleshed out, you can start to see how they work together. Opportune time to delve into gameplay topics, like how far apart should the enemy spawns be to make the pace of the level enjoyable? How many enemies can a player handle at once? Do we need less enemies or should the player’s attacks just be more powerful? How many meteors can Richard summon at once before the game crashes?

You know, important questions.

Creating humor through experiences

During my time at Paladin I worked on a game for Blind Ferret Entertainment based on their hit webcomic Looking For Group.  It’s been the biggest game I’ve worked on and it was a lot of fun, even though we eventually ran into problems that stopped it from going into full production. I wrote a few blogposts about the proces of turning this comic about a game into a game about a comic.

Humor is an important part of the LFG universe. But it’s not all in the words the characters say. Their actions and their surroundings are just as important. So especially in a game, where the story goes hand-in-hand with (or more often is overshadowed by) the gameplay, it’s important to have different ways in which to construct a joke. In this article I’ll talk about some of the game mechanics I used for this purpose.

The LFG group are real buddies. They might bicker and shove eachother around occasionally (well ok all the time), but they still work together to defeat whatever monster is chasing them. So we wanted to emphasize that with the gameplay, not only letting you play with your buddies, but actually giving you benefits if you work together. For instance, If Richard sets Cale on fire, his arrows will be on fire too and deal double damage. Then Benny can heal whatever health Cale lost. Ice spells and swords go very well together too, as do group stuns and area-of-effect attacks like Krunch’s stomp.

But even though these guys are heroes, they can be kind of clumsy sometimes. So we tried to include a way in which each ability at their disposal has some sort of risky side-effect. Summoning Cale’s pet panther has a 50% chance of inflicting friendly fire for instance, Richard’s fireballs might sometimes decide to fly off in a completely random direction, and if Benny heals you in the midst of battle you might sprout and extra arm or leg. Or a beetle head. Combined with friendly fire this makes for some hilarious battles. Even when it was all buggy and crap in the alpha we were having fun with it.

Once you’ve looted all the cold, dead corpses you’ll want to sell some of that stuff. Usually that means backtracking all the way to a village merchant. But surely our heroes can think of a better way right? I mean why not just summon a merchant into the dungeon? And once you’re done you can fwoosh him and you’ll be on your merry way.

Knowing the exact value, damage, protection and/or weight stats of an item that you pick up off the ground is a silly thing… that is why every item in LFG has EVEN more weird stats, so you can see if that new sword goes well with your purple outfit, how sweaty the previous owner was and whether his angry soul may still reside inside the weapon.


Stealing items from one another was also a feature we considered in several forms. If loot was not instanced it would be possible for someone to scoop everything up (I’m looking at you Jerry Holkins), which could lead to some animosity, so if you were close enough to the other player you could tap into their inventory and claim what is rightfully yours. This also works in reverse, where dumping a lot of heavy items into a low-level player’s inventory would root them firmly in the ground under the weight penalty.

And ofcourse there is also the item storage bear.

All these things work together to create humor and narrative that emerges from the stories the players create by playing the game, not just by way of the main story that we designed, so players can actually feel like they’re on an adventure in the LFG world even when they’re not out questing or interacting with other characters.

Translating a comic about a game into a game about a comic

During my time at Paladin I worked on a game for Blind Ferret Entertainment based on their hit webcomic Looking For Group.  It’s been the biggest game I’ve worked on and it was a lot of fun, even though we eventually ran into problems that stopped it from going into full production. I wrote a few blogposts about the proces of turning this comic about a game into a game about a comic.

LFG The Fork of Truth was an ambitious project. It has a ton of lore and a large fanbase. So to deliver something as outsiders that fits into the LFG canon we had to become intimately familiar with its universe. To do that I went through a few important design steps before we could start having discussions about how big the fireballs should be.

The steps below are not a rigid structure but merely the way I prefer doing things, and this process applies just as well on books to films, films to games and whatever else.

Look at the source material

This sounds like a no-brainer, but it is easily the most important part. LFG does not begin and end with the comic – the comic is simply one window into the world of Legarion. So just skimming through the comic and lifting out the good parts is not the way to go about it. Many games about movies take this route and it gives them problems because the two media are fundamentally different in structure.

What I’ve learned from doing a webcomic myself for many years is that the most important part is the characters’ identity. If you have an understanding of how each character would behave normally, all you have to do is put them in a wacky situation and the dialogue will practically write itself. They can never do something out of character because you know them as if they were your friends.

The only one who really has that complete picture is Ryan Sohmer himself, and I was very lucky to be able to talk directly to him. Between that and reading reviews, analyses, comments, looking at concept art and talking it through we tried to gain an understanding of this property that approaches Sohmer’s own.

Find a new angle

Once we had that understanding, we started looking for a fresh new angle. The Chronicles of Riddick: Escape From Butcher Bay is a great example of this. Instead of copying the movie they created a brand new story in the Riddick canon that expands on his backstory and creates context for the things you see in the movies. It opens up a new window into that universe. We treated FoT in the same way.

The heroes are always on the move. And we know the high points of their story, from when they met to their trek to Kethenicia, the dwarves, the Plane of Suck, the Legara threat and beyond. But inbetween, what do they do? Where do they get all their fancy weapons and skills? What happens when Richard misplaces his fork during dinner? We aimed to answer those questions, and have players experience the daily life of this group. Which involves a lot of bickering and setting things on fire.

Adapt it to the desired medium

So now that we know our characters and our angle, we start to see how it could fit inside the structure of a videogame. We are in a fantasy world, we have multiple characters with different skills, violent battles and hilarious situations. So logically we end up with a 4-player coop hack-and-slash action-RPG.

During our design process we wrote down these five design tenants, which influence all our decisions:

Make players feel like they are part of the LFG world, not just a random fantasy world – include well-known locations, characters, events.
Give players freedom – within reason, we want players to choose their own adventures.
Pick up and play – players should be able to get into a session quickly and easily.
Multiplayer – the game is focused on playing with friends, though it should not exclude single-player. Playing with others should have benefits to the challenge and the fun.
Quirky crazy humor – If something has potential to be used as a joke, do so. We have to find the twist in every system, the joke in every quest description. If a player hasn’t laughed in 5 minutes, we missed an opportunity.
Next we have to start thinking how this actually works. Games are all about repeatable actions, so we design the core gameplay loop, a simple flowchart that shows which things you’ll be doing in the game and how they interconnect:

After that we look at each part of this flowchart and start designing the systems behind them. From the way you travel from dungeon to dungeon to the way the inventory works and what defeat means. I will highlight a few of these ideas in a later blogpost.

Prototype

Then comes the time to start prototyping each of these nuggets. Prototypes are super important to test these ideas before we spend time and money on making them. And once these prototypes feel right we can lock the design and go ahead with the actual production.  I’ll talk more about the combat and level design prototypes we made in an upcoming blogpost.