Welcome to Alexander Ho’s Personal Production Journal

Week 2 - Week 3

Alexander Ho, PPJ 1

Tasks:

1. Created the team website: 7 hours

2. Setup the blogs for PPJs: 1 hour

3. Built and hosted the tech demo on the team website: 1 hour

4. Defined clearer requirements and tasks for upcoming week: 3 hours

Total hours: 12

Positive: Everyone is very enthusiastic about the game, and I appreciate that immensly. People have completed the tasks I set out for them, and seemed to have organized well, even within the messy nature of the week.

Negative: As I didn’t have a huge amount of time between having my game chosen and distributing tasks and roles, it was a little difficult getting everything organized. Also managing and communicating with a large group can sometimes be difficult because not everyone is online at the same time. Its a lot easier to convey a message to one person than to nine. Also, learning how to host a github page the way I wanted was a little tricky but its going to be very useful for the future.

Upcoming: Distribute development tasks. Complete development tasks. Create art for the game. Keep up with everyone’s progress.

Week 3 - Week 4

Alexander Ho, PPJ 2

Tasks:

1. GDD: 8 hours

2. Setting up presentation: 4 hour

3. Integrated classes that other team members created: 1

Total hours: 13

Positive: Everyone was able to deliver on their tasks which is amazing. The programmers made it very easy for me to use their code and integrate things together. Even when I haven’t worked on the code as much as them, I can still have insight to whats going on, on the development side. The artist were able to deliver on good concepts, and a decent draft of the documentation actually got made.

Negative: I was extremely busy with other work this week so it was stressful cramming a lot of the game design requirements. Also, its hard to work on game design and develop the game, and assign tasks in parallel. I want to create the base game first, which I feel is well defined, and then once everyone is comfrotable, actually take some time to define additional aspects of the game. I feel that a lot of the game design document additions I made are more temporary in nature as a result.

Upcoming: Pass out development tasks. Start making art assets. Be more invovled in code development. Have a long form discussion with the team on the design of the game.

Week 4 - Week 5

Alexander Ho, PPJ 3

Tasks:

1. Player Controller: 3 hours

2. Grid Public Interface reference for team members: 3 hours

3. Basic Movement: 1 hour

4. Basic Damage: 1 hour

5. Basic Enemy movement: 1 hour

6. Indication Highlights: 3 hours

7. HUD: 30 minutes

8. Integrating Turns: 1 hour

9. Level Generation: 30 minutes

10. Team Design Meeting: 3 hours

Total Hours: 17

Positive: Its really good that we are able to actually get the major components and classes out of the way, because it was tricky developing this project while waiting on so many missing parts. In the end, a lot of major components were layed out and completed which is really good. Also, everyone has a very clear direction for the game now.

Negative: Had to wait for a big component to be finished so I couldn’t get the time to integrate all the the components that I created while using the square grid substitute. Also, because the team has decided to pivot to a different foundaton of the game, the current state of the demo is not as representative of the actual game loop. Hoping to get a reprsentative example by next week.

Upcoming: integrate compoonents with new hex grid class. Refine gameplay loop to reflect the team’s new direction. Add visual assets to the game.

Week 5 - Week 6

Alexander Ho PPJ 4

Tasks: Integrate hex with components and Pair programming with developers: 7 hours

This includes switching over the square grid to hex grid Update player controller Update Hex Tile interface and interactions

Total Hours: 7

Positive: Pair Programming has proven to be effective.

Negative: A lot of work to juggle this week, difficult to organize and distribute task to team members.

Upcoming: finish integration and finish foundation.

Week 6 - Week 7

Alexander Ho PPJ 5

Tasks: New Main character art: 7 Integrate art and animations: 5 Integrate New Hexes: 30 minutes Integrate enemy player interaction: 5

Total Hours: 17 hours 30 minutes

Positive: The game has a good look and feel. People updated me on if they couldn’t get their work done early so we can pivot accordingly for the alpha build.

Negative: The complexity has been confusing for players and we need to tighten up the system and add some sort of instruction or tutorial to guide the player. The mechanic isn’t as intuitive.

Upcoming: Add instructions and tutorial for the game. Fix the bugs. Add abilities. Add monster art, tile art, more character animations, and background.

