Hello!
I'm starting here the first of a few posts detailing how I and my team, Team Esoteric Reference, arrived at our final build of our sophomore game project, Poly, last year, after two semesters of grueling work sessions, spontaneous bouts of testing, and lost sleep.
The final version looked like this:
http://www.youtube.com/watch?v=nM1Mytmdo9c
To explain how we got there, I will begin, logically enough, at the beginning.
Poly's Inception
I first thought of Poly during the summer of 08, in a special place where I get most of my better ideas, fondly referred to as the shower.
I began considering two completely different games, and how I could combine them.
To keep the history short, I decided to take Spore, and Katamari Damacy, and attempted to find a middle ground in the miles of grey area between the two.
A few core concepts came out of this thought experiment that I wanted to use:
1. The game should be simple, and readily accesible. If a ten year old can't figure it out in 60 seconds after clicking the executable, there's work to be done.
2. Gameplay should change as the player progresses in an analagous manner to earlier challenges; Don't change things completely, but give the player more options and new things to do as time goes on.
3. The player's mobility should increase over time.
4. Above all, the game should be fun. If any specific idea is preventing or limiting the quality of the experience, it should be released.
I knew then, and still know, that it's impossible to steer the ship in the perfect straight line chosen at the game's inception. I decided early that if big changes were needed to focus on the fun parts, they would be made.
I had no idea just how much things would change as the game grew, but the final result certainly didn't look like the original blueprint. Nor should it have, in my opinion.
The Plan, V 0.1
Poly's High concept as per the first draft of the GDD read as follows:
"Poly is a fast paced, action packed, puzzle platformer"
Our target demographic was boys and girls, ages 10+.
The original gameplay plan for Poly would have 9 separate character forms, each unlocked by collecting either 3, 6, or 9, of one of 3 mutually exclusive types of powerup.
With these abilities, the player would be solving puzzles and defeating simple Mario-style enemies on their way to the goal, usually on the right edge of the level a la Sonic The Hedgehog.
Collecting one of type B after having 5 of type A would restart your counter, and put you on the type B track.
I'm starting here the first of a few posts detailing how I and my team, Team Esoteric Reference, arrived at our final build of our sophomore game project, Poly, last year, after two semesters of grueling work sessions, spontaneous bouts of testing, and lost sleep.
The final version looked like this:
http://www.youtube.com/watch?v=nM1Mytmdo9c
To explain how we got there, I will begin, logically enough, at the beginning.
Poly's Inception
I first thought of Poly during the summer of 08, in a special place where I get most of my better ideas, fondly referred to as the shower.
I began considering two completely different games, and how I could combine them.
To keep the history short, I decided to take Spore, and Katamari Damacy, and attempted to find a middle ground in the miles of grey area between the two.
A few core concepts came out of this thought experiment that I wanted to use:
1. The game should be simple, and readily accesible. If a ten year old can't figure it out in 60 seconds after clicking the executable, there's work to be done.
2. Gameplay should change as the player progresses in an analagous manner to earlier challenges; Don't change things completely, but give the player more options and new things to do as time goes on.
3. The player's mobility should increase over time.
4. Above all, the game should be fun. If any specific idea is preventing or limiting the quality of the experience, it should be released.
I knew then, and still know, that it's impossible to steer the ship in the perfect straight line chosen at the game's inception. I decided early that if big changes were needed to focus on the fun parts, they would be made.
I had no idea just how much things would change as the game grew, but the final result certainly didn't look like the original blueprint. Nor should it have, in my opinion.
The Plan, V 0.1
Poly's High concept as per the first draft of the GDD read as follows:
"Poly is a fast paced, action packed, puzzle platformer"
Our target demographic was boys and girls, ages 10+.
The original gameplay plan for Poly would have 9 separate character forms, each unlocked by collecting either 3, 6, or 9, of one of 3 mutually exclusive types of powerup.
With these abilities, the player would be solving puzzles and defeating simple Mario-style enemies on their way to the goal, usually on the right edge of the level a la Sonic The Hedgehog.
Collecting one of type B after having 5 of type A would restart your counter, and put you on the type B track.
The original idea was for our character, Poly, to be a polygon with many forms, hence the name.
He would collect Triangles, Circles, and Squares, each of which would change his shape and abilities.
Triangles would allow him to walk on walls, and launch projectiles.
Circles would provide a variety of speed boosts.
Squares would allow the player to break barriers, and spawn platforms.
Why?
My reasoning behind the mechanic design was to offer something rarely seen in platformers: A chance for users to feel creative.
I wanted to offer the players multiple branching paths, each having it's own challenges, to be overcome by their own solutions, comprised of tools the player was familiar with. The goal was to allow players some control over how they tackled the level, so that they might feel more accomplished than having simply followed a one way path through the level.
As far as graphics are concerned, we took a very unusual route for a student 2D game team.
We chose to use animated 2D meshes rather than strict sprites, animating them via linear interpolation frame by frame in an analogous manner to 3D models.
This gave us the spiffy transition graphics from form to form that persisted through our many iterations of gameplay.
The original game plan called for 3 full length levels, and 3 one-third length levels, to serve as tutorials for new mechanics introduced in the next level.
Preparation
I had learned enough C# / Windows Form creation over the summer on my own to serve as sole tools programmer, as well as level designer. I would be making my own level and object editors. The basic level editor was functional by the middle of first semester, while the engine , physics, and graphics were still under construction. The object editor evolved into a mesh editor, and was made irrelevant by later design decisions.
I played through Sonic the Hedgehog 3 & Knuckles with my art director, We Love Katamari, and Spore on my own, before beginning this game, to have examples of nonlinear design as well as physics-intensive and platformer level design fresh in my memory.
We had a physics and graphics sandbox roughly working, though true 2D physics, with arbitrary terrain collision, would prove immensely difficult. Note that when I say arbitrary terrain collision, I mean our terrain was composed of lines of arbitrary length and direction, each stored as two 2D points and a normal vector, to decide the direction of collision. This was done to allow one-sided platform collision, which is an expected idiom in most platformers.
Our physics were bug laden until the very end (I thought we'd never figure out why 90 degree angles broke the game), but we managed to have arbitrary terrain collision, inertia, rotational velocity, and at one point, friction, by the time we were done.
Conclusion
At the end of the pre-production phase, before constructing our first playable, all of us, professors included, were incredibly excited to see where our game would end up.
No one could've guessed how difficult certain mechanics would be to implement, how time consuming it would be to polish even the most basic level content, and just what about the game our testers would find fun.
