Eyegore - Post Mortem

So it's all done and we've said our goodbyes, but on the off chance that some of the later GDs read this, here are some things were learned along the way that might help you.

Things to Know About Unity if You Don't Have a Programmer
I was the programmer, but I am not a programmer. I learned tons and it was an awesome experience, but there were some hard Unity lessons along the way. Learn from our pain.

1) Always check your animation frame rate. We discovered that Maya was set to 24 FPS and Unity was set to 30 FPS for animation. When you import a 24fps animation into Unity, it pads the frame count to make it 30fps, leaving all your animator's frame numbers useless. Always ensure frame rates are proper in your animation program before exporting.

2) Keep consistent pivot points. You can center the pivots in Unity, but the only ones that matter are the local ones on the object. We had issues where I was destroying and instantiating objects and the instantiated platform was way off position because the pivots were in a different place.

3) Prefabs are awesome! Prefabs allow you to make a prop, platform, enemy and so on and drop them into a scene. If you make a change to one copy of the prefab and apply it, all copies take on the same properties. It's a lot easier than finding 200 individual items in a scene and manually changing them. By the time the end of the project rolled around and the levels were getting dressed up, the prefab thing was not followed. It was ugly and wasted a lot of time.

4) Create prefabs on empty game objects. I learned this early on. For example, I created Eyegore using the animation as the base of the prefab. When we changed the animations and I had to re-import that model, I ended up having to redo all the program links, triggers, colliders, lights, effects and a bunch of other stuff. Creating a prefab on an empty object makes animation or other components just a module you swap out and is very useful.

5) In your hierarchy view you can drop an empty game object into it and use it like a folder. For example, and empty game object labelled 'Walls'. Then in hierarchy you can drag all your in-scene walls into that game object and massively reduce clutter. These may not transfer between builds... at least my team swears they were using them when I turned around enraged at the spaghetti in my hierarchy folder.

6) Animation events are awesome. The documentation for them is great except for one little note. If you have not created the animation in Unity and instead have imported it, animations are read-only. Go into your animated object, and duplicate the animation. I made a folder called 'Edited Anims' and drop it in there with a name like WalkEdit. Replace it in the object's properties. Now you can edit the animation in the event editor.

7) Use colliders instead of triggers where possible. Holy cow, this caused so many spawning issues for us. If your character dies when he hits a trigger, welcome to 300 respawns! Where you need to use a trigger, Mat showed us an awesome couple lines of code that will prevent a character from respawning in the same frame (and can easily be adapted for a longer time scale).

8) Unity's collision can be a little fussy at times. I was experimenting near the end with discrete vs interpolated collision but didn't come up with a definitive answer on the way to go before we finalled. We ended up burying triggers in the middle of solid volumes because having the character fall would often hit triggers a full body width away due to interpolation.

9) Never use cloth physics if you want to pause the game. Cloth plus time.scale = divide by zero. It will kill your game.

10) Sound is fun! It defaults to logarithmic drop off. We did not know that. I had the listener on the main character and the source on the camera. They were too far away and you could barely hear the sound. Log dropoff is really best for localized, repetitive sounds (like the constant crush of a cycling trap, or a local siren). Use linear for sounds you want to hear anywhere or that are one offs (main character noises).

11) Along the same theme, if the sound if still distorted or has strange volume issues, switch it from 3d to 2d. It will clear right up in many cases.

12) Fun fact: if you're doing a side-scroller, a cube collider will act with some weird drag and push the character off the axis. We used a capsule collider and a z-lock script for movement to keep him on track. This also happens to things pushed or pulled along the axis. A quick script will lock them in place. Just make sure your levels are built along the same axis or he'll be free falling.

13) Particle effects are very cool. Unity standard comes with a number of very neat ones that can be updated and changed for your project so you don't have to start from scratch if all you want is a flame or explosion.

14) 'While' loops are bad. Very bad. Worse than cloth/Time.scale bad. It's divide by zero then divided again by zero bad. Anything in an Update function acts like a 'while' statement. So, no while statements, mmm'kay?

15) Don't worry if your code is ugly, as long as it works. By the time the last build rolled around, I was a little embarrassed by my earlier code. It was clunky and there was more efficient ways to do it. However, it worked. I'd rather have ugly and effective than sleek and non-functional. Just get used to saying 'Yeah, I know" with a shamed grin when a real programmer reads your code and gives you a disappointed look.

Good luck and have fun!

Eyegore finished!

For those of you who did not get the chance to play Eyegore you can download it here! http://projects.myvfs.com/games/games/GD18_Eyegore/EyegoreGame.zip

