Of Course I'll Play It

Moving to Facebook

noreply@blogger.com (Dusty Monk) — Fri, 16 Sep 2016 18:35:00 +0000

OHAI there! Well as you can see, I've pretty much abandoned the blogger blog. Actually, for the past six months I've pretty much abandoned blogging altogether. Why? Honestly just too busy playing games and making them to spend a lot of time writing about them. And when I do have time to write, I've been more interested in writing speculative fiction than game blogs.

But that's how people are, people's desires, tastes, and interests change all the time. And what I find compelling right now may not interest me in the slightest tomorrow.

However though, for the last six months I have still been really active in sharing my gaming activity - I just to it largely through social media now, rather than formal written blogs. So Facebook, Twitter, and Instagram have become my vehicles of choice. Not Google Plus - that platform I think is not long for this world, and I have certainly left it behind.

But I am still sharing, mostly on twitter, and somewhat on Facebook. But there have been a few recent changes in the industry of late that have sort of sparked my interest in using Facebook as a social gaming platform. So to that effect, I've created a new Facebook Gaming Page. It's called, imaginatively enough - Gaming with Dusty. And I am going to experiment with using that as sort of my central repository for sharing al things gaming and game development. And maybe even speculative fiction as well.

So if you're search has landed you here, and you're thinking "Well crap.. another dead blog.." well you're right. But if you still want to engage, please follow me over to FB and/or twitter, and engage away! I look forward to seeing you!

Here are the deets.

The FB page can be found here:

https://www.facebook.com/DustyGames/

And of course, you can always find me on twitter.

https://twitter.com/dusty_Monk

Cheers, and see you soon!

Story in The Division

noreply@blogger.com (Dusty Monk) — Wed, 06 Apr 2016 13:48:00 +0000

Haven't blogged in awhile, but if you follow me on Twitter, then you know I've been pretty much playing Tom Clancy's The Division since it launched. I've finished the main story, reached the max level, and only have a single zone of collectibles left to gather. Now that I'm just sort of doing the daily gear progression thing, I wanted to take a bit and talk about the story of The Division - what I think worked, and what could have been better. I haven't seen a whole lot of commentary on The Division's story, but what I have seen has been mostly negative. And I wanted to talk about that, because I'm not entirely sure the game is getting credit where credit may be due.

Spoiler Warning
Let's get this out of the way right up front - I'm assuming that if you're reading this, you've finished the main story, and have completed all of the story missions. There will be spoilers for that content ahead, so if you're worried about reveals, please come back when you're at the end.

They Care
To start with, I can say this about Ubisoft without doubt - they care about their story. Whether you thought it was weak or it was strong, at least the story is told out through segments, clips, and elements that are in the game. No sending you to a website to make you learn the story. If a developer takes the tact that "the people that care about the story will go to the website to read it", it tells me they don't care about their story either. And if the developer doesn't care, why should I? Ubisoft's delivery is done over multiple layers, and whether you choose to see it, listen to, it, or pay attention to it is entirely you, but at least it's there for you to experience.

The Story that Was, and the Story that Is
So if you look at the story elements overall for the game, the story can be broken down into two sort of main subsections. First, there is the story of your agent, and what they find out, as you progress through the game. It's your character's story, told through voice over, cinematic clips, and a variety of intelligence reports you receive, listen to, and experience as you progress through the game. And it's this story, I think that most people refer to when they say the story is weak - and for the most part I tend to agree. I think in terms of the main story, Ubisoft missed on some fantastic opportunities. What happened to the first wave of Division Agents? How did the virus get started? Can an antidote be found? The premise of The Division is incredibly relatable, and there are some very cool questions posed. But the answers that you discover to all these questions (and they are answered), felt, at least to me, flat. While I started off full of curiosity, as each part of the story was unveiled, I only felt disappointment in the answer. Not that the answers weren't sufficient - they were. But the answers were, for lack of a better word - just mundane. And yeah I get it the real-world answers to a national epidemic might be just as simple as the one presented here - but why not make it more interesting?

You're Not Part of the Story
However though, my biggest complaint with the central story isn't so much the content itself - that's pretty subjective and I get it. But rather, it's that your character isn't really a part of it. Why are Bioware's game stories so darn compelling? Well a huge part of the reason is that your character is woven directly into the fabric of the story. The game is about you. In Dragon Age Inquisition, you're the goddamn Inquisitor! You literally sit in judgement meting out death or mercy, and your decisions directly affect the flow of the narrative. And even in a more linear game like Tomb Raider, the story is still centrally about your character - you're actively involved in the story in every step of the way. In The Division - you're just an agent - one of many. And in almost every situation, you are not affecting the story, you are just witnessing it. You get there to learn what has already happened. You arrive after the fact, when it's too late to do anything, and you just report back what occured. Your sole contribution in most cases is picking up a few pieces of evidence or biological samples along the way, and taking out a few notable troublemaking NPCs. And hell even in the end, you don't quite accomplish that mission. As a result of this, the entire central story feels more passive than active.

I don't fault the delivery methods of the story, just my character's participation in it. Why isn't our agent in charge of The Division? Why aren't we even in charge of the base of operations that we set up? Why isn't my character making the decisions (even if I, the player, am not) that are driving the narrative forward, or at least directly affected by the narrative? I hope going forward with the story (and let's face it, after the "end", it's clear the story experienced so far is only just the first chapter), that your agent becomes a more central figure to the story itself, and what plays out, rather than a late-to-the-party reporter of what has already happened.

The Story that Was
The other half of the story that you experience as you play The Division is the back story. The story of the spread of the virus, and most importantly, of the people that were caught up in it. You learn this story through the phone recordings, the field reports, and side missions. And I have to say - I thought this story was fantastic. The best stories - the most relatable ones, are the ones about people. And that is what you experience. You are given view into some very personal and private moments of people struggling to deal with an impossible situation, and it is incredibly compelling. The voice-over work done in the phone recordings is superb. In truth, I found myself caring far more about the people I learned about through those phone recordings than I did for most any of the story's central characters. The father who's son calls him frantic, with men breaking into their house, urgently telling his boy to find their gun, before getting cut off. The creepy ex-boyfriend who's broken out of prison, trying to stalk his ex-girlfriend down. The young college student who keeps sending messages back to his brother, who slowly turns to a very Lord of the Flies style life of barbarism. All of these stories were interesting, and compelling, and listening to them made me feel. And that, in the end, is what a story-teller wants to happen.

The only downside, is that this story is delivered in an incredibly disjointed fashion, in bits and pieces, as you pick up the various collectibles. I'm not sure how you would solve this problem any other way, to be honest, and I'm not even entirely sure it's a downside, as the fragmented way you get the story leaves gaps and questions, which in itself is interesting. But it does make it more difficult to put the narrative together. And to that end, I think Ubisoft made entirely the right call, by revealing all the collectibles in a zone after you've finished the missions, side missions, and encounters. They're saying - we hope you found the pieces of the story you experienced so far interesting enough, and if you did, here is where you go to find the rest. Which, is exactly what I'm doing.

The Environment's Story
One of my favorite ways for developers to tell a story is not by telling you, through text or voice over, but by just showing you, through the environment. Not a lot of developers can afford this route, because lets face it, building a compelling scene is just straight up more expensive than writing some quest text. But for those that do, I think it adds tons to the immersion in the game. Sometimes the best story is one that just asks questions, without always answering them. The writers of Lost used this method to string their audience along for years.

In The Division, they do this in spades, which again I think is incredible. Not just the in-game echos, which is an interesting way to deliver a narrative, but if you look around after you disable the echo, you almost always find the left over real-world evidence of what happened in the echo. A crumpled body; blood stained and bullet-riddled walls; a smashed guitar that was used to clobber a raider over the head. And even beyond the echoes, just in the world in general, if you stop, to look around, you'll see all manner of incredibly cool, unique scenes that ask questions. What's up with the rat-shrine? What happened to those JTF agents? Why did she end up playing the piano under an overpass? But to experience those stories, the onus is on the player. You have to stop, slow down, and look around from time to time.

If you haven't done this yet, once your base is mostly or completely finished, do yourself a favor and go down to the far end, past all the vendors. You'll be rewarded with a story of people coming together in a terrible situation. Of people trying to find a little normalcy in a crisis by decorating a small Christmas tree. Friends giving each other solace while sitting on a bunk bed, and other people gathered around the sole working TV watching an old movie. It's very cool, and very humbling, and told entirely without a single bit of text or voice over.

You have but to slow down, and listen, and you will see some amazing sights in the streets of New York.

Mirror's Edge Catalyst comes out soon, and I'll be departing the streets of New York almost assuredly to run, jump, and wall climb Faith through the streets of that other metropolis. Until then, you can still find me cleaning out Cleaners and putting Riker's away most nights. I'm still having fun, and hope you are in whatever world you find yourself in.

Blade and Soul - Ups and Downs

noreply@blogger.com (Dusty Monk) — Wed, 03 Feb 2016 14:05:00 +0000

I've never been very good at spending my free time on more than one general activity at a time. Whether it be working on a game development project, playing my MMO de jour, or something that's caught my eye on the console, typically I tend to only focus on one thing, though I have been known to shift about pretty quickly. And if you follow me on twitter at all, you know that for me, for the last several weeks, that's been Blade and Soul. So what's keeping me in the game?

Beautiful Game

Aesthetics are really important to me, and Blade and Soul has them in spades. And no, I don't just mean the boob physics! (though yes, they do have that as well - it is after all a Korean game) The world itself though is gorgeous. They combine a strong art direction with a bright palette and thoughtful eye towards zone layout to create a combined experience that is overall very pleasing.

Satisfying Combat
If there's anything that you want to get right in an MMO, its your combat mechanics. And I think Blade and Soul has done a fantastic job in this area. By using contextual abilities, tight animations, and a mix of both defensive and offensive maneuvers, they've built a combat system where not only do choices in your build system matter, but so does player execution. Of course, proper rotation execution is important in any MMO, but in Blade and Soul it's not just the order of operations, but the timing of those operations as well that's key, as well as proper reactions. Sometimes when I'm doing a quest that just has me running around wantonly slaying monsters, I turn off the UI just so I can more fully appreciate the experience.

Easy to Group
Something that has really become important to me more recently is a game's ability to form ad-hoc groups for group content. Less and less am I willing to get tied to any particular social structure for a particular game - I'm just to likely to move from game to game, and I don't want a guild tying me down. But I do want to participate in the group content. So a game's ability to find pick up groups, and the quality of those groups, is really important. And this is something Blade and Soul does exceptionally well. They have an ad-hoc party finder for finding a group for just about any quest or minor dungeon on your server, and for all off the major dungeons they offer cross-server matchmaking. And they provide cross server matchmaking for their PvP arenas as well.

This, combined with the soft role designation off their classes, means you rarely have to wait long to find a group for any group content. And the way their dungeons and mechanics are built, rarely does it take longer than 10 to 15 minutes to run a dungeon. I love this! And the fact that they offer daily rewards for just about every dungeon in the game, means you can easily level by just running dungeons, or PvP, or questing - depending on your playstyle preferences.

The Not So Good
But everything isn't necessarily all lilies and sunflowers in the land of the East. There are definitely some aspects of the game that, as I've gotten further into it, I find less appealing.

I'm definitely not a fan of their crafting. Despite participating in four professions - two gathering, and two crafting jobs, it feels very shallow, and even though I'm level 38 now, and have been crafting since I was level 16, I've yet to make anything that I thought was even a little bit useful. And I chose weaponforging and jewelry making as my professions! Crafting is at least starting to produce things that can bring a tiny bit of coin on the market, but overal, it's been a massive let down. Certainly no where near as good as the comprehensive jobs of Final Fantasy IV, or what Guild Wars 2 offers.

I'm also still on the fence about their itemization. The way it works, pretty much everyone's gear improves in exactly the same way. Every class uses exactly one weapon, and everyone in my class will have the exact same weapon that I do. The only variation between one Blademaster's weapon and another is how far along the weapon improvement path they've gotten. You can change your weapon's appearance, so at least they don't all look the same, but there's really no room for deviation from the path, or choice. The same applies to your stats gear - the soul shields. For any particular level range, there is a "best" soul shield for your class - usually the one dropped in the most recent epic dungeon. You equip all the pieces of that shield, and you use it until you get to the next epic dungeon. There is a little more room for specialization here, as you might take a defensive set over an offensive set, but again, it just doesn't feel good. I find I like having my stats on my gear. And even SWTOR's itemization - where all your stats live in mods that you slot into your gear, felt a little more intuitive than this system.

Overall though, I'm still quite enjoying the game. I'm currently level 38, and at least currently plan on playing until I get to the current level cap, which is 45. There is new content coming out next week, as well as some very welcome class balance changes. I don't often play PvP, but when I do, my poor Blademaster gets pretty much wrecked by everyone else.

Until next time - enjoy your game, whatever it is!

OH and XCom2 next week! At least one BnS player I know says he will be dropping this game like yesterday's pajamas to play that when it hits the digital shelves. Will you?

Blade and Soul Beginners Guide - an Overview

noreply@blogger.com (Dusty Monk) — Sat, 23 Jan 2016 23:57:00 +0000

So I started the new year off saying I'd try to deliver more video content for Of Course I'll Play It, and here it is practically the end of January, and I haven't done a thing yet. Well part of the reason for that is I've been spending just about all of my free time playing Blade and Soul! I'm having a blast of a time in the game, and I've had more than a few people ask me what I thought and if I thought they'd like it. So in answering that question, as well as talking about Blade & Soul's sort of base mechanics, I thought I'd put together a general sort of beginner's guide. This will hopefully answer most of the questions I know I had when I first started the game, as well as help you decide if you think the game is something you would enjoy.

So check the video below, enjoy the guide, and please let me know in the comments if I should do more videos like this, or just stick to the written word and pretty pictures.

New Year's Resolutions!

noreply@blogger.com (Dusty Monk) — Mon, 04 Jan 2016 03:02:00 +0000

Hello and welcome to the first post of the new year! I thought I'd kick off this year in Blog Posts in classic style - with some new year's resolutions. Little known fact about me, I love new year's resolutions. I know, most people by now are pretty jaded and cynical when it comes to setting goals for the new year - but for me, it represents a chance to change, and a change to grow, and blah blah mostly I just like making them and seeing where I end up at the end of the year. So now, without further adieu, let's look at what we're going to try to get done in 2016 (oh man it sounds weird saying that!)

Personal - Exercise more, eat better!
Well duh! We all make this goal each year, and I'm no different! I've actually started getting a bit better about exercise and diet in the past few years, but I still fall off the wagon plenty! In fact, I think the last time I was exercising regularly was back in October - so it's high time I get back to it. I'm using FitBit for run tracking, and MyFitnessPal for diet. If you want to join me with your fitness goals, post in the comments, and I'll add ya!

Continue with the Unity At Home Project
I really enjoyed working on my At Home Project. I reached my initial design goals at the Christmas break, but it's no where near really an actual game. I think I'd like to see it become so. Not sure what I'll do with it for real - if I'll ever actually try to market it, but continuing to build a multiplayer mech game sounds like something I'd like to play and do, so what the hell! Look for more posts coming soon detailing my progess on the game.

Extend Of Course I'll Play It into Video
I started doing commentary videos at the end off each Unity blog update, and I kind of liked that. I'd like to continue that. Either convert my YouTube channel or create a new one that is kind of the official Of Course I'll Play It video channel. I'm not promising to do any streaming, per se. Still haven't felt really compelled to get into that. But maybe some Let's Play videos featuring games I'm playing, some more dev/commentary videos, and maybe even a video blog or two.

That's Enough!
Yap, it really is. That pretty much sums up the big things I want to get accomplished for this year - at least in terms of stuff you people care about. Oh I might decide to get back into fictional writing again too - but honestly I'm not yet committed enough to that goal to write it down. So there you have it. Stuff we wants to get done in 2016. I hope you folks will join me, and bring your friends, and together we'll have a bitchin' good time.

Cheers!

Dipping our Devilish Toes into Devilian

