From 3 years to 3 days: Spring #UE4jam
We participated in Spring #UE4jam! While our first project took three
years and is still not released, here is is what we learned while
making a game in 3 days:
One big advantage of using the Engine of another company is that they host great events like game jams.
At the beginning of such an event, a theme is announced to which your team then gets a limited amount of time, usually 2-3 days, to develop a little game. For us as Vhite Rabbit it was the first time we participated in such an event. Two of us, Florian and Maximilian, did join one before, though.
Since the size of teams was limited to five, not all of Vhite Rabbit were able to participate:
- Jonathan took care of code
- Florian took care of texturing and integrating Assets
- Maximilian took care of all 3D modeling, some 3D Poses and even textures
- Tobias also took care of code
- And Philipp Dörflinger (check out his Soundcloud profile), who is not technically a Vhite Rabbit, but helped us out with the soundtrack for Side Trip to Wonderland and in the past. He produced the amazing soundtrack and all the sound effects.
Spring into Action!
… was the topic for this year’s Spring #UE4jam. About an hour after
the topic was announced, we began brainstorming in a hangouts meeting.
The first concrete idea we came up with was a type of time-travel
puzzle game in which you would change around things in the Winter and
then “spring into Spring”, when all the ice has melted. You would then
be solving some puzzle through a kind of Rube Goldberg machine.
We do have over three years of experience in planning overly complex games and we quickly realized this game would never be made in three days.
The nice part about this topic is that “spring” is a ridiculously ambiguous term. You have the bouncy thing, the season, the water source, the new-born plants… so much to work with!
Finally, Maximilian, if I remember correctly, came up with “Spring Cleaning”, which brought in a new perspective. Quickly, the idea was refined into cleaning up your room for “Spring Cleaning”, but with a bouncy spring! This idea was way more realistic to get done in three days.
In addition, this was great for VR: We had some tool with a spring attached, which again had a plunger attached. The entire thing would be held with the motion controllers, so the main mechanic was simple and should be easy to implement and understand. Also, the player is static, hence no motion sickness. The room you cleanup constrains view distance, again, good for performance, and no motion sickness.
At the beginning of the jam we already had been working on a small
game using Unreal Engine for 3 weeks, which was supposed to get
released before the jam, but we did not quite make it (more about that
soon!). As a result, we already had a bit of experience with the (for
us) new engine and were able to avoid fundamental mistakes in project
setup and structure, which was great!
Instead, some process-related problems arose and my personal way of coding collided with the fast-paced progression of game jams.
Short technical paragraph
(Skip if you’re not a nerd.)
For some reason I (Jonathan) decided to make the entire project
consistently use C++ rather than Blueprints. This meant translating
the blueprints of the UE4 project template we based the game off of
into code rather than the visual scripting language which was used
This took way longer than expected, since I had not worked with some of those features in the engine before. In the end, I had learned a lot of UE4 API and having over eight years of experience with C++ allowed me to work a lot faster in the code rather than blueprints.
Even more importantly, I was able to see problems quicker (I always say “Blueprints are Write-Only”, once they pass a certain threshold of complexity).
In addition a misconception of how a certain function behaved cost me around ten hours. I started googling it way to late, because I misperceived the problem as being specific to our project and code base. (See this question on the UE4 Answer Hub for more specific info). Once I knew that, though, I was actually able to make use of that as a trick in other effects/features.
The process related problems were due to the art assets being integrated about two hours before deadline, which resulted in not all functionality being combined with the assets. The realization that some of the functionality had to be adapted to match the assets came rather late as a result.
There were some minor problems with people changing the same files simultaneously, which made synchronizing them between each other difficult and we ended up overwriting and redoing some changes every now and then.
Conclusion: Our team is nuts.
In a good way:
I have never seen anyone but Maximilian push out a fully furnished room, props and custom hand-models with updated hand-poses in such a short time. On top of all of that, creating assets for a VR game has slightly different requirements than for a classic game, more detailed geometry, less faking, but still as performant as possible. I believe the spring-cleaning tool with the plunger attached to it is a master crafted example of how well he met these requirements.
Florian basically flourished this weekend, while I was in deep sh*t with my code and was to busy with that to do any project management, he took over, created all asset lists, game design document, took care of some organizational work like collecting addresses for the submission and most of the texturing work. He worked on getting Wwise integrated with Unreal Engine and later started installing the Oculus Audio SDK plugin. Despite many frustrating moments, he kept pushing through everything.
Tobias was very new to Unreal Engine and I am guessing me wanting to write everything in C++ must have come almost as a shock to him. But even though given the option to use blueprints, he did everything in C++ (the “right” way), much further out of his comfort zone and still he was able to complete all tasks. Even though he had University on Friday and Monday (the time shift allowed us to work till 6 AM on Monday), he dedicated every minute he had to this project.
Philipp was not used to be integrated in our way of working over Slack and Hangouts Meetings, but he adapted rapidly and fit perfectly into the team. Instead of us asking him to make certain sounds, he had his own ideas, which I believe made the Audio of this game so much greater. After all, he knew what could work and what wouldn’t. His soundtrack was absolutely on point. It perfectly reflected what we all had in mind for the game while perfectly working with the increasing hectic the game was supposed to convey in a one minute game-round.
I myself coded 22 hours in one go for the first (and hopefully last) time in my life. I consumed a ridiculous 18 cups of coffee during those three days - yeah, I am on a break from coffee right now - and I am proud how I was able to push through. Even though the first one and a half days were basically hell for me since nothing in my code was working as expected from the get-go. I learned a huge amount of new UE4 API, which made me confident for future Vhite Rabbit projects using the engine.
I am immensely proud of my team. I have worked in teams at University before, but never was there such a feeling of a common flow state as with this team. Every single member of this team was invaluable and I consider myself lucky to have been part of this project. (I will not repeat this too quickly, though. Even my computer didn’t want to start the next day).
We put tremendous effort into “Spring Cleaning Action” and since it did not quite make it to be the game we had in mind, we will clean that up (*haha*) and release it over on itch.io for pay what you want, which gives you the ability to support us, but at the same time allow you to play the game even without paying anything, if you are not in a situation where that is an option.
We believe the idea has a lot of potential and is fun, once we tweak the Spring Cleaner controls a bit (your cleaning tool in the game). You will hear from us!