Context

Eternal Ways is the final project of my bachelor in game design.

The brief was to take the old project and push it further or improve it. So we decided to take the different feedback we had and come up with a new experience.

When :

February-June 2023

Duration :

4 months

Project size :

14 members (7 designers, 7 artists)

Pitch : When Dreadhunter finds himself in a ruined world between the stars and the abyss.

Synopsis : A smuggler who is supposed to take souls across the Twilight Zone to find eternal rest discovers that the abyssal gods are after them. Kushim then consults with the astral gods to try to reconnect the deities.

Data Sheet

Genre Roguelike, Twin-sitck shooter

Camera Third person top down

Mode Solo

Platforms PC

Business model Premium, Without in-app purchases

Target Rogue fans, shooter fans

Producing

The first test of this new project was how to integrate the new people. Meetings were therefore necessary to present the overall idea of the project, to iterate with the newcomers on whether or not to integrate new possibilities into the game, and to set in stone the intentions, so that they were common to everyone.

Intentions and outline of the game

When this work was done, the group split up to implement several concepts to the game such as a final AD, the complete list of different powers, etc...

In order to compile all the information and have a document allowing everyone to refer to something to find information, a Coda was set up. It was also used to centralise documents such as an HCD or an AD document.

At the same time, as we were in the pre-production phase, I started making an Epic Story to plan all the tasks and be able to schedule the production.

View of the Epic Story during its realisation with a calculator on the top left to have an overview per sprint, and on the top right a global calculator.

I then decided to use ClickUp as my project tracking software because I, and especially the people I'm doing the project with, are relatively familiar with it (and it has a rather comprehensive free version for a student project).

I split the project tree in two so that on the one hand the tasks were sorted by what they were going to do in the game, and then the rest of the folders (with the curved arrow) were the projection of the tasks into the sprints.

We then just had to refer to the sprint to find out what was to be done, update it, and everything was done automatically, i.e. updating the task in the other folders and the progress of the sprint.

I also used the classic but no less effective status scheme for tasks. Implemented that can also be translated as "review".

Finally, I chose to define the tasks with :

Assignment: People can directly sort the tasks to see which ones are assigned to them;
The sprint they are in;
A priority so we know what to start with if we have several tasks assigned to us in a sprint;
A label in case we free up time to do a task that is not assigned to us;
Its progress;

Meetings & Macro

When we finished the pre-production period, we set up a new meeting system to optimise production and make them more proactive.

So there were three times a week when we all got together:

At the start of the day on Monday: take the temperature, find out if everyone is motivated and then set the week's objectives.
Depending on the progress of ClickUp and the estimates, a meeting may be organised with the GA and GD leads in the middle of the week to find out where things are going wrong and to discuss the objectives with the main parties concerned.
Friday marks the end of the week, and a review is conducted with the whole team.

Holding meetings with the whole group, of around fourteen people, enables everyone involved to know where things stand and what everyone is doing. It's important to take this into account so that everyone can have the same vision, and the fact that a member of the group can leave at any time for a work placement means that if someone has to take on their work, they'll know how to approach it.

Finally, milestones set up by our lecturers, defining the phases of the project (alpha, beta, GMC) enabled us to calibrate production and get feedback. Despite these deadlines proposed by the teaching team, I drew up my own macro-planning so that it correlated with our project.

← Organisation of macro-planning

Cut by sprint and without the various visible holidays.

I chose to focus on the Alpha period because the DA took a bit longer to fix. We therefore had to make up for the delay in completing the modular modelling and the Lookdev.

The end of the beta also comes at a key point, that of Japan Touch in Lyon, an event where we were able to get a large number of people to test our game. Thanks to all the feedback, we had the last three weeks to polish the game as much as possible.