CAGD 370 - Blog Post 5 & Postmortem

A Hop, Skip, and a Jump

A Hop, Skip, and a Jump is a 3D platformer with player-placeable gravity spheres that launch you based on your current velocity. You are also able to dash forward while in the air which similarly launches you further based on your current speed. This means that if you activate the dash shortly after a jump while you're still traveling diagonally forward and up you will continue along that trajectory for the length of the dash.

Level 02 - Section 02

To start I'd like to share the completed level 02. First up, the overview map.

Level 02 - Overview

Level 02 - Critical Path

The critical path shown in yellow above describes the expected route through the level. During playtesting some players derived significant enjoyment from finding ways to shortcut the shown path. This is an intended design choice. One of the game designer's stated goals was to create an experience that lent itself to speedrunning gameplay styles. As such, the players that chose to find faster ways through the level were engaging in an expected and desired way with the experience.

Below you'll see a view of the 'debris field' that forms the ending section of the level. This view is presented to the player as the fist vista of the level in order to create a sense of vastness as the player traverses ever closer towards it.

We repeat this vista several times as we traverse the level. As the player reaches various checkpoints they find themselves circling around the debris field, spiraling in towards it. This places the debris field persistently to their right creating a sense of consistent directionality throughout the level. I feel that this enhances the players ability to enter flow state by creating an intuitive sense of destination.

Throughout the level I sought opportunities to create choke points that would force desirable framing of the player's destination to further enhance the intuitive understanding of the player's objective.

The above two screenshots exemplify this use of forced framing as the player traverses a narrowing of the level geometry that places their view directly on the end goal once more. A point of improvement for the future would be to move the final destination of the level higher vertically which would have added visual interest to this particular frame and would have further emphasized the player's goal. By placing the goal building somewhat above the average Z value of the debris field it would have marked it as a consistent reference point for the player that stood out from the otherwise noisy field. Below we have a few overview shots of the level.

The image directly above makes it obvious how the debris field was constructed if it was not already. By grouping small clusters of objects then duplicating them with various rotation and scaling variations a shattered area can be rapidly created. Were I to do this project again I would have likely chosen to look in to using a particle system for the debris field or attempted to adapt Unreal's foliage system for the purpose. Alternatively, I would have created a blueprint for scattering objects without overlap that accepts an arbitrary number of objects, potentially with configurable splines that serve as weights for each object's scattering position.

Postmortem

Now that the project has finished I can say confidently that we created a functional and fun prototype. As a group we experienced few problems throughout development and, for the most part, did not feel significant time pressure in managing milestone deadlines. Of note, this project was completed by several groups simultaneously. Those groups each consisted of three people with the exception of ours which held four. Though it can not be stated with certainty, it seems highly likely that the ease of our project came as part of the increased developer count.

Ease

If you'll allow me to speak candidly, this project was designed to teach developers scrum-style agile project management, a process with which I was already quite familiar. Early on I was advised to lay back to allow less experienced developers to have a chance to learn by experience, mistakes and all. I did so, as much as I was able, but I did provide help and advice with regards to user stories and point assignment to ease our producer's burden. Overall, the typical scrum sprint/user story/point format went well and was incorporated into our group's workflow without issue.

Our group was utilized as the example on how to perform stand-ups, for example. I feel that being in the group meant that I improved our group simply through leading by example even as I attempted to step back and allow for mistakes. It also makes me feel that the project's focus on teaching scrum was...misguided. Agile principles and scrum methodologies are, by design, something that can be taught and incorporated quickly while on the job. It strikes me as a confusing and (if you'll pardon my saying so) pedantic choice to spend so much time on them instead of on active development of a project.

Teacher

Due to the increased number of developers on our project I opted for less of a leadership role, choosing instead to focus purely on level design. A part of my goal for the projects I was on recently was to embody a single role only, and to trust in the other developers to fulfill their roles and obligations without my oversight.

I've been endeavoring to build my ability to trust my peers; I intend to make it so that trusting others with their work is my default state. A flaw of mine is one brought on by my years as a teacher. Specifically, I have a tendency to 'hover,' to ensure work is being done satisfactorily and without confusion.

Though the helpfulness instilled in me from that role is positive, I feel the above is detrimental to my colleagues confidence. I've been striving to change it. I'm proud to report that I was successfully able to shift my mentality for this project and that my trust in my peers was rewarded.

Troubles & Solutions

As mentioned, we had mostly smooth sailing. One of the few problems we overcame was due to a Github merge overwrite that caused the gravity spheres in level 02 to revert. This meant that the force values I had assigned and carefully tested to ensure players could traverse the level were all reset to the default (very small) value.

During our first playtest with the gravity spheres players were not able to complete level 02 without significant difficulties. To resolve this, I accessed my desktop PC remotely via Parsec and created a new build based on the branch from before the merge issue. We were able to set up this build (which was missing our UI changes) on one of our test machines so that at least some players could experience all of level 02.

Unfortunately, not all players were able to test both the level and the UI. This meant that our playtest feedback form provided data that was... confusing, at best. However, the informal discussion that was had with each playtester following play proved to be highly beneficial with regards to UI setup and level structure, for those players that experienced those elements.

Changes

The Github issues we experienced during this project as well as during another project I was involved with has made it clear to me that there is significant deficiencies with how version control software is taught (or rather, not taught). I intend to ensure that all future repositories I'm part of have proper rules in place to require pull requests and code review from all contributors prior to merging. Though code review is significantly more difficult when utilizing Unreal's Blueprint system, it is not impossible. At the least it means that file overwrites will be more likely to be prevented, instead allowing for them to be manually diffed properly.

Allowing others to succeed or fail on their own lead to our Github issue but it also allowed for my team to grow significantly. I wouldn't change this but I would like to remind myself that engagement with a project is not optional. I've noted in previous dev logs that I was not as involved with the project as I would have liked; I intend to change this in the future, with a caveat.

I adore games. Truly and deeply, I adore them. I attempt to give all of myself to any game I work on. As it turns out, working on multiple projects simultaneously means that I literally cannot give 100% of myself. Instead, I am learning to strive for equitable balance between projects based on their needs.

Future & Past

Were I to continue development of this project I would institute a significant shift to asset management, first and foremost. Specifically, for a project that is slated to be a full game deliverable, blockouts require additional thought in order to make the eventual beauty pass / asset implementation less of a nightmare. Especially with large scale level blockouts attention must be paid to the possibility of automatic asset replacements. This project was not developed with that workflow in mind and thus would be the first matter to adjust.

I stand by my decision to not implement this workflow from the beginning of this project, however, due to the additional setup time required and the fact that this project required an explicitly non-finalized-asset prototype. Regarding that, there is not much I would do differently for this project other than to increase my initial engagement with the process. I don't feel I properly managed an equitable division of labor between my projects and so that would be the main point of correction on a redo.

In retrospect this project was a complete success. We had few hiccups and generally successful playtests with highly positive feedback. There was even a minimum (though non-zero) amount of wasted work. An aside: as it turns out, the measuring device I created was superfluous because Unreal has a measuring tool built in to non-perspective editor cameras. Regardless, this project was great to work on even though it didn't provide many opportunities for my growth.