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
MassDigi’s Tim Loew will be a panelist at the Berkshire Innovation Center’s BIC Presents Event on emerging technologies and the metaverse. To register, please click here.
» Read More
Join MassDigi’s Monty Sharma for a WPI Wintersession talk entitled “How to find and build a $100 million business: What engineers and scientists need to know to have huge impact.” For more information, please click here.
» 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