Since the vast majority of our team had English as their second or third language, I made sure to ask clarifying questions to make sure how I was blueprinting the objects to react to the player was what they had in mind. Often this done by drawing things out on paper, or making quick demonstrations in engine, and frequently rephrasing what I was saying until I fully understood what they were asking of me. It also helped that the other programmer I was working with helped as a go-between when I still was not quite understanding what they wanted of me. By the end of the Game Jam I had gotten much better at listening to what they were saying and understanding the point they were actually trying to make.
The hardest programming challenge from this project was figuring out how to design a system that allowed us to make only one blueprint and then hand that off to the level designers to place in the level. While at the same time allowing them to dynamically change which players needed to interact with the object in order to have it react in game. Both myself and the other programmer started working on trying to prototype out the framework for this immediately after the team decided on the basic gameplay loop our project would have. I personally tried to create something using the "Cast to" node, however the ended up being extremely inefficient, inelegant, and confusing to figure out. Our other programmer decided to make use of UE4's Blueprint Interfaces in order to easily cast from the player to any blueprint we added the interface to. (The TraceActors macro was a simple Sphere trace for multiple objects so that we could send the BPI information from the player to whatever object was within the interact range)
A fun fact when we were creating the above system, I learned that when someone holds down four keyboard keys at the same time with each one needing to have its input recognized by the game, UE4 does not recognize the fourth input until one of the previous three input keys is released. This is why for our control scheme we decided to have player four on the mouse rather than the keyboard.
Once we had finished creating what would send the information to the object blueprints about which player had their key/button pressed we got to work on designing the logic that would be held in each object to check if the correct combination had been pressed. We made a public boolean array so the level designer could chose which players would need to press their button in order for the object to influence the player character's movement through the level. From the blueprint interface messages we made another boolean array in the object blueprint itself that would compare the currently pressed keys to the boolean array the level designer set. Every time a player pressed or released their button it would check the arrays again, and once it registered the correct combination we would have the object set a boolean that the correct input had been received, and in some cases start a custom event.
This is what the level designer would see when placing the object blueprint in the level, whichever player boxes were checked meant that those were the players that would have to press their buttons in order for the object to influence the player character.
For each specific object we had that would move the player character I worked with the level designer to figure out which variables they would need to change or want to have access to change easily between copies of the same blueprint. For example we had a launchpad that would launch the character upwards in a direction when the character was on top of the object. I made variables for the angle of launching the character on the Y axis and the vertical strength of the launchpad itself.
This was extremely helpful for trying to make the finished game feel consistent and fair to play in the end. By allowing the designer and artists to tweak values independent of the object's base blueprint. From the above example this was what the level designers and artists would see in editor in order to make changes to the variables they wanted quickly and easily.
The other challenge we had was figuring out how to display in game which player's input would be needed to activate the different objects in game so that the players could tell at a glance if their button was required. Initially we wanted to do this via textures to keep the visual clutter to a minimum, however we quickly realized we had too many objects to reasonably texture given the time constraints. So we came up with the idea of making a set of decals for each combination of player inputs that could be applied to the object in editor that would quickly and simply show which players were needed for that specific object. We assigned each player a color and made decals for each combination which made changing the level design or expanding it much faster for the designers. For example this is what an object would look like in game if player two and player three needed to press their buttons in order to activate it.
Participating in Global Game Jam improved my skills with working with new team members tremendously, my communication skills at the end were leaps and bounds ahead with what I started with. I also got to experience a lot of work I started working on being cut in the end because it did not fit within the time frame or scope of what we were able to accomplish for this project. This was something I had very limited experience with before, this project helped me see that even when something you spent awhile getting to work correctly gets cut that it doesn't mean the work went to waste because you can look to see if you are able to use any of the parts in future blueprints. During this project I improved my skill at designing easy to use tools for the designers and artists on the team in order to easily iterate and test different parts of the overall level design. The experience to learn what artists and designers expect from tools like that I feel is extremely valuable experience to have.
Lessons Learned -
UE4 Executable:
UE4 Project File:
Project File & Executable -
During the project the artists wanted me to create a claw object that would be able to pick up and move the player character. This presented a unique challenge because unlike the previous objects where the difference between them was how many and which players needed to press their button, for the claw the artists wanted all four players to be needed in order to use it. The catch was they wanted which player did what on the claw to be able to be changed in a similar way to the other objects we had already blueprinted. So for the first iteration I was able to make the claw itself function, but only had one way of the player's interacting with it (i.e. player one always would make the claw go up or down).
Extended Work -
The above image just has 2 different custom events for each player, one would play the timeline forwards while the other one would reverse it. The issue with only doing it this way was there was none of the customization that the artist had wanted. This lead me to learning a very important lesson and reinforcing another important aspect of coding. At around 5AM (Twelve hours before the project was due) I managed to cobble something together in my exhausted state. I thought I had figured out how to give the artist the customization they wanted. However I noticed it only seemed to work for two claws and any time I added a third, suddenly the third one would not function properly all the time. I had ended up blueprinting something that sort of worked, but I could not explain why it worked. What I learned here is coding when exhausted leads to overlooking simple logic errors that would have been caught under normal circumstances. We ended up not having the claw (and a handful of other objects) not in the final build due to time constraints, but this is what my blueprint looked like by the end of Game Jam.
What I had ended up doing was creating logic that only worked for two unique circumstances, which in my exhausted state during Game Jam I never quite figured out. It was only after probably the third or fourth person I spoke to as I tried to talk out exactly what this code was doing that I figured out my mistake when I designed the blueprint logic pictured above. If I had not spent the time after Game Jam to talk through my code and step through it I do not think I'd have found my error nearly as quickly. After I figured out why my original blueprint only worked in very specific cases I decided to fix it in my spare time so I would learn how to design it properly.
While a few days late for Game Jam, it was helpful for myself to figure out how I should have solved this problem. While a bit awkward for designers or artists I also had the claw working so someone could place as many as they wanted in a level, and chose which player did what. In the future I would have likely made it more clear than what I ended up with but for something personal to work on it did the job it needed to.
Youtube Trailer:
Game Jam Site:
Summary -
I participated in the 2018 Global Game Jam at the SCAD University site, and the theme we were presented with was "Transmission". Our idea was what happens when you insert a coin into a vending machine and the process that transmits it through the inside of the machine. Our team also wanted to make use of the diversifiers; One Tap for All (Control scheme could only be pressing or releasing one button) & Under the Influence (Could only influence character's direction, but couldn't directly control the character). So we decided to make a four player physics based game about helping a coin reach its destination. Our final game ended up receiving the award given out to "Best Use of Diversifiers" which was a wonderful way to wrap up this project.
Challenges -
The glaring challenge of participating in a Game Jam is of course the time limit given to participating teams, this ends up influencing more design decisions down the line than I originally anticipated. The diversifiers we chose lead to unique challenges when myself and the other programmer were creating the blueprints for the assets that would help the coin through the inside of the vending machine. We needed a way to using the same blueprint be able to change how many and which players needed to press their button in order to interact with each object, otherwise we would be forced to make fifteen blueprints of the same asset just to cover all the different combinations for interactions. While our other diversifier made it difficult to make the game feel consistent and fair to the players, something that I feel is difficult to do when using physics based movement. Due to having objects in the level that would only work when the right players pressed their controls, so we needed to come up with a way to tell the players at a glance which players would be needed for each object. Another challenge that was more of a personal challenge rather than a challenge for the group was communication between myself and the rest of the team, this was because for most of the rest of my team English was their second or third language.
Solutions -
Our team handled the Game Jam time limit fairly well by in the beginning getting together our overall vision for what we wanted our final game to be. From there we divided up the tasks for what each person was skilled at, so the modelers started working on the objects we would use in game to move the character around the inside of the machine and the set props. Our level designers started sketching out rough level layouts and myself and the other programmer started working on blueprinting the functionality for the different objects that the art team would model. Since our team had a clear division of labor and set teams, work went quickly and there was minimal redundant work during the process. This allowed our team to finish and deliver our final product with time to spare, so while we all definitely felt the stress of working with such a tight time limit, the impact felt was minimized.
Overview -
A Vending Mission was the game I worked on for Global Game Jam 2018, the goal of the game was to move a coin through the inside of a vending machine with 4 players, each only being able to use one button for controls. Players did not move the character directly, instead they influenced objects in the environment to move the character through the level.
