09 May Unity Dragon NPC Proof of Concept

This October, through the DADIU initiative, I had the chance to do a Unity related  internship at Multiverse ApS, the small studio responsible for KoGaMa. Before you start jumping around and arguing that this is a Minecraft clone, hear these guys out, because the idea behind KoGaMa is actually a great one. We’re faced with a digital LEGO world in which each user can build their own games with their own rules. If everything goes well, KoGaMa can become a sort of “YouTube for video-games”. The purpose of my internship was to explore some proof of concepts of  interest-bearing assets that can be put into the game. Needless to say, I teamed up with a cool geezer and we chose to explore the idea of a dragon NPC (to keep the cool-factor high up, you know). This is supposed to be a short post-mortem of what was learned and discovered.

1. I wanna be a programmer!

First thing first, and this might be a bit disappointing, so you think you’ve got yourself a nice set of Unity development skillz to apply in a real life environment? Think again, because life beats the movies. And deployed code beats any sense of pre-established Unity conventions (well, not all of it, I heard that the KoGaMa engine collision detection mimicked the Unity conventions pretty well; we didn’t have to use it though and test the theory for ourselves). The only way to live in such an environment is to hack the heck out of what you are given and make the magic happen.

2. Øko code?!

We were faced with code that grew organically throughout the long (and still live) development process. Is that a good or bad thing? It is definitely lovely for educational purposes, so as we managed to observe how a codebase should (and in some places, should not)  grow. At the same time, a pain to dig through, with zero maintained documentation and legacy formats used in some places (for example, the Unity particle system had been used in both the Shuriken and old variation). But then again, this is raw reality truth. Many times when you pick up a  job you have to dig through other people’s hieroglyphs.

3. Thinking multiplayer

What works locally, rarely does the trick in a multiplayer environment.  Some blueprint parameters and asset details were coded directly into the server database and hard to figure out at first. With no access to the server-side code and seeing everything through the biased lens of the client code, it was hard to make sure everything works as intended. Moreover, testing was done locally using two instances of the clients, which once again limits the possibility of discovering errors.

4. The final cut

Conclusion: I liked it! The guys at the company were really helpful throughout the development process and quick to provide feedback in a allowing and down to earth way. They made the experience really enjoyable. And I’m also grateful they let us peek at such a unique code with literally an intimate story of growing up. Working for KoGaMa showed me a different side of Unity and felt a bit like a cold war: a gentle and rough process at the same time. I’ve worked with serious companies before, but it is only now that I feel like the game-programmer inside me has become a man! With every internship, a different part of me grows up I guess. 🙂 Due to obvious reasons, I cannot showcase the dragon NPC in a Unity environment, but no one will mind if I show you a YouTube video with the final results. As you can will see below, the dragon has two types of attacks : it shoots fireball from afar and spits flame when the player gets really close. It also sort of dodges when the player gets really close and crumbles to the ground when its health reaches zero. It has a respawn time of 20 seconds and its nemesis weapon is, of course, the sword :). Though you cannot tell from the video because it only features one player, the dragon always targets the closest player, unless that player hides behind a wall for more than 2 seconds. Also, if it receives huge damage from a player, the dragon will attack that one in defense.