This week marks my return to university after the Easter break. Thankfully, the break was very productive and I managed to complete everything I wanted to. I feel like I’m now in a very good position going forward into the later stages of this project. I still feel like I have plenty left to do, but I’m feeling more optimistic about getting Denizen to a polished state.
During the first week of Easter I took a five-day trip to Belgium to recharge my batteries. Prior to my trip, I was beginning to feel quite fatigued with the work I was doing and not terribly enthusiastic about how much time I had left. While in Belgium I visited The Atomium and its accompanying design museum, the Art & Design Atomium Museum or ADAM for short. I also visited the Musical Instruments Museum and took a trip to Bruges. Overall, it was a fantastic trip which allowed me to reflect on my work and look at the bigger picture. When I returned from Belgium, I started to plan my work schedule for the remaining time I have left on this project. With the end approaching I could see what parts of Denizen’s development needed to take priority over the others.
By the end of the Easter break I had managed to design all the puzzles for Denizen and the level structure on paper. During the last week of the Easter break I began prototyping these puzzles and managed to create Denizen’s first level. Sadly, I found that translating my paper designs into playable puzzles took a lot longer than it should have. Sometimes simple things, which on paper seem rudimentary can sometimes lead to an hours’ worth of coding. In one puzzle, I designed two elevators which the player can use to navigate the puzzle space. On paper, you think it’s just something which needs to go up and down and it seems quite simple. However, translating that into the game means you need to consider a lot more. How does the player call the elevator? Can the player call the elevator when it’s moving and interrupt its motion? What happens when the player stands under the elevator when it moves down? Will they be killed? Will the elevator push them away? What happens when the player jumps while riding the elevator? How will the collider of the elevator intersect with the floor? How will the player’s movement be affected by the elevator’s movement? How can you prevent the player from becoming ungrounded as the elevator moves down? What’s the best way to move the elevator? Should it be an animation or coded? Should I use a Rigidbody or the Transform component? And that’s just an elevator, don’t get me start on the chain I had to make for the same puzzle. These questions need an answer, and on paper, you can take that for granted. Despite this, I still think designing on paper was the correct approach, if only so I could get away from the computer for a bit. In future, I feel like I will be able to think about these kinds of considerations more while I’m designing. Hopefully, I’ve learned my lesson.
Over Easter I also thought about how I’m documenting my progress with Denizen. In previous projects, I’ve documented my code extensively, because, for the most part, that was my main job. On this project, I have yet to document my code as thoroughly as I have done before, even though I’m spending most of my time on coding each week. I was planning to create more developer videos, but according to my YouTube statistics, they don’t get viewed. I think creating more would just be a waste of my time at this point, but I still need to think about how to document the less obvious work I’m doing. I may end up creating a longer video towards the end of the project, but that depends on how much time I have left. However, it’s my understanding that our grades on this project will consider the quality of the finished project over the portfolio and documentation. Either way, my coding work still needs to be documented in some form, I’ll need to think about this more over the coming weeks.
After my productive Easter break I was looking forward to getting back into university and playtesting a few of my puzzles with the class. On Friday I had the opportunity to test most of the first level with Adam and James. Although the level is not in a finished state by any means, most of the gameplay is there so I was able to gather important feedback from each of them. This feedback resulted in some much need changes to the puzzles and the way the player commands their companion. Once I have implemented further changes I’m planning to continue playtesting with other members of the Games Design course over the coming weeks.
Next week, my plan is to get the first level fully playable and then conduct more playtests on Friday. I want to get the gameplay finished before the end of next week because I want to devote a lot of time to audio. I think music is integral to the experience I want to create and I don’t want to rush it at the last minute. It’s vital for building the atmosphere in Denizen and so it deserves the time.