noreply@blogger.com (Dusty Monk) — Thu, 10 Dec 2015 13:59:00 +0000

That's a lot of alliteration, Al!

For the most part, I'm actually pretty good these days at resisting Hype, with a capital H. Devilian's been bouncing around my social media circles for some time now as it rolled through one beta after a next, and I looked at it long enough to say "Oh, a Diablo Knockoff", and that was pretty much it. But Monday it popped up on the radar again being just a few days from their official launch, and I gave it a bit more consideration. First, I'm a huge fan of the South Korean MMO art style it uses, heavily reminiscent of games like Tera, Blade & Soul, and Aion. In fact, Bluehole Ginno, the south korean developers, are also the developers of Tera. So that should tell you something about what you can expect in terms of art style. And more to the point - the level of dress, or undress, as it were, you can expect to find most of the female models. Second, it's being published here in the West by Trion Worlds, a publisher I have a fair amount of respect for. Rift is a fine MMO, and I've spent plenty of hours in Defiance. And third, the early access founder's pack was at a very reasonable $20.00 US. So I shelled out a Jackson, patched up my Glyph launcher, and started the download. And so far, I'm quite glad I did. Now, a few days later, here's what I've learned about Devilian.

There's a Whole MMO Here
I think that's probably the biggest point to get across. Because of it's top down nature, if you're like me, you will go into this thinking hubs and instances, aka Diablo 3. At the most, something like Marvel Heroes, with a shared hub, and multiple instance zones. But make no mistake - Devilian is a full blown MMO draped in Diablo 3 clothing. After the brief tutorial, you're in a shared world with other players the entire time you're playing - save for dungeons, which I'll mention below. There are quest hubs with the typical fare of MMO quests, banking storage, auction houses, a mail system, a full blown friends and guild system, the entire works. You can party up with friends and do quests together, or you can run everything solo. There are instanced dungeons just like you would find in FFXIV or the like, with elite level trash mobs, and bosses with boss mechanics. And there's a LFG tool to help you party up for the dungeon. Seriously, it's a complete MMO package, and for me, that was the biggest surprise. And a pleasant one at that, because you know - I like MMO's.

You'll need to buy that extra inventory space Dear..

Very Free to Play
Also, that. For me, that's totally fine. I've been working on a F2P game myself for over two years now. And most of the MMO's I play these days are also F2P. So I've become quite comfortable with the various mechanics and systems that are in place to tempt you to shell out some money here or there, and feel free to ignore them or take advantage of them, without their presence getting my ire up, as it might have once. But you should know - there are lots of those systems in place. Very similar in fact, to Neverwinter Nights in that regard. Daily login rewards, a Patron program (ie., VIP priviledges and discounts), and many individual aspects of the game monetized. Companies got to make their money, and they know no one wants to pay a subscription these days.

You're a God! No Wait.. You're a Devil!
So what about the gameplay itself? So far, quite satisfying. It's a little rough around some of the edges. The cinematics sequences are rough, short, and quite cheesy. I occasionally get lag spikes, but nothing game breaking. As for the game itself - hover mouse over monsters, press buttons, watch them explode spectacularly. Similar to Diablo, the boss mechanics in the two dungeons I've been in so far mostly amount to "Get the hell out off the way of the bad". And the entire time you're leveling, you feel plenty powerful. I may do a follow up beginner's post on actual mechanics - the Devilian form, classes, etc., but honestly there's already plenty of that kind of information available from the betas. But in short, I find the gameplay very familiar, and satisfying. Blow up monsters, collect loot, complete quests, rinse and repeat.

Is the Grind Coming?
This is a Korean MMO. And past games serve as any indicator, that means two things. One, at some point, PvP - and quite likely, open world PvP, will become a thing to deal with. And also, the leveling curve can expected to become grindy. However, this game might just be the exception to that. I've heard of people getting to the level cap - which is currently level 52, in literally a dozen hours or less. And though I know PvP is definitely a thing in the game, So far it appears to entirely be the instanced kind you'd expect in most western MMOs. So I guess we'll see. For myself, so far the leveling curve has felt quite brisk - especially if you augment your questing with a few dungeons.

Let's Do This!
What I mostly wanted you to know is that this isn't a heavily instanced base, hub-spoke model game. It's very much a full blown Korean MMO, with all the good and the bad that entails. So if that's your thing (and it most definitely is mine) you should check it out. Now if you'll excuse me, I have a daily login reward to collect.

Unity3D At Home Project Day 13 - Pushing On!

noreply@blogger.com (Dusty Monk) — Mon, 07 Dec 2015 15:09:00 +0000

So just have a bit of time this morning before work, but wanted to get some thoughts down. And mostly, those thoughts are around carrying on the fight, and deciding where to go next. Let's get to it shall we?

Games are Hard
Game development is hard. It is a fact. I've been doing it professionally for some 17 years now. I've made games completely by myself, I've made games with teams of four, and I've made games with teams of over a hundred. And the one thing they've all had in common is that getting it right is just plain hard. When it comes to design, there is no right answer. What is fun to you will be "grind" to the next person, and "fluff" to the person after that. When it comes to scheduling, you will never be right. You make guesses, estimates, and pour all of your knowledge, and still something will blow up that you didn't expect, or in the rare case, fall out unexpectedly easy.

If it seems I'm belaboring an obvious point, I am. And I'm doing so, because it is a mantra you will need to see you through the long nights if you take the road of a game developer. Whether you are working on your first cohort project at the Guild Hall, or slugging your way through your tenth AAA title, there are dark days in your path, and you will need some guidance to see you through them.

Moving to the Next Milestone
So yes game development is difficult regardless of your project size or your team size. But let's talk specifically now about the case for the independent developer. The one to three person team slugging it out over laptops at Starbucks, skyping each other daily updates, and hoping for the big break on Steam Greenlight or at the App store. Like any ambitious project, you will face those days where it's easies to just - put it off. Especially after you've reached an important milestone. You feel good about your accomplishment, you've worked hard to get the game to a certain point, and not only are you a bit hesitant to dig in and push on, you're not even sure in what direction you should go next. Do we polish the UI experience? Add a major system like multiplayer, that anecdotal evidence suggests we can't do without (or the reverse - what about a single player experience)? And for you, there is no one to lean on but yourself. You are the only strength from which you can pull to push on to the next part of this project. Whether it be a writing project, a personal exercise plan, or your indie game - the strength to go on must come from within. I don't know if it will help you. But those words have helped me on more occasions than I can recount.

So what about Giant Robots?
Which brings us to where we are on our game - the doesn't roll off the tongue "At Home Project", ie., Giant Fighting Robots. In truth, I don't have a clear goal for "how finished" I plan to make this game - and that is actually a problem I need to face. As I mentioned in the previous blog, I have, for all intents and purposes, satisfied my original goal. Two people can drive around in giant robots, and shoot at each other. It wasn't a terrible ambitous goal, but as we've seen, even the simplest of sounding things can take quite a bit of work. And I still don't know yet if this would be a game that I would finish all the way out to the point of it being "publishable" - because quite frankly that is a ton of work, much off it dull and tedious, (who really enjoys writing key-bind configuration screens - really) for something that will in all likelihood never bring me a dime. But on the other hand, I don't really feel like it's finished yet either. So the goal of "finished" for this game is still somewhat undefined, but I feel like it's somewhere between where it is now, and a game that you would actually pay money for. So I've decided I will press on further, at least a bit, to see where we'll go next.

So What's Next?
There are a number of ways I could go next. I could start building new weapons and effects. There are at least a half dozen or more other weapons I would consider a minimum for mech game - missiles, obviously, beam weapons for sure, and maybe even a flame thrower or something fun like that. Lots of work to do there. And there are the mech themselves. I would want to have several classes of mechs, once we have more weapon variety, with light, medium, and heavy mechs available, as well as different weapon loadouts.

There's bug fixing and performance optimization to do already. In just the two man sortie I played with my wife, I saw several bugs and some hitches in performance. If they're there for two players, you know it'll be ten times worse for four or eight. It would probably be wise to squash those things early.

But in truth I don't think I'm going to focus on either new content, or bug fixing, just yet. Instead, I think the next crucial point is the game itself - or more to the point, the life cycle of the game. That means a proper loading screen, a lobby in which you can form the game, then launching the game, and finishing it. With a single mech and weapon working, I have enough to see a single game through from beginning to end, so I think it's time we got a first pass of that infrastructure in.

Of Course, Not Yet
Okay, our path plotted, we should get started. Well, I will. But not I think, until after the holidays are through. With family,get-togethers, and a bevy of distraction between now and the year's end, I'll pick this up after the New Year. So while I'm enjoying some leisure time, playing some games, and maybe even posting a few more game blogs before the year's out, don't look for a new Game Development blog until January!

Until then, Merry Christmas and Happy Holidays!

Unity3D At Home Project - Day 12 - Explosions and Stuff!

noreply@blogger.com (Dusty Monk) — Fri, 04 Dec 2015 15:05:00 +0000

So first apologies that this next update took a little longer. First - Thanksgiving. And second, and this is more to the point - but ran into quite a few problems working through the next pieces, and it took longer than I would have liked to get everything working the way I wanted it to. And there are still issues, but it's time to post an update! We've got quite a bit to cover in this one, so let's get to it!

So when we last left off, we'd just set up some of our first protodata for mechs and weapons, and we'd built a nice effects package called WeaponEffect that allows us to group together a variety effects into a single entity that we can attach to just about anything. We had our weapons firing, but not doing anything. It was time to make them do damage, but once they do damage, then you have to deal with death, and once you deal with death, you have to deal with respawning, So that's what we tackled in segment.

Fun with Projectiles
I've set up the protodata on our weapons to support two kinds of hit-detection. The first, "raycast", will just do an instant raycast when the weapon is fired, to see if we hit something. We'll use this for beam weapons, and most ballistic weapons. The second, "projectile", will actually spawn a projectile and send it on it's way, and we'll let that determine what we hit. That method is a bit more involved, codewise, so I decided to tackle that first. It's not too hard to find simple projectile updating code. The effects package I downloaded had a nice projectile class in it, so I used that as a starting point. But our projectile has some special considerations. It has to be a network aware object, and it has to be spawned through the networking system. It needs a collection of effects associated with it's flight, and it needs a collection of effects associated with impact. So ours works like this.

Launch routine

When it's time to fire a projectile, the owning mech spawns a projectile, and then launches it. The launch routine establishes ownership of the projectile, so it can know who launched it, and what weapon it came from. We need this information for determining range, damage at impact, and who to attribute the damage to. On the clientside only, in OnStartClient, we initiate the projectile's flight effects. During update, on the server side only, the projectiles position is updated, and a check is done each update for collision. If a collision occurs, again on the serverside only, we inform the owning mech, and allow it to deliver the damage payload. At the same time, we initiate an rpc call to the client for the projectile, so it can play the impact effects at the point of impact. So as you can see, once again, whenever multiplayer is involved - everything gets more complicated, as we have to carefully establish the division of labor between things we want to do on the server, and things we want to do on the client.

Projectiles!

Death & Rebirth
So once we had projectiles firing, we needed to set up delivering of damage. Instead of just subtracting health, we created a "DeliverPayload" function, and it can do a variety of things. In our case, it applies damage, and it applies heat. We also then check against the mech's max health and max heat to to see if we're dead or not, or if we've overheated. I haven't even decided yet what "overheated" means, in terms of gameplay, but I've got a hook for it. For death though, it was time to figure out what that meant.

Side Note on Heat: I think heat management is a really important aspect to any giant fighting robot game. So I've put in plenty of hooks for it. Each weapon generates a certain amount of heat when it fires - so beam weapons generate more heat, ballistics not so much. Additionally, each mech has a heat dissipation rate, which is the amount of heat it naturally loses. When a weapon fires, it applies it's heat amount to the owning mech. Of the heat rises from zero, it starts a coroutine to dissipate heat. While the mech has heat, the coroutine reduces it by the proscribed rate each update. When heat gets back to zero, the coroutine stops. I wrote all this code and set all of this up for an effect I don't even have any gameplay simulation or visualization for yet. But that's what we do.

So it was time to think about death, and how we handle it. For the real game, I think I like the idea of when you die, you're out. Each match is a last man standing kind of thing, and when you die, the hulk of your mech stays on the battlefield, and your camera goes to following one of the mechs around that is still alive. But for practicality and testing, I needed to have a respawn. And, for some game modes, I could see respawn being desirable. So I needed to support it, and probably in a first-class citizen kind of way. In order to support the notion of "gamemodes" though, I would need a game management class, and hell, even the notion of a game itself, which I currently didn't have. I wasn't quite ready to jump down that rabbithole just yet, so I just decided respawning, for the moment, is what we do.

Side Note on Death - Death is hard. No really - it's really really hard. Over the years, I can't tell you the quantity of bugs I've had to deal with centered around dead units. This is because it's a weird quasi state. There's some amount of time while you're dying, and then there's while you're dead, and the unit is still in gameplay, but it can't do all the things it normally can, and can't be affected by the things it normally can be. All I'm saying is - don't go into death thinking "Oh health == zero destroy unit done!". That may be what they show you in the little game demos, but in reality it is never that simple.

That meant it was time to set up some game states. I have to tell you there was quite a bit of gnashing of teeth here between game states (dead, alive, dying), conditions (stunned, slowed, heated), and damage (heavily damaged, slightly damaged) and that sort of thing. All of these things are heavily interlinked, and the lines between what is one thing and what is another are hard to define. Get three programmers in a room and start talking about what is a condition versus a game state, and you'll be there for hours. I decided to punt on all of it for now, and establish some firm states, at least. They are Inactive, Spawning, Alive, Dying, Dead, Despawning. This allowed me to establish some ground rules about when the player can control the mech, and when the mech can be affected by damage and what not. Once I had all that sorted out, and code written to support all that, it was time to set up the effects for dying itself, and get those working. And those consisted of a death animation (which is a simple fall forward, provided by the Mech Constructor kit), some explosions, some sound effects, and a new fade out effect.

A Dying Mech

Problems, Solutions, and Workarounds
So getting all that set up was only half the work. In fact, probably less than half the work. Because once it was in, I then proceeded to spend the next week and a half fixing problems with all of the above. First the death animation wouldn't play reliably on clients. And when it did play it was 2 seconds too late. And then the fade effect wouldn't work. And then projectiles were wonky on remote clients (they still are in fact). The point is, I could go on for another three pages on the various problems I faced and the solutions I found, or in some cases, didn't find, but decided to work around. But I won't. What I will do, is give some short tips on how to deal with that kind of situation.

The most important thing is to isolate. Pick one of the many things that are going wrong, and focus just on that. Ignore everything else, and see if you can fix just that one thing. Once you have that working, then move on to the next single thing. Identify, Isolate, Execute. I know, it sounds cliche, but seriously, if you don't, you will be overwhelmed by the mass of shit going wrong in your game.

Finally - Combat!
Eventually, I soldiered on through the problems, and did in fact, finally get most things working to a satisfactory degree. Mechs can fire weapons. The weapons generate projectiles, do damage, and do heat. Mechs can die. When they die, they explode, sound plays, and then fall forward, and fade out. After the mech fades out, the player is respawned in a new mech, at one of the spawn locations. The circle is complete. Finally I was able to hand my wife a game controller, which she relunctantly took, and we drove the mechs around firing indescrimintely at each other, blowing each other up, and respawning. You can see the results below.

Aaaaand we're done. Or.. are we..
Well, technically, I'm done. I have actually at this point, met the full "specs" of my original design - which was to get to a point where I can drive a giant robot around and shoot other players in a giant robot. And we can now do that. But as you can see, we're no where near close to a real game. We don't even have a UI. I feel pretty sure I'm going to carry on for at least a bit further, but there's a huge amount of work still to be done in turning this into a real game. So if you - yes you - actually have any thoughts on whether or not you'd like to actually see and play a finished game created from these humble beginnings, I'd be happy to hear them!

Useful Links
No real useful links this time. I spent all my time rummaging through the unity multiplayer docs, which I've linked multiple times before. At this point in the game, we're mostly out of the "tutorial" stage, and soldering on in uncharted waters of our own.

