SIP22 team selected
By Timothy Loew, Executive Director
Since 2012, applications to our Summer Innovation Program (SIP) have grown year over year in terms of quality, geography, major and diversity. This time around we received applications from 251 undergraduate and graduate students representing 71 colleges and universities from around the world making it, once again, one of our most competitive year ever.
Choosing only 25 as interns was very challenging. After many hours, we selected a really talented group. This summer’s SIP22 team will be made up of interns from 12 institutions including Berklee, Brown, Clark, Fitchburg State, Lesley, Northeastern, Quinnipiac, RPI, RISD, RIT, WIT and WPI.
SIP22 begins on May 17 and concludes on August 5. Over those 11 weeks or so, with guidance from staff and industry mentors, SIP22 teams will be responsible for all the work necessary to prepare a game for launch. Simply put, there is no internship program like it in the world.
Like last year, there’s still a pandemic on so we may be impacted by that again. In addition, this will be our first summer running SIP entirely at WPI and expect a few wrinkles with that, too. The world may still be a bit messy right now but we are adjusting to create the best program and greatest experience ever – and we can’t wait to get started.
» Read More
Despite being someone who has been interested in gaming as far back as I can remember, I had never had the opportunity to try and develop a video game until I was part of this internship. Pretty much all of my programming experience so far has been in relatively simplistic coding environments such as Eclipse and VSCode, and the only output was usually a text output or behavior in the physical realm. While there are similar themes in all coding environments, Unity would prove to be quite the new and interesting experience.
The first challenge that I had to face when using Unity for the first time was the complicated user interface. While I know my way around it now, practically at the end of the program, the sheer amount of buttons, scenes, and new terminology was more than multiple skims of the manual could prepare anyone for. In Fig. 1, instead of being presented with a central area for coding, like in Fig. 2, the user is presented with nothing more than the camera. Also, unlike in Fig. 2, where the user can get coding immediately, the user has to create a script somewhere under assets, which is an idea foreign to most programmers.
Figure 1: Unity’s new project screen, which is relatively complicated
Figure 2: Eclipse, a common IDE, which is simplistic
After getting a grasp on Unity’s UI, Unity began to feel natural. By this point, I had taught myself a bit of C# and had written a few basic functions. Despite this, I still found myself struggling with yet another roadblock: applying scripts. In Unity, there is a good number of ways to reference assets within code, such as through public variables (which allowed for dragging and dropping the assets into the script’s Inspector), which I discovered to be good for tasks like spawning a number of the same asset, or using a find command, which works best for quickly finding something static that already exists within the game scene. I would argue that at this point, any programmer would know the basics of how to use Unity, but in order to do something of any complexity, there are a few quirks that any user must deal with.
The largest of these so-called quirks is transforms. Someone new to Unity, like myself initially, assumed that all of the coordinates were relative to the world. However, this was not the case. This unfortunately led to a few issues in game, such as defining the maximum distance an enemy could move as a box around the enemy, but since it changed based on the enemy’s position, it always stayed in the middle of the box no matter where the enemy moved, effectively allowing it to go anywhere, as seen in Fig. 3. To fix this common issue, the best approach is to make it dependent on something which does not move, including putting it at the same level as the object which contains the script.
Figure 3: One of the pesky bugs who kept going offscreen
Another of these quirks are the Find methods, which I briefly mentioned earlier. In short, their role is to refer to specific game objects elsewhere in the script. Despite these functions having a role integral to just about any game, they can be difficult for new users to wrap their head around, like it was for me. The two different versions of the function are GameObject.Find(), which is used to look through ALL GameObjects that exist in the scene, and GameObject.transform.Find(), which returns the transform (not GameObject!) child of the searched object. This method can also use .parent to go to whatever it is nested in (it’s parent). The first method should be used to find something that exists many steps away and is unique, while the second method is best for items that exist nearby to the script, or within an object which has multiple instances. This is due to how the first method cannot handle repeats, and the second one handles them by going up and down the GameObject’s tree. Variables references in the inspector are a great way to completely mitigate this issue, but both of them have their own use cases.
Overall, I would say that I had a positive experience in Unity after climbing over a few hurdles that presented themselves to me in the beginning. Unity is luckily well documented, which allowed me to use new methods with ease. Also, since scripts are applied to assets very easily, making it possible to see the results of code very quickly, I was as fulfilled as, if not more than, what I get from Robotics projects; there are simply few things as joyful as seeing your code in action. In short, I have had a positive experience with this software which has further sparked my desire for game development, and has shown that it is, in fact, a possibility for my future. I hope that my next projects are as fun as this one.
By Philip Lund
» Read More
Freezy Match, a free, fun and fast-pace matching game, is available for download now on the Apple App Store and Google Play.
Fill penguin orders as they quickly slide across the ice; drag and drop colorful snow cone chunks onto their cones, or risk missing out on some valuable points! As time goes on, you’ll really start to see how hectic this tundra can get. Miss three penguins and you’re out!
The mobile game was created during the fall 2021 MassDigi XP3 internship program by Andrew Lobasso, Ben Lipkin, Gaspare Spizzirri, Jordan Dube, Joseph Benson and Victoria Kelley.
Watch the trailer here and download Freezy Match today for iOS and Android!
» Read More
Kitten Coliseum, a free, fun action battler, is available for download now on the Apple App Store and Google Play.
Play as an honorable cat fighting against hordes of the despicable, but tasty looking, mice from the Mice’s Republic of Swiss Cheese! Control your honorable steed, the Robot Vacuum – and drive, slash and pounce your way to victory!
The mobile game was created during the fall 2021 MassDigi XP3 internship program by Steve Kruger, Jian Liu, Annie Higgins, Margaret Patel and Matthew Peters.
Watch the trailer here and download Kitten Coliseum today for iOS and Android!
» Read More
Flytrapped, a free, fun 2D platformer, is available for download now on the Apple App Store and Google Play.
Follow a flytrap’s struggle to escape a treacherous lab filled with mutant plants, dangerous obstacles and (of course) flies! Eat, bite, and climb to make it out alive. Do you have what it takes to help rescue the fly-boy from impending doom?
The mobile game was created during the fall 2021 MassDigi XP3 internship program by Audrey Spencer, Giancarlo Spizzirri, Hyeongjun Kim, Kenny Venancio, Philip Lund, and Zihong Ren.
Watch the trailer here and download Flytrapped today for iOS and Android!
» Read More
When a designer identifies the core feeling that the game wants to give to the player, it is important to consider that all game elements serve to deliver that feeling. One of the most intuitive feeling games reveal to players is first and foremost visual. A game must have its unique artistic elements in it in order to bring players psychological satisfaction, such as the connection between art style and UI design in casual games, they tend to be cartoony with bright saturated colors. So, the elements of a well-integrated game need to match. These elements need to be matched between art styles such as color and texture and designs such as cartoon or realism to create a sense of harmony. However, the artist’s resources need to be abundant, both in quantity and quality in order to achieve this harmony. So, the bulk of our pre-planning stage uses mood boards to help us before we actually design.
Mood board is the key tool for improving and evolving our ideas throughout the design process. The benefits are obvious: it improves team members’ efficiency and guides a cohesive art generation process.
We began our journey by brainstorming potential game concepts. We created mind maps which generated two concepts we felt had potential.
The first game we tentatively called “Snail Mail”, which is a casual Endless Runner game. The second, also tentatively named, “Venus Flytrap” is an Endless Platform game.
After establishing the concepts to move forward with, we began the mood board phase.
The aesthetic we chose was retro futurism (’50s sci-fi) for “Snail Mail”
Because the feeling we brought to the player in this game was first and foremost crazy and fantastical, we chose a lot of products from the retro-future, such as retro nuclear-powered cars and community scenes. Because our game wants to provide a relaxed and lively palette.
We choose a lot of high-brightness and low saturation colors on our color palettes. In this way, we hope to bring players a relaxed and joyful experience of the game.
We established “Venus Flytrap” to be quirkier and more earth toned. The game’s design focuses on the jungle environment. So, for the mood boards, we tended to look for elements from nature, and we got a lot of pictures for our reference, including dark forests, exotic Venus flytraps, insects, and some carnivores.
Both “Snail Mail” and “Venus Flytrap” games were beginning to shape themselves into more concrete ideas we could present to other teams but our team was more eager to focus on the “Venus Flytrap” idea as we were able to find more reference pictures, ideas, and motivation from the team as we progressed.
From the elements of these pictures, we extract new color palettes, most of them are green and blue palettes with high grayscale. After that, we redesign all the elements to fit the overall game environment.
After that, our game gradually began to have a storyline, and according to us, the player character was a fly trap escaping from the lab and constantly needing to get food in order to survive. So, we started looking for pictures of abandoned greenhouses and laboratories to meet our design needs.
To make our design more believable, we took a lot of different species of Venus flytraps and designed them to be enemies in the game. For example, we liked a Venus flytrap of Cobra Lily and thought it looked like a boa constrictor that could swallow the main character. This design not only meets the overall environmental needs of our game but also improves the sense of harmony between game elements.
As we are moving forward to more environment and enemy resource research, more enemies that tend to affect the game mechanism are created.
The moss from the mood board inspired our team’s game designer of a “platform murderer”, which can kill the player’s character. In addition, we have many new designs to add to the game, all inspired by mood board.
To sum up, mood boards are the integration of our inspiration sources, and their establishment lays the foundation for our entire project. From the beginning to the middle of the game, we’re constantly adding new elements. In the browsing, constantly exercise our design thinking; Change, add, or remove elements of the game to nurture and grow into a mature product.
By Zihong Ren
» Read More
Not all ideas are great. Or perhaps, not all ideas work in a game setting. The process of coming up with a game to create can take many steps. Our team (named Curry) took multiple brainstorming sessions, prototype game builds, and a complete reset of our game.
Let me start at the beginning. For our brainstorming phase, each member came up with a few game ideas (about 3 each) that somehow could be related to a mobile game already on the market. Then we went over each of the ideas and decided which ones we enjoyed as well as which ones could be related to a popular published game with a similar mechanic. With this narrowed list, we then voted on a top 3 and fleshed them out more: researching various games and what made people want to download them. We then did the whole process a second time, having a total of 6 games to narrow down.
We were left with 3 possible games:
- A photo-capturing cryptic game with a mechanic similar to arcade shooters
- An idle fishing game where you capture fish to feed to a bigger one
- A bomb factory game where the player must match the bombs to the boxes, similar to a lot of matching games
The first game idea seemed to work the best for us, so we went ahead and started making an actual game. We had a problem, though, XP3 required us to make two test games of various mechanics. 
Being so attached to the cryptid idea, we branched other gameplay off of that, so instead of just taking photos, the player would capture creatures to add to their zoo, which slowly earned them money. This turned the quick-tapping shooter game into more of an idle property management game.
After making both test builds, we realized that we had a tendency to over complicate things. None of us being too familiar with the mobile market beforehand, we were used to the complexity that came with console and PC gaming, whereas mobile player look for something easily digestible in a matter of minutes. Long story short, the complex idle/creature capturing game was canned, even though art and audio was made alongside it. Still favoring some kind of photo mechanic in our game, we leaned into the idea of the player as a bird watcher, where all they had to do was take photos of birds. While the thought was simple and the photo taking was mildly interesting, there was no gameplay substance to it. The player wasn’t encouraged to have a purpose.
After mulling it over, we decided to take the camera mechanic away as the main focus and put it on attracting birds (specifically for us, owls) to stop by and give you currency as they leave so you can buy more things that could attract more rare owls. It was during working on this new gameplay loop that we got rid of the cryptid idea. Just tapping on cryptids made the gameplay a little too easy, and the theme wasn’t popular on mobile, so it would have been a difficult game for players to catch on to.
So, production began on the owl collecting game. For the whole gameplay loop to function correctly we had to create a shop, inventory, a photo album, and a camera. We also had to create a lot of art and audio assets so it was both visually pleasing and made sense to the player. When designing the game, we tried to mimic what made other creature collecting (most famously Neko Atsume, the cat collecting game) interesting, and improve upon other parts, that included the layout of the menus. Within a week or so, we got a working game build up and running, aside from some minor glitches that came with the input differences on mobile and PC.
The results… It flopped… Terribly. Visually, it was good. Audio was pleasant and added solid feedback. Programming-wise it did what it was made to do. But unfortunately there was no game. Players didn’t quite understand what to do. Why did they need to attract owls? Where was the fun? Okay, I can put a hat on an owl and take a photo of them dancing, but what happens now? When testing the game, we decided not to add instructions, just to see if players would understand the game. Obviously that didn’t work out too well. It was difficult with our small test build to show players how we wanted them to play the game, and how the game could be enjoyable. With all the negative feedback and glaring design problems, we stepped back for a second. Should we keep working on this? It took a lot of assets just to get a small test build working, and it’s going to take exponentially more to get a full game out the door. No, we weren’t victims of the sunk cost fallacy, we dropped production on the game.
Where to next? We could go back into the brainstorming phase, but it’s over halfway through the internship and we need to have a rough draft on marketing materials done by… next week. We needed a game that was both easy to develop and didn’t require the production of a lot of assets (and something that people understood how to play). We looked out our previous brainstorm at the beginning of the internship and saw the bomb matching game. Matching was easy to understand, and all we had to do was create a single bomb icon and recolor it to make plentiful assets on a whim.
Woah, woah—bombs? That’s the theme we want? What about some other ideas? Hats on raccoons? Too many assets. Mad-lib style word matching? Penguins with snow cones? Now hold on a second—that just might work. It’d be simple to create, need minimal assets that we can change programmatically, and the theme is fun and understandable enough so it won’t need a tutorial. With the idea in place, we set to work…and made the prototype in a day. With the mechanics set, we’re now in the process of importing art assets, audio, and a little of that design magic we call “juice” (mainly, particle effects and user interface animations). With production going a lot quicker and more smoothly, we’re hoping that any future flops are merely penguin related.
Thanks for reading!
By Jordan Dube
Team Curry consists of:
- Andrew Lobasso – Programmer
- Gaspare Spizzirri – Producer, Artist, Programmer
- Jordan Dube – Programmer, Designer
- Victoria Kelley – Designer, Artist
- Ben Lipkin – Audio Engineer
- Joseph Benson – Artist
» Read More
Coming up with a game concept can be just as mentally engaging as making a game. Here at Team Stir Fry, we experienced that firsthand. Steve, Matt, Jian, Annie, and I created several flowcharts and moodboards of random buzzwords and pictures before settling on a few to stick with. Space outlaws? Toy boats? The sky was the limit, but there were a good amount of concepts that we instantly agreed on. I honestly did not expect that the first two weeks would be just brainstorming, but it was a fun process.
Personally, as an aspiring game composer and audio designer, I started XP3 feeling overwhelmed. I have had years of musical experience, but I’m currently a newcomer to the game industry with only a basic knowledge of Unity. While the learning curve has been steep, I’m glad that my teammates are there to help me work through the more technical things.
For our tank-style arcade battle game dirty build, I tried to make the music silly and lighthearted using quirky synths, accordion, and banjo since our concepts included cats on roombas and a bear invading a campsite. I also made more of a dramatic orchestral track for our sci-fi version of the build. I searched through plenty of cat and bear sounds to make the game extra silly. My goal for this build is to have something fun that doesn’t take itself too seriously.
Our other dirty build, an endless runner, was heavily inspired by musical concepts. We wanted lofi hip hop. We wanted synthwave. We wanted any kind of music that could be turned into a visual aesthetic. We were even considering turning this game into a rhythm game. Our concepts included a classroom desk, a bold neon aesthetic, and a pirate theme. The pirate theme idea actually came from one of my more orchestral background music tracks. I also created a bossa nova song featuring my own live flute playing as an option. Overall, it is possible that I got a little carried away with the excitement of making background music assets for this build.
As the dirty builds are being worked on, I have to adapt and update the audio assets constantly. Oh, the cat is using a lightsaber, not a laser gun. Oh, the music should probably feature a different scale if we want to evoke a certain setting. The game needs to sound like how it looks, and watching these games grow keeps me excited and on my toes. I’m looking forward to seeing where this project takes us!
By Margaret Patel, St. Michael’s College ’20
*Team picture, from top left: Annie Higgins (Art), Jian Liu (Programming), Margaret Patel (Audio), Matthew Peters (Design), and Steve Kreuger (Producer)
» Read More
As usual, we have a lot of fun stuff planned in the coming months! Please, save the dates important to you.
- 9/24/21 – Pre Game Challenge (location: virtual) registration opens
- 10/4-12/10/21 -XP3
- 11/8/21 -XP4 application opens*
- 11/20/21 – Pre Game Challenge (location: virtual)
- 12/22/21 – Game Challenge registration (location: tbd) opens
- 12/22/21 – XP4 application closes*
- 12/29/21 – SIP22 application opens
- 12/30/21 – XP4 selections*
- 1/24-4/8/22 – XP4*
- 3/21-25/22 – GDC*
- 3/21/22 – SIP22 application closes
- 3/28/22 – Game Challenge registration closes
- 3/28/22 – SIP22 decisions
- 4/1-4/2/22 – Game Challenge (location: tbd)
- 4/21-4/24/22 – PAX East*
- 5/17-20/22 – SIP (location: virtual) onboarding
- 5/21-8/14/22 – SIP (location: tbd)
* Maybe
In addition, we expect to finally begin to update our website and have changed Collab (fka LiveStudio) to DigiStudio going forward.
Revised: 12/22/21
» Read More
Mochi’s Dreamland, a free, fun 2-D platformer, is available for download now on the Apple App Store and Google Play.
Help Mochi climb to the top of his dream tower to save his favorite toy mousy! Mind your aim or you just might find yourself back at the bottom!
The mobile game, originally known as Dream Pop, was created during the summer 2021 MassDigi XP2 internship program by Jacob Siegel, Camden Gamlin, Nathan Moura, Kiria Bentley, Kshitij Gajapure, Melanie Thibodeau and Greg Bonini.
Watch the trailer here and download Mochi’s Dreamland today for iOS and Android!
» Read More
