DEV Community: Terry Nguyen

AIE's Minor Production Process

Terry Nguyen — Wed, 18 Sep 2019 00:00:00 +0000

This was edited by Lizz Rizzo (@lizz0id) and published for the Academy of Interactive Entertainment on its website.

One of the most valuable parts of the course for our Game Development students is the opportunity to collaborate with their peers from other disciplines for their final project at the end of each school year.

Internally, those projects are referred to as "Minor Production" and "Major Production" respectively for our first year and second year game students. Every year, students fall prey to the same problems: communication issues, gaps in technical skill, unclear direction from faculty, or just interpersonal conflicts in general. This year's changes continue the trend of improving the process, which in turn creates a stronger student experience.

Adopting Scrum for the Students

Our efforts to introduce Scrum to students to posture healthy team habits have been successful in past Minor Production projects, which simulates a studio environment. Teams naturally find the transition to be rough at first, but many later report feeling comfortable with the process by the second or third sprint.

We treat attendance as if the students were working full-time in a studio environment. Honoring the daily stand-up was difficult for students that had trouble getting to class on-time. Efforts from students to flex the schedule or conduct multiple scrums to mitigate issues were effectively trading attendance issues for communication or productivity issues. Any further issues are escalated to be monitored under administration.

Faculty designates specific blocks of time to allow for Sprint Planning and Sprint Retrospective sessions. While students are always eager to criticize their work, teams were much more adept at identifying and resolving issues this time around. Rather than focusing on the problems with the product alone, teams were able to also address issues with their process. Pipeline problems like scale issues were non-existent in later cycles.

In addition to the above rituals, we ask each team to present recent developments to the class as a whole. Public presentations not only reinforced the idea that their work should continue to create value for the player, but also provided faculty with an opportunity to review each team's work in a single sitting. If there were any issues with a team's priorities or progress, it would become immediately visible to all faculty members. This improved our response time and efficacy in resolving issues on teams.

To facilitate project management, we use Hack n' Plan, a user-friendly service that models some common Scrum concepts like backlogs and user stories. Its categorized Kanban boards allowed students to track task progress by discipline to minimize clutter.

Switching to Perforce

A major software change for this year was the transition away from Git as our preferred version control solution to Perforce in response to industry feedback. From the student perspective, Perforce allowed them the ability to lock down files to prevent others from making changes while they're working on it.

Merging two sets of changes to code is doable, but reconcile concurrent changes to art assets often resulted in lost work. Removing the need to merge allowed us to eliminate a way for students to lose their work. Unfortunately, students still lost work from improper use of Perforce, as was the case with Git.

A side-benefit of adopting Perforce was the reduced difficulty in training artists to work in-engine to improve their iteration time. Programmers were able to focus on bug-fixes and feature development rather than integrating art assets (at least, to a lesser degree). This also meant that artists could get more immediate feedback on their work rather than being blocked by busy programmers. In both cases, this led to better iteration times which allowed for more refined work from all departments.

Publishing for itch.io

Minor Production had always been conducted strictly internally, which left students unprepared for when Major Production rolls around due to its inclusion of a public showcase. To address this, each team had to publish on itch.io in order to better inform the process of creating a public brand for the game.

This was a double-win for us: students were able to publicly showcase their work online while also giving them an task with a very measurable outcome. Work on the page itself naturally led to questions about branding and messaging: how would a team describe its product to the public? It also promoted discussions around creating instructions for on-boarding players into the game, which often gets forgotten in the midst of the development.

All of the Minor Production projects are publicly viewable on our itch.io profile page.

Introducting the Game Design and Production Department

Every AIE campus struggled with the integration of the Game Design and Production (GD&P) department, which is a new venture comparted to its Game Programming and Game Art counterparts. In our case, GD&P students found difficulty with finding parts of the production process to take ownership of.

Documentation of design work on the game clearly fell on GD&P in the form of Word documents and project management tools. Some found themselves largely monitoring Hack n' Plan while others felt trapped under paperwork for weeks on end.