The Unity3D At Home Project
Here is the main page to the entire project, if you'd like to catch up on previous posts and see this from the beginning.

Unity3D At Home Project - Day 11 - Weapons & Effects

noreply@blogger.com (Dusty Monk) — Tue, 24 Nov 2015 04:27:00 +0000

So now's the point of the project where we roll up our sleeves and really start to dig in. I talked about all the ways in which our design space can go in last week, and about constraining your execution as much as possible. But even so, we just have a heck of a lot to go and build. I've got a lot of ground to cover in this blog alone, and we're still only about half way through implementing a single weapon. So let's get to it!

Data Driving Your Design
This topic could be an entire blog in and of itself. It's a fundamental concept that every professional game of any scale has to have. And yet, surprisingly enough, there's no real built in support for it in Unity. And few game tutorials or showcases even talk about it. But I'm going to drill it in here: plan on building a database for your game. Think about it - in just about any game you build, there's going to be some collection of some similar units, with shared characteristics. This could be the players, mobs, weapons, spells, abilities - whatever. You'll need a way to easily manage the shared data associated with those objects, independently of modifying the objects themselves. So what you want to do is put all of the static, shared data into separate records - which you can then serialize in a table, and then create instances of those object based on their base record. There's no real agreed upon industry term for this process, but at Ensemble (and now at Robot) we called that separating the protodata from the instanced data. Let's walk through an example.

In our game, we have mechs. Now we want a variety of mechs, with different characteristics. Things like health, maximum speed, turn rate, heat dissipation, etc. So we set up protodata for the mechs, where each protomech record defines those characteristics for a single class of mech:

Those records can then be serialized in an XML table, for instance, or stored in a database. When we instantiate a mech, we give the mech a protoID to use. It will look up the protorecord for that ID, and use the characteristics for that record. In that way, we can share the static data among every instance of our units. And furthermore, the static data can be edited by designers, or yourself, independently of the instance prefab. I did a similar thing for weapons, so now each weapon has a protodata record assoicated with it, which defines how much damage it will do, whether or not it is a triggered or channeled weapon, etc.

Note - In my case, I ended up just attaching the protorecords directly to the prefab itself. That's why they're derived from monobehavior, so they can be components. I did this for two reasons. One, in this game, I'm the only designer, so creating a "table driven method" of editing the protodata is not as important. Two, the mech prefabs themselves are actually protodata, when you think about it. The problem with this is that now a copy of the protodata lives on every instance of a mech in our game. In a game where I'm unlikely to ever have more than 8 units in game at any one time, this is probably okay. If these units were say, villagers in an RTS though, or mobs in an MMO, this would not be okay. Never be afraid to modify your conventions for the realities of your situation.

The new Dagger mech, with Protodata

Setting up the Architecture
With the protodata firmly established, it was time to figure out exactly how a weapon works. Before I wrote a single more line of code, I actually pulled up OneNote, and started typing out my architecture design in stream of consciousness notes form. This is something I do every time I'm tackling a new system. I want to know exactly what all the pieces are, and how they connect. I spent several hours on Saturday doing this. Walking through the system, trying to account for everything in my design that I knew I wanted to support. I wanted to handle channeled weapons (where the weapon fires as long as you hold the trigger down, and stops when you let up - like a flamethrower) and triggered weapons. I wanted to handle AOE damage and DOT damage. I want weapons to work both as projectiles and instant raycast. And it all has to work in multiplayer. And most importantly, we want to separate the effects associated with the weapon from the simulation part of the weapon. Effects should only happen on the client, where simulation changes (damage, etc) have to happen on the server. This last point was the most key piece of the architecture.

I'm not actually going to detail the entire architecture here. This blog is going to be long enough just describing the process. I will try to get the OneNote book that I'm keeping notes in shared, for those of you that are sufficiently masochistic as to want to peer even further into my thoughts. For the blog though, suffice it to say that I ended up with an architecture that seemed like it would do what I wanted. It would work in multiplayer, handle all the design prerequisites, and keep the effects separate from the simulation.

Along Came Multiplayer
I was of course, completely wrong. With the architecture in place (and in writing!), I spent most of the rest of Saturday actually writing the code to support the design. I set up the various classes - Mech, ProtoMech, Weapon, ProtoWeapon, WeaponEffect - and wired them up at least enough for me to go through a simple fire process and see if the pieces worked. And, unfortunately, they did not. Not even a little bit. I immediately sat about debugging, and rummaging quite a bit through the Unity Multiplayer manuals, trying to figure out which pieces I had wrong. Unfortunately, by this time it was late Saturday, I was tired, and I went to bed unhappy with the state of things.

Sunday, in the light of a new day, I backed out my pieces, and started re-establishing them, one by one, until I finally figured out the problems. Out of my troubles though, comes a really technical, but really important, Unity Multiplayer Gem. Which I will share with you!

Unity Multiplayer Gem - All network behaviors must live on the root object of an object that is spawned by the networking manager. They cannot live on subobjects.

See? Already you know more than you did coming in. Once I understood that fundamental truth, I was able to clean up my system and get it back on track. Well that's not entirely true - I did make a brief foray down a dark path where I attempted to spawn the weapons separately from the mech. This was not.. how to say it - a good solution.

The Effects Problem
We've already gone on long enough for this morning's blog, but there's one more piece I spent a lot of time on, and so feel like it too deserves a mention. Again, this is a topic that could well garner an entire blog onto itself. Managing effects collections - things like sounds, lights, particle effects, animations, etc - can be a huge system. And your solution can vary from just straight up hardcoding the effects for each individual weapon, to building some general "effects manager" that allows you to handle a wide variety of effects in a generic fashion. And I spent quite a bit of time Sunday struggling with which end of the spectrum my solution would fall on. Every part of me wanted to build a really robust, full featured, effects manager. But I also knew that could be a really big system that would be put in place to handle what is most likely only going to end up being a half dozen or so types of weapons.

In the end, I came up with a compromise that I feel pretty good about. I have the notion of a WeaponEffect, which is a collection of effects to be used in any given situation. So for instance, the muzzle flash of a gun might be a WeaponEffect that contains the gun's fire animation, the sound effect, the light, the particle effect, and maybe a mesh to show the muzzle flash. Each of these individual effects will live on child objects to the parent weapon effect, and will have an EffectActivator component attached to it. The EffectActivator component allows for independent delays and durations for each effect. In this way, even though the entire muzzle flash effect may be 1 second, the mesh activation flare may be only 0.05 seconds, the animation can be 0.8 seconds, the sound effect can be 0.5 seconds, and start a half second late in the effect. In this way, I should be able to build relatively complex effect systems for individual effects at any given time. Remember - we have to support explosions at some point!

Note - The effects themselves. One thing I really did not want to do was get in the business of actually building particle effects. Let me tell you - good particle effects are an art form in and of themselves. I went to the Asset Store and purchased a collection of Sci-Fi weapon effects for $35.00 that I think has pretty much all of the effects I need for my game. It's a really nice, robust collection - I'll link it below. However, like many of these assets, it comes with a pretty large collection of code that is their own "ready to use" weapon system. If you were so inclined, you could take that system and probably integrate it into your game. That was not my desire at all. So again, I imported the package unto a separate project to test and evaluate, then imported in only the particle effect prefabs and shaders into my project.

Finally!
So that's about it. I spent a lot off time working on the systems this weekend, and by the end, I literally had one weapon, halfway working. That is, it plays effects - but doesn't actually shoot anything yet. But most importantly, we now have a system in place. We know how the pieces work, how they relate to each other. I still have lots of code to write to finish the system, and to build out all our weapons - but I'm no longer wondering how it will all work. And that, is how games get made.

Questions? Comments? Be sure and mention them below.

Useful Links

Sci-Fi Effects 1.15 by Forge3D
This is the Sci-Fi Effects package I downloaded. These guys have now provided all of my effects and sound effects for my game. Maybe I should contact them about some nice environmental pieces.

Unity Multiplayer Manual
I've linked it before but I spent so much time here this weekend it bears listing again.

At Home Project Design Notes
The OneNote notebook I'm using to keep my design thoughts in as I work on the project. Not really fit for human consumption, but feel free to peruse if you wish. A Microsoft account will probably be necessary to view it.

The Unity3D At Home Project
The main index page of the At Home Project. If you'd like to catch up from the very beginning, this is where to go.

Unity3D At Home Project - Day 10 - From Simulation to Gameplay

noreply@blogger.com (Dusty Monk) — Fri, 20 Nov 2015 14:35:00 +0000

So this is a bit of an interim post, where I just talk about game developery things, without having done real work on the game itself. As such, it's likely to turn into a rambling diatribe that no one actually gets to the bottom of, but there's a process that happens here - it's really important - and one of the reasons I'm doing this blog as I make this game is to share the things I've learned from fifteen years of game developement. So here goes.

Look how far we've come already!

The Story So Far
So up until now, in our game (it really is going to need a name soon), all I've really done is worked on simulation. That is, we've just been working on some fundamental things we knew we were going to need, without really thinking too much about actual gameplay. And we've seen even just that is actually quite a bit of work. We've got a mech animating, walking about with a game controller, playing sound effects, and a camera that follows in a pleasing manner, and it all works over multiplayer. But now we're ready to start actually firing weapons, and that means the mechs need to have health, and we need to do damage, and that means we actually have to start thinking about gameplay. Now, I could slap a health value on the MechController component, and I could just jump right into putting together a weapon that fired some effects and ultimately modified that health value. That is, I could, continue right on with building a weapon that does the most basic thing, and I would probably learn a lot - but if I did so without really starting to think about gameplay, then I would probably end up - pardon the expression - shooting myself in the foot. That is, without taking a moment to actually design some of our game, we would either be building a weapon that didn't take into account all the things we want to do. Or worse, at the opposite end of the spectrum, if we build too generic of a system, we might end up doing a lot of work to support things we never really intended to build.

Exploding Design Space
So in short, before we go any further, we need to think about the actual design of the game. And when you start thinking about all the things you might want to do, well the problem space just explodes. For instance, here is just a short list of thing to think about in our game design:

For mechs -
How many different types are there?
What are their characteristics? Health? Armor? Speed? Acceleration? Weight?
Do they have jump jets? Shields?
Do we worry about heat and heat dissipation?
Does terrain effect our mechs? Do they cool down standing in water? Go slow through mud?
Are we even going to have water and mud?

That's just a few. What about weapons?
How many different kinds of weapons? Lasers? Missiles? Chain guns?
Do we have hard points? Can you swap out weapons on a mech in some kind of loading bay?
Can you pick up weapons while in game?
What are the effects of weapons? Do we have healing weapons? Slowing weapons?
What about ammo? Do weapons have ammo? Do you have to carry it with you?
Can you pick up ammo in game?

And then let's think about the gameplay itself:
What do the levels look like? Is it terrain? Is it a city block? Both? Some kind of interior?
Are there powerups, in the traditional shooter sense? Repair stations? Cooling stations?
Are there destructible objects in the world - trees, buildings, etc?

Okay I'll stop - you get the idea. Now, I know that you know, what I'm about to say next. Yeah Dusty, we get it. You can't do all of it - pick the things that are important, and focus on those. Duh. But the thing is, (and yes, that was what I was going to say next, thank you very much) while that's very easy to say, when you've got your sleeves rolled up and you're down in the trenches building your game, it's actually really hard to do. Because, like me, you love games. And you want your game to do all those things. For every single item I've listed up there, I can make an argument as to why we absolutely have to have them in our game. Jumpjets? Whoever heard of a mech game without jumpjets! Ludicrous! No destructible buildings? Mech games are all about smashing trees and buildings! It's not a mech game without that! No hardpoints? Deciding on your loadout and swapping weapons is key to playing one of these games! It's where some players spend the most time - how could you make a mech game without it?

Tradeoffs
In 2006 Rob Pardo, then with Blizzard Entertainment, opened the Austin Developer's conference with a keynote on Blizzard's design tenants, and how they shaped the success of World of Warcraft. It was, for me, a watershed moment. I was there, I listened to the keynote, and I furiously wrote down everything he said, but it turns out I didn't need to. Because those things have stuck with me, and here, ten years later, they are still my creed when it comes to game design. And one of the biggest things he talked about, in Blizzard game design, was having to make tradeoffs.

The company also tried to remain conscious of trade-offs in game design, and the fact that "every decisions costs" in one way or another. "All game designers are very greedy by nature," Pardo said. "We want to have every cool feature, and we want to serve every market. The reality is that almost every design decision comes with a trade-off. Nothing in game design is black and white, it's all shades of grey."

That's from a GDC article on his keynote. And it goes on to list the examples Rob gave of tradeoffs they had to make for WoW - Instanced dungeons, flight paths, stylistic art design, and so forth. And the interesting thing is, if you look at some of those decisions, you know that they have since then changed their direction on many of those things. And you can say those tradeoffs were the wrong things. They were bad decisions because they ultimately reversed them. But they weren't. They were good decisions, because they allowed them to ship the game at the time. And then, years after the game had shipped, they had time to revisit those decisions, and make a different set of tradeoffs.

If you aren't familiar with Rob's GDC keynote, I highly encourage you to read the article I've linked below. In my opinion, it's required reading for anyone making games - large or small.

There's a lot I can learn from MechAssault

Find a Model that Works

Okay so I've rambled on about the problems around your exploding game design, and the necessity to make tradeoff decisions about what you do and don't want. So how do you go about making those decisions? Well one important thing to do is to find a game that is shipping, that is similar to what you want to do. For instance, for me, I looked at MechAssault. It's an old game, but they had to face some off the same tradeoff decisions I'm thinking about right now. What did they decide? If I were making a game, say about interstellar trading, I would probably look at the greats like Trade Wars 2000. Or I'd play a lot of Eve Online. The thing is, there is almost certainly out there, somewhere, a game that already exists that does at least some of the things you want to do in your game. Find it, play it, learn from it. That doesn't mean copy it. But what were the things they decided to forego. Why? Did it work for them? That knowledge will help you in making your own decisions.

Experience

The other thing that helps, and unfortunately this just really only comes from the school of hard knocks, is just your own experience. The more you do this, the more you'll come to understand the ramifications these decisions have. For instance, I know that if I decide I want to have hard points and swappable weapons, I'm signing up to build a complex, yet intuitive interface to allow users to change, select, and set weapon systems. And that's a lot of work! Even just saying yes to Jumpjets means hours of tweaking thrust times, landing velocities, animations, and particle effects.

Constrain Constrain Constrain

You have to make tradeoff decisions regardless of how many people you have working on your game. And those decisions aren't easier, just because you have more people. In fact, often they're harder, because with more people, you're tempted to tackle more systems. But when you're just one or two people trying to knock out your indy game, the mantra has to be constrain, constrain, constrain. Even myself, in my own head, when I think about the decisions I have made for this game already, I know I'm probably biting off more than I should. One of the biggest problems I faced in Atomic City Adventures was that I built too large of a game, for one person. And it took too much time. So if you got this far, and you come away from today's blog with only a single thought, it is this - take everything you want to do in your game. Widdle that list down to the absolute bare minimum list of things you absolutely have to have in your game. And then be ready to throw half of that away, and figure out what you can do in your game with what's left.

Skip to the End

Okay I've rambled on about game design long enough. For the next blog, I'm going to talk about the specific decisions that I have made for the At Home Project, and then about some ways to data drive your game systems. And then I think we'll be ready to actually build some weapons.

Questions? Thoughts? Please post them below

Useful Links

AGC: Blizzard's Pardo on WoW's Success

This is the writeup on Rob Pardo's keynote address at the 2006 Austin Game Conference. Required reading for game design, in my opinion.

The Unity3D At Home Project

Interested in reading about this project from the very beginning? Find it here!

Unity3d At Home Project - Day 9 - Twistin' by the Pool

noreply@blogger.com (Dusty Monk) — Tue, 17 Nov 2015 14:41:00 +0000

