The Colony Devlog 7 – Press n’ Stuff

Yo colonites! We were featured recently on an indie gaming news website, here’s the some of the backstory to our game should you care to give it a read.

New devlog video coming out soon along with some more beta passes. Stay tuned.

What made you think of making a game about building the best ant colony?

The game’s idea originated a couple years back after a particularly long gaming session one night on a DK2. Unlike any other gaming platform, it wasn’t until I had tried Virtual Reality as a medium could see the possibilities VR immersion could bring to the player.

What The Colony hopes to achieve is bring that small-person-in-a-big world feeling to the player in a way that hasn’t been achieved yet until VR was possible. We see glimpses of this perspective in many pop-culture forms, movies like Ant-Man, Honey I Shrunk the Kids, Antz,and A Bugs Life have been a part of our childhoods and bring a fresh look at our familiar world but from a different point of view.

This small world brings a wealth of inspiration to draw from for our game. Ants, bugs, and insects are truly fascinating creatures. High degrees of cooperation, building, digging, pheromones, and species variety all bring real-world mechanics that can be explored through a video game.

What is the most interesting aspect of the game development process having based your game about ants?

The sense of scale. While our game is inspired by realism, it’s far from it. That being said, we stay true to the theme in the environment, weapons, and the gameplay mechanics throughout the game development process. This creates a world which is significantly different than most games. For example, our weapons are made from carapace, sticks, and bone rather than metal or plastic and play very differently than those in other games.

Our environment has been very fun to build. Small things to us humans are huge to an ant! Blades of grass, rain, trash, people, and spiders play a very significant role in our game and play a much different role than what the player is used to.

We’re hoping for this game to be as much for to explore than it is to play with others.

What were your major obstacles in learning how to make a multiplayer game?

In my experience, you can find game networking everywhere but nowhere at the same time. It’s everywhere in that games have been using client / server network design since 1996 and Quake, but nowhere can you find an actual working example that brings some of these newer technologies to a point of abstraction that they can be used by someone who hasn’t worked in the field for 10+ years.

Technologies like server-side authoritativeness, lag-compensated bullet detection, point of interest, match making; all of these are very much a part of our everyday gaming life but implementing them in a project still remains a learning and financial barrier. Learning all these different character creation tools and Unity can be daunting to a new start-up even without all the networking libraries and terminology you have to deal with when you’re dealing with online gaming.

Another aspect is troubleshooting your problems is significantly harder when networking is involved. Within the non-networking realm, you can often see your problem because everything is local to your machine. In a networked world, replicating variables and states over a network can cause you not always to come to the root cause of an issue right away.

In fact, this became very apparent recently when we were having trouble with networked projectiles. When one player threw a large projectile (in this case it was a wooden “toothpick”) at another, they would need to lead the target well in advance for the spear to register a successful hit. The network syncing between the client and the server was off, but the reasoning behind this timing mismatch wasn’t immediately clear.

After much trial and error, we discovered the server frame was the cause of the issue. The moment in time from when the client said, “I’m throwing this spear” and when the server registered the throw was off by a single fixed update frame, causing a very slight difference in where the player saw the spear.

These are tough challenges and you don’t find these kind of problems with a locally networked games, but after all is said and done, there’s still nothing like having a player join your game and playing with friends. It’s a great feeling and makes all the pain worth it in the end.

What advice would you give to indies who want to start making a multiplayer game?

Start learning networking early. Many game design decisions need to take into account networking early on if you don’t want to kick yourself later for having to do it again. Also, there are significant restrictions that can’t be accomplished with networking. Networking deterministic physics, for example, still remains a very hard (if not impossible) thing to do right now with Unity, which, if you’re making that kind of game really limits your networking options.

How did you make such a kick ass trailer?

The aim of the trailer is to spark the curiosity of the audience and overall, I’d say the feedback leads me to believe we’ve created that spark.

The trailer was the result of five days’ worth of work over a Christmas break combined with copious amounts of Red Bull and much trial and error (ie. face palming).

There’s much of the game that has yet to be shown and even more that’s being developed, but it’s motivating to see folks as inspired by our project as much as we are.

In one of your devlogs you said you remembered how to code but forgot good code design haha… could you elaborate?

While I’m not the only developer on this project and can only speak for myself, this was a very big challenge for me personally and it really comes down to time management. Now, I’m no stranger to cutting code, I’ve worked in the software engineering industry for upwards of 15 years, but Unity was new to us when we started this project over a year ago. Through that learning of Unity, much of the excitement of game development comes from learning a new skill or implementing a new feature. Importing your first animation and seeing it player in-game, UV mapping and texturing your first player character, it’s really easy to get excited and wrapped up around an idea within your project. This has been my experience when coding.

Up until this point, I’d say when it comes to implementing a new feature, my normal plan of attack would be to “Damn the cost, just get it working, we’ll fix it later.” The problem with that is that you never “fix it later”. After a while, your whole game is feature-rich, but fragile. Weird errors start cropping up and while you can implement features quickly, making them reliable, performant, and robust enough to withstand moderate code change doesn’t occur.

So what changed? My current philosophy is to ask myself if a particular feature has the possibility to grow or expand before writing code. If the scope is relatively small and isn’t dependent on much functionality, code away, if not, doing some upfront design work will save you time in the long run. On the flip side, you can’t spend all your time designing your solutions because any significant change in direction will amount to a very large loss of productivity.

Model-View-Controller (MVC), inheritance, loosely-coupled design, Big-O notation should all be tools in your toolbox, among many “Best Practices” community-created articles.

What is the biggest lesson you learned while developing The Colony?

Don’t fall in love with your ideas. It’s easy to think your ideas are magical, original, and is going to change the world. The problem is you spend time on that idea, three weeks go by, and you show the prototype to your friends and you don’t receive the reactions you’re looking for. What’s your next move? It’s easy to say, “Well yeah, I’ll just take the feedback constructively and move on” but this task is harder when you just spent three weeks going to sleep at 1AM trying to bash this awesome idea out!

One example of this was a voxel systems I built for The Colony a few months back. It was a great idea! It created smooth terrain deformation that allowed the player to build tunnel into the land. What’s not to love, right?

Well – here’s the problem. When you’re digging a hole and have no other objects in your view other than dirt, you lose the sense of scale, you lose your friends and colony, and you see a lot of dirt…all…the…time.  What kind of performance can I expect in a game with 30+ people digging everywhere? What’s fun about this?

While it did provide a player the sense of digging, you lost a lot for that benefit. In hindsight, the question we asked ourselves was “What’s so special about our voxel solution that isn’t like every other voxel-based game that’s out there? Are there better ways to give players that sense of digging without the aforementioned drawbacks of a voxel system?”

Our solution to this problem is going to be previewed at an upcoming devlog post (UPDATE: devlog now out here), but the moral of the story is to remain flexible. Build the game you love, but be open to feedback. At the end of the day, you will lose time working on features that you will throw away, the trick is to throw them away early and have the resolve to move onto something better when that happens. And remember, even if you lost time, you’re still learning, and there’s value in that too.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s