Producer Role
When we started the project, the team had never worked together before so my first challenge as producer was to create and establish a pipeline
that worked for all departments to make sure that everyone could deliver their work on time. Role Breakdown
The first months we created a production team which ensured the team selected an idea amongst all the brainstormed ones after rating them based
on the teams interests during development.
This was particularly important because some of the hardest challenges for the whole team were defined due to the game that Dorothy's Job came to be
since the very begginning.
The procedurally generated level system, how to show the different types of dirt on the floor, keeping the twin-stick genre core mechanics adjusting
them to a cleaning-like gameplay...
All these things repercuted in the game's development roadmap and made us constantly reconsider
the game's scope.
• Choosing milestones carried tough decisions. We decided on four different deadlines in which we would
evaluate our own work.
Those dates were; First Playable (around 2 months of development),
Alpha (4 months), Beta (7 months) and Gold (final release).
• Had to evaluate the productivity of team members to ensure there were no bottlenecks and to detect potential problems, for example,
stopping iterative processes on time so some features didn't need to be delayed.
Features Developed as Producer:
Challenges & Solutions
We had to iterate until we found our pipeline
Due to the nature of each departments tasks, this pipeline was a bit tricky to create. The design team needed a bit of time at the begginning
to start creating the game's basic core loop and deciding what was going to be in the game, but since we couldn't afford having
part of the team in pause we had to plan ahead and start getting work done.
At first, the design team changed the game so much in such short time that the programming team couldn't start getting the system's
up in engine.
The deadlines helped us to affirm the game concept and get some things carved in stone. The first great milestone, the First Playable
, was a prove of concept that helped us define what was Dorothy's Job going to be and most important, what it wasn't.
The milestones helped the team create a common idea of the finished product and made us share that vision, as well as help us, the producers,
ensure the direction and decisions we took were working towards a defined game.
Conflicts between departments
Some game's characteristics required features that could jeopardize the whole project and resulted in tension and conflicts between team members.
As an example of this, the procedurally generated level idea that the programming team decided to take as a challenge, while adding so much
to the game, compromised aspects regarding other departments.
Due to this programming decision, the art team was tasked with creating enough
rooms to fill the pool, to make sure the algorithm had enough rooms to create different levels. The design team planned that at least 50 rooms were
needed to feed the level generation so the 3D team needed to create models, dress and illuminate that many rooms before we could make sure
the system worked as we wanted to.
This compromises built up tension for some members of the team, to the point that some disagreements and stress materialized into fights
in which I, as producer, had to mediate and solve.
Game Designer Role
Role Breakdown
The first months we created a production team which ensured the team selected an idea amongst all the brainstormed ones after rating them based
on the teams interests during development.
This was particularly important because some of the hardest challenges for the whole team were defined due to the game that Dorothy's Job came to be
since the very begginning.
The procedurally generated level system, how to show the different types of dirt on the floor, keeping the twin-stick genre core mechanics adjusting
them to a cleaning-like gameplay...
All these things repercuted in the game's development roadmap and made us constantly reconsider
the game's scope.
• Visibility carried though decisions. The two types of dirt planned for the game (liquid and dust) needed to be shown on the floor, and must be visible through all
the different enemies, bullets and status effects, the UI. That created some disagreements, discussions and iterations throughout the
development in which production needed to adress and mediate.
• Had to evaluate the productivity of team members to ensure there were no bottlenecks and to detect potential problems, for example
stopping iterative processes on time so some features didn't need to be delayed.
Challenges & Solutions
•The procedurally generated level tool
The procedurally generated levels were a programming team request since the start of the game's development.
This affected the project in such a way that the game's beatchart, QA and narrative development couldn't be implemented until
the programmers managed to develop the level-creating tool and made sure it followed the design team's guidelines properly.
We (the production team) needed to make a tough call and choose whether we trusted the programmers to get it on time or we told the
design team to start designing the levels manually (our plan b, which was close to becoming true), and
loose one of the
most charming aspects
of our game.
After a bit of a push and getting dangerously close to the deadline, they managed to pull through and finish it on time and the game
got a marvelous level generating tool.
•Visibility ingame and color coded information
Due to the game's genre, the design team planned lots of different aspects of the game that needed visual representation
in game, mostly on the floor which was the part the player saw most of the time. This made it so the art team had some trouble
whilst deciding how to color code the information.
Game Designer
ROLE BREAKDOWN:
As Game Designer, I was part of team of 6. We picked up the game since the brainstorming phase and starting developing the game concept into gameplay. Since the game idea came from the main character, Dorothy, the whole game needed to circle around a buff cleaning maid.The nature of the game made us have to take some concessions in what twin-sticks shooters are and some mechanics which are common in this genre. For example, given that Dorothy is supposed to clean the mansion, props couldn't break by player actions and leave debris.
This was particularly important because some of the hardest challenges for the whole team were defined due to the game that Dorothy's Job came to be since the very begginning.
The procedurally generated level system, how to show the different types of dirt on the floor, keeping the twin-stick genre core mechanics adjusting them to a cleaning-like gameplay...
All these things repercuted in the game's development roadmap and made us constantly reconsider the game's scope.
• The procedural level generator tool was a requirement from the programming team which challenged them to have it on time
for release, and forced the production team to have constant backup plans in case it didn't meet the quality standards.
• Visibility carried though decisions. The two types of dirt planned for the game (liquid and dust) needed to be shown on the floor, and must be visible through all
the different enemies, bullets and status effects, the UI. That created some disagreements, discussions and iterations throughout the
development in which production needed to adress and mediate.
• Had to evaluate the productivity of team members to ensure there were no bottlenecks and to detect potential problems, for example
stopping iterative processes on time so some features didn't need to be delayed.
