Retrospective
Concept
The concept for my Division III began as a game idea. I originally wanted to create a real time strategy game. However, the more I thought about it, I realized I lacked many of the skills necessary to make a complete game. This morphed into the concept of assembling a team to make such a game. However, I considered the concept further, I realized Hampshire lacked the structure for forming such a team. This spawned the idea which would crystalize into my Division III, GlowLime Games.
GlowLime was intended to serve students interested in game development coming from all disciplines and levels of experience. The intent was to provide educational, hands-on experience in game development.
Artist’s Statement
I believe collaboration makes for better projects. As the often used African Proverb reads, "If you want to go quickly, go alone. If you want to go far, go together." This is highly applicable to game development. I’ve often found it’s quicker to throw myself into solo projects, without the checks and balances of a full team. However, working on projects alone, especially projects at the scale of full games, guarantees there will be elements missing. Working on a dedicated team offers superior chances to explore a full range of considerations. For Design, it offers a degree of critique and fine tuning which is hard, if not impossible achieve with a solo workflow. For Art and Audio, there is a level of quality control where acutely trained eyes and ears can survey the work being put into the game. For programming, where I’ve spent a bulk of my time this year, there is a different but comparable type of quality control. The process of code review ensures the code within the game is efficient, comprehensible, and maintainable.
Structure
GlowLime is in a large part based off the LiveCode program at Becker College. This is a semesterly program run by MassDiGI. Each semester, they place students on development teams to work on projects (typically pre-existing ones), and assign them specific goals for the semester. The key way in which GlowLime distinguishes itself is by being student run. Whereas MassDiGI has a full-time management team dedicated to its success, GlowLime’s Management team is staffed by students from the Five Colleges. This comes with both drawbacks and benefits.
The primary benefit of having a student lead organization is the direct peer-to-peer communication. As managers at GlowLime, we regularly talk to our fellow students and receive feedback & input on how they feel GlowLime is being run. This feedback loop ideally leads to an organization which meets the needs and wants of the game development community in the Five Colleges. Another benefit is the opportunities for leadership and organization provided to students in GlowLime’s Management team. Maintaining an organization which serves upwards of 50 students a semester is a distinct challenge. It’s a challenge few students get the opportunity to explore while still in their undergraduate studies. In this way, GlowLime helps prepare the students in Management for future leadership roles.
A student run organization is not without its limitations. One of the main limiting factors is time. None of the students on the Management team can devote themselves in a full-time capacity to the project. This has always been a constraint on the scale/quantity of work GlowLime can accomplish as an organization. While it’s a limitation placed on all student organizations, GlowLime runs the gamut between student group and startup. This rare duality is uniquely difficult to execute. In many ways, GlowLime is a student club like any other. However, one of its goal is to produce polished, professional games. We also seek to provide students with a simulation of professional work experience
These expectations bring with them a degree of rigor not always found in student organizations. At many times, I feel GlowLime fell short of offering the professional standards to which it aspired. We endeavored to maintain professional production timelines, host organized events, and create polished games. There were distinct successes, but also many moments where we fell short of these goals. It was hard to motivate students participating, both at a Management level and Collaborator level to put in the necessary time.
Collaborators at GlowLime are the developers creating games. Like the Management team, the work is entirely volunteer-based (though we worked with Hampshire Professor, Ira Fay to establish independent study credit options). Some Collaborators turned out to be exemplary workers, but others were either too inexperienced or did not have the necessary time to commit. I think this is one of the important learning aspects of GlowLime. While the experience may be valuable for some, for others, it may show them that they don’t have the dedication or motivation to work in games professionally. Much as GlowLime itself is an experiment in building teams of students to work on games, it provides a space for students to test whether this is the kind of work they want to do professionally.
We've conducted surveys about team satisfaction at GlowLime during Spring 2016 and Fall 2016. The responses are generally positive (though rates of response are not high as there are few incentives motivating students to fill out the surveys if they’re not receiving independent study credit). The three main areas we asked students about (on a peer-by-peer basis) were "Productivity," "Communication," and "Ease of Collaboration." A majority of students rated their peers on the higher end, with only a few students receiving ratings of 1 and 2 in any category. It’s worth noting the Spring 2016 survey used a 1 to 5 scale for rating (5 being the best), where the Fall 2016 survey used a 1 to 10 scale. Naturally, more variance and trending towards medium ratings of 6 and 7 can be seen in the Fall 2016 survey, whereas many of the Spring survey results fall in either 4 or 5. Overall, it appears students are satisfied with their collaborative experiences at GlowLime.
Services
Pitching
Each semester GlowLime hosts a "Pitch & Interest Meeting" (which I'll discuss more later). This event gives students the chance to pitch their projects to an audience of local student and professional developers. There are two categories of projects at the event "GlowLime Official" projects and "GlowLime Match" projects. I'll also discuss GlowLime Match further at a later point in this section. We gather a list of projects pitched on a Google Forms survey. We ask all students pitching for a checklist of information including a working title, necessary roles, and a brief description of the game concept. After the students present their concepts at the meeting, we post a second Google Forms survey featuring all the projects as options. We request developers interested in working with GlowLime for the coming semester fill out this second survey. This survey contains questions about which projects they're interested in and inquires about their game development skills.
Project Selection & Team Formation
For the Official GlowLime projects, we review all the applicants who indicated interest in working on projects pitched through this track. We review projects based on popular interest, but also with careful consideration for scope (how feasible the game will be to make in the allotted time), originality, and distribution of skills from those interested in working on the project. While the exact logistics on how projects are decided has varied from semester to semester, it is a democratic process among the members of the Management team. We also take into consideration the fact some managers may also be the ones pitching projects. If this is the case, they're asked to abstain from any final discussion/voting on whether their project should be selected. Once the projects themselves have been selected, our Hiring department reviews the applicants and distributed them onto the projects based on their skills and interests. The aim is to give each team an ample amount of skilled developers, reliable department leads, and a selection of less experienced developers who can learn from their peers. If a student's pitch is selected, they're automatically offered the role of Creative Director (the head Creative lead on the team).
GlowLime Match
During GlowLime's first semester, we encountered issues with team leads wanting more authority of their projects and less oversight from GlowLime's Management team. We expect the Creative Director and Producer of each GlowLime team to meet weekly with members of the Management team (historically our Projects Manager and Operations Manager respectively). Observing not all students wanted such a structured system for their projects, we also launched "GlowLime Match" in our second semester of operation. This offered the same pitch process for students to gain visibility for their projects, but allowed them to independently select and run their teams. This also helped us draw a clearer distinction between where GlowLime does and does not provide oversight. Overall, this has been a positive move which has increased the number of projects and developers being pitched during our semesterly event.
Statistics
GlowLime has seen an increase in student engagement from our beginning. Our first semester, we began with roughly thirty students working on projects. During our second and third semester of operations, we had closer to sixty students working on projects at the start of each development cycle. While there is a rate of attrition throughout the semester, the initial number of students engaged are very positive. Especially in our first semester, we observed a disproportional number of Hampshire students to other schools. We also had zero Mount Holyoke students during our first and second semesters of operation. Generally, students joining were in their second or third year of school. In our third semester of operation, we've improved school distribution with at least four students from each of the Five Colleges. However, the prevalent majority of students are still from Hampshire (likely due to the fact GlowLime was largely founded and is mostly run by students from Hampshire). We've also seen an increasing number of remote collaborators from other schools such as Berklee College of Music and University of Southern Maine. Overall, the numbers show a solid number of students engaged and will hopefully increase if GlowLime is able to scale upwards.
Games
I’ve worked on five major game projects for my Division III:
Fall 2016
There are two other projects I've linked under Projects which I wouldn't count as my main focuses for Division III, but still demonstrate my work and growth as a programmer and game developer this semester. Object Factory was an endeavor to teach basic programming principles through Unity, a challenge I've struggled with accross many of my projects this semester. Centron was built during the Global Game Jam and nicely demonstrates a well-scoped project for the time frame, which is something I've often struggled with on other projects.
Defender's Light was my flagship project. It was my own design and a chance for me to run a GlowLime project to the specifications I thought appropriate. I also wanted to test whether a GlowLime project could be brought from concept within a single semester of development. The results were mixed. On one hand, the game is playable and shipped. However, it was not without its compromises. Many of the art assets are still unfinished and there are still distinct bugs in the code. There were also many design goals not fully met. In reflection, there are elements which could have been better prepared. The team distribution could have been more balanced, the design goals could have been clearer, and the scope could have been reduced (though this was something I tried to keep in mind while designing it). I still believe building a GlowLime game in a single semester is possible, but it requires a very well executed combination of manageable scope, an experienced team, and proper project management.
The post mortem on Defender's Light revealed team members generally thought the team was a positive one to work on. They did note communication could be improved among departments. They also noted meeting attendance as an issue, especially later in the semester. Generally all departments were noted as being open to feedback; however, there were overestimations of ability, especially on the programming team. Wed had too small a programming department and struggled to recruit new programmers throughout the semester with severely limited success.
Lucid was a project I picked up partway through the Fall Semester. Its programming team was struggling (as many of our programming teams at GlowLime do), and I stepped in to assume a Lead Programmer role. The team struggled to find its footing, and the gameplay experience we finished is not complete. Nonetheless, I'm proud of the programming work I put into the project and I still believe the concept has potential. We managed to reach a state where the game is playable, even if not fully clear in terms of player objectives. Lucid was created by an Amherst College student, Mashi Zaman.
The post mortem for Lucid notes a lot of issues with the programming team, namely the lack of an experienced Lead Programmer from the onset of the project (I gradually took over the Lead Programmer role as the semester progressed). Teammates generally seemed happy with the visuals of the game, but were less satisfied with the final functionality. The texting feature (the main focus of the semester) was praised, but others noted the lack of a tutorial among other key features. There was also notes about attending team meetings, improving communication, and holding team leads more accountable.
Progress or Die was a project which accompanied an event I'll discuss later, GlowLime: Winter Studio. It was created by Hampshire Student, Matt Regan. As a project, the scope began too large, and given our limited production timeline (roughly three weeks), we were too slow to trim the scope down to a reasonable amount. Another struggle for me was the structure of the Programming team. With largely varied levels of experience, it was hard to properly lead the team and deliver a functional product. I switched from extreme to extreme, initially putting too much time into the task management aspect of the lead role, and spending nearly all my time on actual tasks near the end of development (sacrificing a degree of leadership and mentorship to do so). As a proof of concept for full-time work experience, I believe the project was successful. However, like the others before it, it's an incomplete experience.
Respondents to the post mortem survey for Process or Die noted the imbalance between designers and programmers. Namely, many felt it would have been desirable to have more programmers and less designers on the team. Many found working in-person and full-time to be a helpful experience and superior to the part-time and remote nature of most GlowLime projects. When contrasted to semester long projects in GlowLime, respondents found the experience to be more intense, but also more productive.
Letters to Reid was created by a Hampshire student, Martha Hollister as her Division III. The core concept was exploring how we cope with grief, specifically the loss of loved ones. A game focusing on these themes was a very intriguing to me. It was also a project I related to on a personal level. As with the other projects, I served as Lead Programmer. There were challenges, much like the rest of the projects, but we managed to create a playable experience. My main work on the project was a map parsing system which read in game levels from spreadsheets and built them at runtime. This tool was an example of symbiosis between design and programming. Enabling the designers to execute concepts without increasing the workload on programming has been a primary goal of mine throughout the year. From a programming standpoint, I believe I’ve been successful in this regard: designing tools and systems which support tunable input from designers. These tools allow for a great deal of flexibility, and empower the iterative process of game development.
With Pickup Pup, created by Smith College student, Sam Luangkhot, I believe I succeeded in maintaining a strong symbiosis between design and programming. Here again I served as the Lead Programmer for the team, a role I've now held for every major project in my Division III. A majority of the game’s data is stored in spreadsheets giving design full control to manipulate. Im also very happy with the structure of the code. Along with Grace Barrett-Snyder, formerly one of the programmers, and currently the producer of the team, we built a very specific and orderly style guide for the codebase (documented in our Technical Design Document.) Given the consistency in style of the code, and the object-oriented principles we've adhered to, I feel as though the codebase exemplifies the programming conventions I've learned and honed during my time at Hampshire. The team itself is much smaller and tighter knit than many teams on official GlowLime projects. Given this project is not affiliated with GlowLime, we're afforded a level of selectivity which GlowLime's inclusive structure does not permit. This has allowed us to create a more professional and experienced team. Overall, having a finely selected team has made the development process more efficient. Our current production goal is to complete all major work on the game by the end of May. We seem on good track to meet this goal.
Throughout the games I've worked on during my time in Division III, I've seen the concept of compromise emerge above all. Whether it’s compromising for time's sake or compromising with other members of teams, approaching game development with a level of flexibility has been key. On the converse, holding onto ideas or features too desperately has consistently materialized as a detriment to the process.
Events
During my time at GlowLime we've hosted and attended a variety of events. These events break down into four main categories:
- GlowLime Project Events
- Speaker Events
- Showcase Events
- Workshop Events
The most important of these four is easily the official Project Events. These events: our Pitch & Interest Meetings and All Team Meetings are key to the operation of GlowLime. The Pitch & Interest meeting is a time for student developers from across the Five Colleges to come and pitch their concepts. They present game ideas and lay out the kind of teams they need to complete work on their games (among other logistics).
Speaker events are also very useful as they expose students to industry perspectives and different aspects of game development. This year alone we've hosted Pat King, CEO of Woodpenny; Paul Hake, CEO of HitPoint Studios; and James Portnow, creator of Extra Credits. We also work to promote and encourage students to attend the Pioneer Valley Game Developer MAKE! TALK! PLAY! events which happen each month. Introducing students to professional developers is a key part of the experience of learning about the industry.
For Showcasing events, GlowLime has presented at Gameacon, Woo! Game Pile, and MassDiGI's Made in MA PAX party. Attending these events is supported by Hampshire's CLA (Campus Leadership and Activities) department. Since the establishment of the student group, GlowLime Games: Hampshire Division, the CLA’s support has been invaluable to GlowLime's ongoing efforts. While we remain dedicated to serving the Five Colleges, we recognize many of our Managers and Collaborators are based at Hampshire. Being registered as a student group here has proved useful multiple times over. Thanks to CLA funding, we're able to journey to Worcester, Boston, and even New Jersey to attend Showcasing events. This is another excellent opportunity for students to see more of the local game development industry. It's also a great chance for them to demo the games they've been developing. Receiving feedback from other developers and gaming enthusiasts is crucial to improve the quality of games GlowLime is developing.
GlowLime: Winter Studio is our pilot event for game development workshops. We secured the computer lab in Adele Simmons Hall for three weeks in January 2017 (during Hampshire's winter break). We setup a structure in which students could work full-time on a project, Progress or Die and hone their skills working on a development team. While students were encouraged to work full-time, there was no way to require or enforce this, so many did not choose to attend the workshop daily. It was a notable drawback, when only select students were consistently coming in to work on the project. However, there was a notable advantage of having the opportunity to work on a project full-time compared to the part-time nature of many game development projects at Hampshire.
Competitions
I've now attended the MassDiGI Games Challenge twice. The Games Challenge is a pitch event dedicated to game development, in the spirit of such game shows as Shark Tank and American Inventor. Teams ranging from the high school to the collegiate level come to the Microsoft Center in downtown Cambridge to present their in-development games. I first went in 2016 representing a GlowLime team (and arranging for three more to attend along with my own). I attended again in 2017 representing Pickup Pup. In 2016 (before the start of my Division III), I was there pitching a game I worked on as producer, Lex the Wizard. In pitching the game, we discovered it wasn't yet ready to demo and the lack of a monetization strategy hurt its marketability in the eyes of the judges.
Grace and Sam also worked on Lex the Wizard in 2016. The three of us returned in 2017 with Pickup Pup having learned from the previous year. Our demo was tighter and vastly more playable, our pitch was highly refined, and we had a solid monetization strategy. Ultimately, we came in third in our category (College Alpha). This demonstrated a noticeable step forward in our development and pitching skills over the course of a year. It also highlights a drawback of GlowLime. As a for-education organization, we opted to avoid monetizing our games. The decision helps to avoid complicated issues of ownership and compensation. Building games on a volunteer-basis makes the logistics simpler and stakes lower. However, for a game like Pickup Pup (which is independent of GlowLime) we're able to set in place monetization strategies. At this stage in the game's development, we plan to add incentivized ads (video ads which grant the players rewards for watching) and in-app purchases (the ability to buy virtual content with real money). These combined approaches are commonly seen in modern mobile games.
Failures
GlowLime has experienced many successes in the time it's been in operations, but it's not without its failures and limitations. The same goes for the games I've worked on. In both cases, I've made mistakes and poor judgment calls.
With GlowLime, the mistakes have often been misbalancing workloads or hiring people who could not handle the tasks they were assigned. There were many times I asked too much of certain individuals while not asking enough of others. There were people who worked on the organization who did not give enough to their role, and I was often hesitant to confront them about these issues. In hindsight, this hesitation made GlowLime less efficient than it could have been. Failures in selecting teammates aside, I also struggled to manage my time well.
A recurring trend in my work has been taking on too many projects. Division III is no exception. While I'm proud of having worked on so many different projects and gained such varied experiences, I also feel I could have produced higher quality work if I'd focused on less projects. Defender’s Light as my flagship title is an excellent example. I was encouraged to spend the entire year working on the project as many other Division III students tend to do. However I opted instead to ship it within a semester to demonstrate GlowLime is capable of producing projects within a semester. Doing so gave the project less time than it deserved in development.
As a programmer, I've also experienced failures, namely trying to over-insulate systems. While I stand by my claim that a flexible system is important, I have run into many cases where my refusal to code something the quick way instead of the clean one lead to increased production time or not fully meeting deadlines. There are times I've found it difficult to balance being a software engineer and game developer. The core principle of software engineering is to write clean code, whereas the ultimate goal of game development is to finish and ship games. These objectives are often at odds.
For Pickup Pup, I've found myself building entire spreadsheets and parsing systems for one-off features which are only loosely connected to the core systems. While these steps do increase the flexibility and customizability of the project, they also add significant overhead for relatively simple features. Such systems which could be hardcoded in a fraction of the time. It's difficult having learned the principles of clean code and modularity to identify where to draw the line between well engineered and over-engineered.
Another way in which I've found this hampering me is collaborating with other coders with different coding conventions or principles. I mainly worked with two engineers remotely for Defender's Light and found myself repeatedly rejecting pull requests which were technically functional but not implemented in the style/method I would have used. While I feel I'm an efficient coder in isolation, I'm still working to find the most efficient ways to collaborate with other engineers.
One of the core challenges I've faced in working on engineering teams is varying levels of experience. More often than not, I've found myself the only member of the team who's experienced in Unity. This brings with it the challenge of balancing engineering work and mentorship. I endeavor to do a good job at both but often find myself falling short because both tasks are so time demanding, it's extremely difficult to do both justice. Across all the major programming projects of my Division III (save for Pickup Pup), I've struggled to balance being a teacher versus being a developer. Coming back to the bottom line of meeting production requirements, I often have to sacrifice proper mentorship to ensure a finished product.
This is a challenge GlowLime struggles with as a whole. The disparate levels of knowledge about Unity and C# on programming teams create inefficiency and seriously limit our capabilities. Each semester we attempt to form balanced teams with experienced programmers; however, there are often simply not enough programmers who have prior Unity experience. While it's possible to learn in a semester, we've repeatedly observed students who don't have the time or motivation to do so. The rate of attrition of GlowLime programmers is especially high due to these limitations. One initiative we're looking to launch this coming semester is scaling each project by experience level. Ideally, we'll have a project geared for beginners, another for intermediate developers, and a third for more advanced students. While this applies across all disciplines, it will be especially helpful to inexperienced programmers as the required technical knowledge for a beginner project will be much less than the expectations on an advanced project.
Legacy
The concept of legacy has always been an important principle at GlowLime. One of the main ways we've worked to secure the organization's ongoing integrity is through hiring dedicated student managers who will continue on the efforts as the current Managers graduate. My main choice in this area was promoting Joel Esquilin to Executive Director. I served in the role throughout my third year, and for the first semester of my Division III. Joel took over for me in December. He's been doing an excellent job thus far. The intent in promoting him before I graduated was to continue provide a level of support, but still give him the full agency in leadership. My hope is this will best prepare him for the coming year when GlowLime is primarily his responsibility (until which time he chooses a successor for the Executive Director role). Across the Management team, we've been working to find younger students to join and learn the logistics of soon-to-be vacant positions. We've been working to make the process of onboarding as seamless as possible. The first step is getting new Managers setup with our collaboration tools (Slack, Trello, Google Drive). Next, we work to expose them to the expectations and requirements of their roles. We aim to gradually offer them more responsibilities to feel comfortable in their roles. In this spirit, I’ve also been training Hyeonseok Cho to replace me as Technical Director. Ultimately, the ongoing success of GlowLime depends on having students who are passionate enough to lead it. However, I think we've established a solid foundation and structure throughout GlowLime’s first two years of operation. Hopefully this will be sufficient to ensure its longevity at Hampshire and the Five Colleges at large.
New Learning
I mentioned compromise before when discussing my game projects. This has been a theme throughout working on GlowLime and my Division III as a whole. Finding the proper compromise between time, quality, and team dynamics is a constant challenge. This balance is hard to maintain, sometimes impossible. However, I've found situations where I've been unwilling to compromise often had the worst outcomes. Having served in a variety of leadership of roles during my Division III, I still believe there are times when it's necessary to take a strong stance, but being flexible is far more important. Game development, just like any other collaborative work, is largely dependent on team dynamics. Sometimes team dynamics are unstable simply based on the personalities and dispositions of team members. Here again, finding ways to compromise and work around & mediate such conflicts is vital. We've had such situations arise at GlowLime and have done our best to handle them.
I've also learned a great deal about programming, specifically as it relates to games. The way compromise is most apparent in the discipline of software engineering is balancing clean, organized code against development time. Personally, I'm more interested in creating the best structured code. However, I've learned there are times when this is not feasible to prioritize quality of code. There is always the bottom line of whether or not the code works in time for the deadline. It's a hard balance to strike, like the aforementioned production considerations. However, I've developed techniques and methods for creating clear, clean structures, while delivering them efficiently. One of my successes has been developing a pool of classes and systems I can reuse between various Unity projects. Having a majority of the basic code written to reuse across projects has saved me a great amount of development time. I've also found building flexible/solid foundations of code has highly paid off later in development cycles. Initially, it always seems fastest to write code which simply meets the present technical requirements. However, it's also important to anticipate how the requirements of a system may change, and design code be flexible in such situations. Especially for longer term projects, this minimizes the amount of overhead required when making changes to pre-existing systems. This is often where a bulk of the time cost comes in software engineering. In my experience, building systems from the ground up is relatively quick, whereas changing existing system can prove very time consuming. The time cost at this point is largely based on how the system was originally engineered.
Reflection
I believe it's important to frame Division III, GlowLime, and the games produced as experiments. All the projects, and GlowLime as a whole constitute a mix of successes and failures. Learning why certain aspects failed and why other succeeded is key. I hope through the variety of experiences I've had in game development, specifically software engineering and project management, I've discovered many pitfalls which some won’t stumble upon until they're working in the professional sphere. I also feel I’ve failed often enough and made a sufficient number of missteps as an organizer to see how I can become a more efficient leader. However, there are also the successes in my Division III which deserve recognition. I was a major contributor in creating a game development organization at Hampshire and in the Five Colleges, I believe this is especially notable because no comparable organization existed here before GlowLime. We managed to make at least three games per semester for the last three semesters. All of these games reached various states of being playable. I'm proud of the work I've done. More-so, I’m incredibly proud and grateful for the work all the other contributors have given to GlowLime. To thank all the individual managers, collaborators, and advisors who put time into making the organization what it now is would take many more pages. At the very least, I can say this was the most valuable part of the experience. Getting the chance to work with so many talented developers and organizers, to meet so many new people, and to learn from them from was easily the most valuable part of my Division III.