Wake Up Devlog Week 1

I began my first week of Development by creating a trello board to organise my development, and work in line with Agile Methodology. This will be beneficial to my project, as it will enable me to more easily and efficiently organise my tasks into achievable Sprints for each Week, and to plan ahead in my Development using a timeline to ensure the Development of my Game goes smoothly.

In addition to Sprint Management, I also used my Trello board this week to collate my research links, as well as any Questions I needed to answer regarding more specific Design decisions for the Game. Using covers, I could colour code these cards accordingly.

For example; green covers indicate a Question I have answered, and a red cover indicates a question I still need to answer.

Using Trello’s ‘Labels’, I will be able to distinguish just by looking at the sprint card, what disciplines I will be focussing on in that given Sprint.

   For example, the Sprint for this week involves Documentation, Design, Planning and Research.

   Trello also allows you to set deadlines on cards which will be helpful for time-sensitive tasks and questions during Development.

Having an AGILE KanBan board set up at the beginning of the first Week allowed me to get straight to work on finalising the idea I will be developing, and was helpful for breaking down the steps I needed to take for this first week of Development.

After setting up my Trello Board, I needed to tackle the issue I faced leading up to this week: what Game am I going to develop?

Before this week, the thought had crossed my mind that I could try combining my two Game ideas: however, I was reluctant to do so, due to my uncertainty that the theme and Narrative of my turn-based game idea would meld with the Third-Person Shooter Gameplay loop.

However, after some time mind mapping the idea on Miro, I started to become more optimistic by the minute about the idea of combining the story and theme of the first idea into the Gameplay loop of the second.

As I delved deeper into the idea of merging my ideas, the more my worries about story and Gameplay conflict lessened. I think that a literal battle for escape inside your own mind has the potential to be a powerful metaphor for Mental health issues; and a more sombre and surreal atmosphere can definitely be pulled off in a 3D environment. If anything, it is more feasible for me to do- as a low-poly art style not only gives off that feeling of unease if used correctly; but I feel far more comfortable in that field of art than 2D illustration.

When I was more settled on this Game concept, I set up my sprint tasks for the first week of Development; which involves researching different Roguelike Designs and the themes of mental health i want to portray; finalising the Game concept more thoroughly with this research in mind as well as using Design Theory frameworks; and making a start on my Documentation.

The main questions I began to ask myself after conducting some research were:

What kind of procedural generation will I use?

How will I structure combat encounter rooms and their enemy spawning?

How will I handle difficulty progression, and make the mechanic of choosing the next type of room to progress to more impactful?

The answer I arrived at for these questions linked together:

To give the mechanic of choosing your next room type (each room type has specific rates out of 100% for different encounters; combat encounter, shop encounter etc.) some Dynamics, I decided that difficulty progression should be tied to how many rooms (combat, shop or otherwise) the Player has been to. Each room contributes to the enemies’ gradual increase in stats; so going in too many non-combat encounters may leave the Player behind the Game’s difficulty curve if they are not careful. Additionally, I decided that the determining factor for the Player reaching the boss combat encounter should be how many combat encounters specifically they have been through. This further adds to this dynamic with the room choosing mechanic, as the Player will always reach the boss after a certain amount of combat encounters, meaning that if the Player has taken too long without adequate preparation, they may find themselves outpaced in scaling by the boss.

This dynamic added to the room choosing mechanic makes the Player’s choices more impactful, and will mean that the Player will have to think about what rooms they choose more carefully. The RNG involved in this will also add to this Dynamic; as the Player will never be 100% sure if the encounter they are hoping for will come up, no matter their choice.

As for procedural generation and room/combat structure; I decided that the Game’s combat encounters should be structured similarly to a small floor in the Binding of Isaac. This would allow me to make a pool of room layouts with enemy spawns (can potentially use Unreal Engine’s Level Instance feature for these) and place these procedurally on a grid. This form of procedurally generating room placement and pulling rooms from a pool of pre-created rooms would require less technical finesse than procedurally generating terrain in a large room, and would also allow me to specifically Design combat encounters around the Enemy and Player combat mechanics, leading to Combat encounters being more fun and interesting.

After finalising these details, I began writing a One-Pager Design Document to get the overall Concept with these updates onto Paper so I can show my peers and ask for feedback.

It was Saturday when I started writing my GDD. My goal was to write down detailed descriptions of the main mechanics I had already implemented / am going to implement, and create an outline of the topic / features I am going to write about in the coming days; before dedicating my Sunday and Monday primarily to researching my Dissertation Topic before Week 2 of my Game Development.

In the past, my GDDs have often been a little sub-par. I never considered just how much detail needs to go into a GDD. It was the realisation that if I were to give this to a programmer, they may have to work with that doc and that alone, that made me realise I needed to start putting far more detail than I previously have into my GDDs.

When writing about my Movement and Skill Charges / Cooldown Systems, I made sure to give detailed explanations about the logic of Events / Functions that would be needed, so that if this Document was hypothetically passed to a programmer, they would be able to interpret these descriptions and independently implement the logic into a Project.

Previous Week

Next Week