The Art of Pain

Cheers everyone.

It has been some time since I graced this space, and today I want to talk about my role on Eyegore as the artist. Many people think the artist stops at the concept phase, spinning vivid images from dreams and half remembered mumblings of the writers.

Not so. The artist on a three man team is much like being a swiss army knife of skills ranging from sculptor, to illustrator, to fortune teller. 

On eyegore, the process starts with a concept doodle in a notebook, and a tap on the shoulder of our majesty whose spread sheet reigns like an iron curtain over our heads. Then, if she approves, I bring it into a more formalized picture... 

And almost immediatly throw it out and begin sculpting in Maya. This is because the message the form has to send needs to be as obvious as possible, and often times it only becomes clear int he making of it.

The fire trap for instance started life as something akin to a jet funnel, with pipes connecting to it. What it ended up as was something closer to a large flamethrower welded to the ceiling, with fuel tanks on either side. Not the safest design choice, but more visually striking.

 to this

That leap required the aforementioned sculpting and divination, but I'll gloss over those in favor of brevity.

Next up is to make it look like a flame thrower. To do this involves another skill, UV mapping. For those not in the know, it is the process by which you make a 3 dimensional object into a flat map onto which you can put pictures. The process by which we unfold that object is UV mapping, and has been known to cause death by boredom. A lot.

but in the end you end up with something like this. They map gets more complicated the more organic the shape. Eyegore's UV for instance has been known to calcify many an unprepared eye.

Then comes the illustration portion. I have to paint details and textures onto this map, which are then applied to the 3D object to give it the final look you will see int he game. Now replicating the texture and feel of a real world object using only the hand takes years of practice and patience. 

So I cheat.

A Lot

I go out on the internet or around town and take close pictures of objects, then overlay them on my art to create those difficult details in a fraction of the time. Photoshop is your friend. In the end the texture will look something close to a mess. Only the specially trained or the insane can accurately interpret these arcane cartographes with any accuracy.

Finally, this is applied to the 3D sculpture and it goes from gray block, to awesome game asset. There are other things to add: A normal map which gives the illusion of depth and geometry, a specular map to tell the light exactly how to act when reflecting of the surface, or an occlusion map which is a mystic science I still don't understand.

Lastly it is exported into a file that can be read and loaded by Unity3D as an asset into the game. It also has an animation applied to it, but that is a conversation for another day. When all is said and done, the fire trap will now spit fire and prove very fatal to any and all comers. 

Until next time, I leave you with a picture of what I am doing currently, figuring how to put hints on the wall of our castle so players can die in the ways we intend.

Wait...

I'm getting an error.

There is more than one audio listener in this scene?

So, infinite respawn is... bad?

Jazz Hands!

Time to import the transitional animations for Eyegore.

Wheee!

Our last import day brought us the Stringbean.



















Today Eyegore is rocking some amazing 40 foot arms and some awesome jazz hands.

Truth, Lies and Project Management

Project Management and you...

I'll talk about coding another day, but for now I'd like to look at being the project manager of a 3 person team.

At one point we were asked to describe our style of management. Somewhat confused, I replied "Tyranny?". Apparently they were asking about Agile versus Waterfall. Pfft. Whatever. The point is, the world's in a mess and I just need to rule it... I mean manage the project. Yes.

Given that there are three of us and we have a metric crap ton of work to get done, it's obviously not feasible for me to be a full time PM. I look at it more as a project coordinator. A facilitator of projects, as it were. So what is the key to managing a small team with a lot of work and very little time? Well, it helps if the team is receptive to being managed. Luckily, this team is. And done! Okay. I'll try and break it down further.

Sprints
We start every Monday with a short meeting. I go over the task list (excerpted in really tiny script above for your viewing pleasure) and we assign a sprint for the week.

It's an unholy blend of agile and waterfall where the 'due dates' we came up with in pre-pro function more as a guideline and not a rule. They gave us a rough idea of the priority of the tasks to be done, but are not set in stone.

Each person has their own colour of stickies so they can easily see if there are any dependencies (I stack related stickies, so that the yellow at the bottom is waiting for all the top stickies to get done). I first ask if anyone has a preferred task set they want to complete, and assign that. After that, or if there are no preferences, I start writing sticky notes until my target starts to whimper.

The key here is knowing how your team works. That's rough at first, but it's important to get a sense of the pace of work, and how well your team members estimate time. I've been tracking this just to make the numbers official, but I feel pretty confident that 80 - 90% of what I assign in the week is doable (the remaining is there to allow some flexibility in how we work or for priorities to be rearranged).

