website templates

Go Go-Karts

Go Go Karts is a 3D arcade multiplayer couch racer that is set in the fantastic Fable World, a magical theme park where legends and myths are real. Adventure awaits, and legends will be built in the wonderful land of Fable World!

The Project

- Engine: Unreal Engine 4.21

- Team Size: 46 students

- Development Period: 4 months

Position: Lead Software Developer

- Managed the programmers in the cohort

- Coordinated with other discipline leads and stakeholders

- Ensure everyone has the latest version of the project

Mobirise

From Epics to Departments

Coordinating with the technical departments and ensuring to explain the required features. Depending on the complexity of the problem, I would talk through with my programmers to a potential solution. I would push them to work as little as possible in zoos, and instead in the artifact. This allowed for peer programming, as well as guaranteeing their work is in the milestone presentation.

Maintaining Architectures

When a feature required multiple technical departments, I would attest to the different architectures. Anything specifics, I would gather the departments, and solve the problem together, as to not make redundant paradigms. Once a solution is found, I would take note of it and review their work later to ensure it works as expected.

Working with Leads and GD

Every morning we would meet to give daily updates. We would create Epics together and filling out conditions of satisfaction for the next milestone. Anytime my programmers needed assets or challenged new features, I would talk to the designated leads.

Working with Producers

The Lead producer would schedule times for meetings with other leads, stakeholders, and departments. My producer and I would manage time within the milestone for the different departments as well as insisting on going on destressing walks around the building.

Working with Stakeholders

Meetings would consist of updates to in-progress features and solutions from previous blockers. Stakeholders were also our mentors, so we would learn how to be an effective leader, work through interpersonal issues, and efficiently working with multiple disciplines.

Presenting Milestones.

Every two weeks, we would present to the stakeholders the current state of the project. I would show the technical achievements my group has made, as well as address issues and potential solutions. If specifications were requested, I would address designated programmers to explain further.

Mobirise

Ensure Latest Content

Nightly Builds

I maintained a batch file that would create an executable of our game. This batch file would run every night, as to not interfere with the development process. The batch file was crucial during the last few weeks for Q&A, reflecting completed bug reports.

Perforce Guardian

I was in charge of monitoring the activity to our Perforce repository. Discussing with peers necessary rollbacks and investigating submissions past discipline locks.

Technical Support

For other disciplines, I helped as much as I can with any technical issues. These included, but not limited to, Perforce setup and problems, Unreal level streaming, clarification to use programmer's interfaces, and whiteboarding math problems.

Mobirise

Team Postmortem

1

Honest and Dependable

The organization of Q&A allowed for fast bug fixing. Having redundant requests combed through and removed allowed programmers to focus on what was important.

Effective communication within interdisciplinary groups made it easy for programmers to designs intuitive interfaces. We could create tools that helped level designers and artists accelerate in their creativity.

Consistency of the nightly build made authors responsible for checking their code before submission. Fewer and fewer build errors showed up, as we continue to check our work with others

2

We Are Always Improving

We learn through the grading process that we should crunch to get requirements done, rather than learn how to run an effective scrum. Our grade should reflect when we crunch so that we are focus on planning and scope.

The leads need to have Unreal experience so that they do not missout on the how-tos. The experience will also help in creating interfaces that work well in unreal rather than against it.

The leads never refined the pipelines. When given a request, the lead could not ask the right people because of too many responsibilities. So the initiator would end up taking the initiative to ask the closest designer.

3

We Are Passionate

People who we can work well with, as well as those that we can't. Even with the tough ones, it is still a learning lesson to work with them, rather than to avoid them at all.

Have SD meetings early on to have more organized architecture and systems. Talking through those systems can help make scalable systems, rather than making blind guesses.

We need to have more SDs in C29.

Mobirise

Personal Postmortem

1

What Went Well

Communication towards the end of the project was significantly improved. We were able to resolve bugs relatively quickly, which meant we could refine core mechanics.

In the final artifact, we kept the majority of the programmers' work from the first few weeks. Their work was either updated or altered from the first iteration, of course. Since they kept working in a local version of the actual level, programmers could peer check each other, meaning it didn't work only on their machine.

The patience and grace that the programers had for me. They knew that this was a tough position, and they were open to helping out in any way they can.

2

What Went Wrong

I came into this project, not knowing how to work in Unreal. I understood theoretically how an interface worked but did not have detailed solutions.

I did not give my programmers timely responses and thorough reviews of some of their work. Creation of duplicate variables and spaghetti blueprints made late development difficult for last-minute features.

I did not create a live document of all of the interfaces that my programmers made. I relied on not only my mental model but my programmer's model as well to interact with each other. In doing so, it bottlenecked our development time. Only one or two programmers knew the structure, which put them on technical support rather than development..

3

We We Learned

Plan the creation of Epics and Conditions of Satisfaction a week early. Planning features soon will allow them to be fleshed out, enables the leads to gauge if earlier features need to be revised or dropped, and will not halt the department's planning day after the milestone.

Plan hours dedicated to updating wiki documentation of the different interfaces created. Authors are responsible to not only understand their work but to teach others how to use their work. Documentation also allows other programmers to work with or update the interface, in case the original author is busy with other tasks.

Be mindful of asset requests. Not addressing the request soon will lead to drive-by requests, which will lead to confusion and miss communication. Leads should know about the request, and make a judgment call to either allow something "simple" to slip or reassuring that a meeting is necessary.