The confusion only worsened with expectations around GD&P's direct contributions to the game itself. How programmers and artists should expect to collaborate with their designers was unclear, which led to numerous cases of miscommunication. Teams were left with levels they weren't sure how to build or game loops that needed more playtesting and refinement.

Conflicting messaging also occurred internally around the responsibilities of the GD&P department leading to confusion even within faculty members, which then cascaded down to the students. We hope to better form next year's curriculum around a more well-defined set of expectations will benefit everyone.

Plans for Next Year

As we plan for next year's production projects, the ultimate goal still rings clear: we must be training students on the skills that will help them most with navigating the challenges they'll face in the workplace.

Making them effective at their craft is not enough by itself when students expect to work in an industry that needs collaboration from so many different fields and specialties. The production projects are a primary way for us to train and evaluate students on their job readiness.

Areas for major improvement for us include:

Better modeling the different roles that exist on game development teams
Training students on the framework of Scrum and AIE Seattle's implementation
Addressing common pipeline issues ahead of the production projects with prior lessons

We poured a lot of effort into formalizing many of the "Scrum" or "pipeline" or any myriad of broad expectations that we had placed on the students in prior years. Now with the groundwork laid out, we can focus on how we can prepare and communicate with students during for future production processes.

Resolving File Paths to Tools on Different Workstations

Terry Nguyen — Sun, 19 Aug 2018 21:37:00 +0000

Cross-posted from my blog

Synchronizing settings between my desktop, laptop, and studio workspace has been amazing for letting me constantly iterate on my development environment setup. I can make one change anywhere and use it to evolve my tools no matter where I'm working.

This is made possible by transferring information via GitHub Gists automatically with Shan Khan's Settings Sync extension. Unfortunately, support for the use of environment variables in VS Code's settings is but only a requested feature for now. This means that while my settings will synchronize, I'll have to adjust the paths every time I download it on any workstation besides the one that uploaded it.

Recently, I found a way to get around this issue: symbolic links.

What is a Symbolic Link?

As a concept, a symbolic link creates a soft link between point A and point B in your file system. Point A represents the "link" while point B provides the "destination". Anything that tries to access point A will work from point B for any subsequent references for directories or files.

Creating one will depend on your operating system and available tools, but the general idea is that you'll use a command-line application. On Windows 10, this is easily accomplished using mklink.

Be sure to be conscious of differences in jargon and terminology, such as the difference between an NTFS junction and symbolic link!

Using the Symbolic Link