Week 7 - Week 8

Alexander Ho PPJ 6

Tasks: Added new lighting render pipeline/added lighting effects: 4 Created new background/obstacle art assets: 4 Integrated the UI art assets: 2 Added monster sprite and animations: 2

Total Hours: 12 hours

Positive: I’m very excited for these lighting effects. They should add a signifigant visual impact to the game. There are lot of creative ways to use it as well.

Negative: A lot of members weren’t able to get their tasks down this week. I should ask members for updates more often rather than waiting until the end of the week to ask for a progress report. Also there are a lot of bugs with the game.

Upcoming: Tune up the lighting/visuals as well as do a ton of bug fixing.

Week 8 - Week 9

Alexander Ho PPJ 7

Highlight predicted tiles: 8 hours Tutorial Slides: 2 hours

Total hours: 10 hours

Positive: players according to the playtest, are finally able to have a better understanding of the mechanics of the game. Everyone was able to get their tasks in.

Negative: there are a lot of bugs that we need to fix. The reception to our game during playtesting is subpar.

Upcoming: Intense bug fixing and polishing. Get the abilitites tutorials in.

Week 9 - Week 10

Alexander Ho PPJ 8

Crash movement feedback: 4 hours Wall sorting layer reconfiguration: 3 hours Art implementation: 1 hour Lighting: 1 hour

Total hors: 9

Positive: The game is starting to look a lot prettier. The crash mechanic and camera shake make a world of difference when playing the game. Sorting layers also don’t seem to take too many computing resources, despite being a couple layer nested for loop (and a lot of nested for loops as we have to do it for every border obstacle).

Negative: There are still a ton of bugs and kinks to work out. There are a lot of edge cases to work through that tends to leave a lot of problems.

Week 10 - Finals Week

Alexander Ho PPJ 9 Post Mortem

During the beginning of development, it was difficult to brainstorm ideas, organize tasks, and assign tasks at the same time. At first I tried to plan out the architecture of the game in great detail, but that quickly fell apart as developers needed to implement things in different ways. So a lot of time was wasted trying to come up with elaborate architecture, and it would have been better if I assigned more overarching tasks such as “Enemy AI”, “Player Movement”, or “Grid generation”. Having more high-level tasks accomplishes a couple of things. First, is that I don’t have to concern myself with the implementation and that can be left to the developers. I only need to learn about their public interface for integration purposes. Also, because all other developers are only concerned with the high level results of a task, it’s very easy to see how much someone is succeeding or struggling in their tasks. We don’t need to mull over coding details to see that player movement isn’t done yet, or that enemy AI is very buggy. In terms of organizing tasks, it was wrong of me to try and flesh out the mechanics myself and then discuss with the team afterwards. I thought it would be easier if we had a solid gameplay and changed it from there. But this lost us a week of development time. But more importantly, it left a lot of members confused as to what we were trying to accomplish. A great solution to this was our long game design meetings. During these meetings, everyone would be able to pitch in their input, understand everyone’s ideas, ask about what we are trying to create with the game, and overall just bring everyone to the same page. I would have these types of meetings as soon as possible and as often as possible in the future. By having more broad tasks, and having more design meetings, it alleviates the stress that I have to take on organizing everything and allows for team members to have input as well.

Another difficulty we had was trying to accomplish too many and too complex mechanics. This left many members confused on the state of the game, and created a backlog for tasks. Personally, I would have rather we accomplished more, cleaner, and simpler implementations for the sake of development, then trying to bite off more than we can chew for the sake of “theory” and “game design”. For example, I agree with the team in that a hexagonal grid would work better in the game we are developing. However, that introduces a whole new, and much more complex and unituitive coordinate system, along with many other problems, that makes development very difficult. What’s worse, is that the grid is a core part of the architecture of the game, so having this be backlogged pushes all the other tasks that we could have been working on to later weeks. To try and remedy this, I created a temporary square grid system in about a day to design out the public interface. This proved to be useful because it gave the developers a clear vision on how to design the hex grid. If we were to just go along with the simpler idea and expand later, it would have given us a cleaner and more robust implementation. This applies to many of our mechanics as well, such as player movement.

