Supraball UE4 - One year anniversary #1

Last week we celebrated Supraball's one year anniversary (we said 'yey' and continued with our lives). Next week we will celebrate the one year anniversary of the Unreal Engine 4 edition of the game! But what will we celebrate? Not a lot of information has been released about this 'port'; is there even any progress? Where are my hats!? Therefore, the coming days I will post a small series of updates regarding the state of the port from the beginning up until the current version, as well as some side projects that spawned from the main work.

I joined the team a little bit more than one year ago. At the time, both Unreal Engine 4 and the first public alpha version of Supraball got released. While great news for indie game developers, the timing could not be worse. Namely, the Unreal Development Kit (Unreal Engine 3) is fairly limited compared to UE4. With our eyes on the future, we had to make the decision whether to continue with the UDK version, or recreate the game for UE4 from scratch.

Yes, from scratch! Zip, nothing, nada! A lot of the code relied on old Unreal Tournament code, which came as a template / example as part of UDK. In the case of Unreal Engine 4 however, the sun shines a little less bright. On one hand the new engine gives developers much more power, while on the other hand they'll have to implement the most trivial things themselves. Input movement, team support, HUD, animations, and many other facets that were borrowed from UDK had to be redone, as they were simply not present in UE4.

At first glance sticking to UDK seemed to be the better choice. However, we decided to opt for the full rewrite anyway, with our minds set to the future. Sticking with UDK would be like sticking with Windows 95. It might work, but it is definitely not ideal. You're working with closed source, outdated, unsupported legacy software. We want the game to be grant, and for that it is required to keep up with the times.

Besides, the current UDK code was heavily based on prototyping; the game's source is full of dead code, logging artifacts and general inconsistencies. Fixing bugs and extending the game with for example a new gamemode is a lot harder than it should be. Solid engineering principles were not really used, which makes maintenance is a huge drag. The game needed a proper rewrite in a lot of parts anyway.

[caption id="attachment_2126" align="aligncenter" width="500"]
Boring code documentation nobody cares about[/caption]

A complete rewrite means that there are not that many spectacular things to tell the general public. It's not easy to show off how you have implemented the ball's player history component, or how you have implemented a generic team system. It's not flashy and non-programmers would not understand. In this post I'll try to do explain it anyway, to give an impression of the work done. While I can try to make it as interesting as possible, I'll start off by talking about the most boring part: the beginning.

In the beginning, there was nothing. There was a player and a camera. No notion of environment, apart from an empty, untextured plane and two clumsy boxes that were supposed to look like goals. No input movement was available either. Luckily, UE4 does not completely spit in your face as it does come with some character movement functionality.

You'll still have to hook it up yourself though. Make the camera rotate on mouse input, build in multi-jumping and making sure it's not macro-abusable, add in dodge functionality for keepers. Oh wait, we didn't have keepers yet, and we didn't have keepers yet because we didn't have teams. That's okay, we can fake being a keeper for the time being in order to test dodging.

Next up, was adding a ball. A simple mesh that can't even spawn yet. We didn't have spawning functionality, so we hardcoded a ball into the map. By nudging it around a bit, we could make it enter a pre-defined area. That area would become what is now called the goal. A goal should belong to a team, which was something not yet added into the game.

Scoring is also dependent on the gamemode. In the UDK version, the scoring values and functionality were hardcoded into the goal. This makes it impossible to re-use the goal in some other gamemode like say dodgeball, or special variants of the original Supraball gamemode.

[caption id="attachment_2138" align="aligncenter" width="413"]
Long and coupled UDK scoring code[/caption]

In programming terms, there's a lot of coupling between game actors, which is bad and needs to be reduced as much as possible. The required gamemode however, was non-existent and had to be recreated from the ground up. Aside from scoring functionality, a gamemode also keeps track of all the scores, players (and teams!), match time and spawning mechanics.

As you might have noticed, things were getting fairly complicated and complex; given these are still basic things that had to be done. To make it even worse, everything has to be working from the ground up with networked multiplayer, and nobody was familiar with the ways of how the new engine actually worked. While UE4 and UDK share a lot of similarities, they are at the same time very different and aside from some purely logical things like 'if this then that', nothing could be easily copy-pasted.

[caption id="attachment_2124" align="aligncenter" width="500"]
Goal code for handling things that can be used to score with[/caption]

After 6 months, we had some basic functionality like actual movement input, picking a ball up and scoring touchdowns, as well as some core gamemode functionality. There was not much to work with at the beginning, so there was only so much we could do.

You cannot start implementing ball kicking when you have no weapon. You cannot start working on the weapon when you have no ball. You cannot start working on the ball when you cannot score. You cannot score when you have no gamemode and cannot move. It goes all the way down!

In the next post I will go into more detail about adding the weapon to the game, and I might answer where those hats are!