Game & Level Designer
Tim Andersson
Shell Yeah
A fast paced arena battle party game
"Gather your friends, pick a character and duke it out in a local multiplayer battle game.
Give your opponent a whooping using skills, cunning or dumb luck, anything goes in Shell Yeah!"
PROJECT OVERVIEW
The team:
-
3 Level Designers
-
4 Game Artists
-
3 Animators
-
2 Technical Artists
-
6 Game Programmers
Production time:
-
8 weeks half-speed = Around 160 hours.
Engine:
-
One Engine. Our house made engine
My Contribution:
-
Level Design
-
Level Propping / Level Art
-
Level scripting
-
Game Design
PROJECT DEVELOPMENT
Structure and Goals
For this project we elected to make a simple couch multiplayer party game.
We played Boomerang Fu and used it as a reference for our game. This entailed short, quick
rounds, a plethora of small levels and support for up to 4 players.
The game rules are as follows:
A player wins if they reach the point limit first.
Each player gains a point when they defeat another player.
The match consists of rounds where a random level is picked.
Each round spawns the players and lasts until one, or no one is left standing.
Our Mock-up
Planning and overview
One Engine
The game was going to be built in our own engine and editor named One Engine. In previous projects we would build the levels in Unity and export them which would often create many extra hoops to jump through and be very limiting in assigning data to instanced objects.
We had a rocky start using the One Engine, and we didn't even have a save scene or click to select object in viewport feature at the start of the project.
One important step during pre-production when we level designers alloted time to use the editor and write down issues and feature requests.
First steps
In the first weeks we Level designers took upon us the work of researching and documenting game features, metrics and decided on how levels would be constructed and what features they may use.
The documentation phase was made very smooth by my Level Design colleagues who set up a Miro board, PowerPoint documents and other workflow tools.
Level Designing
As per usual, the levels underwent several development stages. From Paper sketch idea to final product, different people were involved in each level as it underwent passes.
For initial sketching I use pencil and papers
Page 2 of my idea sketches
Level Features
We decided to start off with 30 levels, 21 of them would have at least one of our decided on features:
-
Levers and moving objects
-
Rotating Objects
-
Portals
We created a spread sheet that would make sure we had at least one level with each possible combination of features and started sketching level ideas.
Deciding on the levels
After sketching almost 70 levels together, we had a review session where we looked at each level, graded it and made notes for itterations and ideas. We picked out the 30 levels we liked the best and arranged them in Miro along with our notes, numbering them from 1-30.
These review sessions would occasionally be called throughout the development and we would decide on cuts, changes and discuss improvments and concerns in general.
In our last review session we would place each level in a tier list and work from top tier toward the bottom to make sure we prioritized finishing the best levels first.
The chart where we placed the levels we decided on
Our Miro board
Agile Work strategy
One important question each project is how we utilize source control correctly and make sure we don't step on each others toes by creating conflicts through working on the same file simultaneously.
This was simple for the first passes where I would take levels 1-10, the next level designer 11-20 and so on. This worked fine, but due to difference in thoroughness and general work speed we would move towards simply asking if level X was available for work and informal declarations on what files one would work on.
Later on as graphics artists would wrap up their modeling and started to take on environmental art roles we would utilize a diligent card system in Miro. We used colored cards with names and check marks to signify who was working where and what stage was complete in each level. This worked great but required frequent and diligent source control use to make sure local files always were up to date.
Block-out
Before blocking out each level a colleague crudely modeled the floor of each level in Maya and added them to a numbered scene. This gave us an outline that would speed up rough blocking out even further and would serve as a fall-back floor in case vertex painting would not be available.
Fortunately Vertex painting floor collisions would soon be available and became routine in blocking out each level.
Addition tasks during this stage would include.
-
Placing spawn points
-
Making sure every scene included a camera actor
-
Tweaking scale of the level
-
General iterations on the sketch idea and compromises
Gameplay Ready
After blocking out each level we would move on to replace our cubes with meshes and add other essential features. At this point we could barely game test our levels. Our selection of meshes were also very limmited, so we focused our attention toward making all of the scripts, vertex painting the floor's outlines and building rough large scale scenic features.
Scripting
What our scripting system looks like
More than half of our levels would contain scripted components. Fortunately, we had quite simple mechanics such as moving and rotating objects. Our system did not support exposed variables however, and every scripted component had to have it's own script file.
I learned quite a lot by having to use delta time instead of relying on time lines and it was quite fun.
For event communications we used tags and ID's as we had no way of using pointers to specific objects in our scenes. Like the rest of the editor tools we used in this project, our scripting system was initially unreliable and difficult to use, but it constantly improved and evolved throughout the project as we discussed issues and requested features with our programmers.
"Level 18" features a lever and several moving objects
Hitting the lever would toggle walls between two positions and rotations
Environmental Art and Collisions
During the last two weeks graphics artists had completed their asset lists and took on environmental artist roles. This let us level designers make several passes over the levels where we examined collisions, fixed gameplay bugs, added extra polish to scripts and even tweaked gameplay values.
We spent a lot of time creating invissible collision walls when we realized our models were too complex to handle ricochet well. We had a ton of playtesting during this stage with feedback and bugreports streaming in that kept us busy with many small fixes.