A major difficulty we had was getting the players to understand our game and engage with it. There are many layers to the mechanics in our game, and it is not always very intuitive. The player will move to players that the player didn’t intend them to move to. Things will happen that, as developers we understand why they happen, but having the player understand why they happened is a whole different story. In trying to chase “interesting”, “complex”, and “theoretically good game mechanics”, we lost sight of engaging our audience. We received a lot of comments during our surveys about how play testers “had no idea what they were doing” which is definitely a blunder to morale during development. For me personally, I would have gone for more of a simpler mechanic and with a singular and strong hook, rather than something that requires multiple steps and layers to understand. And then from that foundational hook, we could expand it and make it more interesting, and make it more interesting later in the progression of the game as well, when players are more invested and willing to learn more complex mechanics. Also, the step by step tutorial we are trying to implement I think is a great solution to teaching our mechanic. Although it may be a little hand holdy, because our mechanic is not naturally intuitive, it’s a small price to pay to get the player understanding and engaged with our game. It’s worth making the tutorial immersive and interesting as well, but with the time that we are given, having a short hand holding experience is not something I’m too concerned about.

Something that went really well was how everyone was engaged in the development of the game. I’ve worked on a handful of group projects, but this one was probably the first time I have seen team members care about a project this much. There are a couple of factors that I think contributed to this. First, is that everyone was able to see their contribution to the project and understand how integral it is to the development of the game. Every contribution spanning from adding to the code base, creating art, or pitching ideas during meetings had a clear impact on the direction of the game and I felt like team members were able to take pride in this project. Also, another important factor was being able to visually see the game come together in terms of aesthetics and mechanics. Basically, as it was starting to move further away from placeholder code and art, and into a more full fledged game, team members definitely were more excited. So as I continue with my game development journey, I think what I am going to try to do is get the art and foundational mechanics in as well as humanly possible. Because by doing so, it thwarts a lot of temptation to meander and “plan”, but instead will get people excited and engaged.

Also, something else that went very well was code development. Generally there is always one major programmer that takes over most of the work for the sake of efficiency. However, in this project, all of the programmers were able to contribute to the code base in a significant way. This provides a couple of advantages. First, is that because everyone is using each other’s public interfaces, people start to care more about their code quality because no one wants their code to burden someone else’s. Also, because everyone is working on the code base, everyone is familiar with the code base, which is not as much of a given as I used to think. There have been times where I have worked on coding projects where someone would take up a majority of the programming, which often results in unreadable and quickly put together code. This makes it extremely difficult for other members to then go in and read and expand on the code base. And something I have definitely learned is that no one really wants to read your code, and much rather code something themselves. But in this instance, we were great at communicating how we were supposed to use each other’s script, thus making it much less daunting to actually work on the code base. Something that I’m going to do moving forward to encourage this behavior is have people present their code during meetings and go over how to actually use their code (and not necessarily the implementation details). This will give everyone a much clearer idea on the architecture of the project, while also avoiding creating duplicate code (which has actually happened once or twice during this project).

Another great thing that we were able to accomplish was the sheer amount of content we were able to produce for the game. There were a lot of mechanical details, art, animations, presentations, and documents we were able to complete, all while juggling other classes. Honestly, I am proud of how much the team was able to get done. I think a big factor in this was how dedicated everyone was to making the game better. Even when we didn’t have a build officially due for a week, everyone felt an immense sense of responsibility to get their tasks done before presenting. I think that this is really a testament to how effective engagement and motivation can be on productivity. Everyone thoroughly communicated their progress and was always transparent when they couldn’t get their tasks done. This is important because it prevents backlogging, especially when another developer is depending on separate tasks to get done. So I think an important aspect that I will absolutely try to nurture in the future is excitement and a sense of responsibility in team members. And a great way to do this is to get concept art out the door as often and quickly as possible. When people see concept art, it’s a lot easier to dream and imagine the final product, and it sparks a hunger in people to try and get it done. I hear it all the time during meetings about how cool this and that would be just from looking at the concept art. Also, another great way to nurture motivation is to let people breathe. Not bogging people down with tasks leaves them hungry for more the next week. A higher percentage of tasks tends to get done, and people’s mental health and disdain tend to be kept in check. This project definitely had its ups and downs and I learned a lot from it. However overall, I am very grateful for my group and am proud of the work we were able to accomplish. I’ll definitely utilize the lessons I learned about motivation, project management, and simplicity in future projects.

