Trailer created by Ryan Vachon
Download the Game
(25 MB .rar)
Read the Design Document (.pdf)
Design Document written by Ryan Vachon, with additions and edits by Craig Ellsworth
Buzz Ambroseno
Sean Conrad
Bryce Coster
Ryan Vachon
Designer, Voice of Poseidon
Programmer
Artist
Lead Designer
(excerpt from the Design Document, written by Ryan Vachon)
Orion takes place on an Ancient Greek island. The land in which Orion covers is unpopulated and abandoned, and the remnants of the Greek Civilization are strewn throughout the region. Some of the ruins contain magical elements, such as the "Star Catchers," altars devoted to the stories of the heavens that, when in contact with a star, charge with energy, and emit a blast that launches the star back into the heavens. The Greek God Poseidon oversees this region of land and water, which was abandoned after the decline of the Greek Civilization.
The basic structure of the course in which we created Orion was: "You have four months to make a half-hour 3D game. Here are your milestone dates. Go." We were given an incredible amount of freedom to design and build a game. What became of that is a fun, engaging, cerebral puzzle/skill game that the team can be proud of, and an appreciation of the weight of responsibility in a small team.
1. Keeping Scope
Scope is always a huge issue for young game developers, because they want to push forward their grandiose ideas without the resources to make them happen. By keeping scope down to only the bare essentials necessary to get the game off the ground, it left a lot of room open for us to deal with unexpected difficulties or unforeseen necessities.
When we realized it was necessary to add invisible walls to prevent the Player from jumping up to the top of the mountain, or add respawn zones so the Player could not swim out to nowhere, there was more than enough time to implement them.
We were also willing to make cuts for the sake of scope. When management insisted that the Player should be able to control the speed/strength of their projectile, we cut out the ability of the Player to affect the environment (e.g., knock over pillars), because there was not enough time to implement both. We then redesigned puzzles to make use of the new mechanic while trashing or reworking puzzle ideas that required environment manipulation.
2. Working with Strengths and Weaknesses
The team consisted of three designers, but only one artist and one programmer. Because of this, we came up with a game idea that gave a lot of room for level and puzzle design (so all designers had a lot of work to do), but was also as light as possible on the mechanics so the programming went smoothly.
To handle the art needs, the art style was cartoony, so that the artist could create a lot of simple assets in a short amount of time for the designers to populate the world with, then concentrate on the few detail-heavy assets, such as the trident and the area set pieces. The art assets were also made to be as modular as possible, so that simple scaling could change a pillar to a dam/bridge, or a marble slab into a hedge with a palette swap.
3. Walking In with a Prototype
The semester previous, I had created a mechanic in Unity 3D that became the seed of Orion: There were big balls (stars) stuck in trees or floating low to the ground, and you had to send them up into the sky by hitting them with a pea shooter. The final game became very different than my prototype, but it gave us a direction to go in, and a simple mechanic that was easy to code.
The programmer got something to study, and the designers got a space to play in and explore. The prototype play gave us a series of what-ifs: What if the stars fell down instead of up? What if they rolled along the ground? What if they were hard to find? What if they were hard to reach? What if the stars made a constellation when you were done? From these, we refined and reiterated the concept until we reached a fun mechanic and concept that everyone was excited to work on.
4. Equal Say
Although there was a Lead Designer, everyone's input was welcome in the design process, including the artist and programmer. Three designers had three different design strategies, which melded together flawlessly. And when things seemed designer-heavy, the artist and programmer would give their gut reactions as to what was fun. A designer might feel proud of a puzzle, but if the artist or programmer thought it was too frustrating, out it went.
Similarly, everyone had equal say in the art. While the artist certainly knew what he was doing, he asked for input from the less-artistically minded of us to know if the art was good to a layman/lay-player.
Although programming got less of this treatment, when there were bugs in the code, the designers and artist did take a look with fresh eyes, and on at least one occasion, hours of frustration was solved by a cursory glance of an outsider.
What Went Wrong
1. Three Designers, One World
Orion has one contiguous level, designed so the Player, upon reaching the top of the mountain in the center, can look down at the other areas and see how far they've come, and feel proud of their accomplishments. It was also designed that way so the Player can see views of the other areas at the beginning of the game, so s/he can see how much s/he has to do. We wanted this effect from the beginning of design, and we shaped our overall level/world design around this idea.
The problem then became that, when one designer was building the game world, the other designers could not build other areas at the same time. This slowed down the world-building process tremendously, and took much longer than originally planned for. This meant that we ultimately had less time for QA, and the occasional gameplay bug was never fixed.
2. Three Designers, One Artist
With three designers coming up with plenty of level and puzzle ideas, it fell on a single artist to create all of the assets for the game, leading to a tug of war with scope. We began with five areas, which got chopped to four; dozens of puzzles got chopped to nineteen. Ultimately this led to a tighter game (and put the length at exactly a half-hour, as was the goal), but even so, the landscape is occasionally barren.
This also required serious cutbacks in the possibilities for art direction. We were limited to a cartoony feel precisely because a variety of realistic art assets for a half-hour long game could not be created by one artist in four months. Some of the simpler assets were created by a designer (e.g. rocks) to alleviate a little of this problem, and simple modular assets helped a great deal. The designers and programmer also helped with the lighting and particle effects, especially during crunch time.
In the end, I am proud of the art of the game, and think that the artist did a tremendous job, especially given the needs of the project and the time constraints. The game has a unique feel to it, and I always smile when I play Orion. It paradoxically feels warm and inviting, cold and lonely at once. Looking at the art now, I would not want it any more realistic.
3. Subversion Control
Unity 3D has a bit of a feud with subversion control. They don't like to talk to each other much, and when they do, they get into all kinds of arguments. Now, the pro version of Unity doesn't have this problem, but the indie version does. Even Unity Indie and Pro are estranged siblings, and putting them in the same room is disastrous. We thought we were using the pro version of Unity for the project; turns out we were accidentally using both.
Funny story: there were not enough Unity Pro licenses for every PC in the lab where we did our work, so PCs with Unity Pro on them got a little piece of gray tape stuck to the monitors so everyone could see before sitting down if they were at the right computer. Some clueless saps didn't know what the tape was for, and removed them for funzies. Some more clueless saps didn't know the Indie/Pro conflict, and had the bright idea to download and install the indie version on all the machines that didn't have Unity Pro on them.
As a result, we all became clueless saps by not noticing until halfway through the project that the cause of our Unity/Subversion problems was the Indie/Pro mismatch. When we finally uninstalled every indie version of Unity in the lab, things went much smoother. Of course, it took two months to figure it out, which slowed down development horrifically.
4. Keeping Cool
Crunch time is pure dag-nasty evil, as everyone knows. Sleep is for the weak; real men carry IVs of caffeine. Pulling all-nighters to make deadlines does not a happy team make. Tempers flair, arguments over minor issues become Thunderdome matches, and seppuku is as commonplace as Mountain Dew. And even during less crunchy times, setbacks and unforeseen problems can cause plenty of frustration and stress.
As Producer, it was my job to keep morale up and make sure everything went smoothly.
I learned I'm not good at that.
Communication became a big issue, because I am a non-confrontational person. Instead of finding ways to solve personnel problems, I often let them go unresolved, and I just stressed over them, as if I had no control, when I was the one who had the most control. Both game-related and social issues came up that were dealt with in passive-aggressive ways, rather than direct, personal, and sensitive confrontation.
I did, however, grow from this experience. Since this project, I continue to try to improve my social and leadership skills, to make sure such issues are minimized in future projects. I do still have those old tendencies on occasion, but I am striving to eliminate them and develop better habits.
Lessons Learned
1. Design to Strengths... and Weaknesses
One of the more difficult challenges in having a lopsided team is making sure that everyone has plenty of work to do without giving them too much. Trying to create a design-heavy game with simple art and programming needs was the right way to go with this team; however, with design almost always comes more art.
We had our artist create as many modular assets as possible, but it was a struggle to make each of the four major areas looking unique and distinct.
Instead of creating a "design-heavy" game in the sense of level design, it might have been better overall to iterate on fewer puzzles, making them the best they could be. Instead of nineteen stars and four areas, perhaps dropping down to three or two areas would have helped our artist, and dropping to about ten stars may have allowed us to work hard on those and flesh out all puzzle possibilities. More drawing-board time and prototype playing could have given the designers enough work to do without pushing the artist's resources to much.
2. Take the Wrong Role
In becoming producer for this project, I learned a lot about management, but I learned much of it too late. Personal conflicts with other team members brewed and spilled over from the workplace to the social life, and I take my share of the blame for it.
Learning so much in this experience has taught me that I have so much more to learn. I enjoy design work, but being a producer is not for me, at least not yet. In taking on the role, I came to understand how much having a good producer is needed, and also to understand where I do or don't fit in the hierarchy.
Some people have switched from art to design, design to art, design to sound, art to sound, or even learned that game development isn't where they want to be at all. I have seen each one of these switches take place. Inter-disciplinary switches have happened as well, from level design to mechanics, vice versa, etc. I myself switched from writing to level design, and before that from programming to design.
It is important to explore all possibilities before settling down. Sometimes you have to take the wrong role before you realize which role is right.
The Acropolis on the Mountaintop.
Poseidon's statue on the beach, and the Player firing a shot at a star.
View of a puzzle on the cliffwalk. The Player must fire a charged shot at the star over two ramps to get it to the star catchers, and the Player must column-hop to reach the islands.
View of the forest (center and right) and the beach (left) from the top of the mountain.
A star catcher on the beach that just shot a star into the sky.
The Tree Nymph in the forest, stretching like a ballet dancer.
