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

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

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

Decision Style #4: Activity-Focused Design

I'm still awe and wonder about what shit comes up when you search for our post titles. This time it's a tech-talk-bullshit gem.

Anyway, it's time to get going with the prototype game and start piecing together all the little tools written so far. I mentioned it on g+ already, but I reached the point where I needed more than my usual ToDo list to keep track of what I want/need to do next.


Just a small part of my "map helper"

The first map I used for testing was quite big and complex and with some 20 rooms and even more doors a bit - shall we say - shit to keep track of. So I invested 2 hours to make a smaller map, then rendered it out and drew my notes on it (making revisions on paper is a bit messy after a while).

Color coded rooms help to maintain overview and layers in photoshop make it incredibly easy to keep track of items to place and doors to connect. Right now I'm placing these in Unity and wiring things up to be able to do a "play through" with the main objectives: find docs (USB drives), codes and key key cards and avoid being caught.

The next thing on my ToDo list however is the minimap, which wont show you the location but items, guards and cameras (and their "senses"). With that in place it's finally time to add security to the map.

Maybe I should add a trigger for the exit first so I can have a "well done" screen up and running (and make it feel more like a game than a pure game mechanics test bed).

-- Oliver / nGFX

I AM NOT YOUR F1 BUTTON!

Code won the game.

This only makes sense if you've read last week's post about FSMs. At some time during clicking and dragging states and trying to fit my idea into the corset of the FSM, I figured I need to write my own actions to make things worthwhile. So I started to write my own action. The problem is once you start writing your own, you need to find a point to stop and expose values to the FSM (that can then fetch these and pass to the next action ...).