TERM TWO PPJ

Welcome to Name’s Personal Production Journal

Week 1 - Week 2

Alexander Ho, PPJ 1

Full Team Meeting: 3 hours Art and Story Meeting: 3 hours Pipeline docment: 1 hour Asset list: 1 hour

Total: 8 hours

Positive: Everyone seems excited about the project and seems motivated to do their tasks. Onboarding was smooth and everyone was able to get setup with the tools they need to work.

Negative: We couldn’t get to working on the actual game today, but its something that I think is ok for the sake of a smooth onboard transition.

Future Plan: Start assigning tickets to every member and work on character animations.

Week 2 - Week 3

Alexander Ho, PPJ 2

Helped Yash with AI integration: 3 hours Coordinated Dev merges: 2 hours Came up with tasks for team mates: 1 hour Meetings: 1 hour

Total: 7 hours

Positive: people are able to merge changes into Dev relatively seamlessly and they are getting good progress done on the game. The games knew mechanic has a nice flow.

Negative: There are a lot of issues with the advanced AI and a lot of them stem from integration. A lot of onboarded members have also expressed frustration with legacy code.

Future plan: try to get the new AI in and test the new game mechanic. Also get some more character animations in and juice.

Week 3 - Week 4

Alexander Ho, PPJ 3

Integrate ice level assets and setup the ice level: 3 hours Art style meeting and help Matt with style: 2 hours Help edit the GDD and revise final vision for the game: 2 hour Came up with tasks for team mates: 1 hour Team meeting: 1h hour

Total: 9 hours

Positive: The playtests have improved and the game is in a much more stable state. We are getting close to the point where we can start adding additional content. Also, creating a new level in terms of aesthetic is easier than anticipated.

Negative: We are so close to a stable base game but little bugs keep arising and there are still tasks people need to integrate. Also level editing tool might take awhile.

Future Plan: Start adding additonal content along with UI. Maybe setup a dedicated juice team to make the game feel ebtter, because its currently working.

Week 4 - Week 5

Alexander Ho, PPJ 4

Write down hwo to create a new level and make level creation easier: 2 hours Art style and UI meeting: 2 hours Coordinate merges and manage programmers: 1 hour Clean up and create new tasks for upcoming weeks: 3 hours

Total: 8 houts

Positive: The tasks are a lot cleaner now and we have a much clearer direction where we want to go. Also a lot of functionalities have been merged.

Negaitve: With so many new features being added, there are definitly some instabilities and bugs that have arised.

Future plan: Fix the new bugs, get more levels up, and vastl imrpove the movement UI.

Week 5 - Week 6

Alexander Ho, PPJ 5

Edit some art assets: 1 hours New Tile Effects: 5 hours Tile Effect integration: 3 hours Create new levels: 3 hours Meetings: 2 hours

Total: 14 hours

Positive: There were a lot of features we put in , and its starting to feel more like a complete game. We have five levels, with working tile effects and enemy manipulation of those tiles. And almost every major feature we wanted in the game is in the game. We just need to improve on some of them, get the level editor, integrate AI, and bug fix so much. Everyone on the team was super super communicative and responsive which made my life so much better.

Negative: Oh goodness we have so many bugs, some of them seem to be game breaking too, (but more so in the editor?). There are so many little interwoven code references that it creates way too many opportunity for bugs. I would have loved to have approached this in a more clinical, and cleaner software engineering perspective (which we still did to a degree), but just with the sheer amount of features we have to add, the little time we have, and the amount of people to coordinate, these workarounds and code smells are bound to happen. Definitly am going to try to mitigate that as much as possible. A great remedy for this is to have mini meetings with the relevant coders so that I, as the team lead, can get a clearer high level picture of whats going on, and move the project forward accordingly.

Future Plan: Bug fix, bug fix, bug fix, and we might even post pone any new features and focus solely on bug fixing. Especially because this is actually starting to get in the way of development. And hopefully along the way our code we be more cleaned up. Also implement all the new art assets.