The sticky notes are up for the week, and I mark the task as assigned in the spreadsheet. When a task is complete, the team member leaves the sticky note on my desk, I tick it off the task list and toss the finished sticky onto the pile.

The Spreadsheet
The fastest way to get someone to leave you alone is to open some giant, multi-coloured spreadsheet. Most people have an innate fear of Excel and will immediately back away. We have such a spreadsheet. It was based on a template I found in the Necronomicon and we've been pretty happy with it (except for the faint sobbing noises you hear late at night when it's really quiet).

Really, the only point of setting up a spreadsheet is to catch all the minutiae of game design. Not every group will want or need this. It depends on your style and organization. I have no style and terrible organization, so spreadsheet it is!

The task list is really broken down into small detail. For example: the Brain's model, UV, texture, move animation, idle animation, script, voice recording, voice processing and adding each component into code are all individual tasks. I could have simply put "Brain - 20 hours" but that really doesn't tell us dependencies and it's a lot harder to estimate time on a monolithic piece of work like a major game character. Currently, the game's main character Eyegore has 33 sub-tasks to be completed just to get him in game and working.

I made a quick set of graphs up for the team. You can see them above. The blue line is projected work done, the red is actual work done. I got rid of all the stuff we purged from the project and it's actually kind of cool how well they're matching actual and expected. Woot?

Originally the graphs were set up to check for outliers, like the time I had to say "Hey guys? We have 36 days of work planned for this week's sprint?". That's the time to go back and rebalance the workload. That's easier with an agile system, but you always have to keep a tight rein on the backlog or else it's going to be week 12 and people will be sobbing under their desks (more than usual).

One really important thing to note is that nobody cares about your spreadsheet but you. Seriously. Mine's covered with graphs and arcane formulae, but they only matter to me and only insomuch as it helps keep the team on track. Numbers can be absurdly fun to crunch (oh god I'm a nerd), but keep them relevant and understand their meaning and why you track them. Also understand that if you ever hand in your spreadsheet, you will be expected to explain it. So, that's where the lies come in.

I've said too much.

(The average reaction to seeing a project manager's spreadsheet)

Hello!
i'm Tim Wirch, Lead level designer and audio guy for Eyegore!

here posted is an early whitebox level for Eyegore. This was for our testing the traps out as well as multiple pathing options and to see how long our levels for our vertical slice slice should be.







as you can see we now have textures for most of the wall tiles as well as for the traps and Team whimsy now has particle effects on the traps and sounds for the traps as well!

Eyegore the First

Hello Hello, one and all!

Welcome to team Eyegore's game blog. join us as we construct the most work environment possible for our minions. Currently in testing is Eyegore, our pet hunchback. He must try to make it back to our lab, while escorting a surrogate brain past all manner of nasty traps. the brain you see Behind him is a mobile cloning machine, so no matter how hard he tries the fun never ends!

Here he is warming up

Now obviously we ensue that all our minions are fully fire compatible, as well as ice, electric, and kinetic (squish) compatibility. all of this means our Eyegores are more than capable of mortality at a moments notice!

Currently our castle is in the pre-alpha stage. Sometimes Eyegore manages to escape unharmed, other times manages to get his squishy self jammed inside walls. But rest assured, Eyegore will not escape our... enthusiasm for lethality.

Thats all for now, stay tuned for more posts by the rest of the team in the coming month!

Welcome to Eyegore

Welcome to Eyegore. I'm Larissa, the "coder" and project coordinator of Eyegore. I use quotes around "coder" because my coding could best be described as basic. As in the last code I produced on my own was in Basic. However, Unity is fairly user-friendly for a code-scavenger like myself, so on we go!

I'll start my description of Eyegore with an anecdote. When I was 12, I played my first game of D&D. At the behest of a fellow 12 year old, I painstakingly created a barbarian. We lovingly crafted all my skills, my gear and my various and sundry items I was carrying.

Proud of my creation, I took my first step into the GM's world.

And I died to a trap on the door into the dungeon.

This brings us full circle to Eyegore, a game where you die to traps instantly and repeatedly. An homage to all sadistic 12 year-olds everywhere, I guess.

We're taking the sting out of death, making it fun, funny and important. Going against the gamer instinct for self-preservation, we invite you to toss Eyegore gleefully into ice, fire, spikes, and electricity as you travel through the castle. We hope you enjoy this look at development and the game it becomes!