Post news RSS Antegods Development Update 1: Stonepunk, Spindle Points and ScriptableObjects

Antegods Development Update 1: Stonepunk, Spindle Points and ScriptableObjects

Posted by on

After revealing Antegods three months ago, we started working on our fast-paced, team-based arena shooter full-time. And we’re really getting into the development groove! As our art, design and code departments are all making major progress, and the general direction is crystallizing, we feel confident enough to start sharing regular development updates.

These blog posts will follow a simple structure, as our three leads talk about what they’ve been working on. We hope you’ll enjoy following our process as much as we enjoy developing Antegods!

Art - Tom

First of all, let’s introduce the team of artists working on this epic title. My name is Tom, the lead artist at Codeglue, and I supervise two art interns named Demy and Michael. We’ve already layed a strong basis for our visual style, with an appropriately solid name: stonepunk.

Because we have a general idea of the game, a basic story and some prototypes that we can work from, we decided to start building on the game and its universe starting with some of their smallest inhabitants. We call them the ‘natives’ (that is, until we have a better name), and they’re only about the size of a regular human being! Which, in a game of Antegods’ scale, is really small.

The natives are the creatures who live in the worlds you visit during the game. They started as small civilizations, until they found a way to control the mystical ‘silk’ energy that is everywhere, but remains invisible until greater powers appear. To prepare for the silk, the natives have built enormous temples and machines. Here are some of the designs we made for these structures:


As you can see, this temple looks a lot like the ones we can find on earth. However, a native is able to sit inside it and turn it into an enormous cannon.


Some of the biggest things that the natives have created are the gigantic stone ‘titans’. These are the teams’ bases, but also their tanks, the game’s most powerful objects. Once they have enough silk fed to them, they create ultimate destruction and, possibly, the opponent’s death.

This concept shows a temple that ‘spins’ silk from the air. A player can pick up a ball of silk here, and then bring it to a safe spot.

Next time we can show you some more cool art. What about the player characters and the titans themselves?


Here are a couple of designs for the Titan’s starting point. These objects are probably too big, as a native would be the size of a pixel here, but it’s fun to try to visualize the unthinkable.

Design - Wytze

Hi, I’m Wytze, game designer on Antegods, and I’d like to give a small gameplay introduction. In our game, players fly giant battle ‘totems’ in 2D arenas set on procedurally generated planets to defeat the opposing team’s titan.

Matches follow a core gameplay structure: explore, gather, destroy. Players first explore the level to gain information about its layout and resources. Based on this intel, they set out to collect the available silk in the level to charge up their own titan. Finally, the activated titan needs to be controlled by two totems to destroy the opposing team’s titan. The levels’ procedural nature forces players to think on their feet and improvise strategies. Here are some more details on the most important gameplay elements:


Each player pilots one of these giant statues. They’re like mechas, except they’re made of stone. The totems can fly around freely and fire their weapons to kill opponents and destroy terrain. Totems can be customized by combining three components: suit, wings and gun.


As Tom mentioned, silk is used to power everything from totems and titans to the natives’ cities. In terms of gameplay, it’s the game’s most contested resource. It can be acquired in two ways: by gathering it from plants, which have a one-time silk pick-up, and by gathering it from ‘spindle points’, which offer silk periodically. Once the silk has been picked up by a totem, it has to be carried to the titan, a ‘turn-in point’, or a native camp in order to use it. If a totem is killed while carrying silk, the silk is dropped and can be picked up by foes and allies alike.


For each team there’s a single titan, the massive statue that plays a central role in Antegods. Players win the game by destroying the opposing titan. It can be controlled by a totem, to move it around the level. As the titan also functions as the team’s spawn point, this allows a team to move its spawn location. The titan is powered up over the course of a match by gathering and delivering silk. It becomes more powerful until, eventually, its weapon also activates, which needs to be controlled by another totem. A fully activated titan, controlled by two players, is a force to be reckoned with.

Native camp

A level usually contains multiple native camps, inhabited by that planet’s natives. These are strategical positions that can be coerced to fight for you by delivering silk to them. If they’re on your side, they will help your team members by regenerating their health or shooting at nearby opponents.


Each level is procedurally generated, according to a ruleset that guarantees fun and playable symmetrical levels. The uniqueness of each level means that players need time to explore at the start of each match. Levels are built out of destructible terrain of varying hardness, which regrows after a set amount of time. Each level contains different objectives that players will fight over, including the aforementioned spindle points, turn-in points and plants.

Over the last months we’ve been prototyping the game’s strategies and have been shaping its unique flow. In future blog posts I’ll elaborate on the design decisions we’ve made thus far, so you get a better understanding of our process.

Code - Niels

Niels here, Antegods’ lead programmer. Antegods is being developed using Unity 5.2, although we tend to update to every major update throughout development. We base our code on on the MVVM pattern. Our ViewModels (or Controller in MVC) are very lightweight and just connect the functionality of the models.

Our models are based on Unity’s ScriptableObject, allowing the designer to tweak any variables, but it also allows them to create different instances. For example if they’re tweaking the movement of our totem, once they’re happy with it, they can duplicate its instance and tweak it for a different totem class.

Anything you can think of in functionality is a model: health, movement, collision, aiming, knockback. A model can be very small (and they should be small!) such as health, which contains just a single tweakable variable: MaximumHealth. It also exposes 4 methods internally: GetHealth(), GetMaximumHealth(), Heal() and Damage().

Now you might say that Heal() and Damage() are the same thing, but it’s always a good idea to use names that corresponds with what happens in the game. Instead of receiving minus damage when grabbing a health glob, just receive a positive heal amount.

There is one problem with using ScriptableObjects: you can’t reuse these objects on the same object, because they reference the same object. So if you have two totems, and you hit one, but use the same health reference, you both lose the same amount of health!

To combat this, in the Awake() function, we create a new instance of the reference:

health = DataModel.Create(health);

We fixed the issue of using the same health model. However, now the designer can’t tweak the original reference and it’s automatically updated in-editor while playing. We solve this by inheriting from


This way we get two extra methods: OnAfterDeserialize() and OnBeforeSerialize(). The latter one is called quite a lot and can generally be ignored. OnAfterDeserialize() is the interesting one. Here we call the ‘OnSerialize’ event. This event eventually arrives at the call:

UnitySerializer.Copy(copyFrom, this);

copyFrom is the original data model. This is a method which uses reflection similar to the way Unity serialization behaves. This way all the references automatically get updated anytime the parent object gets updated.

Next time: even more technical stuff! ;)

You can find more information about Antegods on our presskit() page:

Antegods is supported by Dutch Cultural Media Fund and the MEDIA Programme of the European Union


Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.