i really enjoyed working on Eyegore and am very proud of our final product. I got to work with a great team and we accomplished a lot in the short three month time span. It was my pleasure to work on all of audio of Eyegore. Making the world of Eyegore sound dangerous as well as adding some humor touches to it as to not take Eyegore completely serious. The audio and world of eyegore started off too serious for what we origionaly designed it too. We wanted to make it fun and amusing to hurl Eyegore into traps and objects and not make it realistic and dark. For this I had to re-design a lot of the sounds from realistic to cartoony to compliment the new style of our game!

As well as the Audio for Eyegore we also had to design levels where it forced the player to die and learn the multiple ways to use corpses. This proved to be more challenging than we originally anticipated. This forced us instead of making large sandbox style levels where we wanted players to explore and solve the level their own way, to create smaller single screen sized levels where players would be forced to learn the mechanics one at a time as to not get overwhelmed. In the end players string everything they learned into the larger levels that encourage players use that knowledge and explore.

in closing
The experience of working on Eyegore was great and I had the pleasure of working with Blackwell and Larissa on the game. Now its portfolio time and off to job hunting! You can view my portfolio at TimWirch.com

Happy gaming and i hope you try Eyegore out and let us know what you think!

Remember Dead or alive, Eyegore is useful either way

Concept to Complete

Final Build

And we're done here...

Eyegore started as a three person project with no programmer and all of us staring uncomfortably at a blank screen. It finished as a side scrolling platformer featuring a ne'er-do-well hunchback and his travels through a dangerous castle.

Concept!
We knew without a programmer that we would have to keep the game focused and realistic for our skill level. Unity classes at VFS taught us how to move right and left, add velocity and write stuff on the screen. We could work with this.

Pre-pro gave us an ambitious (9 traps! Multiple interactions! Full ranking and scoring systems!) plan. Time-wise, this proved a little over-ambitious and we cut out the extra stuff. More traps would be great, but also would be overwhelming for players in a 5 minute experience. A ranking system started running counter to the game design as people found their fun in killing Eyegore as many times as possible in a level as opposed to completing the game as soon as possible. After alpha, we made some serious cuts and got the game in working order.

Redesign!
However, alpha had another set of challenges. We had been ignoring the people saying 'but is it funny'. We assured them that, yes, it eventually would be funny. Just... not right now. But why wasn't it funny? That's a real problem and it threatened to derail us. The game hinged on humour and we just weren't bringing it.

This prompted a redesign on sound, some art and animation. A bunch of assets were scrapped and reimported. We brought the game back in line with what we wanted from it.

From there on, features and fixes were the words of the day. We brought a (mostly) working copy to the table on industry night. There were some collision issues that continued to elude us, but all in all it was a solid little piece of work.

Industry night!
Seemed to be a bit of a love/hate thing. We took a chance in our presentations with using a specially designed demo level. We found that we had a lot of trouble directing the viewer's gaze with our playable levels. So much shiny! It worked well for some, not so well for others. We got dinged a couple times in feedback for presenting an 'unfinished' game level. Ouch. :(

We got some excellent feedback in person though. Some great thoughts on how to make the game more casual, and how to make it more hardcore. Someone called us the most 'hardcore art game'. Interesting for us since we felt we skewed way into casual, but it was pointed out that the lack of direct instructions in a game (do this X times or lose) actually skews the game hardcore.

Very cool to get different perspectives on this.

Final thoughts!
All done now, and what a ride. It was a great experience working both within our team, and with the other teams in the class. It's left me wanting to do more, and make better games (and hey, now I can program... a bit).

Oh, and see my portfolio at larissam.ca.

VFS Industry Night Impression

It is a weird feeling having so many eyes on a project that until the night before was only for us. Overall impressions were very positive, with one Industry Mentor calling us best in show, and Tim from Massive Bear, saying he'd never seen anything like it.
The constructive comments were also very helpful. we need to work on our death animations to further sell the point and the humor. One piece of design commenting stood out that each of the levels should have had Eyegore attempting to do something before going to the door rather than just straight on navigation, which I found intriguing. I like the idea of a goal to complete beyond the end, lending itself to a larger plan for the game. Something to ponder.
As a whole I think Eyegore stood us very well and will continue to do so as we tweak and improve it down the road. See Blackwell's portfolio here bhird.com

FINISHED!

We have gone gold. The game is finished and we are still alive. though I think its left a mark us...

Once we have our industry night done or at least dealt with, we will post more images of the final game.

Eyegore around town

We we're told to decorate our space, in line with the theme "making games should be fun".
Our window was no exception

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.