Table Of Contents:

Project Planning

The first thing I do on every project now is a brief module brief. Essentially, I’ll read through the module brief and summaries the project goals, submission requirements, and the expectations to achieve the top marks. It serves as an exercise to better understand the module, and as a tool to reference later whenever I need a quick piece of information.

Brief Module Brief

Another thing I generally do is a week-by-week plan where I list tasks at the start of each week and cross them out as I go along, as well as map out milestones and deadlines. I struggle with long term planning, so adaptable short term planning like this works better for me. It also allows me to get a good picture of the amount of time I have left. However, project planning with Jira is required for this module so I need to adapt my strategy. I am very unfamiliar with a lot of the systems and jargon used on Jira, but I do know how a kanban works. My previous planning method can be transferred reasonably well to a kanban chart, as all I need to do is list these tasks in to do/in progress/done categories. I have also added a priority column for deadlines (and journal categories as I often let them fester in my backlog and forget about them) and a next tasks column so I can plan what I will do imminently once I finish other tasks. I’ll need to get a better idea of how Jira works and what is expected and revaluate my project planning, but this works for now. I may create a long term gantt timeline once I have a more specific overview of the entire project.

image.png

Proposal Meeting

I had a meeting with Joel discussing my project plan. My primary concern was understanding the potential scope of the module. This module is much larger and less prescriptive than any other I’ve done, alongside my project idea being potentially much more extensive than I could possibly do within a university project. Fortunately, Joel was confident I could achieve the upper limit of what is expected, and that a vertical slice is ambitious but possible.

After discussing further, we figured the best focus would be selling the idea of a larger world and game. As I’ve already put a lot of effort into building the larger world in my GDD, it would be worthwhile trying to convey that world by making sure the player can see areas they could potentially explore if they had the tools/abilities. It will be important to create good sight lines and layouts to accommodate this. Additionally, I need to sell the explorational aspects of my game by creating obstacles with potential solutions even if the player of the demo is unable to find that solution. For example, having an unsurpassable gap that makes the player think about what tool they need and give them the desire to explore and find it.

I wouldn’t need to implement mechanics to sell the idea of a larger world. The demo player could almost be an “observer” instead of the actual game character themselves. For example, stealth mechanics will be an important part of the early sections of my game as currently planned, however I could avoid implementing enemy AI with sound and sight detection as that isn’t necessary to sell the idea. However, I would ideally like to implement one tool/ability so the player understands the lock/key exploration system, and to showcase my programming abilities.

First Group Tutorial

I had my first group tutorial with James and three students. We largely just shared our project and answered questions from each other. When discussing the depth of my mechanics, everyone suggested I should try to implement basic stealth mechanics rather than ignoring it completely. The example given was simply having an area where you sneak through long grass in front of an enemy, and the player simply needs to crouch to avoid a hitbox above the height of the grass that simulates where the enemy can see, and then simply restarting the player at a checkpoint. Both the start of Sekiro and Ganon’s Fortress in Zelda Wind Waker were given as examples of simple stealth sections before getting access to the players weapon. Everyone also suggested that I should definitely aim to have at least one tool/ability for the player to gain.

I also had a discussion with another students, Glen, about Jira where he explained that I could essentially copy my previous weekly planning method into Jira as weekly sprints. He explained I could create a backlog of all my tasks and add them to a sprint at the start of each week, and the gantt chart should fill in automatically with the dates.

13.03 Check-in

I had a quick one on one meeting with Joel during a lecture. My primary concern was understanding the expectations of Jira and how to use it. I showed my current system of using one big kanban chart, and he suggested that they would like to be able to see a timeline of the projects progression and how well I have kept to that project plan. In order to do this, I just needed to start start adding dates to all of my tasks and the timeline should create itself.

With regard to the work itself, he essentially wanted me to make better use of my time. I had spent too much time creating my Japanese fort, and much of the details should be left until later. I explained that my next planned tasks were to program and animate climbing, and expand on my level’s visuals by adding the foliage I had just made, and replacing the grey boxes with actual assets like walls. He said he would expect I could do that for the end of next week, and that we can do another check in to ensure my progress. This could be put into my first Jira sprint with dates, and by doing the same thing each week going forward I would build a good quality Jira.

Jira Revamp

Now I have a better understanding of Jira and the expectations from the marking rubric, I am able to reorganise my project plan. I started by adding categorised “epics” to the timeline section, which allowed me to add my previously created tasks to the timeline by placing them in those categories and adding start/finish dates. In addition, I could categorise these tasks into sprints which would simplify my kanban chart I was already using to display only the tasks I wanted for that week. Then all my other future tasks would be listed in my backlog.