It’s finally over…
Hello everyone! It’s finally time, to get down to the PONCHO postmortem, where we talk about everything that went right, and everything that went wrong with the development of the game.
It’s a been a long, almost 5 year journey that has changed us forever. Now, a year after the initial release, it’s time to spill the beans on everything we’ve been through.
Before we do that, first we must say with a heavy heart that we’ve been forced to give up on the Vita port of the game. Things out of our control are stopping us from actually sending it to Playstation, and we have no choice but to cease development of it. Unfortunately, we can’t give any hard reasons for the cancellation without incurring some kind of legal penalty.
We hope we haven’t disappointed anyone too much with this news, but it is what it is. We’re truly unable to pursue it any further, and believe me, we’ve tried. With that out of the way, here we go…
Winter 2011: It begins with a sprite
It’s 2011. Danny Hayes (me) and Jack Odell both have day jobs, but wanted to make a video game of our own. We decided to go full indie, and make something we knew would take years, and put everything we had into it, with the ambition of making something on the scale of BRAID or CAVE STORY. But we had no idea what to do. We were young, optimistic, and filled with big dreams of creating the next indie hit.
Then, one day, Jack created an interesting character design:
I instantly fell in love with this character. I was excited. We still didn’t know what kind of game we’d make, but we knew it was going to be about this guy. A platformer seemed like a good fit, so we spent some time talking about how to make it innovative and interesting compared to other Platformers.
Both Jack and I talked about retro inspirations, namely parallax sidescrollers on the Sega consoles, and how you’d see mountains and hills in the backgrounds, but you could never actually go there.
Jack suggested we could separate the game into layers and shift between them at will to achieve that idea. We then we named the robot after his red namesake and thus, PONCHO was born.
2012: A year of idealistic struggling
Before PONCHO, I had coded mainly for iOS and in C++. I had no idea how to use Unity, but decided it would be the best option since it had easy porting and was more accessible at the time than the Unreal engine.
Throughout 2011 and most of 2012 we went through a bunch of prototypes, re-designs and re-codings as I learned how to use the Unity engine more effectively. At this point, I did the code and level design, and Jack did the music and art. It went something like this:
Build the game in actual 3D, using a world of 3D cubes with 2D characters to create a 2.5d effect. Realise that it doesn’t look good and start again using a 2D planed environment layered over itself hundreds of times to create the 2.5D effect we wanted.
Redesign of PONCHO to make him more cute and iconic looking
:
Design level art to look like this:
Start adding some cool ass characters:
It went on like that. By the end of the first year of development, we had most of a story, basic shifting gameplay and several levels with a bunch of characters and menus. But while mine and Jack’s art was passable, we wanted a real pixel pro to join the team and take over the art side of things.
2013: Matt joins the fray!
I posted on a bunch of pixel art sites, saying that we were looking for an artist to join our team. I had saved some money from my day job so we could afford some real talent. We got something like 50 applications, including one guy who strangely only had a portfolio of Hentai to show us, and one who’s portfolio included nothing but a single pixel art tree. Luckily there was also Matthew Weekes and he was just the best. After several months, the game looked like this:
Awesome. We finally had a quality game on our hands, and everything was starting to feel real. Also, in case you were wondering just how many layers and images are on the screen at any given time, have a gander at this early progress level:
The design issues
Designing Poncho was tough. As well as designing each level plane and making sure things like jump distances and obstacle placement was perfect like any other 2D platformer, it had to be designed so that it would work in sync with basically 2 other levels that you can move freely in between. We had to make sure that puzzles and obstacles on one layer couldn’t simply be bypassed by shifting to another layer without some thinking.
Additionally to make things more complicated for us, we wanted to make the game pseudo open world, so the player could choose to go left or right and still complete each area, with multiple paths and choices in which puzzles to tackle. So levels also had to work in a way where each plane would have to match up to the levels either side of the current one. Each “world” is made of a ring of levels, so by moving in one direction, eventually the player would be moving in circles effectively. This removed a lot of the stress of backtracking, instead of being at the end of a level and having to move all the way back from where they came, the player could take a shortcut by continuing to move in the same direction.
So, instead of working with pen and paper (which we did at first), I designed most of the levels in engine, moving things around and playing until each level felt like a cohesive whole where each layer was in sync with each other. It took a long time to get each level right.
Originally, we were gonna setup levels with varying numbers of planes, possibly going as high as 9 planes or so, but we felt that having only 3 planes would allow for a more concise and simplified design, plus it would far less development time.
After getting a feel for how to create levels we started to get creative in different ways we could use the shifting mechanic and added some cool effects:
Obstacles and blocks that shift on a timer
Obstacles and blocks that shift when you do
Levels that move between 2D and 3D, merging layers on a timer (That’s the infamous Disco level)
Levels where the view is set in 2D but the player has to think in 3D space (The great lake)
Anti Shift fields that stop players from shifting in certain areas
Level planes that slide horizontally and move over each other
Machines that would merge large numbers of layers and place the player on the front on back layers (seen in the later levels)
And more…
There were also a bunch of things we wanted to do and were in the original design, but ran out of funding before we could add them into the actual game:
Fields that were connected to doors, if the player shifted within the field, the door would shut and the player would have to attempt the puzzle again
Oil slick areas where the player would slide along quickly and have to time jumps and shifts
Super layered levels, where there were several layers in a single level
Shift fields that would throw you back if you shifted into them