Sights Set on GDC

When we posted our previous update, we were slowly getting back into the development groove after the holiday break, still getting used to the idea of the year 2016. And now? Just two weeks later, it’s full speed ahead to finish a demo of our team-based battle arena shooter Antegods, to showcase it at the Game Developers Conference this March.

Actually, it’s not quite full speed ahead, as our art lead Tom is on vacation. So this time we only have updates from the design and code departments. However, design lead Wytze took on an art task, which almost makes up for Tom’s absence..

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. Let other people know that you’re curious about the development of Antegods!

Design – Wytze

This week was a little different for me, as I spent little time on game design. How come? With the looming GDC deadline, I was helping out in the code and art departments.

My first task was to implement the Squad Command menu, an in-game menu that players can use to quickly communicate with their teammates. There are two steps: first the player selects a verb, the type of action she requires from her teammates. After selecting a verb, a second menu pops up automatically. Here the player chooses a target for the command.

The Squad Command menu allows players to tell their team to defend the Titan, capture a Native Camp or collect Silk, regardless of their own position. Players can continue flying their Totem while using the menu, which should only take a fraction of a second once people are familiar with it. It’s compatible with both mouse and controller input.

My second task this week was to experiment with particles and try to make Silk Balls. These are the balls of energy that players gather in order to power up their Titan.

To create particles in Unity, we use a plugin called Particle Playground, which adds a lot of options on top of Unity’s built-in Shuriken system. To get familiar with the plugin, I pulled apart some of the example particle systems and turned some knobs. Once I got a handle on it, I started creating the Silk. Here’s the main reference image I attempted to replicate:

I went through multiple iterations, mostly playing with the amount of particles, the textures on the trail renderers, the particles flying out of the ball and the core of the ball. Here’s the Silk Ball deconstructed into its various elements:

The Silk Ball consists of two particle systems and two spheres. One particle system for the spherical flow of Silk; these particles move in a vortex and leave a trail renderer. The other particle system is used for the Silk flying outward. The transparent sphere creates a glow effect and makes the ball feel a little more solid. Finally, the inner sphere is mainly there for readability, with a darker color so it’s visible on light backgrounds as well.

In the future we’ll iterate on the particle’s look to get even closer to the envisioned flowy, thread-like feeling. But for now, this is a good representation of Antegods’ Silk.

Code – Niels

As we’re scrambling to get our GDC build together, we decided to work on some crucial features and leave the gameplay iterations for now. One of those features is (drum roll…) a mini map!

The mini map is an important feature for many games involving tactics or strategy. Look at things like DOTA, League of Legends and Starcraft: they all rely heavily on knowing what’s going on around you, outside your viewport.

Well, programming a mini map for a world that’s randomly generated and almost entirely destructible is quite a challenge! But we managed to do it, and here’s how.

First off, after a level’s been generated, we need to know its bounds. This can be done as we’re generating, saving the left, right, top and bottom most positions. For our first public build, we decided to not update the map with the destruction of blocks, meaning that we can generate a static texture of the level’s main layout.

The generation of this texture is simple. We have a list of all the destructible blocks in our level and just loop through them, setting a colour on each position. The other pixels are left transparent. Then we add icons for specific level features.

These icons are positioned based on their actual positions in the game, and scaled so they fit in the minimap space. We then use a fine grid for determining visibility, and display it using a shader to combine the fine grid with a static color map.

Just above, you see a minimap with most of its left side discovered, the right side not explored at all, and the titan and totem providing full visibility. Note that the capture point icons will still show, but are not updated if the blue team takes over. That is, until you have direct vision on them.

The current implementation of the mini map eats up quite some CPU time; I plan to resolve this by offloading the work to a thread: