Gaming Your Way

May contain nuts.

A trip to the hair stylist

More character overhauling. 

I decided to test a short hair look and I found that I really like it (and I don't have to animate the pony tail as an added bonus)

 

 
I also finished combining the different maps into a single 2048x2048 one (well one for diffuse, specular, gloss and bump) - thank fuck there's something like UVWxform that allows to offset UVWs via numbers instead of having to move the UVWs by hand. I also fixed the eyelashes and moved them into their own texture (as they are the only part that needs alpha).
 
-- olli

Overhauled main character - or isn't there something else to do?

When you look at a game character every fucking single day (like during my daily 2h indie dev time) it gets harder to ignore things you don't like every time. First these little things just annoy, then they piss you off.

One of these things was the game's main character's low poly version. I used auto-reduction purely because it saved a few hours of manual polygon reduction. It's quick, but it almost never works well enough. So last week I started to rework the low poly mesh and then added some more time to give the whole model an overhaul. The result not only looks better, but also saves 1k polygons ...

Not that it really matters considering the size the character is shown in the game (or that anyone would notice).

Here are two more comparison images, hands and the jacket:

 

I know I should be working on the code side of the game and finally adding the goon back in (which will get an overhaul as well), but it is good to have that out of the system.

Speaking about systems, I still want to do a post about the minimalistic FSM thing I wrote for the game (to replace the clumsy pseudo FSM like construct I was using so far) - well next time.

-- olli

Light and shadows ...

I'm not sure I mentioned it, but setting up lights (in 3D) is an art form (even with today's "click and done" tools and global illumination). Even more so in "realtime 3D", when you have a very, very specific idea of how things should look.

AgentZero (or AZ for short) isn't different there (did I mention that the prototype finally has a name?).

My original plan was to be able to light each room (as I would do for rendered 3D) to get the light *right*, but of course there is no such a thing as "right" when setting up the lights in Unity. The first bummer was the fact that even with shadows turned on the lights shine "through" the scene, ie. when turning off a light on the first floor the room below it would become darker too.

