Internship with

Bent Image Labs

A brick-based builder designed to test run an AR platform still in development.

When I first got in touch with David Daniels at Bent Image Labs about the possibility of taking on a production or project management internship with them I did not expect to be bringing three of my compatriots with me.

We would need an artist capable of creating assets for mobile, a programmer to work on specific functions, and a developer capable of working in engine and blending the two.

I arranged several meetings between the four of us and David, and eventually between the four of us and our team of supervisors. Overall the air of excitement and apprehension filled the room as we concluded that final meeting.

One question lay on everybody’s minds, “What now?”

Building the Builder

For us the internship would be a long Game Jam, where we would spend roughly nine weeks building an application intended to put the software through its paces.

Our bond became a symbiotic one, with mutual benefits.

We provided feedback, they provided us with a testing ground for our newly minted skills as well as supervision and assistance where needed.

My expected duties were varied:

provide a log and record the team’s hours
develop a system of tracking our progress using the Trello Board provided
manage the team and keep them on task
find assistance and communicate with our supervisors
locate the provided equipment
document everything

Off the bat I set to work employing a refined version of the brainstorming methods I had used in a previous Game Jam.

The team came up with a short list of functions we and our supervisors wanted to test out.

From there we came up with a few ideas of what sorts of applications we could produce in the nine week span of the project.

We settled on a simple brick builder, one that covered all the bases while at the same time not making a lot of high demands on the software.

Managing the Project

In comparison between GitHub and BitBucket:
BitBucket is friendlier to mixed programming/art teams.

It allows you to hook a Trello straight to the project.

With GitHub, it’s has a Kanban board that is more programmer heavy. So it’s set up to automatically turn the project into a board, and relate said board to the project. I’m going to have to look more into how it works before exploring further. GitHub also has automated data tracking, so I wouldn’t have to make the tracking charts by hand… but again, it’s more programmer heavy.

As far as other tools go, Basecamp is an excellent tool, but it doesn’t seem very Agile friendly. It’s a great place to keep track of an overall organization, but not so much on a product-based project.

GitHub and BitBucket both use a native Markdown language system as their text to HTML interface, which is Perl-based.

My next step was to request Wiki functionality.

This Wiki came in handy several times over the course of the project, especially when my programmers know them made a note of something the week prior, but couldn’t remember the specifics.

Additionally, putting together the Wiki before you decide how to organize the Trello can help organize the Trello. We used the opposite approach for the VR&R production, which works fine, but it’s hard to determine what functionality you need before you get going.

As a side note: BitBucket’s Wiki system is easier to format than GitHub’s Wiki, but GitHub’s Wiki is more comprehensive.

Proper format for a functionality Wiki page:

## Plan
_I want a detailed plan, like, what sort of approach did you use. Explain what you intended if you can._

## Execution
_Explain what you actually did. Use sample/snippets of code. How was this implemented? Where did you put the code?_

## Result
_Leave a detailed explanation of what happened when tested. How many things broke? How did they break? Give specific examples. Be thorough._

## Issues
_What specific bugs were discovered with your code? What are some guesses as to what caused the issue? Please number your issues so that they can be correlated with the fixes below._

## Fixes
_List any potential fixes, ideas for fixes, or what have you. Highlight the fixes that worked in some way. Please number the fixes to reflect the issues above._

## NOTES

In addition to this, I needed to put together a “How to Wiki” page for those not familiar with the MarkDown system used on BitBucket and GitHub.

A Learning Experience

I needed to be intimately familiar with the product being produced.

For me this meant constantly testing and giving feedback.

If I don’t know what the team is working on, then I can’t set realistic deadlines and I certainly can’t make a pitch to anyone interested in the product.

I need to give the teams time to prepare and know what they’re bringing to the table, even if it’s just fifteen minutes.

Even though hosting meetings can be a thankless job and you get a lot of complaints, come the end of the project, your team leads will usually request additional meetings to cover specific things and to get everyone on the same page, and that can be quite rewarding.

FELLOW INTERNS

Max Bennett - Gameplay Programming
Dasha Moyer - Gameplay Programming
Tobias Wolfe - Artist

SUPERVISORS

Brandon Farrell
Jason Crossley
Vachara Nick Lertackakorn