So this week is a story about getting sidetracked, about building things you didn't expect to build, and that sometimes it's exactly what you need to do, and sometimes it's exactly what you want to avoid, and of course there's no easy way to tell the difference.

Where are the Guns?
So it started off with me thinking about weapon systems. I've got a mech that's moving about pretty good, decent sound effects, decent control, and decent camera. It working in multiplayer, and the next logical step is to start thinking about making these things shoot. That is, after all, the point!

There is an entire blog to write (in fact, probably my next blog) about how the design space here really explodes. I won't go into a huge amount of explanation by what I mean about that here (after all, there's that blog I've yet to write about it). But I will say this got me to thinking about (and wanting to look at) other games I've played in the past of similar genre. And that reminded me of MechAssault. MechAssault was a game I played for the original XBox, and I mostly remembered two things about it. One - I loved it. Two, it was a very arcade style version of a mech game, with simplified weapon systems, control systems, and interface. And it used an XBox controller to drive the mech. Perfect! I don't even have my original XBox anymore, but I was able to find some Let's Play videos on YouTube, and that gave me the information I needed to have. Take a quick look for yourself below.

Now, I went to the video looking to refresh myself on how they handled their weapons. And I got a lot of good information that will inform my own decisions. But what made the biggest impression on me was their control scheme. And one thing you'll notice is that all the mechs have 360 degree turret spin. This so the mech's movement direction and fire direction can be completely independent of each other. The camera is slaved to the torso, while the legs spin about to move in whatever direction the player is driving the mech. The result is a mech that is very 3rd person shooter-esque, allowing you to move forwards, back, and sidestrafe, all while keeping your camera and reticle focused on your target.

It works pretty darn well. And while I didn't necessarily feel like I had to copy their control scheme verbatim, what was certain to me now was that I really did need to give the player independent control of the mech's turret (torso), and thus their aiming reticle. And if I ever wanted to support player's having jumpjets in the game, or any target up on a ledge, they needed to be able to aim up and down as well, to at least some degree. So turret control it was!

Unity Makes it Easy - Maybe Too Easy
So at first I thought, I have no animation for the turret spin, but I think I can easily create one, and then have the input feedback play the animation. And then a second thought was - that's dumb. Just have the input control the rotation of the turret completely. You just need to rotate it's local orientation, and maybe place some limit's on it.

That seemed pretty doable, so I sat down, preparing myself to do some of the dirty work of turning an input axis variance of -1 to 1 to turret rotation value. Now, Unity already gives you so much, just built right into it's math library, to assist with these kinds of operations. With functions like Quaternion.SetLookRotation and Vector3.SmoothDamp, I figured I would be able to build what I needed without much difficulty. But then Unity does one more! While rummaging through my project, I found, already provided, a script in the StandardAssets folder called SimpleMouseRotator. Guess what it does? Yup - exactly what I need! I literally slapped this monobehavior on the gameobject that represented the turret mount point, fired up the game, and bam! Turret rotating!

Don't Look a Gift Horse in the Mouth - But Know What it's Eating. Or Something..
I was actually tempted to not use this, and build my own anyway. But my own personal limitation was I would build the code we needed, or use whatever was provided in Standard Assets - and this was right in Standard Assets. It would be dumb not to take advantage of it. And while I may be stubborn and hard headed, I try to not be dumb.

I played around a bit with the parameters, and quickly made the thing my own. In fact, I ditched the SimpleMouseRotator component altogether, but pulled the salient code into my MechController component, where it could have easy access to the camera, animator, and other things on the controller that it might want to talk to. And other things could talk to it.

The 'thrust' input axis

The Last 20% Takes 90% of the Time
And boy did it ever! In fact, in this case I'd say it took 99% of the time. It took me literally less than 30 minutes Saturday morning to get my turret rotating. In fact, it took me longer to figure out how to map the Xbox controller's right thumbstick to an input axis. Namely because I knew nothing about Unity's base input system, and needed to spend some time learning how to set up an axis! By the way, the XBox 360 controller page on the Unity Community Wikipedia was a really useful resource for this. I'll link it below.

But then I proceeded to spend all day Saturday, much of the day Sunday, late Sunday night, and pretty much all night Monday getting things to a point that I liked it. Yap - just about three full days of programming to get it where I liked it. So what took so long?

The Perfect Storm of Competing Systems
Mostly this was a case study in too many systems interacting with each other in too many ways, and me trying to get it right, while doing a poor job of isolating each system. We have the mech's rotation code, with its own collection of turning rates and dampening factors. We have the turret rotating code, also with its own collection of turn rates, dampening factors, and constraints. And then we have our follow camera, which also has its own collection of turning parameters, angular velocities, and constraints. I would try to get one of those systems working just right, but then when it interacted with the other systems, things would go to hell again. And it's not always clear where the problem was. I noticed at high angular velocities, it seemed the mech was shuttering. Was the actual mech shuttering though, or just my camera? Turns out it was the camera itself.

I won't go into every problem that I came across, tried to solve, and then re-approached over the weekend. I will say that I had a lot of fun, though it was also extremely frustrating as well. For most of the weekend, I had the camera slaved to the turret's direction - which made sense. I wanted the reticle to always stay center of the screen, so you when you rotated the turret you were also rotating the camera, and you always looked down then center off the turret, though not necessarily in the direction you were moving. But this produced a whole host of problems, both around controlling the mech, and also just being able to keep the center of the screen on any given target while driving at full speed. At one point I built a self-centering system. While it worked really well, it produced other side effects that resulted in super fast turret rotation only when changing turret direction. I finally turned it off entirely while I sorted out other control and camera issues.

Finally, after having driven way off into the weeds in multiple ways, I decided to back way the hell up, turn the turret rotation off altogether, put the camera back on the mech itself, and think really hard about what I liked, and didn't like, about how the mech controlled. I then began turning the systems back on, just a little at a time. And I realized that I really liked having the camera back on the mech itself, especially with the turret rotation turned on. It allowed me to see the turret rotating left and right, which gave it a very MechWarrior feel. When the camera was slaved to the turret, I never saw the turret rotate, you just saw the word spin with you as you looked up and down. This proved to be really disjointing though, as the camera spun wildly about. Plus the camera's rotation speed then needed to be super fast to keep up with the turret, which introduced a lot of oscillation and variance when trying to aim. By putting the camera back on the base mech, it didn't have to be super fast, which allows it to move more smoothly, which makes driving the mech much more of a pleasure. Plus I can see the turret's rotate left and right as I drive, which is just satisfying. This would mean though, that I could no longer keep the aiming reticle in the center of the screen. It will need to move about the screen to match wherever the turret is aiming. So be it. The gains gathered more than made up for it, in my opinion. It shouldn't be hard to build an aiming system to accommodate that.

The Last Big Shift
So things were now falling into place, and I was once again getting happy with the mech's control. But I still had one major problem. In driving around the mech, whenever we turned sharply, we would immediately lose speed. So far, I've been controlling the mech in 3rd person movement style. The w,a,s,d keys, or the left thumbstick, move the mech forward, back, and rotates left and right. When controlling the mech with the gamepad, as you hauled the thumbstick far right, it moved more towards the center. This reduced forward motion. If you were very careful, you could keep the thumbstick mostly full forward and pulled right or left slightly, to make a sharp turn at-speed, but in the heat of battle you're mostly just going to want to haul left or right on the stick, and not worry about maintaining speed. That simply wasn't going to be possible with the current control scheme.

Then I remembered back to my days of MechWarrior 4: Mercenaries - also referred to fondly as The Last Game I used a Joystick For. And I remember that game put the thrust control for the mech on a separate lever. So to get the mech moving, you rolled the thrust up, and left it. And to slow the mech, or back up, you had to pull thrust back. What if I did that? The more I thought about it, the more I liked it. It just felt right. It felt MechWarrior-ish.

So I checked in all my changes thus far to GitHub, just to be safe. Then I created a new input axis, called 'thrust'. I mapped it to the controller's A and B buttons (and also to keys 'W' and 'S'). Then I made all the other necessarily modifications to my controller, so that forward momentum came from thrust, and the left thumbstick controlled direction only. And I loved it! It feels so much better now. The mech maintains speed, and controlling the thrust gives the mech much more of a simulator feel. Which, in my opinion, isn't a bad thing at all.

The Sound Pass
Finally, to top it all off, remember last week I mentioned I wasn't super happy with the mech's footstep sounds I ended up with. And I new I wanted a sound for the turret. So I made another pass on all the mech's sounds. Much happier now with the overall sounds. The turret sound is really nice when controlled with the gamepad. It's kind of crappy when controlled with the mouse, because of the sporadic way mouselook feeds that axis. But I'm going to save fixing that problem for another day.

What Did We Learn
I actually learned a lot in this upgrade. I learned how to map and modify Unity Input schemes. I refreshed myself on some fundamental trigonometry - let me tell you it's been awhile. And I was re-reminded that camera and control schemes can be really hard to get right. Small changes have incredibly huge impact. But you shouldn't quit until you really feel good with your system, because these systems are fundamental to the enjoyment of your game. Here's this week's recap video!

Useful Links

Unity Input
The manual page for Unity's base input system

XBox 360 Controller
The Unity Wikipedia page for the XBox 360 controller. Really useful if you want to use a gamepad with your game.

The At Home Project Main Page
If you'd like to read all of the blogs associated with this project, you can find them here.

Unity At Home Project - Day 8 - Sound Effects

noreply@blogger.com (Dusty Monk) — Tue, 10 Nov 2015 19:38:00 +0000

First, I have to start off with stupid things I do. This morning, I blew almost the entire morning trying to find a good plugin, piece of javascript, whatever, to allow me to imbed code snippets into blogger. Sadly, while my C# is strong, my javascript is weak, and though I found several alternatives, I was at every turn foiled in some way or another. Two hours later, I'm no better off than I was before, but out two hours of my time. I'm still fuming about it, so I just had to put a quick rant up. I'm sure I'll tackle the problem again, or maybe use a GitHub gist.

In the meantime, let's talk about this week's goal - getting some sound effects on our walking mechs. Again, my original goal was pretty simple - get an engine sound, and some walking legs sounds on the mech, and that's pretty much it. Of course, as we'll discover, even the most simplest of goals can be fraught with peril!

Getting the Assets
So the first thing to do was to acquire some sound effects. Again, to the Asset Store, credit card in hand! There are a ton of sound effect libraries out there, and unfortunately sampling them is something of a pain. What I learned is that most sound effect assets put their effect out in a SoundCloud for you to sample, but they also put a music or ambient sound bed under the sound effect samples, to keep you from stealing them directly from the sound cloud. And while I appreciate the need, it also makes it darn hard to actually sample the sound effects. I ended up going with Sci-Fi Sounds from Forge3D. Over 500 sound effects for $25.00 - there's bound to be something in there I can use, plus some GUI sounds and what not that will be useful later.

Importing Libraries ProTip - Never import an entire asset collection into your main project on initial download. Create a new sample project, and import them into that. Use that project to get familiar with the asset collection, and then move what you need, once you understand how it works, into your main project. I don't need 500 sounds floating around in my main project right now - I need two, to be precise.

Once I had the sounds though, it was time to start going through them one by one, to find something I liked. After an hour or so of rummaging through the sounds, I settled on a few that I thought would be good, and moved them into the Robot-Sandbox project.

The Mech Mixer

Getting Started
So going into this week, I new the basics of Unity Audio - at least "old school" Unity audio. I knew about listeners, and sources, and that sort of thing. But I also knew that as of Unity 5, they had added quite a bit of functionality through the use of mixers of some sort, and that seemed like something I'd want to take advantage of. So the first step again, was back to Unity tutorial videos, and the online manual. And it turns out, it was actually quite useful. I won't go through all of it, but I will provide a link at the bottom of the blog if you want to dig in yourself.

Coming out of the tutorials, I knew that I wanted at least two mixers for my project. The master mixer, which would use to blend SFX and Music, and a submixer, for my mech itself. And on the sub mixer, I would set up different groups for each of the engine and footsteps sounds.

I then added two audio sources directly to the mech controller prefab, and gave them audio clips. I then modified the MechController script to grab a handle to each of these components, so I could manipulate them.

The Engine Sound
There's a really cheap and easy trick you can do with vehicle engine sounds to produce an "engine-like" effect, and that is to continuously update the pitch of the sound with the overall speed of the vehicle. And this is exactly what I did. I put the code in the move function, which is called every update, right after I calculate ForwardSpeed from the user input controls. This was, as I discovered, actually a big mistake.

OnFootstep event added at two
locations in the animation timeline

The Footstep Sounds
For the footsteps, I knew I needed to add animation tags to the animation, that would fire callback code, which would play the animation. Adding animation tags, or events, to animations used to be hard to do in Unity, but since mecanim was introduced, it's pretty easy. Just go to the events drop down in the animation editor, scrub along the timeline to the desired location, and insert an event. Whatever you name the event will be the name of the function that is called on the object that the animation controller is associated with, which in our case is our MechController.

I was able to get all of this set up and working pretty quickly. The engine sounded nice. I ran into one problem with the foosteps sounds in that they were always playing, even when the mech was standing still. I realized that because the walk animation is blended with the idle and the run, at all times some point of the walk animation was playing, and that's enough to fire the events. It would be nice to have a way to say only fire the animation event if the weight of this animation is above a threshold, but I didn't find any such setting. So I modified the callback function to only play the footstep sound if the forward speed of the mech was above a certain threshold. The other thing that I noticed was that when the mech was only just barely moving the footstep clang had the same, really loud volume. So I attenuated the volume of the footstep sound by the forward speed of the mech.

Leg Sounds
I toyed with the idea of having a separate sound for the legs lifting. I like the idea of sort of a hydraulic servo noise coinciding with each leg lifting up, and then a loud clang as the footstep came down. Unfortunately, this turned out to be really problematic. Because the leg moving animation is blended, you never really know at what speed the leg will be going through it's cycle. In fact, you don't even know that it will complete the cycle, as it could reverse direction in midstep. This meant that the servo noise, once started, may or may not ever actually line up with a full leg raise and lower cycle. I played around with a variety of sounds and adjustments, but never could really get it to be what I wanted, so eventually abandoned separate leg lifting sounds, and just stayed with footsteps.

So I was playing the engine noise, playing the foosteps, and the sounds were getting fed into my mechmixer, so I could add effects or adjust the volumes independently if I wanted to, and that was in turn getting fed into the main mixer, which was in turn getting fed to the listener. We're all good right? Well, not so fast.

Multiplayer Problems
And now is the time when we learn why we've already hooked up multiplayer. Once I was satisfied with the sounds in single player, I connected a second mech to the play screen, expecting, for the most part, everything to work as expected. Instead, it pretty much blew up - soundwise that is. As soon as I connected the second mech, all I could hear was this super loud, constant noise I didn't recognize, playing on top of the sounds my own mech was making. Other than that, the other mech in the scene wasn't making any noise that I could tell - no engine noise, no footseps, nothing. What the hell was going on?

Well it turns out, a lot of things. And it took me the better part of a Sunday morning and afternoon to sort these things out. The first problem, the super loud constant noise - turned out to be the engine of the other mech, playing at a constant pitch - no attenuation at all. This was because I was attenuating the pitch inside the move function, which as I mentioned earlier, is called every update by the user input controller - but only on my local player! So on client mechs, this function never got called. First thing to do was to move that pitch modification to the general purpose update. And, at the same time, make the ForwardAmount variable I was using a SyncVar, which is Unity's way of replicating variables across the network.

Well, when I did that, the other mech now was making no sound. Dammit, that should have fixed it! Some debugging logic later, I learned that the ForwardAmount variable was always zero on the client machine. More pondering and investigation, and I finally had a grip on what was happening. Setting the variable to [SyncVar], causes the server to replicate the value out to clients. But my variable was getting set by my local client. I needed to get the value from my local client up to the server someway, so that it could then get replicated to the other clients by the server. But how to do that?