Week 6 - Week 7

Name, PPJ 6

New Enemy AI: 10 hours move over to only using hexType as the way to indicate different hex tiles: 1 hour fix null instance bug that crashes the game: 2 hours edit the levels: 1 hour Meetings: 1 hour Make enemies leave a trail of changed tiles: 3 hours new background generation: 2 hours

Total: 20 hours

Positive: Pretty much 99% of our mechanics are in the game. The game breaking bugs are gone. The huge missing piece to our game, the enemy AI, is finally in the game. All the goals we wanted to get for the beta build is in.

Negative: The level editor still isn’t complete and our levels are too simple. But this upcoming week the level editor will be an absolute priority because we need an easy way to create more levels, as we have all our new content in.

Future plan: Bug fix, add restrictions to abilities, and complete a usable level editor

Week 7 - Week 8

Alexander Ho, PPJ 7

merge fix: 1 hour defining tasks: 2 hours coordinating and helping every member with merges and tasks: 3 hours

Total: 6 hours

Positive: we were able to get highlighting for bounce in our game, but also a cleaner infrastructure for all predicted movements. Also we have ability restrictions.

Negative: The level editor isn’t complete. At this point I’ll just finish it myself because the designers and game need this.

Future Plan: Finish the level editor and get the art in.

Week 8 - Week 9

Alexander Ho, PPJ 8 Connected all the levels and scenes - 5 hours checked everyone’s levels - 5 hours added projectile enemy ability - 8 hours added spit enemy ability - 3 hours added heal enemy ability - 2 hours added dialogue to each level - 4 hours fixed all enemy prefabs - 3 hours finsihed inspector level generation - 3 hours tuned of enemy AI - 2 hours added electric tile ability: 2 hours

Total: 37 hours

Positive: We are close to having a completed game. All of the mechanics that we would want are in the game.

Negative: There are some unappealing things that we need to fix, a lot of stuff with UI. Also, we had to cut out some mechanics because we did not have time to put it in for this week. This includes things like deflect. Had to simplify the enemies a lot.

Future Plan: Clean up the UI a lot, playtest the game and tune up the AI.

Week 10 - Finals Week

Name, PPJ 9

Ran Playtests: 2 hours Major Build bugfix: 5 hours Ability indicator: 3 hours Reconfiguration layering: 2 hours

Total 12 hours

Positive: finally fixed the build bug. Which was super super super annoying. But luckily Jarod and I were able to deduce the problem.

Negative: There are a lot of other minor bugs

Future Plan: integrate art and clean up the game.

I started to get the hang of assigning tasks and ditching the meeting system and instead meeting people individually was a lot more productive because it saves everyone time and it helps me understand the nuances better.

Also, I was able to coordinate merges a lot better and the workflow that we had going was really good. I was able to easily switch between branches and locating bugs became a lot faster because it was easy to spot which merges casued an issue. Simply reverting the merge helped take us back to a stable state.

Another good thing was that the incoming people were able to contribute signigant work to the legacy code which I thought was really helpful. I think this was because I gave them team leads to ask question with, such as Atticus with Michael and Cyn with Kendal. I didn’t have to do all of the explaining and instead was able to divide the workload and code explaination.

I also learned how to actually assign tasks. What I mean by this is that sometimes high-level tasks would be too daunting for some people, but at the same time, tasks where I explain the technical details generally weren’t going to be followed through. So I went with the middle ground, giving open ended technical requirements but still allowing room for team members to develop their own method for accomplishing it.

I definitly should have split it up into subteams and have them coordinate tasks and take responsibility instead of having me assign all of the tasks. I think this would have created a stronger game. Not only split up into subteams with leads but split tasks into subteams. For example, having David and Ravi coordinate by themsleves a UI would have taken a lot of weight off my shoulders.

Also there was a lot of meandering. A lot of major pivotal tasks kept getting push back such as the AI and the level editor so we couldn’t do anything. In the future, I’m going to address these issues a lot faster rather than putting banking all my hopes on my team member.

There also could have been a lot of better code practices in hindsight that we could have implemented because a lot of things we have to go in an manually change such as the levels but with the time that we had ripping that out and implementing a stronger software solution would have taken too long.

back