So I ended up separating rooms with layers and "exclude" lights, so the lobby would be layer "RoomA" with the lights limited to that layer and the first floor would be moved to layer "RoomB", while the second floor would use "RoomA" again (as there was enough distance, so the lights didn't shine through).

This shows the old lights in action, with 3 spots per room there where 12 in there, plus the spots in the elevator and behind the doors (which are turned off when the door is closed).

Due to the nature of the beast there are only so many lights Unity handles well, setting the important ones to "important" helped a bit, but the nail in the coffin was the new "Restroom" room. When opening the door some annoying flicker showed (when the light was turned on behind the door). I may have been able to work my way around that, but I decided to overhaul the light completely and reduce the number of spots a LOT.

The new lights in place, it got a bit brighter and it lost a good deal of depth, but not to a degree where I would have cursed and shouted. Instead of using spots I went for 2 directional lights - one main light and one fill light to light up the edges. On the plus side I still can exclude rooms from that and add individual lights there (think dark passage), I need yet to find out if I can change layers at runtime, but if not I find a way around that.

The lobby with the new lights (not as bad as I feared either).

I'm toying with the idea of adding a light that moves with the player to recreate a bit of atmosphere, but for now the light has to stay the way it is now.

... and with this I'm going to continue coding the handling of the WC stalls.

-- Olli

Slight change of direction ...

During the last couple of month the prototype game changed a lot and I entered a state not unlike "full production mode" (just with less time to actually work on the game).

This is what it looked like the last time I posted about the game (because, let's be honest, the last post was fucking ages ago):

The most obvious thing changed is the map:

As you can see, it moved away from the platformer style to something room based, the elevators were moved into the back (instead of blocking the path) and there are no goons in there (yet).

It started easy enough with the idea of removing the gun from the player and introducing the "hiding" mechanic, I also started to dislike the way the goons moved around "randomly" (the reason why I wrote a  pathfinder based solution). Also some of my early playtesters mentioned that the mechanics weren't quite working as well together as I thought (something that had dawned on me as well).

Once the old map was gone it wasn't that hard to settle on the room based map and add the mechanics that suited the slower pace, just to realize that I made a full circle with the game idea (and a round trip of about a year). Mechanics wise the game is more or less the same as the one I first started over a year ago, just the visuals changed from top-down/iso to fake-2D:


Right now I'm exporting some new rooms in order to add some more features (cameras, laser gates, etc.) and later get the goons back in, but this time with less freedom to move around (for the most time). Mostly they will be used as guards (patrolling a set area), but some may walk off and explore the map on their own.

Last image in this post is the "Elevator Cam", which ended up in there because I needed a new way to control the elevators from the inside:

And with this I'm going to export a restroom.

-- Olli

ps: There are more frequent updates on this on (my) twitter (@nGFX, link on the right) as it is sometimes easier to just write 5 words and post an image.

Unity, Mecanim ... the easy way ... for dummies ... like me.

If you happen to be old enough to know a world without youtube and like the written word (like a tutorial), tough time for you.

So if you want to learn, say about using Unity's main animation tool Mecanim, but also happen to *HATE* tutorial videos (because they waste your precious time) you're in deep shit. I'm not saying that Unity's tutorial videos are shit, but watching 30 minutes of someone talking away for an information that fits on 2 lines of written text (and maybe a screenshot) ... well, you get my point.

Fear not, we have written words (and screenshots)

Let's start by wasting some space with the basic problem: You have a character, animated him (or her) and want to use it in Unity. I might need to point out that I'm NOT using Blender (so things may be a bit different for you, but the basics still apply).


That's Violet and the odd 850 frames needed to animate her.

Let's fast forward the export and import process and jump right to the part you'd do if you haven't watched any tutorial video on setting up anims or re-targeting them in Unity.

After you're done setting up the animation clips you might end up with something like this:

(taken from a character that needs updating)

In a way you're set and can start setting up the animator's state machine, but what if you change the model or need to update / change the animation? Well you end up re-creating all the clips. Joy.
After the second time it becomes some sort of a curse.

Oh my.

If you have at least read the Unity manual on this (which is [again] very much lacking useful examples), you should know that you can re-target animations between models that share the same bone structure. But you may have (like me) overlooked the fact that this also solves the problem of re-doing the clips over and over again when you update your character.

Exporting the character to use with Mecanim

(This headline is just there to ensure google finds this post)

This process might be a bit more work when starting, but it saves a shit load afterwards. Let's start with exporting the "base" (and NOT animated character). In my case I select the skin and bones and hit "export selected" and get this dialog:


I should have exported the base model in T-pose and without animations, though (makes it easier to create a ragdoll).

Anyway, that's done, go to Unity and import and setup the base model:

Note that there are no animations to be imported.

Exporting animations and setting them up in Unity to be used with the base model (and re-target them)

Now it's time to swap the tedious process of setting up the animation clips in Unity with the tedious process of exporting the animation clips from our 3D app (although, this is the by far better choice in the long run).


The trick is, that this time I only select the bones when clicking "export selected" and the important part of this dialog is "bake animations" and the option to give a start and end frame (hint, hint). 
Actually, you could of export the skin again, but there really is no need to do so.

And after (what felt like an hour) I've got my clips exported and in Unity.

Preparing for re-targeting the animations

The tutorial video needs about 17 minutes to explain all that shit, but we can get the important information from a single screenshot:

When importing the animation, we copy the rig from an existing model (the base model) and click apply. Now set up the animation clip by changing to "Animations" and because we only exported the needed frames it's just changing the name from "Take 0001" to something meaningful (and maybe go over the other options of the clip, like looping).


That's it. Now you can just setup the animator state machine as before. Violet's looks like this right now:


Viola! A bit of text, some screenshots and no need to watch 30 minutes of video. Mhm, but then it took me about 2 hours to write this ...
... I think I better start making videos. 

-- Olli

New Test Level and Goon AI

Fuck funky headlines. So I said it.

Today's post is all about ... the new test level and new goon AI (mhm, maybe back to funky headlines?).

Let's start with an image:

The old test level with two elevators and some searchable objects (grey boxes).

While this worked well enough the random / percentage based goon AI it didn't look good on the new test level. One reason might have been the way I've dealt with entering/exiting the map. In short the goon wanders around until he reached the number of steps he should do and then takes the next exit he comes across. For the smaller test level this was OK, but with the much wider new level this revealed some problems. Due to the random nature, goons sometimes would just walk back and forth between a door and the elevator until it reached the required steps to exits again.

This made me rethink the way the goon walks around and I settled on the idea that it would (and does, comes to that) look better if the goon has a predefined path to follow. 


The new test level, also shown is the potential path I want the goon to follow and the new elements.

Of course this added some more things to think about, most obvious is that the goon needs a path to follow once an entry and an exit have been assigned.

As Unity comes with a nice built in NavMesh, I tried to get away with that...

... and as soon as that was in, it showed that this won't work "out of the box".

To make that story short: it works just fine as long as you can work with a continuous path, but the different floors and the elevators proved to require a lot more work than I was willing to put into. One of the "easy", but tedious solutions were using Off-Mesh Links, so the NavMesh Agent would know how to reach the different floors. As far as I found out (prove me wrong) there's currently no way to create Off-Mesh Links on the fly via code.
Creating those by hand in the editor would have made a brave man cry (I gave up after a few). For each elevator, one link between the left and the right side and for every floor AND every side, so for a 3 floor elevator: 15 Off-Mesh Links (if I counted right). 

Erm. No.

Time for plan B.

Plan B was easy, just create nodes for my a* graph based pathfinder. 

Well, creating nodes was easy, as I already had a lists of all doors, elevators and the other stuff. 

Connecting these is a different story (in a way that makes sense). Until now the map elements (which the goon could interact with) only stored the current "block" (needed later when blocks will be combined to build a bigger level) and I really didn't want to add a "connected to" list or a "floor".

So the (nasty) solution was to read out the coords and store these in a PointInt3D (my simplified int Vector3 version) by multiplying the position by 10 and reducing the y value to the floor (ie. 0, 1, ...). 

For instance an elevator creates X nodes (yellow dots, one for each floor): like [0,0,0], [0,1,0] and [0,2,0]. While I'm at it, I also connect these (so the floors are connected, too).
Then I looped over all floors and and created a temp list of the elements per floor, this list would then be sorted using the x value and viola ... all nodes per floor in order from left to right. Now simply connect Node[i] and Node[i + 1] and the floor is connected. As I had created the links between floor earlier, creating the complete graph (red lines) was a no-brainer.

Of course it isn't quite as easy as this, just look at the map and notice the green line marked "No! No! No!". I fixed this by .... well let's just say it is a dirty trick...

The path (blue line) is created by a simple "Pathfinder.GetPath(StartNode, EndNode)".

How the goons deal with that is for the next post, as this one is already long enough.

-- Olli


Sibling Rivalry and How to Stop It

Having three goons running around, but only a limited number of elevators is calling for trouble. So in order to make that work ("Only one goon per elevator, please"), we had to come up with something really clever (well, almost).


The first obvious option might have been to make the goons talk to each other and let them decide which of them will enter the elevator. Not the easiest solution and there would have been a lot of back and forth between the goons just to make sure they talk about the same elevator.

The second option was a central piece of code that sorts goons and elevators, group the ones belonging together and then decides which one will enter the elevator (not a piece of cake either).

Luckily, option three is just what we need, it's almost clean, it is simple and if it fails it sorts out itself after a while.
Last post I mentioned that the goons look ahead and "decide" what to do with the target (doors, walls and elevators [and player]), so we use this to lock the elevator as well.
I added a simple flag ("claimedBy") to the elevator code (which makes them move up and down) and that was it (OK, not quite, but mostly).

With this in place, only a few things needed to be added to the goon's AI:
If a goon "sees" the elevator and the elevator is not currently claimed, the goon claims it.
If the goon decides to turn away from the elevator after he claimed it, the elevator is released. If the elevator is already claimed by another goon, ignore it and check again next step. If the goon is killed, check if the elevator needs to be released.
That's it.

Let's code these shiny UI icons and make them work, too.

-- Olli

Google Chrome (v42+) and the Unity Web Player

As much as I like the Chrome browser, google sometimes annoys the crap out of me for playing the web police.

If you're greeted with this:

 
when doing a quick test built for friends (using the unity web player), try this in your url bar:
chrome://flags/#enable-npapi
Activate it and don't forget to click "restart now".

Not a pretty fix, but hey ...

-- Olli

Go left. NO! Not that left, the other left!

Let's start with a screenshot of the recent game prototype:

The testbed for the goon's AI.

Even though it's only 2D, there's a lot going on to let the goons walk around the map on their own. Handling their normal way is easy enough, it is just looking ahead 2m and then decide what to do next (mostly broken up into multiple random chances).

If the goon sees a door, it is set as next target and he start walking into that direction (although there's a check every now and then to see if the player can be shot). After he reaches the door there aresome things to decide:

  • Have we reached the max number of steps (90% chance of using the door to exit the stage)
  • if not, there's 10% chance of an early exit
  • ... and a 5% chance of turnung around
  • otherwise pick the next target
Doors are easy.

Elevators on the other hand trigger a lot more possible actions (heavily simplified):

  • Is the elevator on the same floor? (and is it empty?)
    • Enter, pass or turn around
  • otherwise:
    • is the elevator coming towards our floor (90% waiting for it)
When the goon is finally in the elevator there are still a lot of things to check:

  • are we heading towards the player's floor? (keep going until we reach him)
  • no? (chance of riding another floor or exiting the elevator)
  • are we at the top or the bottom (90% chance of getting off, but which way?)
  • ...

Here's an image of an early draft for the goon AI:

And the first playmaker based version (I since moved that over to code)

The code version is in a way easier to maintain than the playmaker version, but also less easy to track when you want to know what's going on.

And with this, I need to get back to the goons ...
--Olli

And on the 8th day I created a mini-map.

With this title in place, I don't think I have to write much about the technical details, do I?

I read an interview a few days (or is it weeks?) ago (forgot who was interviewed) and one of the things that were said was something like "mini maps are a lazy design choice". Maybe.

I still needed something like that in the prototype game, one reason is that it shows where things are, but I don't want to show a map. In reality it works more like a radar, but honestly who is going to search for "game development" and "radar"?

...

And here ends this post. I got myself a new PC, you see. Seems like I now got most things set up and running again (I could have just migrated my old stuff, but I do like a fresh start now and then).

Well, tomorrow is Monday, so it's time for a new post anyway and I try to push it in between some very serious deadlines.

 

-- Oliver / nGFX