Week 1 – Tamarrion

Howdy! 

This is the first of many blog posts I’ll be making over the course of about two months

So we’ve started with a whole new exciting project, called Tamarrion. This game was conceptualized by myself and Camilla, during the winter. It’s a part of our Big Game Project course at the University of Uppsala.

(Here’s the Vertical Slice, a sort of a Concept Document that shows examples and base mechanics of a conceptualized game:

http://www.pdf-archive.com/2015/04/06/tamarrion-verticalslice/)

This is Tamarrion, a Paladin who’s only goal in life is to make the baddies life a misery.

The beginning

The first week has been all about quickly putting out a prototype; a world where we can test and iterate early in.

I’m the Game Designer, Creative Direction and Level Designer for this project. This means that most of the time, I’ll be spending with the programmers, making sure that the creative vision is realized, and that we’re all in sync with the overall product.

I’ve been writing Game Design Documents all week long, and that’s something I’ll be doing over the entire course.

We’ve opted to go with a new way of distributing our design documents, the same way that Godus (a game from the eccentric Game Designer Peter Molyneux) does it. I’ll be creating separate design documents for each area that needs covering. Examples being Camera, Player Movement, Player Combat, Stats, Boss Behaviours etc.

This means that any time a Programmer needs detailed information about a specific task or mechanic it is easily searchable in the google drive.

The beuty and the beast

There’s two main elements in the game scene that have to be worked on early and iterated upon often; The player and the boss. The protagonist and the antagonist.

We’ve mostly worked with simple Hit Mechanics for melee and spells (Hitboxes etc), camera, player movement, AI and animation.

Let’s pick one of them and talk a bit about them.

So, the hitboxes are a integral part of the game.

I decided upon creating two different hitboxes for the boss. The player will hit the Boss with a melee attack if the attack is within the boss hitbox. It is calculated by casting a ray from the front of the player model, meaning that the COLLISION hitbox is seperate from the Melee Hitbox.

The same principle was created for the spellhitbox, but larger. Once again a ray is cast from the player direction, and if the players ray (direction) is within the Spell Hitbox, the spell will be triggered and will automatically fly towards the boss. This is to make sure that the player actually have to do a bit of aiming (although that’s a very small part of it), but also that the player does not abuse the Line of Sight, meaning that it can’t run, facing away from the boss, and cast spells at the same time.

An early concept I made for the hitbox detection of the boss

Aaaand, an early concept of the spell hitboxes.

Seeing how the player has to be able to strafe-move and attack at the same time, the programmers had to make sure that the animations are blended properly and separated so that all movement looks and feels natural.

The camera has probably been one of the main factors this week. The Camera is the lens through which the player will be looking through; the window of the game. It has to fit the game aesthetics. So, we looked at our inspirations: Secret World, World of Warcraft and Dark Souls. We’ve come up with a model that suits our current needs, but since I’m doubling as a QA as well, I’ve already been playing around with it a bit, and I know for a fact that it’ll need quite a lot of tweaking.

EDIT:

Since I wrote this a bit late (I was rather busy all last week), I’ll be updating y’all tomorrow as well with what we’ve done recently.

That’s all for now. Take care!