It’s 2016! Happy New Year! We’re looking forward to a year filled to the brim with exciting Antegods developments, and we’d love to have you along for the ride. Glad you’re here, by the way. Did you have a good holiday break? We sure hope so.
On a more practical note: unlike before, this post contains updates from only two of our leads. Because we were busy finishing up another project late last year, the code department didn’t have time to sit down and write. But if you’re into game programming, you can always reread the last update, which had a double dose of code. Right?
Design - Wytze
Since a couple of weeks before the holiday break, we’ve been testing Antegods in-house regularly, to see if we’re getting the experience we’re aiming for. It can be difficult to quantify to what extent you’re reaching your design goals, which is why we’ve set up a solid testing structure.
For each test we have a couple of high level design goals. For the most recent play test, these were the following:
- The Titan provides players with interesting strategic choices, is fun to use, is a force to be reckoned with, and becomes more powerful as the game progresses.
- Players feel like they’re capable of structurally working, with their team, towards the end goal of destroying the opposing Titan, using a self-defined strategy.
- Players feel that they can control their Totem well and engage in interesting fights, of which the result is decided by player skill.
These are somewhat abstract goals, but they help to focus our attention on several core game qualities. The goals will evolve slowly as Antegods game play improves and starts to do what we want it to. From these goals we also create key questions, which are specific questions that we want to answer after the play test.
Ten Codeglue employees, including the Antegods development team, play-tested the game. We had a lot of fun, despite the very chaotic course of the game. Ultimately the red team (my opponents) made a strategically risky play by moving their Titan very far forward towards our Titan, which was well-defended by two native camps we’d captured earlier in the game. Constant attacks from our totems and native camps made short work of the red Titan and we won the game.
After the play test, all testers filled in a questionnaire, which we used to get feedback from each individual player. I then analyzed the questionnaire information, as well as my own observations during the play test, to answer the key questions.
Overall players were very positive about the game’s movement and shooting, and they felt the outcome of a combat situation was mostly decided by player skill. The two weapons were valued equally on average, and mostly seemed to come down to personal preference. We’re very happy about these results, because this is the core of the game, which players will spend a lot of time on.
Players also enjoyed capturing neutral native camps and destroying enemy native camps. They’re one of the most strategic elements of the game, and so far they’re doing their job well.
However, there were some problems too. When I compared all gathered information to the high level design goals, I found four key issues with the current game play:
- The Titan is too weak. Instead of being a dangerous moving battle fortress, it’s a liability that needs constant protection. It can’t protect itself and it’s too easy for enemies to deal damage to it at any point in the game.
- There’s little overview over the battlefield. Players often spread out to go their own way, after which they don’t know where other players are, or what the map looks like.
- There are too many objectives, including spindle points, plants and native camps to discover and contest. The large amount of different objectives leads to a sprawling and unfocused battlefield, instead of tight strategic efforts to win the game.
- There’s a lack of match progression and structure. The Titan gains some power, but doesn’t change much over the course of the game. Native Camps are the main element that structure the match, giving long term area control in exchange for silk.
We will address these problems through design changes to get closer to our high level design goals. We’ve already thought of several changes to make the Titan stronger and more tactically interesting, we’re adding a mini map for overview, and we came up with a new way for the spindle points to activate. I’m going to work these designs out in detail, and show them to you next time!
Art - Tom
Hi there. At Codeglue we structure our work in ‘sprints’, and last sprint we discussed the design process of the Totems and the Titan. We all really liked the Totem characters, and from previous experience we knew that a fully animated character adds so much to the game. Therefore we decided to model the Totems and animate them, so we could see the in-game result faster.
We wanted to use Unity’s Mecanim system to transfer animations from one object to another, thus enabling loads of characters with slightly different proportions. This way, we wouldn’t have to create animations for every character.
Because we had little experience with Mecanim, we had to research a lot, and go through a lot of trial and error. We came across a variety of problems, which we’ll show you here. Some of them might be pretty stupid, thanks to our lack of knowledge, others are just Unity working against us. (Really!)
First of all, we thought that when using Mecanim, you could just transfer all your animations to another rig (the animation ‘skeleton’ of your 3D model), but only if the bones of your rig share the same names. This almost works…
The first issue we got was that we had to use Generic as the rig type. This is because our character has no arms, so we thought we couldn’t use the Humanoid mode. This way we couldn’t attach the bones to the Unity Mecanim system that could re-target the animations.
We first made a base character with a base rig and some basic animations, thinking we could get all this base stuff to just work on the normal and heavy rigs. So in Unity we set up the base character, split the animations from the FBX and made sure those worked.
We were able to transfer the animations to the rigs of the normal and heavy characters. However, the bones of these rigs were placed on the starting points of the base rig. The results was that the characters did their animations, but they were completely torn apart. Not good!
The head on the model in the front should be placed higher than that of the model next to it. The Generic rig places all the bones of the animation at the original location.
Next up, we thought it’d be a smart idea to use Humanoid rigs and trick the system. We attached the wings to the lower arms and placed the character in a T-pose. This worked better! The animations were transferable, as the rigs of the Heavy and the Normal character weren’t destroyed.
However, the animations looked very different from how we created them. This was because the Humanoid system throws away Translate animation data, and constraints animations. Because you tell the system it’s a humanoid, certain motions we tried to trick didn’t work, as Unity said that a human could not do such things.
Here you can clearly see that the animations of the wings are different from the animation on the right. This is because Unity’s Humanoid rig restricts certain movements.
So this sucked big time. Both approaches didn’t work. We couldn’t use Generic because this wouldn’t allow us to re-target animations properly. And we couldn’t use Humanoid because we’d lose great animation quality and it would always look different from what we intended.
Here you see the both approaches, both with their own issues. All share the same animation. (Top: Generic with funky heavy model. Bottom: Humanoid with horrible animations.)
How did we fix this? Well, we didn’t really fix anything. But we found a workaround that works for us!
As mentioned in an earlier post, the character consists of 3 interchangeable parts. The body, the wings and the weapon. Because the Body is a Humanoid without arms, we decided to use a Humanoid rig for this part. The bones of the arms are there, we just don’t use them.
The Wings are completely custom objects, that will have their own animations. These wouldn’t have to be transferred to each other, so we could just use generic rigs for them, and even add Translate animation data, making them more awesome. To tell the system where the Wings need to be placed, we added a small invisible object to the body called ‘R’. This stands for the right wing. We just place the root of the wing’s rig at this exact point.
The setup of the characters.
This way we have transferable animations for each body and a place for each wing. These wings can be as epic and custom as we want them to be.
Here you see that we can transfer the animations from one character to the other. The wings use their own Generic rig for their animations.
In our next blog post we will dive into the radial communications menu, show some more concept artwork, and talk about team colors.
To keep up to date, follow us on Tumblr, Twitter or Facebook. Or subscribe to our newsletter. Whatever is your taste in social medias! :)
Antegods is supported by Dutch Cultural Media Fund and the MEDIA Programme of the European Union