The method unity gives you for getting information from a client to the server is to create a Command function. Command functions, when called, will be executed on the client and server. But Unity also warns you against making Command Functions every single update - and this was something I pretty much needed updating as often as it could. I was pretty stumped at this point - I didn't want to flood the server with CommandFunctions, but I needed some way to get a value replicated from the client, through the server, to other clients. And that was when, it hit me. The animator!

The animator has a NetworkAnimator component attached to it that Unity has thoughtfully provided that replicates animator properties across the network. And one of these properties was the forwardSpeed property I needed to query! So I could, thereoretically, on any client, query the property from the animator, and I would either get the value I personally set on my local client, or the replicated value on network clients - but the same code should work either way! So I tried this, and it worked, and that, in the end, was the key to solving the rest of my multiplayer sound effect problems.

I have no idea how actual efficient this is at this point. But using the animator as a general purpose means of replicating player-controlled-variables to networked clients seems like a really useful trick. We'll see if it bites us in the ass later on, but it's something I'm keeping up my sleeve for future use.

Make sure Spatial Blend is set to 1.0

Where's the 3D Sound?
So this wasn't a problem specifically with multiplayer, but was a problem I didn't discover until I added the client to the game. When I did finally get the sounds attenuating and playing correctly, they still weren't fading over distance. Why not? These were supposed to be 3D sounds, and I could see clearly the volume falloff curve set up on the audio component. Well there is a parameter on the audio component called Spatial Blend. Turns out this parameter is really important. It determines how much of the sound is made available for spatial modifications, including distance attenuation (and reverb zones, and other goodies). If your sounds aren't modifying their volume over distance, this should be the first thing to check on your audio source. Set it all the way to 1.0, which is full 3D.

The Lesson
This week turned out to be a lot harder than I thought it would be, which is often the case in game development. I ended up spending as much time if not more figuring out the multiplayer problems with my audio set up than I did in setting up the audio in the first place. I've said this before, but this really drove the point home - if you're going to multiplayer, do it early in the project. And then for each piece you think you have working, fire it up in multiplayer, and see if it's truly working. And then be prepared for a bit more coding.

Once I had everything working (finally) mostly to satisfaction, I put together a short video, showing off the audio. This time, I even added some commentary, which relates to the stuff I've talked about in this blog. Enjoy the video, and let me know if you have any questions or thoughts!

Useful Links

Sci-Fi Sounds
This is the audio asset pack I ended up using from the Asset Store

Unity Audio Tutorial(s)
If you're getting started with Unity Audio, this is the place to get started

Main Page for the At Home Project
If you'd like to see all of the At Home Project posts, I've provided an index here

Unity3D At Home Project - Day 7 - Walking with Robots

noreply@blogger.com (Dusty Monk) — Tue, 03 Nov 2015 14:35:00 +0000

So it's time to move into the next phase of our project. We've done some simple experimentation, and dabbled in some of the core pieces of a 3rd person action game. We created terrain, texturing hills and mountains, and learned about how trees & foliage work. We got a character controller and a camera controller to allow us to drive a character around. We mapped some animations to a simple biped, and learned about the animator controller. And we established simple multiplayer support, connecting a client to a host, and letting two players run around the world together. But none of this is giant robots fighting each other, which is our goal. So with our base pieces in place, it's time to say goodbye to Unity-Terrain project, and start working with giant robots.

The Mech
The first thing of course, is to acquire some robots. This means a shopping expedition at the Unity Asset store. There is absolutely no shortage of models and resources aimed towards mechs and giant robots, because well, duh - giant robots! I spent quite a bit of time shopping various models and pieces, but decided upon the Mech Constructor pack. This pack provides the mechs as a collection of interchangeable pieces that fit together. This system is going to provide a lot of flexibility in building the mechs, and providing weapon variations, which in turn provides us with a lot of flexibility in our game design.

Here's a cold hard truth about indie game design. If you're building something traditional, and commercial, often your asset availability will dictate your design, not the other way around. In an ideal world, we design our game without thought towards asset or code availability - we build what we think is fun, and then create the assets to support that. But in the real world, if you're a small team trying to make something big, any design you create will have to be supported by assets. And if you can't easily acquire them, you'll have to tackle making them - and you may or may not have the ability to do that, readily anyway. So for instance, say in our giant robot fighting game, we want our robots to have shields. We'll to support that, we'll need some kind of cool shader effect to apply to the robot that has the shields, sound effects for powering up and down the shield, and probably some spawn particle effects as well. Maybe a collection of weapon impact particle effects and sounds to support hitting the shielded mech. Realizing that you don't have the time, money, or resources to easily build all of that, you may decide shielded mechs may not be a thing in our game. Unity's greatest strength to indie developers is the availability they give to acquire assets and technology so that you have more flexibility in making those tradeoffs. But make no mistake, every design decision you'll make should be influenced by whether or not you have the resources to support it.

Okay back to our project. So I purchased the mech constructor pack, created a new project called RobotSandbox, and imported the new assets. Within a relatively short amount of time, I had pieced together my first mech. A light mech - a chicken walker (if you're familiar with mech types, and who isn't!), with a matching pair of cannons for weapons. Good stuff - he'll do fine for our prototyping.

New Controller & Camera

The Standard Assets pack that comes with Unity has a pretty robust controller & camera rig. I ditched my simple camera & controller from the last project, and set about using these more robust pieces. Now, I like to preserve stock code and assets intact if I can, so I made copies of these classes, called MechController & MechCamera, and put them in my own project's scripts directory. That way I can modify these classes to my heart's content, and not worry about messing up the originals. And modify them I will!

So I added the new controller and created a very simple animation controller that just contained a single blend tree for the robot's motion that had two states - idle and walk. I then added the necessary parameters to the animator for the controller to be able to work with it. Set up all the pieces, and pushed the play button. And nothing. Well, not exactly nothing, but not what we want either. The mech animated correctly (mostly), and would turn, but wouldn't walk at all. Time to dig into that controller and take control. So to speak.

Root Node Motion

So it didn't take too long to figure out the problem here. Unity's Standard Asset 3rd person controller is heavily dependent upon root node motion animations. So what does that mean, exactly? In a typical motion & animation set up, the avatar's movement is determined by external forces, and the animation state is derived from the movement. So user inputs get turned into velocities and rotations,, the velocities & rotations are fed to the animator, and it blends to the right animation state. Your animations are all animated in-place, which is to say the root node of the model doesn't translate in anyway through the animation.

In a root node motion animation system though, the animation drives the movement. Movement animations, such as run and walk, actually translate the root node of the model through the duration of the animation some distance. Inputs are fed into the animation, the animation blends to the correct state, the model is translated some distance through the course of the animation, and that distance is fed back to the simulation, which updates the actual position of the avatar. So in brief, typically motion drives animation, but in root-node motion system, the animations drive motion.

Which is right for you?

For just about as long as I've been making games, at the beginning the project, we have this discussion. Root node animation movement, or standard movement animation? The artists always want to use root-node animation, as it provides the best linking between animation and movement. Your characters no longer slide, or rotate in place, or move about in any way without a one-to-one sync with an appropriate animation. The programmers & designers though inevitably want to use a standard motion system, because there are so many things that can drive character speed, and they want complete control over that, and don't want to funnel it through the animation system. In every game that we started out attempting to use root node motion, we eventually abandoned it, and returned to the traditional method of movement driving animation.

What am I using?

Well despite the preponderance of evidence I have from my own game development career, this is, as I've often said, an experiment. And I'm kind of interested to see if I can make root node animation work. There's only one problem. The animations that came with my mech pack don't have movement built into them. They are in-place animations. Remember what I said earlier about your assets driving your design? Yeah that.

But as it turns out, there is a poor-man's way of rigging a root node motion derived system onto in-place animations. You can do it through a curve. Unity allows you to add arbitrary animation curves to any existing animation. If you create a parameter in the animator with the same name as the curve, the values of that parameter will be driven by the curve values during the playback of the animation. So by creating a float parameter called WalkSpeed, I could vary this parameter through the duration of the walk cycle to more closely resemble what the mech was actually doing during that animation. Then in the callback provided by the animator, I can query that parameter, and turn it into a velocity applied to the avatar's transform. Viola! Crude root-node animation!

WalkSpeed Curve
for the walk animation

