Passing time in Montreal with Unity and shields

In these my last days and weeks in Montreal, I spend most of my spare time poring over documentation, tutorials and example-projects for Unity – and to some extent, Blender – soaking up as much knowledge about and experience with these tools as I possibly can. The goal: to become self-sufficient and able to create games and/or prototypes of games in Unity, entirely on my own. Not necessarily to go at it all on my own, but I figure it will be a good foundation for whatever comes next.

My existing “foundation” has been slowly built over the past 13 years and includes (but is not limited to) exposure to and experience with C++, C JavaScript, AI scripting using visual tools as well as asset-handling/basic animation work in 3ds Max, gameplay design and gameplay-related worldbuilding efforts. I am by no measure close to being an expert in any of these matters individually, but I am hoping that the collective sum of experience and knowledge that I have obtained over these years – from both inside and outside of the industry itself – can serve as a springboard of sorts into the world of Unity and independent game development.

UnityScript vs C#

UnityScripting in action
UnityScripting in action
Speaking of Unity, and scripting; I’m finding obscure joy in converting various Unity tutorial scripts from C# to JavaScript. “JavaScript!? Why on earth would you do that?” you might ask. Well, firstly – it’s not regular JavaScript, which is why many users prefer the nickname instead: UnityScript. Assuming I’ve understood it correctly, UnityScript is an object/component-oriented, .NET-based (Mono) JavaScript implementation based on the Boo programming language. In practice, it seems to me that it is used very similarly to C# in Unity, albeit with slightly different syntax, certain peculiarities and some potential limitations (depending on what you’re using it for).

Secondly, while converting tutorials from one language to the other I’m learning how it’s done in both languages at the same time, and though I’ll sometimes run into stumbling blocks where language-specific implementation of code is required, it forces me to apply my braincells, dig deeper and really figure out what’s going on and why.

Of course, that would be true when converting the other way around as well, but since I happen to like Unity’s Javascript-syntax and C# not so much, that’s what I’m going for. Worst case scenario, if there’s something I’m unable to achieve in UnityScript I might be forced to also use C# scripts in the same project. I might see things differently if I end up collaborating with someone who prefers C#, but I’ll cross that bridge when I come to it. *shrug*

Meanwhile, at work…

Example of shield-clipping in AoC
Example of shield-clipping in AoC
My final days at work mostly consist of tinkering with AI scripts for an (unreleased) dungeon that I have been working on, updating the documentation for said scripts in preparation to hand it off to whoever will work on it next, as well as diving into an issue that’s been a thorn in my side for quite some time, but which hasn’t had the highest of priorities: Shields.

More specifically, shields that clip through the heads of characters, stick through their hands/arms, are incorrectly positioned/rotated when equipped and/or are seen from the side in the inventory instead of the front (making it hard to actually see what they look like).

Having previously already gone through every single shield-asset in the game and documented what was wrong/needed fixing with each, I’ll now be trying to fix as many of those issues as I can before I pack my things and jump on a plane back to Norway.

Lessons learned by working at Funcom for five years

I have an upcoming jubilee of sorts in a few months, at which point I can celebrate having endured life in the game development industry for five (measly) years. This cause for celebration is somewhat diminished by the fact that Funcom announced earlier this month that they are restructuring and consolidating offices – which means that I, along with the majority of the other developers at Funcom’s Montreal office, are being let go. For my part this means that I have at most two and a half month left before my official last day at FC, and having started working for FC in late March 2008, this means I might just about pass the five-year mark (yay!) before I’m officially out of a job (nay!).

Throughout these last soon-to-be five years I’ve had the pleasure and privilege of working with a diverse bunch of awesome people (and I hope that I’ll be able to work with some of them again in the future!) on two different MMORPG projects, and I would not change that for the world, but what exactly have I learned after this time spent working in the game development industry? Which of the preconceived assumptions and expectations I brought with me have held up, and which have been thoroughly shattered? What knowledge have I acquired that I can bring with me where-ever I go next?

I’ve played with the idea of writing a post along these lines in the past year or so, but what I’ve found out is that it’s not easy to summarize several years worth of experience in a simple blog post. Instead, I will try to focus on some of the more obvious lessons I have learned, the ones I can point at and say “that might have been useful to know/realize the value of when I first started”. Some – or maybe all – of them are perhaps obvious enough that they’re hardly worth mentioning, but then again – everything is obvious is hindsight.
Continue reading “Lessons learned by working at Funcom for five years”

Character resets and permanent death

Zubon posted over at Kill Ten Rats about resetting characters (examples given: Torchlight, Kingdom of Loathing) being preferable to resetting worlds (examples given: Torchlight II, Borderlands 1 and 2) when reaching the end of a game. The former entails resetting (or retiring+re-creating) a character to scratch and giving it some boost or other (stats, skill-points, items, gold) to give it a flying start, while for the latter you reset the game-world and increase difficulty to match the current status of the character.

While an interesting topic of discussion on it’s own, this got me thinking.

Resets in virtual worlds

Character resets in games like the ones mentioned above is nothing new – it has been done in MUDs and BBS door-games (like Legend of the Red Dragon) for decades already, after all. It would still be novel in a modern virtual world, however, and personally I would love to see a virtual world where the following mechanics are combined:

  1. Optional or forced retirement of characters that have reached a certain threshold (character lifespan, fame, fortune, epic achievements)
  2. Permanent death(!)
  3. Restarting after either of the above events as a heir of the original character with some form of inheritance/boost (stats, more powerful than usual heirloom item, title, etc)

Continue reading “Character resets and permanent death”