I did not have the foresight to use the same username on both my desktop and laptop, leading to differences in paths that lead to my user folder. (Windows 10 doesn't help with this at all since it relies on the personal information you provide during first-time startup to create the first user account.) To resolve this, I ended up creating a symbolic link from C:\Users\terryn\ to C:\Users\terry\ which solved all of my problems.

Visual Studio Code is My Favorite Text Editor

Terry Nguyen — Sun, 04 Feb 2018 21:37:00 +0000

Cross-posted from my blog

For the longest time, I had always held that Visual Studio was the number one tool that I would recommend for development for the vast majority of use-cases. It was the first tool I used to program in C++ and C# and was also the very same tool that I missed when I started working with Python again.

Lately, I've found myself asking whether I could be solving the same problems with VS Code. That's been ringing pretty true as of late. Since I was on the fence for a while, I thought I'd take some time to just list out some of the reasons why I'm growing more and more fond of VS Code as my daily driver.

Workspace-specific settings

My co-workers and I spent a good deal of time arguing over some relatively harmless but important rules for our coding guidelines (spaces are better).

After settling on eight-space wide indents, I quickly realized that I was going to run into an issue with Visual Studio: the text editor settings can only be set program-wide. I was going to have to switch back and forth or find a suitable extension to do so if I wanted to adhere to the conventions we had set.

In VS Code, the concept of a "workspace" allows you to define a set of settings that apply when a folder is opened. Creating an override for a specific workspace was pretty simple; I just had to create a new folder and specify some overrides. It follows the same format that's used when you define them at a user-wide level. This let me retain my settings for my personal projects while seamlessly adhering to our happily agreed-to conventions.

Relatively fast startup time

Notepad is a great text-editor for all text things whose lines ending in CRLF, but what do you do for everything else? Editing everything without proper line-breaks sounds like a nightmare. Opening Visual Studio for a single file or folder is definitely an option, but you'll be in for a bit of a wait. For me, the answer was VS Code.

Run	VS 2017	VS Code
1	3.5508	1.1607
2	2.9868	1.1258
3	3.4115	1.1736
4	2.4786	1.1928
5	3.3778	1.0983
6	2.9395	1.1373
7	3.1672	1.1528
8	2.8437	1.3238
9	3.4466	1.1818
10	2.9016	1.1408

Result	VS 2017	VS Code
Avg	3.1104	1.1688
Min	2.4786	1.0983
Max	3.5508	1.3238

The above times are given in seconds.

I decided to do some unprofessional profiling to see how long it takes to go from launch to the start page in both VS 2017 and VS Code. On average, VS Code is ready to go almost 2 seconds faster than VS 2017 is! That isn't a lot, but it can add up if I'm opening up a lot of files or find myself needing to restart my editor often.

You can dig into the specifics behind the settings and configurations that I used for profiling in this Gist.

Cross-platform support

According to the Steam Hardware & Software Survey, the vast majority of PC gamers are gaming on some variant of Windows. (that's 98.33% at the time of writing) A similar statistic could be found amongst game developers, if only just for the ease of play testing on a configuration not too dissimilar to what most gamers would have.

I'm interested in using something else for the sake of control as well as ricing, but a number of my students use OS X or Ubuntu on their home machines.

Visual Studio is only officially supported on Windows, but a MonoDevelop-based iteration is available for Mac. While the two share the same branding, the two are really wholly distinct products which have only recently begun to share some logic after Microsoft's acquisition of its original maintainer, Xamarin.

Windows, Mac, and Linux are all officially supported by the VS Code team. That makes for at least one more tool that we can keep using we no longer feel obligated to use Windows as our daily driver! This also means that my Windows-free students have a tool that they can adopt as a part of their toolstack.

Most students aren't comfortable working with the terminal, so there's a lot of "WTF" looks on their face when they omit the -m switch when committing with Git.

I suppose that rules out something like Vim as an alternative for them. ;)

While you'll be hard-pressed to find cross-platform support in older game development tools, it does seem to be a consideration that today's tools are devoting resources towards. I can only imagine that this was, in part, sparked by an increasing need to deploy on a variety of platforms as opposed to any one platform alone.

High versatility through extensions and settings

Both Visual Studio and VS Code offer a plentiful extension gallery that is easy to browse from your preferred web browser as well as from within the app itself. This adds to the extensibility (heh) of your editor, allowing you to customize it to your particular preference and usecases.

VS Code has taken to more of a modular approach, building out support for major languages like C++ and C# as individual packages, though TypeScript is included by default. These interface with a standard set of APIs to provide for common code completion and symbol lookup functionality that you would expect from any IDE with first-class support for your language of choice.

Wishlist

A Better Windowing System

I haven't quite found anything with as nice of a windowing system as Visual Studio itself, though both Atom and VS Code are making their way towards it. It's just so simple to be able to tear off any tab and dock it, snap it, or create a new window entirely.

Right now, you can choose between a one, two, or three editor pane layout that stacks horizontally or vertically. That isn't as flexible, but gets the job done well enough.

Path Normalizing for Different File Systems

The lack of path canonicalization has been giving me a lot of grief when debugging my Unreal Engine 4 projects. Placing and managing breakpoints in my source code is super smooth, but it's what happens when a breakpoint is triggered that's the issue: two editors to the "same file" are opened.

Path Input	Value
Path Opened by User	`C:\MyProject\Source\MyGameMode.cpp`
Path Provided by Debugger	`C:\myproject\source\mygamemode.cpp`

Both of these will normally resolve to the same path when working in an NTFS file system, but the difference in casing causes VS Code to consider them as two different files, resulting in two different editors being opened, thus cluttering my editor. This is exacerbated when I step through logic spanning multiple source files, all of which will spawn a multitude of editors in the process.

You can store two distinct files in the same path that only differs by case, but you'll need to both read and write to that file using something that doesn't depend on the Win32 API.

For more information, see this Stack Overflow post: "Why is NTFS case sensitive?".

Closing Thoughts

With that all said, VS Code is definitely not for everyone. I'm a strong believer of finding solutions and tools that best meet your objectives as opposed to working within the constraints of a single tool where possible. If you have the option of choosing your solutions, then it's important to evaluate whether there's something better out there that you should be moving towards.

Even the VS Code FAQ notes that its goal is only to be a lightweight tool that's a solid alternative when you're just looking to code, build, and debug your project. Leveraging bigger tools like NVIDIA Nsight or built-in profiling and whatnot is still left to the bigger tools like Visual Studio.

My Pull Request Etiquette

Terry Nguyen — Sun, 14 May 2017 02:04:22 +0000

Cross-posted from my blog

I'm pretty keen on the idea that amassing a collection of perspectives and experiences is part of the process of creating a better informed opinion or piece of work. It seems like, with the exception of UI/UX design, that the FOSS community benefits from this pretty well.

Part of that comes for free with a culture that is more conducive towards problems that are more readily approachable from an objective standpoint, though this can easily go awry without establishing a proper community culture in the first place. My first foray into creating something like this was when I decided that I'd take a stab at creating my own "awesome list" for UE4 since I hadn't found a decent one out there.

Getting started was pretty simple since @sindresorhus had already spent a fair amount of effort into establishing guidelines and suggestions for an awesome list, but I hadn't planned out how I was going to handle contributions.

The first one rolled in from @trentpolack, who "added a bunch of lovely things" to the awesome list ranging from tutorials to plugins. I was really excited at first; someone had not only looked at my list, but was also proposing changes to it! After looking at it though, there were some issues:

An errant \ character in the body text
Tutorials where strictly assets/plugins were being listed
An improperly formatted link to an otherwise stellar resource
Unalphabetized entries within the same category or sub-header

There was nothing particularly egregious about it considering that all of the issues entailed short fixes, but there was one question that remained: Was I supposed to respond and ask them to fix it, or should I just fix it myself?

On one hand, it'd be a real quick thing to have them do so I could cleanly merge their pull request into the repository with little effort on my behalf. However, it also felt a little cruel to reject them for something relatively insignificant that I could readily fix on my own since I had already identified them. It was also just Markdown, so it was technically still valid, just unappealing to look at.

While the puritan in me wanted to ask them to redo it, I ultimately leaned on the side of accepting it and fixing it on my own. Putting the typographical errors aside, I merged and closed the pull request after adding a comment stating some of the changes that I made to the content afterwards.

Maybe I was making a bigger deal out of it than they were, but I wanted to make sure that they understood the rationale behind my changes and that I appreciated their time. I wouldn't want to make the barriers for contributing too high for something so simple.

Perhaps that is an unsustainable practice for repositories with much more traffic, but I felt that this was appropriate considering the lack of activity and relative "new-ness" for the project. I'm eagerly making my way towards the day when I finally place the finishing touches on it before submitting it for listing on the awesome list of awesome lists.

Moving forward, I think I'd like to apply the following thoughts when forming and reviewing future pull requests:

Has the submission showed any indication that the submitter has read the contribution guidelines, if present?
Is the submitter interested in helping develop a better project?
Do the changes in the pull request reflect an appropriate amount of work for the given request?
Does it genuinely meet the standards for community contributions?

We're all humans that make mistakes! Some of us are also developers, in which case we're likely also busy and may potentially miss a thing or two when we're trying to help someone or something out. Hopefully this leads towards a better experience for any submitters or reviewers in the future!

EDIT: Fixed some typos and made some clarifications