Of course, my first guess at these values was absolutely terrible. The values were nowhere near correct, plus I still needed a speed scalar to actually get the mech moving. The mech looked terrible turning in place, as there are no in-place turn animations (and the walk anim really wasn't suitable). So this is where you cue the tedious and incredibly time consuming task of tweaking values, adjusting equations, watching the results, and repeating to get what you want. I spent pretty much an entire Saturday morning doing exactly that, and in the end finally settled on an animation curve and movement speed scalar that provided the best variations for both the walk and the run cycles that produced the least sliding. But I wasn't done yet, not by a long shot.

Acceleration
So I had the mech's walk & run motion looking pretty good, when it was at full speed. But it still looked wonky going from rest to moving, and then returning to rest. After thinking about it a moment, it occured to me that the sudden shift in movement value was the culprit. The input controller returns a value from -1 to 1 along the vertical axis (forward). But when you're using a keyboard, it goes immediately, in a single update, from 0 to 1. It was slightly better with the gamepad, but still you tend to just jam the stick forward when you want the player to move, so it largely produced the same results. So going from rest to full speed created all kinds of problems. The feet slide all over the place as the animator tries to blend through three animations over the course of a few updates. This is a mech - it's not meant to go from rest to full blast in a single update. We needed an acceleration factor, so that no matter how much you jammed on the forward vector, the mech would take time to get up to speed (and conversely, time to return to rest). Not only does this make the mech feel better, but it gives the animation system time to blend through all the animations in a satisfying manner.

At first I tried applying the accleration directly to the physics equation on the animation callback, where the actual motion is set. The first version of this had the unintended but hysterical result of causing the mech to shoot off into space, sailing over the edge of the platform and plummeting to oblivion. Fun, but not really desired. I also realized that this was a bad place to modify the movement, because it would adjust the speed after the animation, which meant the animation couldn't take advantage of it. That is, I was directly undoing the work I did in setting up the root node animation to begin with! No, for this to work right, the dampening had to occur on the input side, so that it was fed into the animation, so it could adjust appropriately.

Once I realized that, it was a pretty simple change. Instead of taking the forward motion value directly from the input value, I made the forward motion value interpolate over time to the desired input value. I then added an accleration scalar into the equation, so we could have some mechs accelerate faster than other mechs. This worked perfectly! The last piece to handle was turning in place. And I decided that these mechs just don't turn in place. My move controller (remember, borrowed from Standard Assets) allows an "at rest" rotational speed, and a "moving" rotational speed. It calculates the current turn speed by interpolating between those two values by the current value of forward motion. By setting the at test rotational velocity to zero, the mech doesn't turn if it's at full rest, but as soon as you start moving, you can turn. I like this effect. It's a mech. If you want to turn, you need to get it moving.

Final Blend Tree for the Mech

Walking Backwards
This turned out to be a tougher problem than you would think to solve. At this point, my animator only interpreted forward motion values from 0 to 1. If you haul backwards on the stick, you get values that range to -1. So I modified the range of values for the blend tree to accommodate a range of -1 to 1. But what animation to play when walking backwards? I don't have a "walk backwards" animation. I tried just playing the walk cycle animation, but ugh, it just looked terrible when the mech was trying to move backwards. Plus, when moving backwards, I noticed the mech kept trying to turn sharply in one direction or another. This was a mess.

You've probably already figured out what I needed to do here, but I'm not always terribly bright. So I thought, well maybe these mechs don't walk backwards. Maybe when you haul backwards on the stick, they move forward, but try to turn sharply about. So I tried this. I set up the animator to use the walk animation from -1 to 1. From -1 to 0, the blend would play the walk animation only though - it wouldn't blend to run. The rotational value was already trying to calculate a turn from forward to 180 behind you, but dampened by the rotational acceleration, so as soon as you started moving by hauling back on the stick, the mech would immediately try to turn around.

So, this worked pretty well, in that it had the desired result. But there were still two problem. The first, was a design issue - in that in this mode, every time you wanted to back away from an opponent, your had to turn your guns off the opponent. You could argue this is a good thing - makes you think about turning away! But I had a feeling it would drive players crazy. I think it would drive me crazy. It also just felt unnatural. Mech battles are, for better or worse, often two mechs standing toe to filling each other up with rockets and lasers, while slowly backing away. But design considerations aside, there was another issue. When you pulled back on the stick, and the mech started to turn and move, it would accelerate. But then as you got turned around, and the camera swung about behind the mech, you would naturally shift from pulling back to pushing forward. Well this would cause the input values to vary from -1 to 1. But because of our own acceleration parameters, this would cause the mech to slow to a crawl, and then start to accelerate again. That meant as you turned 180 degrees, and then started to move forward, you couldn't maintain speed.

Set the animation speed to -1 to play the anim backwards!

So, this wasn't terrible. I played around with the mech like this for a long time, and had just about decided that was how it would work. But I really wanted it to walk backwards. So I went back to the animator one more time to see if there was something I could do. And it was there, while scrubbing through the walk cycle, it hit me. I just needed the stupid walk cycle to play backwards. If I played the walk cycle backwards during the backwards movement phase, it did exactly what I wanted! Surely there was a way to specify to Unity that I wanted to play an animation backwards? And it turns out, there was! In the blend tree parameters, there is an animation speed value, that defaults to 1. You can adjust this to make the animation play slower or faster during that phase of the blend. And if you set it to -1, it plays the animation in reverse! Perfect!

So by now it's time to skip to the end. That was the key to getting walking backwards working correctly. I damped backwards movement by half, so you can only move at walk speed going backwards (not running). And it took me awhile to figure out how to adjust the turnspeed amount when moving backwards so the mech didn't immediately try to turn about when you pulled back, but that was a pretty simple change as well.

Multiplayer!

Multiplayer Again
The last thing I did was to also convert this project into multiplayer, like I did for the Terrain project. It was a relatively simple process, now that I've done it once before. I had one gotcha where nothing would move over the network because I forgot to add the NetworkTransform component to my mech avatar. Turns out that's pretty important.

Mechs in Motion
At last, I was really happy with my mech's movement. It rests comfortably in idle. Jam forward on the stick, and she moves out, matching the animations really closely. Turn left and right, and she turns with you, slowing as you turn, which is perfect. Let go of the stick, and she rumbles to a rest satisfactorily. And haul back, and she slowly moves backwards, and you can turn her left and right as she moves. I love it! Man, all I need now are guns!

Here's a video of our finished mech in motion:

Next!

I'm in crunch at work this week, so who knows when I'll get a chance to work on the project again. I think the very next thing I want to add are sound effects. Our mech just isn't a mech until it sounds like one. That will mean a trip back to the asset store, undoubtedly. After that, I think I'm happy enough with camera and motion to start thinking about weapon systems.

Until then, if you have any questions for comments, please leave them below. Here are some useful links:

Mech Constructor Pack

This is the asset I used for the mech models and animations

Scripting Root Motion Animation for "in place" Animations

This was the tutorial I used for figuring out how to get my poor man's root motion animation working

Unity3d At Home Project
The master blog page for the entire project

Unity3D At Home Project - Day 6 - Multiplayer

noreply@blogger.com (Dusty Monk) — Fri, 30 Oct 2015 13:34:00 +0000

So as you've probably come to realize the "Day" in the title really isn't significant. I could be "Issue", or "Section", or "Chapter" if you like. It's really just a way for me to designate each subgoal within the project. And that's really important - subgoals. When you're making a game, the entirety of the game itself can be incredibly overwhelming. Menus, scores, multiplayer support, weapons, animations, the list goes on and on and on. And a lot of times you're going to be thinking - what next? How do I get it all done?

Your ability to compartmentalize your game into sections - and more importantly - systems, is going to be one of the most valuable skills for you to develop. Pick out a specific section of the game, decide what the goals are for that section, and implement it. But all of the pieces of the game are intrinsically interconnected. And most pieces build upon some other piece. Which is why it's not only important to decide which section you're working on, but what order are you going to build the sections of your game. For instance, I wouldn't spend a huge amount of time focusing on building a level in my game until I had a better grasp on the gameplay - because those things are going to shape level design.

The next section piece of our game puzzle I wanted to implement was basic multiplayer. Now - that word, all by itself, is still a whopping tall order, so I needed to constrain it even further. Specifically, I wanted to be able to have two clients in the same game together, and be able to run around, and animated correctly. And as you'll see, in the end, Unity made that frighteningly easy. In fact, it will probably take me longer to write this blog than it did for me to get it up and working. But first things first. Let's talk design a bit.

Multiplayer Architecture
Multiplayer architectures come in a variety of flavors. One is peer-to-peer. In this model, all actions are synced across all computers connected to the network simultaneously. It's extremely important that everything be replicated in exactly the same way. The Age of Empires games were written this way - there was no dedicated server in a multiplayer game. The downside to this model is that it is extremely easy for one machine to become out of sync in its game state with the other machines, and to not realize it. I can't tell you the hours we spent at Ensemble tracking down exactly those kinds of bugs.

These days, most everything though uses a client-server architecture. One machine is authoritative for the game state at all times. Clients make requests to the server, and are informed of other client's actions on the server, and update their game view appropriately. However, even within the client-server architecture, there's a couple of different ways to go.

One method is to use dedicated server. This machine runs and maintains the game state for all of the connected clients, but doesn't run a client itself. The other method uses a host client. The host client serves as both server and client on the same machine. Other clients connect to the host client, and have the game state replicated back to them. This architecture, of using a host client, has some advantages and disadvantages.

The biggest advantage is that games can be played anywhere there's a network. You don't have to have a dedicated server running 24/7 to serve games. If two people have your game, they can connect to each other, and immediately begin playing. Furthermore, anyone that knows the IP address of a host client machine can connect to that machine, and join in. It allows for the greatest flexibility and ease off play for a casual game.

However, there are quite a few disadvantages as well, when there is not a dedicated server. First of all, as you can imagine, in a host-client multiplayer game, the player that is running the host usually has a bit of an advantage, just in sheer terms of latency and response. His machine actually is running the simulation - his client is going to get updates the quickest. In this day and time though, with bandwidths being what they are, this is not typically much of an advantage. And if your game is turn-based, or completely non-latency dependent, it's not an advantage at all. But the biggest disadvantage is that you, the developer, don't control the server. So this means no account systems, no persistence, no way of saving game state sessions from game to game. It also makes it pretty much impossible to prevent hacks and cheats from entering the game, if you're not hosting the servers.

For those reasons, if I were doing this game "for real" - that is, to make a business off of it, I would almost certainly insist on a model with dedicated servers. And pretty much most games these days that have any multiplayer component do exactly that. Hell, some games that even aren't multiplayer still require you to connect to a dedicated server, just for authentication and account purposes.

But this game is an experiment. And is as much an exercise in exploring technology as it is about making something fun. And one of the pieces that I want to explore, besides Unity's basic multiplayer capabilities, is their matchmaking system. And at the moment, their matchmaker currently only supports host-client multiplayer architecture games. Now let me be perfectly clear. I'm not saying Unity's multiplayer architecture doesn't support a dedicated client-server model. It absolutely does. But their matchmaking service, currently, only supports client-host games. Furthermore, if you did want to build a dedicated server, though they have announced plans to eventually do so, currently they do not provide hosting for that server in their cloud services. That means you either have to run the server yourself, or find some other cloud hosting service (like Amazon EC2) to host your server for you.

So, for all of those reasons, we'll be using a host-client architecture. Now, this decision is extremely important, because it dramatically shapes the nature of our game design. No dedicated server means no persistence beyond any particular game session. No accounts, no logins, and perhaps most importantly, no real means of monetization through in-app purchases or microtransactions, This pretty severely limits your means of monetizing this game to either doing so outright purchasing (and quite frankly who buys games anymore?) or in-game advertising. That means, if I were really intent on making this game make money, I'd probably be better suited making it a mobile app. Fortunately, I'm not too worried about monetizing this game at the moment - as I've said, it's an experiment - but these are still really important things to think about when making your game.

Unity Multiplayer
So in truth, I probably spent more time reading over Unity's multiplayer documentation than I did actually setting it up in my game. And because it is so well documented, I won't go into the API in detail here, but I will touch on a few highlights. Unity's multiplayer api is provided at two levels. The first is a low level, network transport layer that provides socket management, messaging, and serialization functions. The second layer is game-ready high level api (HLAPI) that provides a full suite of tools at your disposal to handle all of the most common multiplayer chores, including state synchronization, client commands and RPC calls, lobby services, spawning, and even, as mentioned, matchmaking services. And it is my intention to take full advantage of the HLAPI.

Setting it up
So what did we have to do, actually, to get it working? Well as I said, it was surprisingly simple. Unity 5.2 provides integration of their cloud services right into the editor, so the first thing I did was register my project with the multiplayer matchmaking. Now, I haven't even taken advantage of any of that part of the multiplayer system yet, but I am registered!

Unity also provides a template for converting your single player project into a multiplayer project, which was actually pretty useful. The biggest shift that comes with converting your project to multiplayer though, is going to be your shift in thinking. Up until now, you just thought about "the game", and everything is happening in "the game". But now, you have to think in terms of the client and the server, or both. Does this action happen on the client only? On the server only? Both? And more importantly, if this code is controlling some game object, like the player, is this code running on the player that I personally am controlling, or is it running on a player object that someone else is controlling, and how does the code know the difference? And that is where Unity's API comes in, as it provides a good deal off state information for all of those cases.

So the first thing I did after registering was to make the collection of components that now defines our player (Kyle the Robot!) was a prefab. I then modified his controller script by deriving it from NetworkBehavior instead of Monobehavior, and attached a NetworkIdentity component to him. That makes him Network aware. The HLAPI provides a drop-in Network Manager class to oversee the multiplayer system as a whole, and you just drag your player prefab right onto the manager to let it know what the player is.

Now I only want the player control code to run for the local player (my player), as his movement information will be replicated by the network api to the other clients. So I wrapped the gathering of user input and modifying his movement based on that input inside of "IsLocalPlayer".

Remember my shitty camera? Well the camera control is a client-only object, so I didn't extend it from NetworkBehavior. However, it can no longer be directly attached to the player object, as the player object will be spawned by the multiplayer system. So I wrote a little code in the Player Controller's OnLocalPlayerStart callback routine that finds the AvatarCamera in the scene, and attaches it to the local player, so it can follow it around.

And that was pretty much it! With that little bit of code, the player was successfully getting spawned, controlled, and movement being replicated. And the camera followed it around correctly! One thing I noticed was that the animation wasn't getting replicated to clients. But lo and behold, Unity provides a NetworkAnimator component that you can attach to your player prefab, give it a reference to your animator component, and it will handle replicating the animation state for that object to the clients. And it just fricken' worked! Unbelievable!

So, success! It took me less time to get multiplayer up and running in my project than it did to set it up on GitHub - no exaggeration. Sometimes thing surprise you.

Want to try it? Another fun thing I learned about was GitHub releases, where you can attach a set off binaries to your project for people to download and use, so issued a "release" of Unity Terrain. I'll provide a link to the game down below. I mean, right now, there is literally precious little to do execpt to connect, and run around each other, but it does work. And if you have any questions or comments don't hesitate to leave them below. Next time - we start over with a new project, and we talk asset collection!

Useful Links

Unity Multiplayer Overview
A nice overview of Unity's multiplayer system, straight from them.

Converting your Single Player Project
A template for converting your single player project into a multiplayer one.

Unity-Terrain Release
Download the binaries off of GitHub and give it a try!

The At-Home Project
The master blog page for the Unity At Home Project

Knights of the Fallen Empire - An Introduction

noreply@blogger.com (Dusty Monk) — Sun, 25 Oct 2015 22:09:00 +0000

So last week the early access for Star Wars - The Old Republic's new expansion - Knights of the Fallen Empire kicked off. And with this expansion Bioware has delivered not only an amazing new chapter (nine chapters, in truth) in their portion of the Star Wars universe, but a host of changes to the game's core mechanics as well. So I thought, beyond the story itself, I'd take some time to introduce returning players and new players to some of the interesting changes released in the expansion.

On Spoilers
While I've tried very hard to not reveal any specific characters or plot points from the story, some of the screenshots and discussion of the content after the story will be, by its nature, mildly spoilerish. If you're fanatical about having a completely pristine experience your first play through of the game, feel free to return to this post after you've finished the nine chapters of the story. If however you just want to know about the expansion and don't mind a screenshot or two that might reveal this or that character that you will encounter, please read on after the cut!

And so it begins...

The Story
Of course though, the first thing, and absolute most important thing that has come out with the new expansion is the incredible new story for your character. If you enjoy Bioware games at all, and you like Star Wars, I can heartily recommend the story to you. In fact, it's worth picking up the 60 day non-recurring subscription solely to play through the story, even if you're not a fan of MMO's. When you subscribe, you receive a token for a free level 60 character. So you could get your level 60 character, go to your ship, and immediately start the quest.. Which I highly recommend, as it's easily the best content released for this MMO so far. And that, is all that I have to say about that!

Contacts, Followers, and Alerts
Once you finish the story, you'll find yourself in a new hub, which provides a welcome respite from the Fleet. And more importantly, you'll be introduced to a new kind of content - Alert Missions. While you still have companions, just as you have in the original game, you will find you have a network of contacts as well. And these contacts will provide you with a variety of different missions, while you'll receive alerts for in the new contact interface. The alert missions reward you with locked supply crates, which can be turned into contacts for both a collection of rewards, as well as influence with that contacts. And that's the main difference in the new system - not only do you earn influence with companions, which can provide buffs and improvements while accompanying you, but earning influence with contacts will provide you with new levels of missions. All of this - the alert missions, your list of companions and contacts, and the influence you've earned with them, are tracked through a new follower interface, shown on the right.

Beaming About
One new feature that is certainly worth mentioning is that Bioware has made it exceedingly easy to get to and return from these new alert missions. You can teleport instantly to the beginning of an alert mission (no matter what planet it's on) through the contacts interface. And upon completing the mission, you can teleport back to the contact of interest, through the same interface. In fact, I'm of the opinion that it's almost too easy to beam about from planet to planet now, but there's no denying the convenience. And I don't think any of us miss trudging through Spaceports.

Classic Conversations
Something else that's new - most of the contacts that you interact with, use a conversation system that is reminiscent of Knights of the Old Republic. You may love it, you may hate it. But I understand the reason for it. The classic conversations, in which the NPC has voice over, but your character does not, provides a nice compromise in a quest delivery system that is more interactive than a standard quest panel, but is not quite as expensive to produce as full blown cinematics for each and every alert mission interaction.

Heroic Missions & Flashpoints
Once you finish the story, you'll be introduced to a new collection of Flashpoints. I won't discuss the fiction behind them, but they are offered in a solo mode, and then a follow up in Heroic+2 mode. Now you might be thinking - oh great - more Heroics. But all of the heroic's in the game now have been converted to Heroic +2's, and all have pretty much been tuned to be soloable with a decent companion. And you don't have to gear your companion - they just get better with more influence.

Classic Flashpoints
So besides alert missions, and the new heroic+2 flashpoints, the group finder now has a ton of flashpoints available, which are tuned to be completed by any group of 4, which means that the queue times are almost never bad, even for DPS. Great, casual, fun group content that can be completed in about 30 minutes sessions.

Gearing Up
SWTOR's commendation system is still in force, though the commendations have been replaced with data crystals. But it's direct one to one replacement. Common crystals get you 208 rated gear, glowing crystals get you 216 gear, and radiant crystals get you 220 rated gear. The same things that earned you commendations in the original game still get you crystals in the expansion: flashpoints, dailies, and story mode operations.

So Much to Do!
In short, it should be obvious that SWTOR's done a great job of providing you with quite a bit to do once you've finished the story. A whole network of contacts and associated missions, flashpoints, heroic missions, all provide you with something to for just about every style of play. All of the original flashpoints now provide a solo-able version, and you are now auto-leveled to whatever planet you are visiting. This means that even if you're bored with the new content, any of the old content you skipped over while leveling can now be returned to, and it will drop relevant gear and crystals for your level! And of course there's PvP dailies and warzones to earn new gear for as well, if that's your thing.

As you can see, I'm pretty pleased about the wealth of content for this expansion. I'd reached the point in SWTOR where, outside of PvP, I really felt like was only repeating of story mode operations by way of content for me to do. And now, it's like getting an entirely new MMO to play in, and that suits me just fine.

Unholy Alliance & Wookie Mistake Gaming Guilds are all in for Extra Life - Check it out!

noreply@blogger.com (Dusty Monk) — Wed, 14 Oct 2015 13:10:00 +0000

One of the very cool grass roots movements that's taken hold over the past few years, and really grown, is the Extra Life movement. If you're a gamer at all, you already know what Extra Life is, but in the odd case that you don't, essentially on a certain day gamers from around the globe promise to play games for 24 hours to raise money and awareness for children's hospitals. It's a fantastic effort that raises thousands of dollars for children's illness and hospitals. If you'd like to learn more about Extra Life, and maybe participate yourself, please check out their website here.

Sadly, my schedule is such that I rarely can afford to spend an actual 24 hours myself participating, but I try to assist in some way by sponsoring and promoting those that do, however I can. And as you may or may not have noticed, while my blog doesn't get nearly the attention it should from me, I am pretty active on teh social medias - especially twitter. As a result, I've had an opportunity to form friendships and relationships with incredibly cool folks and organizations that participate in a wide variety of gaming. And especially of late, that has mostly been centered in and around Star Wars the Old Republic. One of those folks I've had the pleasure of becoming acquainted with is Stardust Legacy, (follow her on twitter at @UnholyAlliances), and her SWTOR guild & gaming group Unholy Alliance.

And Unholy Alliance is going ALL IN for Extra Life Day. Multiple marathoners, tons of events, all in all it sounds like a heckuva great time, and of course, all for a great cause. So while I personally won't be able to participate in Extra Life day, I will definitely be watching (and sponsoring!) some of the fine folks over there, and I absolutely encourage you to do the same. Here's the scoop!

You can check out the information directly at their website they've set up for the event here. Please give it a link, and come game with the fine folks at Unholy Alliance on Extra Life day this year!

Unity3D At Home Project - Day 5 - Unity Update & Version Control

noreply@blogger.com (Dusty Monk) — Sun, 04 Oct 2015 13:39:00 +0000

So wow, it's been a few weeks since my last update. Let's see, first I am pretty much swamped at work, and unfortunately things are only going to get more swamped. And there was a trip to Boston for three days to attend the Unity Unite conference. But that was a good thing, because coming back from Unite I feel re-invigorated about Unity development in general, and had a host of even more things that I wanted to try and do.

So let's refresh. Currently, our At Home project is still mind numbingly simple. We have a brain dead camera controller, we have a character controller, and an animated bipedal humanoid. We've created some terrain, set up a skybox, and laid down some grass & trees. It looks like something, but it's far from being a multiplayer robot-shooter, as promised! So along those lines, the next step I think is to set up multiplayer for the project. Support for multiplayer is going to create an entirely new infrastructure layer for the entire project, and just about everything else we do will sit on top of it. So it's best to get it in and set up early, and the start building on top of that.

But before we even go that far, I had a little prep work to do. I needed to do two things - one was upgrade to the latest version of Unity, and the other was to set up some sort of revision control.

Unity Upgrade
So why upgrade? This is actually a bit of a departure for what you would do in a commercial project, so I can't necessarily recommend it for your own work. Typically in a project, you might upgrade once or twice during the early stages of development, but pretty soon you want to lock in on a specific version, and stay with that. Why? Because each time you upgrade the engine, you introduce the possibility of new errors, new changes to the way things behave, and in general it's a level of instability that you have to deal with. So you have to weigh the cost of dealing with whatever instability the upgrade brings against the value of whatever features it provides. And as you get further into your project and get closer to shipping, the cost of any instability, no matter how slight, is usually not worth the risk.

Unity's Cloud Services

But because this is an experimental project, and the whole point of this project is to learn about and play with some of Unity's most recent features, I've decided that for this project, with each new major version they release, I would I turn, upgrade to it and roll it in. So as I was currently at 5.1, and they'd already released 5.2, I needed to upgrade. And 5.2 brought a whole host of fun new things, most notably the integration of all of their cloud services directly into the editor. So things like Analytics, Cloud Builds, and yes, even some of the multiplayer stuff, can all be accessed directly from within the editor.

Remember what I said about Upgrades?
So yes, even though this was an upgrade of only a single sub-version, and my project literally consists of only stock assets from Unity, after upgrading to 5.2, there were issues. All of the trees in my terrain suddenly had blocky leaves, and I was getting errors from SpeedTree about invalid materials. Now these are just stock assets, I didn't set them up, and I don't know jack about how they work. So a little bit of google-fu later, I learned that all I needed to do was revisit each material in turn, and click the "Regenerate Material" button for each asset, and resave the scene. That did, in fact fix the problem, and shortly our project was back to normal, and now running under Unity 5.2. But just tracking that problem down and getting it fixed took the better part of an evening. So caveat emptor - do not take any engine upgrade lightly.

Version Control
I'm not going to dedicate much time in this blog to describing what version control software is, or why you need it. There are a ton of guides out there, and every piece of software has it's own collection of beginner's tutorials. Linked below is a very nice overview and introduction, if you're not terribly familiar with the concept. I will though add this thought. Even if you're a one person team, working on only a single game - you need version control. It shouldn't be considered an option, or a nicety. It should be considered mandatory. And here is why.

Even if you're a single person working on a project, version control software gives you the freedom to try dangerous and experimental things with your code. To go down an alley just to see if it pans out. And if it doesn't, you always have the previous version of the code to roll back to. And this is really important.

So as we were about to add the multiplayer layer to our game, and this is going to significantly increase the size of the project, I decided now was the time to get some version control for our project set up. And the first, and probably most difficult decision to make, is which software to use. For me, initially it wasn't even a question. I'm a Perforce guy, going back for years. Just about every project we've built at Robot (and Ensemble before) used Perforce. And when I spent two years working on my own project at home, I had a Perforce repository set up. It works, I'm familiar with it, it's free - just get it in and working.

But Perforce through me a curve ball this time, and in so doing, it opened up an opportunity for me to branch out a bit. (See what I did there? Jeesh.. programmer humor.. it's the best) See, the latest version of Perforce's software - Helix, puts its evaluation copy inside of a VM machine appliance. And, quite frankly, its a huge pain in the ass, and is a terrible barrier to put between their software and someone who just wants to try it out. The first thing you have to do is download and install some other piece of software - Oracle VirtualBox, or an equivalent, to host the virtual machine. Then you download their 1.2 GB appliance, and import the appliance into their virtual machine. Which means now you're running a virtual machine, a server inside the virtual machine, and that has to run continuously on your server computer - which is probably also your development computer. But to make it worse - for me, it just flat out wouldn't work. I got everything installed and set up correctly, but try as I might, the browser and client software simply couldn't see the server. And after three full mornings of jacking with it, including rummaging through firewall settings, installing on two different machines, etc., I had lost all patience to mess with it a moment more.

So my next thought was, well screw the evaluation VM appliance, let's just install their production server, and set it up. But then I thought.. wait a minute.

So as I've said, I've been a Perforce guy since day 1. But there are of course a ton of other solutions out there. And I've dabbled with Git, and SVN on a few other, previous occasions, but never really given them much of a try. And I kept hearing on the wonders of distributed revision control, and more importantly, seems like everyone is hosting a project on GitHub these days, so maybe now was the opportunity to learn something more about these, and set this up in the cloud. So that is what I - somewhat begrudgingly, I have to admit - did.

Git & GitHub
So you can just set up plain 'ol Git on your host machine, and host your own local repository, and check software and code directly in and out locally, if you wish. And if you do so, I can assure you it will be no less arcane. Typing cryptic command line commands into Git Bash will have you feeling like your Neo and it's gawddamn 1995. I kept expecting the command line cursor to suddenly start typing on its own to tell me to follow the White Rabbit.

But the GitHub site has a desktop client you can download that does a nice jot of hiding Git's squirrelly commands away from sight, and lets you set up a local repository, and keep it in sync with the remote repository at GitHub. One detail to know about GitHub, and this is an important one - the free GitHub membership only allows public projects. So unless you want to pay, your entire project will be downloadable and viewable to the public at large. I understand that if you don't want your project to be public, BitBucket provides a suitable, online repository that is private, and supports up to 5 collaborators.

So with a relatively short amount of time (a few hours, in total), I had my repository set up, and my Unity project hosted within it. I made a few small changes and tested some commits, and everything seems to be working swimmingly.

And that's that! Not only do I now have version control set up for my project, but I've made it publically available for you to download and peruse, which is in keeping with my desire to make this project more open. I'll provide a link below directly to the repository.

Next time I'll get back to work on the game itself, and hopefully the next blog you read will be about how successful or not I am with integrating multiplayer directly into the game.

Some useful links:

The Unity3D At-Home Project on GitHub
The increasingly inaccurately named Unity-Terrain project on GitHub

Introduction to Version Control
A really nice overview of version control.

Basic Git
If that's your thing.

GitHub Windows Desktop Client
Providing a nice interface between GitHub and your project

Beginner Unity Basics #20 - GitHub and Version Control
And excellent, concise tutorial for setting up your Unity Project on GitHub from Frosty Gaming. Good stuff.

Unity At Home Project
The Master Blog Page for the At Home Project

Unity3D At Home Project - Day 4 - Basic Animation

noreply@blogger.com (Dusty Monk) — Tue, 01 Sep 2015 00:44:00 +0000

Busy weekend, busier week, but I did manage to sneak in a little bit of time on Sunday to play around with simple animation, and to get our avatar animated.

You may recall last week I wasn't sure if I was going to dig into the barely functional camera controller some more, or start working on animation. I decided to skip any more work on the camera controller for now namely because, as you recall, ultimately I want this to be a giant robot game, and I'm thinking robots with turrets, and I'd want the camera attached to the rotating upper half of the mech. Additionally, we'll be using a 3rd person shooter point of view, and until we get a crosshairs on our hud, and some weapon systems, there's not a lot of point in fine tuning the camera. So let's get Ethan animated, instead of just gliding across the terrain.

Well the first thing to realize is - I didn't use Ethan. See, the Ethan prefab that is provided in the standard assets is a great resource. In fact, it's a little too good, as it has a lot of stuff preconfigured already, and that was exactly the stuff I wanted to configure myself. To learn what those components are, how they're set up, and how they related to each other.

Learn
So the first thing I did, and I did this part at periodic points throughout the week, was to start getting familiar with animation basics in Unity 5. To be precise - humanoid animation basics. And I started that by just working through Unity's own tutorials, and even reading the manual.

Introducing Kyle
So as I mentioned, Ethan is a bit too far along for our purposes. I really just wanted a straight up humanoid mesh. I dug around the asset store, and found Space Robot Kyle. Kyle is from Unity tech itself, and has been around since, forever. Most importantly, he's a simple, skinned mesh, and a material. In other words, he's perfect.

Creating an Animator, and an Avatar
So I got Kyle imported easily enough, but it still took a bit of work to actually get going. I created an empty Animator controller easily enough, but I was having trouble creating an Avatar to associate with the model. I would go to the rig tab of the model view, set Avatar Generation to "Create from This Model", and click "Configure", and nothing would happen. Eventually I learned a very important lesson. And that is, if you have your Unity inspector in debug mode, about half of the automated inspector tools Unity provides for you around animation either don't show up, or don't work.

Finally, when I turned off debug mode, and clicked configure, it loaded up the Avatar Configuration scene, and allowed me to configure the bones. Not unsurprisingly, the bone mapping and muscles were pretty much exactly correct.

One interesting side node. As soon as I generated and applied the avatar to my mesh, the existing mesh I'd placed in the world view took a 90' turn to the right. I suspect applying the avatar mapping will even reorient your model if need by for it to align correctly with mecanim's bone system. Fortunately, deleting the previously placed one and dropping a new one into the game had him nicely oriented.

Animations

Now I had an animator controller, and an avatar associated with my model. It was time to actually hook up some animations. This part wasn't too difficult. I only wanted to do some really simple stuff: Idle, Walk, Run. Double-clicking on the Animator Controller in the project view brings up the animation sequence editor. Unity provides a pretty sophisticated system for sequencing and blending animations, and if you've ever worked with animation sequencers before, this will be quite familiar. But Unity does a great deal to automate the process for you, including an ingenious method of setting up 1 and 2 dimensional blend trees with many animations. To the left here you can see my very simple blend tree I ultimately ended up with for Kyle.

But what animations did I use? Well I used Ethan's. And that, really is the key point here. Unity's mecanim system makes it ridiculously easy to mix and reuse animations from other models. See, back in the bad 'ol days, all animation files moved bone positions around by explicit bone names. That meant that the skeleton of your rig had to exactly match the names of the bones that were used when the animation was created. Which is why all the legacy models you buy at the store come included with some animations. And if you wanted more animations, you had to make sure they were built specifically for the model you were using. Mecanim though democratizes this process, and makes it stupidly easy to rig, and use animations from other sources. And yes, I know this is all over Unity's mecanim promotional literature. But there's a world of difference between reading a feature set, and actually being able to use that feature.

Final Touches
In any event, before long I had a functional, if simple, animation tree built. I added my controller script to Kyle, pointed the camera at him, and launched the game. He animated perfectly while idling.. but.. he didn't animate while moving. Oh duh. One more step - get a reference to the animator, and update the animator parameter values (in this case a whopping one - ForwardSpeed) through script. Oh hey now he works!

One tweak I noticed right away was that he didn't animate backwards. Stupid me, when I initially set up the blend, I set the thresholds from 0 to max forward movement speed. Well this doesn't account for moving backwards. I adjusted the blend tree again to account for negative speeds, and limited his backwards moving speed to be limited to half his forward moving speeds. Overall, pretty pleased, and not bad for what was about a single night's work. Here are the results.

This is the fourth segment in an ongoing series wherein I build a game from scratch in Unity3D. If you'd like to read the entire series, click the Game Development tab above, or just click here.

Unity3D At Home Project - Day 3 - Basic Camera Controller

noreply@blogger.com (Dusty Monk) — Tue, 25 Aug 2015 13:17:00 +0000

So I finished off Renaissance Coder's character controller tutorial (you can find it here) with implementing a basic camera controller. And by basic, I mean really basic. You give it a target, and it slaves its position to the target, plus an offset that you give it. For orientation, it just interpolates from its current orientation to that of the target. Even though it was a fairly small piece of code to write, I still learned a few interesting things, and had some hiccups.

Cool Things

Mathf.SmoothDampAngle
This does rotational interpolation for you. You give it a source value in radians, a destination radians, and some time values that determine how fast you want the function to interpolate towards your destination. It returns an updated angle, and also modifieds a turn velocity float that you can use in successive updates. Really handy function.

LateUpdate
I'd forgotten about LateUpdate, but this is an update function that occurs each frame after normal Update and all of the FixedUpdates. By updating the camera position and rotation in this function, we ensure it happens after the other updates.

Hiccups

My initial offset for the camera position had the sign of the Y offset reversed, which placed the camera somewhat inconveniently underground. While cool and interesting, wasn't exactly the effect we were going for.

The other thing I noticed immediately after my first test was that the camera was still facing straight ahead - not actually looking at the player. The tutorial had mentioned an X-tilt factor, but had failed to ever actually hook it up and use it. I converted the value to radians, applied the rotation to the target's X rotation (which is always straight ahead), and then used the editor to adjust the value until we got to something close. What was interesting was that when I changed display resolutions, the amount of avatar in the camera field of view changed. Which goes to show you the kind of BS you actually have to deal with when building a real camera.

You can see the functional camera below.

Notice my gravity quotient is way way too low, so when I go sailing off the tops of hills, I only sort of gently float back to ground over time. Also notice even the leaves of the tree have collision, lol.

What next?
Well I'm not 100% sure. The camera controller is functional, but only barely. There's no orbit control, and there's no collision. But building a robust camera controller can be a pretty dark rabbit hole - correclty and intuitively handling camera collision is a non trivial task. So I could leave the controller alone, and move on to animation. But by the same token, the current camera is by no means near adequate, so we'll have to see.

Unity3D At Home Project - Day 2 - Simple Character Controller

noreply@blogger.com (Dusty Monk) — Tue, 25 Aug 2015 02:40:00 +0000

So the Standard Assets pack comes with a 3D character controller right out of the bag. And it's fairly functional - does everything you want it to do. In fact, it's actually a little more complex than I want for first pass. Their 3rd Person character controller contains separate components for the Controller, an Input Controller, a Camera Controller, and an Animation component, and contains code to handle interactions between all of those.

I'm trying to put pieces together piece by piece, so what I really wanted, to start with, was just a very simple character controller. Renaissance Coders YouTube channel came to the rescue, with a great, nofrills character controller you can code up in literally about 20 minutes. You can find their tutorial here.

This allowed me to get a simple, functional character controller up in the afternoon, and I completely understand all the pieces. I also added a capsule collider to my avatar mesh (Ethan), so he would collide with the trees as I moved him around. Once I added the capsule collider and set it's offset appropriately, I could turn on gravity on the RigidBody.

One other interesting thing I learned here was that you need to freeze rotation on the rigid body in all three axis. The first time I tried to move poor Ethan, he fell flat on his face, and then I could only move him up and down. We have zero tie-to-ground code here, so if the unit runs up against the tree, for instance, it only slowly moves back down to the ground, based on gravity.

This controller is super simple, and there's a billion lines of code to write here for it to become an game-ready controller, but it fulfills our purpose of being able to move the unit around.

Here's a video:

Unity3D At Home Project - Day 1 - Terrain

noreply@blogger.com (Dusty Monk) — Tue, 25 Aug 2015 02:25:00 +0000

I wanted to start with a simple terrain, using stock assets. Worked my way through a three-part tutorial, creating and sampling along the way. Stock assets provides a nice small sample of terrain textures, trees, and grasses. Very limited, but enough to play with.

Terrain was created, and I played around with the height tools, and foliage creation tools. Biggest disappointment was that I see no way of doing height-limited painting. I'm sure there are some third party tools that provide that, but it was a nice default feature in Torque. I dropped in Ethan, the stock character, for reference.

I also created and set up a light procedural skybox. Options are available for three different kinds of skybox, but the stock assets sadly don't provide any skybox-ready textures.

Ethan - Lost in the Weeds!

Unity3D At Home Project - Introduction

noreply@blogger.com (Dusty Monk) — Tue, 25 Aug 2015 02:11:00 +0000

So, I find myself at a curious point in my professional career. By now, you probably know (or should) I'm a game developer. I work at Robot Entertainment, where I get to work on some pretty fantastic games. Right now, I am the Project Lead for the dashboard. The dashboard is the application you use to launch the actual game. It handles all your inventory, your decks, provides access to the store, etc. In short, it's a pretty darn big project in and of itself, and its written entirely in Unity. As I've been working on it for over 15 months now, I've become pretty proficient in Unity. But, the dashboard is an application. And while it's got some very game-like aspects to it, it is not, strictly speaking, a game in and of itself.

So as such, I find that while I've become pretty darn familiar with building an application in Unity, I know almost nothing about its core game systems. I know, right?

It's been some 4 years now since I released Atomic City Adventures, and during that time, I've not done any at home game development, save for what was needed for work. But I've been itching more and more of late to actually sink my teeth into some honest to goodness game systems, so have finally decided I'd work on something small at home. Of course, you know me - I can never do anything small.

The Goal
The goal is, in short, to get familiar with some of Unity's game systems. I know plenty about Unity - but I don't know much about making a game in unity. But Unity is a big engine these days. You could spend months in it and not become familiar with all the pieces. So I need to settle on some core ones. Here they are:

Terrain - I know a lot of games these days don't even use terrain any more, but Unity has a terrain system, so I want to know how it works.
Character & Camera - I want to drive a character of some sort around, and have a camera that follows it. Basic stuff.
Animation - And by that, I mean character animation. Specifically, the Mecanim system.
Networking - Unity 5 has introduced an entirely new multiplayer/networking layer. I'm itching to dig into that and try it out.
Gamepad - I've taken a shine to playing games on the XBox One. For a change, I'm going to actually be design towards usage with a gamepad, as opposed to mice & keyboard. And no, don't even talk to me about mobile.

Stretch Goals
If we get really industrious, there are a few other pieces I might like to dig into:

Physics - I'm thinking about destructible objects and models, most specifically
AI & Pathfinding - I haven't decided if I'll mess around with AI yet or not, but it's kind of ironic that I spent most of my professional career doing pathfinding and movement, and aren't event attempting to mess with it here.

The Game
I spent a lot of time thinking about the game's design. Whole minutes even. Here it is:

Drive around in a giant robot and shoot things.

I know right? Genius. But that's what I want to do. Specifically, if I can lean back in my chair, drive a giant robot around with big guns, and shoot another player that's also trying to shoot me, I'm going to call the game a success. Anything more than that is gravy.

And yes, I know I can probably download an entire kit from the Asset Store that does just about all of this for me, but the object is for us to get familiar with Unity. Not to get familiar with someone else's code that is already familiar. So in order to ensure that, I'm setting the following restriction on myself for the project:

The asset store is to be used for art/content assets only.

That is, models, animations, particle effects, explosions, textures, etc. But all game systems, we'll build ourselves, or use what Unity 5 provides us.

And that's about it. I've already started, but now you know what I'm doing, and why.

The Girl with the Golden Gun

noreply@blogger.com (Dusty Monk) — Wed, 15 Jul 2015 12:39:00 +0000

So I've been at 60 for a bit now, and wanted to change up the look of my smuggler Kaytte. I saw someone in Fleet the other day that had built an entire outfit with pink and white, and found a speeder that matched in color scheme, and it looked really sharp. Thought I might do something similar. So that sat me down the task of surfing Tor Fashion, and other SWTOR transmog sites, to see what was available and where I could get it.

And that's when I learned customizing your appearance in SWTOR can actually be really challenging. Much more so I think than in WoW. For instance, most of the best vanity pieces are only available through Cartel Packs - crates you buy at the F2P store, and offer a random selection of goods. And the Cartel Packs themselves are rotated in and out, so at any given time, even if you want to roll the dice on an RNG crate, the one you need may not actually even be currently available. That's when I realized my carefully planned mog probably wasn't going to be doable at the moment.

But I still wanted to do something, and I had some cartel coins burning a hole in my pocket, so I used Dulfy's excellent guides to crate contents to pick out the kinds of crates I wanted, and bought a half dozen. No mounts or pets, sadly, but I did pick up some vanity armor pieces I did like, including this chest piece and gloves.

I started rummaging through my rather voluminous closet of stuff I've kept for forever (I try to keep at least one look of just about everything I come across) to find suitable pants, belts, boots, etc, to go with this top. OH - and blasters! Oh but the thing about weapons - you can't change their appearance. Most of the best weapons are moddable though, so you can still use just about whatever weapon set you want. But as I looked through my weapon collection, I realized it would be better to build a appearance around a particular set of blasters, rather than to try to find blasters to fit a look.

And that's when I noticed I had a lovely matching pair of double-barreled gold blasters. At the time, they were way too flashy for my current look, but if I built an entire look around them.. well, we might have something!

With weapons selected, I set about picking out the other pieces, and then spent time on the GTN looking for a suitable white and gold dye module. Dye modules tend to be expensive, some going well over 6 digits in price, but I found a nice yellow and light grey set for about 50K. Spent even more money on matching crystals (after all, it wouldn't do for my gold blasters to fire green bolts now would it?), and even more on a matching speeder. And then to top it all off, I had a customization kit for my HK-51 droid that was all silvery and retro-futuristic looking, so I applied it as I thought it went well with the look.

And thus, the Girl with the Golden Gun was born. I'm actually quite pleased with the results, I find her appearance to be someone reminiscent of Emma Frost - and that ain't a bad thing.

I took some tips from Ravalation's blog on taking action screenshots in SWTOR, and let me just tell you, the game doesn't make it easy. Pick on enemies too easy, and they die before you can even get set, much less rotate the camera. Pick on enemies too close to level, and you'll find yourself mauled to death while you're busily snapping photos. :) But I managed to get a few good ones, so here they are.

Now that I've settled (for now) on her appearance, I really should probably get around to collecting those datacrons..

Operation Overhaul!

noreply@blogger.com (Dusty Monk) — Sat, 11 Jul 2015 13:49:00 +0000

See I did a little thing there in the title - did you see what I did? Oh nevermind. So this week the Bioware developers put out a blog talking about what they're doing with instanced content in the new expansion, and holy smokes it's a lot! They're essentially overhauling their entire system. And they also say that there will not be any new operations or flashpoints for said same expansion. Ostensibly because they're, you know, overhauling their entire system. So of course if you look at the discussion thread for that blog, you'll find what at current count is a 58 page thread, mostly filled with hate and discontent, regarding the fact that the there won't be a new instance. There's kind of two interesting discussion topics here, so I'm going to talk about them a little bit, separately.

I find the SWTOR community - interesting. Maybe it's because I'm on Ebon Hawk, a roleplay server, but by far and large I find the community in game to be fantastic. People are mostly helpful, there's very little racist or hate talk in general discussion, and PUGs mostly tend to be filled with people that are there to have a good time. It's part of the reason I'm still playing the game.

But then I go to the forums and read a discussion like this and it's just page after page of vitriol and hate. I'm reminded again of why I visit forums so rarely these days. And, I think there's an entire blog to be written (not this blog, today) about cultural change, and how it's up to us to initiate that change. It's us to us to choose a tone of discussion that isn't so grounded in absolutes, that isn't always phrased in terms of "If I don't get this I quit". I know there's a tendency to believe that "well, because forums of large communities have always been filled with hate, they always will be.." and there's nothing we can do about it. But I've lived long enough to see real cultural shifts happen. When I grew up none of us wore seatbelts, and everyone smoked in their offices. These days, just about everyone wears a seatbelt, and no one smokes in their office anymore. And if you'd asked me as recently as ten years ago if gay couples would ever be allowed to marry in Texas, I would have said absolutely not. But cultural shifts can, and do occur. I don't know how to make forums less filled with hate, but I suppose I can start by not practicing that behavior myself. And asking you to do the same. And asking you, in turn, to ask everyone you know that - when it comes to giving feedback to developers - let's all try to be a bit more.. civil.

So let's talk about the instance changes! Personally, I love them. To understand why, you have to know something about the kind of gamer I am. First, I really don't consider myself a casual gamer. Now, I do enjoy a casual game style, but make no mistake - I play a lot. In fact, just about every single night I'm in one or another MMO of choice. And even though I am often playing alone, I love group content. I want to be able to do 4-man and 5-man instances, and to even participate in raids and operations. But I don't have the luxury of a permanent gaming group to play with. Partly because I move around so much, and partly because pretty much all of my gaming friends do too! So we're constantly in a state of coming and going from one MMO to the next, occasionally crossing paths, but rarely being in the same game at the same time for any length of time.

In short, I'm a hard-core casual gamer that plays alone that loves doing instanced content. And, as it turns out, there are millions of other players just like me. Bioware realizes this, and they're laying the foundation in this expansion to allow players that play under these circumstances to get the most out of their game. Which I think, is awesome. Let's look at the changes.

Solo Flashpoints
Fourteen different flashpoints (the classic, story-mode flashpoints) will now have a solo mode. This means, I can fight pretty much at-level, regardless of my actual level, all the story mode operations I couldn't find groups for as I was leveling. And yes, you could technically do this before, but you were so crazily overpowered that I found it boring. Boss mechanics are just swallowed up in the vaccuum of overkill, and you still have to wade through waves of trash either way. This keeps those fights interesting. And even better, now if you are progressing through your story, you can do every one of those instances *at* level, either with a group if you can find one, or without, if you prefer not to.

Tactical Flashpoints
Tactical flashpoints are fantastic. The're the equivalent of skirmashes in Neverwinter, or Guildhests in FFXIV. They are tuned to be completed by four people, and pretty much any four classes will do. This means queue times are pretty much instant. Fourteen of the previous flashpoints will now have a tactical mode. Tactical flashpoints will also bolster you to the appropriate level, so you can pretty much start doing all of them as soon as you get to level 10. Again, a ton of group content there for you to experience, pretty much regardless of your level.

Hard Mode Flashpoints
These requires a 4 man, normal group (ie tank and healer) and there will be 24 of these available to you at level 65.These are most of existing flashpoints, but with their difficulty tuned up to be challenging at level 65. But seriously - 4 man groups. You know you'll be able to find groups for these, and don't have to worry to much about not finishing them.

Operations
Their will be both 8 and 16 man operations, and they'll all be available in either story mode and hard mode. And a different storymode operation will be in the group finder each day. Story-mode operations are the equivalent to WoW's LFR instances. End-game content, tuned to be completed by a pickup group of the appropriate number of players. For a player such as myself - this is perfect. This means, in one way or another, I'll still have an avenue to see all of the content in the game.

So.. much.. stuff
I completely understand why the progression raiders and people at the very end-game portion of this game are unhappy. But Bioware is I think, making the exact right steps to put their end-game mechanics in a position to work well over the long term. You know there will be more operations to come. But the fact that Bioware is doing this fundamental restructuring is a much more positive sign for the game's life than if they'd just cranked out another operation. It says they're planning for the long haul. That they're doubling down on the game, and they see it continuing to grow and expand for years to come.

And for me, right now, I couldn't be more thrilled. I know that when I hit the level cap after the expansion drops, there will still be a ton of stuff for me to do with my character. And if I find a group or guild to do it with, all the better. But even if I don't, I won't be shut out of the best content in the game.

So until the expansion is released.. I'll be waiting patiently..

Buyer's Remorse

noreply@blogger.com (Dusty Monk) — Fri, 03 Jul 2015 15:00:00 +0000

I don't often fall prey to the whims of my crowd, but I'm beginning to suspect that's what's happened here. I've returned to FFXIV, and picked up the new expansion. Everything is exciting and new, and I should be happy as a clam. Except.. it isn't, and I'm not. So.. what's going on here.

As you know, I've been bouncing around a bit from MMO to MMO, once the shiny wore off of Draenor, and I found was feeling hemmed in by my own garrison. And it really wasn't so much of a I'm searching for the next best MMO kind of thing, but really more of a there's a lot of cool shit going on in many MMO's right now, and I want to check that out! thing.

So for about the last six weeks or so I've been playing Star Wars the Old Republic, and really enjoying it. My smuggler Kaytte has climbed her way all the way to 60, and she'd completed all of the current main story - right through the Shadow of Revan, She wasn't totally geared up yet, but gearing wasn't too much of a problem right now anyway. Also she'd earned a nice bank of credits, buying and selling things on the GTN. Point being, while I wasn't neccessarily feeling done, per se, I did feel like I'd reached my original goals for the game at the time - which was to make it to level cap and see the story all the way through.

And all the time I've been playing, I've also been eyeing FFXIV. See, FFXIV is an excellent MMO. This much I know for fact. I played it a little at launch, then came back last summer when they had a free weekend, and stuck with it pretty much all summer, leveling a Bard all the way to 50. So it was, just about the time I reached 60 in SWTOR and finished the main story, FFXIV officially released the Heavensward expansion. Oh my.

Now, if there's one thing I've learned from experience, it is that if you're thinking of returning to an MMO, the time to do it is when they're having a major event - such as an expansion launch. Many people will be returning, and they'll be a great uptick in population - and that uptick will likely only really substantially last a month or so. You want to ride that wave of returning pop. Queues will be faster, group events work better - and everyone is experiencing the new content at the same time you are. It's like a partial reset of sorts, and it's best if you experience it with everyone else. So I decided - HEY, you've reached the level cap in SWTOR, there's a new expansion coming out for FFXIV - now's the time to check it out! So I did.

I patched up FFXIV, and jumped in and logged into my bard, and was greeted with that familiar "returning to MMO feeling", which is to say, I was staring at three hot bars full of buttons and couldn't remember much about what any of them did, or the order in which I should press them.

Now, I was aware of the Heavensward expansion, and had watched a few of the teaser videos, but that was just about the extent of my knowledge about it. I did know you had to have a character at level cap to experience the new content, but I had that, so I wasn't too worried. Shortly after logging in and running around a bit, I went ahead and navigated the maze of Square Enix account sites to purchase the expansion, so I could patch it in, and start leveling my way to 60. And of course, all the best in game goodies came from the collector's edition, so nothing would do but to get that edition!

Now, being greeted with a hotbar full of icons I didn't recognize, I decided to ease my way back into the game by way of switching jobs to rogue, which wasn't in the game the last time I played, and was one of the things I wanted to check out. The nice thing about FFXIV, is you don't have to re-roll a character to start over, you can just switch jobs with the current one, and get the same effect!

So I set about leveling rogue, and remembering how to play the game. It wasn't really grabbing me, but I know that leveling low level alternate jobs is pretty a pretty grindy affair of running fates and bland side quests, so I wrote it off to that. Also ran a few low level dungeons, had a pretty good time, and before I knew it was 20. Time to switch back to my Bard and start in on that expansion content!

So Kayette switched back to Bard (where clearly she's happiest), and I started running some fates, and did a few low level dungeons, to get back into the swing of her rotation. She was currently stuck at Garuda in her story. Mind you, I still hadn't done anything with the new expansion yet, but at least I was earning XP towards 60. I used the Duty Finder to tackle Garuda, downed her without too much difficulty, and we were on our way again, making progress on the story. Surely there wasn't too much left to do right?

The thing was, the whole time I've been playing, I still hadn't really recaptured that feel. I couldn't explain it, but the game just wasn't grabbing me. I felt kind of a malaise at running fates, and working my way through the story missions felt - bland. More than anything, I suspect it was a matter of aesthetics over mechanics. Coming from SWTOR's excellent, fully voiced in-game story cinematics, to FFXIV's mostly unvoiced cinematics, where the full extent of your character's interactions with the NPC's is to nod in the affirmative, felt - well, a bit anticlimactic.

But I soldiered on for a bit, progressing a bit more through the story. But at this point, I began to wonder in earnest, just how far did I have to go on the main story, before I could actually start seeing some of the new content in the expansion. And that was when I realized.. goodness.. it turns out, quite a bit. See, while I am actually only a few short instances from finishing the original vanilla story, you have to finish all of the other expansions stories as well, before you ever set foot in Ishgard. And it turns out.. that is a lot of content! Dozens upon dozens of missions and instances. And, if the was giving me the feels, I'd wouldn't mind a bit. But sadly, for whatever reason, it just isn't. As I'm progressing in quests, mostly I felt like I should be checking in on m smuggler's GTN sales, and learning how to run operations with her!

So, just out of curiosity, I logged back into SWTOR. And had more fun in 30 minutes of play there than I had in the last 2 weeks of FFXIV. And that was when I thought - What are you doing? Like it or not, a mistake has been made here. Whether it's just the difference in presentation of the missions, or maybe it's just the thought of the weight of fully re-engaging in another MMO right now, when I just got well engaged with my previous one, was too much to bear. But right now, the thought of progressing through all of those FFXIV missions to see the quote-unquote new content (let's be honest, it will all be new to me) isn't compelling me. So I think you'll be seeing a return of the SWTOR screenshots in my morning game sharing time on twitter.

You'll forgive me if I wax parent-ish a bit here, but it feels like there are two lessons that I knew already, but clearly needed to be re-reminded of. The first, is to remember to not throw good many after bad. I was feeling compelled to force myself to play FFXIV because dammit, I did just spend money on the expansion, and by god I need to get my money's worth! But the money's gone, and if you're not having fun, are you really getting good use out of it anyway? And the second - and far more important, is for the love of god, research an expansion before you buy it knucklehead!