With this working quite well, I came to the point where I needed to pass more than a single string or float, but my own class with data (or I had to pass a set of values) and suddenly the beauty of this new toy (the FSM and it's supposed easiness) started to fall apart. Years of coding took over the show, brain cells kicked into crunch mode and in an act of fury I deleted the FSMs from the game. A good deal of hours fiddling and working against instinct paid it's price and code once again won the game.

A few hours later the door control was coded and working, multi language ready, too:

 


Tooltips and control hints up and running and talking to each other via SendMessage, so no links in code are needed.

The interface for using the tooltips is unified and based on "Items" that carry a name, a set of actions and "results" (inspired by classic adventure games). So the Control panel right of the door has the "Item" component attached, it is also linked to the door (to request the door's state). In the image above the door's state is "locked" and the action for the control panel is "unlock door". The result is a new door state: "closed" and a changed action on the control panel "open door", plus the control hint is being updated.


I need more time...

Of course opening a door using a code (or hacking it if you don't have the code yet) takes time, this is also handled by the item, allowing to set a time these action needs to be performed - from 1 sec to a few minutes (it also handles if the time should reset if you leave before the task is performed).

Searching items is done as well, so if you search one of the blue boxes you find the key code for the door and can use it.

Next on the list are guards and the security cameras with these in place the map will be more or less playable and can be dressed for a quick game.

But that's for next week's post.

-- Oliver / nGFX

Now with "Realistic-looking flames and colors" ...

... now that's the thing you want to read on an artificial fire log.

Prototyping stage.

I've been hammering out tiles over the last couple of days to be used in the prototype of my pet-project game I'v started. This time I'll try something different and do a very basic prototype first (before jumping right in and doing full fledged 3D models before even knowing if the idea is valid)

Though, I must admit that I couldn't resist and make the tiles just a wee bit more pleasing to the eye than plain grey-boxed ones...


Busy building the dummy map ...

As dummy maps go, this is a fairly bigger one than what I would normally do for level 1, but it's also a testbed for all the things to come. Mainly guards, cameras, locked doors and drawers to search through.

Unlike the usual pointless bullshit I write every week I have something helpful in mind for the next post ... something about culling and exporting stuff ...

-- Oliver

And then they said that burning the secret documents ...

... only made things worse.

See, all the good intentions are gone by now - that is having the weekly post done before Sunday, well at least it's not 23:52h.

Although I have a good reason as I haven't worked at all for two days straight, trying to get my laptop back to work. In theory it would have been a case of just restoring the last weekly backup, but alas ...

I'm using a Dell, you know, running win 8.1 pro (64bit) with Intel Rapid Storage (magically using a SSD and a HDD mixed up for speed), Intel onboard gfx and an additional ATI Radeon card for 3d / games. I mention this because this combination is the the reason for the two wasted days (although, it's partly my fault).

The whole mess starts with me noticing that the Catalyst Control Center wasn't running (so no choice which card to use), as I had that earlier (when running still running win 8) so I knew that I just needed to install the latest ATI drivers again. That done and a reboot later the only thing I got was a black screen and a flickering cursor. What followed was a lot of cursing, because after I used a "recover to last working version" I ended up with a clean win 8 install and just a few of my settings and none of my programs left.

Ha! No problem, I have a backup that is just one day old.

To cut this short, in order to get the OS partition restored I needed the following: change boot mode to legacy (UEFI by default, to run the linux based frontend of the backup software), turn off the Rapid Storage/RAID settings in BIOS in order to access the HDD and write back the partition. With this in the recovery only took about 30 minutes, great that there's nothing to be found about this on the interwebs ... and you only come to this after 2 days of "can't this", "error that".

Oh and I had to install the ATI drivers provided by Dell in order to make things work with win 8.1 ...

... now lets's start with this week's post.


Yes, I used that image before.

I mentioned that the HUD in MTR is far from ideal or even "pretty", too much information, too small and not helpful. One of the tasks on my list therefore read "redesign HUD" and this post will go through some of the iterations that the HUD went through.

The information I wanted to show was: car, position ( the badge icon), lap time/total time and boost (the battery). Once the race is running, having 4 pairs of changing numbers is quite a bit much distraction from the track.


Iterations of the new HUD.

As you can see the icons changed quite a bit and all of the icons that were used as labels are gone now, too. 

The final HUD comes in two flavours: horizontal (for smaller screens) and vertical (for larger screens):


Default view for larger screens ...


... and for smaller ones.

The latest version adds a hint of color to the backgrounds of the badges (using the car's main color). The position is now shown by the order of the badges, the local player is marked by the orange line (color may change). It also brings back the battery icon, well sometimes, but that's for another post ...

More next week,

-- Oliver / nGFX

#addlistoftrendinghashtagshere

It's Sunday again, although for a change it's not 23:45h while I'm writing my weekly blog post.

I guess I mentioned last week that the lazy days are over and I have to get back into the joyful pace of client work. Last week I started to setup a new client site and the racing game came back to haunt me (and it needs finishing too, if possible before the end of the year).


Website layout.

The sceengrab above is what we got as sitemap for the client website. We spent a few minutes wondering about how to turn that into a website and then settled on the idea that we just use that. To our surprise it pleased the client extraordinarily - which in turn pleased us. It even pleased me, until I started to imagine how to build this and not use an image / image map (which, let's be honest, would be a moment I should quit my job).

So I set it up as a combination of css3, canvas and javascript to make it as dynamic as possible. There's all the latest shebang hover effects (like highlighting connected circles and lines), transitions (when circles turn into popups) and some parallax effect when scrolling down to the other parts of the website).

It doesn't happen often that I can say "I'm quite pleased with the outcome".

 

After that I went back to MTR.

I'm still in 3D mode so instead of starting with code I started building the 3rd car.


The 3rd car, at least one more needed.

This one is quite easy, no fancy corners and this is the outcome of about 4 hours work. It's missing some details like the bumpers and lights, but that's for tomorrow morning. I even look forward to UVW map it (well, who wouldn't, as it's essentially a box with wheels).


I think the rendered version looks a bit shit right now.

I'm not quite sure what the 4th car will look like (although I have an idea) and with that I can finish of the dreaded AI. I then have to do a client version of it - which even might become the initial public release (so I have it out of the door for a while). The client version will feature single player mode and six fixed tracks only, maybe a few (very few) car upgrades.

We announce the next important post after the break ... or next week.

If you haven't done so already give Lost Outpost your greenlight love:
http://blog.gamingyourway.com/post/2013/09/16/Lost-Outpost-on-Greenlight.aspx

Catch you next week,
-- Oliver (nGFX) 

I want to be a social media strategist ...

... because if I were, I could "Create a deliciously irresistible blog post title". 

Oh and no, we won't let you do a guest post on the GYW blog that could "benefit" us both.

The real title of this week's post should have been "Deciding how textures should look like". Client work took over again this week so I just did small thing during the daily 30 minutes of development time. One thing was to setup the machine puzzle in Unity and importing "Danielle" (one of the Characters you'll be able to play) from the old version of the Hellstrom Project. I juts need to make the animations work with the new controls (although I need to rebuilt the character anyway in order to animate the walk cycle using the standard 7 keys one I found in an old animation book - from the early days of animated films).

The rest of the time I spent evaluating how I want my textures to look like, as this also defines how I do the rest of the environment.


current unmapped version

When I started modelling I wanted to use no textures at all and just create lightmaps and solid coloured objects not unlike the unmapped version above. As much as I like the look, it also makes things a bit more complicated. Objects like rocks and cave walls need to be modelled to make up for the missing textures and honestly the flat walls look a bit dull.


using image based textures

I admit the example for image based mapping doesn't show my point as well as I thought when I made it, but as you can see there's a lot of detail behind the machine. You also may notice that it kinda looks flat, so it could do with normal mapping and/or more geometry. Even though I could build the stonewall with detailed geometry and then render the normals maps, adding details with extra geometry if needed, this will add a lot more work to the initial alpha version. No to mention that it doesn't look like I imagined it.


Painted textures and a few extra polys for details
(the 3 "blocks" right of the arches)

"Painted" isn't quite right (yet) but it shows the direction I want to head for the textures. The few extra polygons needed for details won't hurt (and I guess I can still optimize a few unseen ones away later)

And with this I'll end this post and try to come up with something to post next week.

 

Oliver (nGFX)