And we’re back with a vengeance: this is another of those long and detailed development posts. We go in-depth on our experiences and learnings from the GDC, but there’s more: we also describe how we’re tweaking the game’s color palette, and programming the dashing mechanic.
We hope you’ll enjoy the post, and as usual, that you’ll let us know how you feel about it. Liking and sharing is appreciated too. Tell others that you’re curious about the development of Antegods!
Design – Wytze
At GDC, we had our own booth to show off Antegods. We set up two Steam boxes, each with two controllers. We connected them through LAN, so players could play as two human players versus two other human players, with AI bots filling up the empty slots, creating two teams of five.
A lot of people came by to play and the responses were super positive! Many said the Mayan aesthetic of Antegods looks great and original, and they loved our use of the word ‘stonepunk’ to describe it. Due to the amount of polish we already have, some actually asked if we’d already released the game.
The good
Beyond the aesthetics, players generally got the hang of flying and shooting quickly, with the twin-stick style controls mostly considered to be intuitive. Some players preferred firing with the trigger, rather than by releasing the thumb stick, so we’ll continue to offer both options. After telling people how to shoot, they discovered they could destroy the terrain and were already having a good time.
Then when we told them how to enter the Titan, they had a real wow moment. Simply being able to control this giant entity and smashing it through blocks made them feel powerful. Once the Titan’s shockwave and weapon activated and the two players could control these as a duo, they felt even more powerful. Conversely, when a Titan approached them, it scared the crap out of them and they usually tried to flee quickly.
After playing a full match, most players had a good understanding of the game’s mechanics and the dynamics that emerge from it. The game’s ideas seemed to ‘click’ very well, people understood what we’re trying to accomplish and enjoyed it. Some chose to play multiple games, and you saw their understanding of the game’s strategies grow with each match, leading to really exciting moments. For me as a game designer, those are some of the best acknowledgements you can get, so I’m really excited to continue improving the game!
Explaining silk mechanics
Despite the positive reactions, there were also some clear problems. These were largely caused by poor communication, and in some cases a complete lack of communication.
One of the most difficult mechanics to explain was the collection and delivery of silk. The following were common questions players raised:
- What is this thing called silk?
- Where and how can I gather it?
- How much silk am I carrying?
- Where and why should I deliver silk?
We have identified the following as causes of these problems:
- The name ‘silk’ does not relate to the gameplay mechanics.
- Silk is automatically dropped off when players are near a native camp or turn-in point, which means they deliver it unintentionally and aren’t aware of it.
- There is no direct feedback when dropping off silk.
- The indicator for how much silk a player or Native Camp is carrying is small and unclear.
- There’s no visual indicator for which objects create silk and which objects gather silk.
- Nothing in the game links the turn-in point to the Titan’s silk levels.
- The indicators for silk (progress bars and numbers) have no relation to how silk actually looks.
- Some silk particles bugged out visually, which made them hard to see and recognize.
From these issues, it’s clear that we need to find a better way of communicating how silk works, so the gameplay can be figured out more easily by players. Below, Tom goes into detail how he’s developing a visual language for silk that should clear up a lot of player confusion.
Readability
Another prominent issue is the readability of various game elements, which in part is due to the color scheme we’re using. Teams can be hard to tell apart for new players, because spindle points, medium blocks and neutral native camps seem to belong to the red team, while the nimbus and silk seem to belong to the blue team. Again, Tom will go into solutions to this problem below.
Guiding new players
When demoing an in-development game at an event, you’ll typically spend a lot of time explaining it to players. Antegods doesn’t have a dedicated tutorial yet, and if it did, it would probably be off-putting to people trying to check out many different games on an expo floor.
For GDC, we implemented in-game instructions that would tell players what to do, but they didn’t pay much attention to them and didn’t give players enough explanation and guidance. Instead, we had to verbally explain how the game works to each new player, which got exhausting real quick. For future events, we’ll have to look into better ways to guide new players.
Dashing
Some players remarked that they felt like the game was a little slow, while others wanted to have a better way of dodging incoming projectiles. We think we can fix both of these by adding a feature we had in mind already: a short-range dash.
Each player will have the ability to dash. You can press a button, at which point your totem will gain a speed boost for a short time. During this dash, you also smash through blocks you come in contact with. After using it, you’ll have to wait several seconds before being able to dash again.
The intent of this mechanic is to allow players to dodge projectiles, get around corners quickly and in general add a deeper skill level to maneuvering. It should also help to increase the game pace, without increasing the characters’ base speed. Below, Niels will explain how he handles implementing gameplay features, using the dash as example.
Self-explanatory names
Finally, we had a lot of trouble explaining how the game works due to the terms we’d decided to use. For example: we chose the name silk because it fits well with the aesthetic and narrative concept of this energy type. However, when we tell players to ‘collect silk’, it doesn’t have a direct relation to the energy balls on screen, nor does it explain that it’s a type of energy that can power the Titan or native camps.
If instead we call the silk what it essentially is, ‘energy’, then people can link it to real-world energy, as energy is also used to power machines.
Compare these two for example:
- Collect silk from the spindle point and deliver it to the native camp to capture it.
- Collect energy from the generator and deliver it to the turret to activate it.
In the first example we have to explain what silk is, what a spindle point does, and what a native camp does and looks like. In the second, all gameplay names are related to their real-world usage and thus more straightforward.
So for each of the game elements in Antegods, we’ll have to think hard and come up with the most self-explanatory and descriptive name. That way we’ll make it a lot easier for new players to understand the mechanics of each game element.
Continued development
In all, we received a lot of feedback from players, helping us to see the current strong and weak sides of Antegods. I’m really excited to get back to development and make the game more understandable for players, as well as testing new gameplay ideas to deepen and diversify the game’s strategy and tactics!
Art – Tom
Between the last Art post and the one you’re reading now, the look of Antegods changed a lot. Because of the deadline that was the GDC, we had to make some quick choices and sometimes couldn’t pay attention to the big picture.
One of the things that suffered from this was the in-game color scheme. With Antegods we’re going for a stylized realistic look, which means we can’t go too bold on the colors. But, because the game gets chaotic and wild easily, it all needs to be super readable.
The above screenshot shows 4 Red players fighting against 2 Blue enemies (the third is flying away). We see two types of blocks and the Red Titan. Or do we?
There are actually quite a few problems here. For one, the characters seem to blend into the background, and the difference between blocks isn’t very clear either. Importantly, it’s not immediately obvious which player belongs to which team and what kind of loadout the players have. In the future we want numerous combinations between bodies, boosters and weapons, which will all have their own stats, so players need to be able to see who is carrying what.
Because the GDC deadline has now passed, we can get back on track with development and give this serious problem a serious look. Now, don’t expect a solution or a final result at the end of this post. But I will try to give you an insight into how we’re tackling this problem.
The first thing I did was making everything white, so it was easier to color things. After that I gave everything a basic color, starting with the teams.
The above screenshot shows the first attempt to create team colors that always stand out against the background and are clear for everyone, including the colorblind. Taking the latter group into account is extremely hard though, so we decided to postpone colorblind features until some other point in development.
In this screenshot I’ve also colored the blocks. The characters still stand out, so that’s nice. We can say that the team colors will always be red shades of orange and purple, and blue shades of purple and blue.
The next biggest thing that always needs to be visible is the silk, simply called ‘energy’ from now on. It makes sense to give this a generic color too. There are two options we can go for.
The first is that we give the energy the complementary color of the teams.
This screenshot shows that this is a greenish yellow. (Note: The tool I use for colors is a website called Paletton.) There are some downsides to this color: it looks poisonous; it’s a commonly used color for health in games; and last but not least, not everyone in the company likes it.
The second option is to make the energy white. Because a world never has a solid white color, this will make sure it always stand out. For now we went with the greenish color, though.
The color scheme for the most important things now looks like the screenshot below. Note that having a dark glow for the teams, and a light glow for the energy also helps making the energy pop. Something to think about.
The other thing mentioned about energy was that it wasn’t very clear for players. What is this energy? How much is there of it? How much do I carry? Where do I need to take it? These questions can be answered by having a strong visual language, I think.
Everything in this game is about energy, so it has a lot of functionality, which makes it hard to come up with a perfect solution. Again, don’t expect a final result in this blogpost. First of all, we had to make a list of the appearances and usages of energy.
- Plants give out energy, varying from 1 to 4 per plant.
- When a player picks up energy, it’s added to the player HUD. A player can carry up to 20 energy.
- This energy can be brought to a native camp, which needs 10 energy to be activated by a team. Both teams can hand in energy, but one team will be the first to conquer it. So a native camp needs 19 energy slots.
- Then there’s the turn-in point, that transports energy to the team’s Titan. This one machine must work for both teams and all players, so it needs a lot of energy slots.
- The Titan will receive the energy and store it, and will unlock abilities depending on the amount of energy. It needs to be very clear how much energy the Titan has. It now handles a 100.
- The spindle point creates 10 energy before handing it out.
We’re working hard on this issue. For the organic plant shape, we’ve come up with the following:
This droplet-like fruit can grow by itself, but also in clusters:
When these are picked up by players, they are placed inside containers that are clustered the same way. You get the following effect:
We can place these containers on almost anything. For example, the turn-in point can have a reservoir that the players fill up and constantly fire these at the corresponding Titan. The native camp can have slots to place the clusters in. The Titan can have a droplet shape that fills up.
There are still a lot of questions, but I think we’re heading the right way. In the next blog post, I hope I’ll be able to give you some more solutions to these problems. And hopefully there will be some room to talk about a piece of software called Substance Designer.
Code – Niels
Building gameplay in Antegods is always done using a similar process. We usually discuss the gameplay mechanic we want to build, so we can bounce ideas off each other. Then at the start of a sprint, when we do our planning, and a specific game mechanic pops up as needing to be implemented, Wytze writes up a small piece of text explaining what he wants it for, and how he envisions getting there.
We have an internal wiki-like website, on which we keep an up-to-date state of the game (design, code and art related). For the dash functionality we have the following information:
Totems all have the ability to boost. Once the boost is activated (default: left trigger/space key), you accelerate at a faster pace and move at an increased terminal velocity for X seconds. While this boost is active, you break through blocks on impact (similar to the Titan). Once the boost wears off, it goes on a cooldown for X seconds. During this time the boost can not be reactivated.
We then have to find a place in code for the new feature. In this case it’s related to movement, so we take a look at the character code. Our character’s movement is comprised of two systems working together. Namely the collision and movement systems.
All these values have been hand-tweaked by Wytze and have a meaning in the code. In our case, we want to temporarily change the Acceleration and Terminal Velocity values, so that a player can move quicker than normal. Then, after a certain amount of time, these values need to change back. The movement code allows for a velocity higher than terminal velocity, it’ll apply a heavy friction until the terminal velocity has been reached. This feels really natural and doesn’t suddenly deadstop you in your tracks, if for some reason you go faster than the terminal velocity.
There are now two steps left. We want to playtest whether we want the player to continue controlling the character while dashing, or whether we should disable the input on the character once you’re dashing. And lastly, there’s a cooldown period. Usually you just add a ‘float timer = 0.0f;’ and add the delta time to it each frame. However for timers that change a state after a longer period, it’s best to create a generic system, so you’re writing less boilerplate code.
GameManager.Instance.DelayedCallback(periodInSeconds, EnableDash); This way our GameManager class will call EnableDash(); after a period defined by the variable periodInSeconds. No need to worry about writing a simple timer yourself, clean and easy!
Internally, this works as follow:
partial class GameManager
{
private struct DelayedCallbackHelper
{
public float timer; public Action action;
}
private List callbacks = new List(); public void DelayedCallback(float timeInSeconds, Action callback)
{
callbacks.Add(new DelayedCallbackHelper() { timer = timeInSeconds, action = callback
});
}
public void UpdateTimers()
{
for (int i = callbacks.Count - 1; i >= 0; i--)
{
DelayedCallbackHelper callback = callbacks[i];
callback.timer -= Time.deltaTime; if (callback.timer <= 0.0f)
{
callback.action();
callbacks.RemoveAt(i);
}
}
}
}
This is an easy and reusable way to build timers. We refactored several code files to use the DelayedCallback instead of maintaining a timer yourself.
Next time
We hope you like what we’ve shown you. We’ll have more soon! To keep up to date, please follow us on Tumblr,Twitter or Facebook. Or subscribe to our newsletter. Whatever is your taste in social medias! :)
Antegods is supported by the Dutch Cultural Media Fund, Cultural Industries Fund NL and the MEDIA Programme of the European Union.
