Posts Tagged ‘AI’

Heat Tsunami!!!

As heatwave rips through Australia for the next few days there isn’t really much I can do but blog on a laptop.

It feels more like a Heat Tsunami. But Elise says that’s just confusing. Also, just googled it, and it is a term!

I’ve been keeping pretty busy lately despite all the fun awesome things to be had over the holidays. I’ve also been a little sick with a really annoying cold, and only just getting over it. So progress on our new game has been a little slow, but still very fruitful.

I think I’ll keep to the subtitling format because it just makes things so much easier to explain without creating mega-lo-blogs (like a Megalodon, just in blog form).

So here’s what’s been happening!

New Years Resolution!

As part of my new years resolution this year, I’m going to spend a bit more time drawing, and art in general.

Since I’ve had my head buried in books for the last few years and learning everything I can about every necessary to make a living as Indie Game Developer, I’ve kind of neglected the skills that really kind of started it all.

So expect some drawings to come!

Our Next Game

Our next game is moving along well, but slowly. With all the madness and fun-times recently, there have also been a number of technical advancements we’ve had to research and integrate. Plus the Heat Tsunamis don’t help.

It has been quite challenging, with a lot of new things to learn and existing systems being revised. We probably could of made more progress going a little simpler.

But in order for us to get to the games we really really want to get, we have to throw ourselves in a little deeper on this one. This one has been quite the hurdle but it’s only the initial hurdle to doing bigger and better things!

Elise has been working when she can to create some new props to be used in the level. She’s had a pretty busy schedule lately which has been difficult to make leaps in progress with the art. With the crazy weather we’ve been having it is also making it even more difficult.

I’ve been modelling, rigging and making some new animations for some of the new characters. They’re in the same style as The Very Organized Thief owner, except we’ve been trying to make them a little less scary looking.

We’ve also been using articy:draft (from Steam) to plot out the flow of our game. It’s probably one of the most useful things you can get for yourself as a game designer, especially for working out flows. Whether it be dialogue, game events, or even story. It just makes it so much easier. Writing things like that into a monolith document, really doesn’t help with clarity sometimes. We highly recommend it.

Working with Red

The Red Framework has a significant overhaul during the start of the project. Mostly to help standardise the workflow and iron out some issues.

I’ve been refining Red AI (our AI system) to be a little more easy to use. Also fixing some limitations which we encountered in The Very Organized Thief. Still some work to be done but it has had some major improvements.

I also recently bought Reactor AI from the Unity Store, which is a system for AI Behaviour Trees. I’ve been using it as an extension to RedAI. I had already partially built an Behaviour Tree system for Red AI but it had no tools to make it easier to work with. Reactor does! Making my life a little bit easier and giving me a great opportunity to work more with Behaviour Trees!

With those changes Red AI is now a hybrid AI system which uses a combination of two different types of AI systems, which is State Driven, and Behaviour Tree Driven. Allowing us to define States which can either be coded specifically for more control or use behaviours trees. For what we have planned in future games, it’s the most robust solution which will allows to build complex AI much more rapidly.

Red also has a Dialogue system, which was originally called DKit. But more about that system another blog post : P

The Very Organized Thief

I have been working on The Very Organised Thief a little here and there. Nothing major that a new version needs to be built and uploaded. But Elise and I have been talking about what we want to add to it.

With Australia Day coming up, and having the ability to have Seasonal related content. We thought it might be fun to have an Australia Day update. We’ll also been talking about doing Valentines Day update as well!

If things go well this week we should be releasing an Australia Day version!

Crowdfunding Planning

Elise and I have been spending a lot of time discussion how we’re going to do it. And we’re still kind of holding off on jumping on it too soon.

We do know that if we do, our primary goal will be to get Elise a Maya LT license. Many alternative solutions we’ve looked at have only proved to be more frustrating, buggy and requiring us to do more work when bringing them in Maya (the one on my computer). Many of which I’ve written MEL Scripts to counter, but still leaves some additional rework.

If she gets a Maya LT license, it’ll be a much more familiar environment for both of us and things will hopefully require less rework. And less spontaneous bug crashes and poorly translated interfaces…

We’ll see what happens in the next few days and or weeks, but we plan to do it soon!

Playing Games

I’ve been making an effort this year to play more games.

I’ve recently been playing Castlestorm and Okami-den on the DS. I’m also still playing Final Fantasy VII… so good!

Castlestorm was an unexpected surprise. A little juggle-y at times considering all the things you can do. But it’s satisfying to play, really fun, and looks fantastic. The game is casual and feels like it would be easier to play on some kind of touch interface, but despite that it’s still very fun. Give it a go if you get the chance.

Okami-den. If you’re a fan of the original Okami game, you’ll love this one. I’m a little ashamed that I only just started playing it recently, since I it was originally given to me for Christmas … in 2012 … it’s been a busy year v_v”. Despite it feeling like it’s missing a little detail, it holds true to the art style and gameplay. If you have a DS or you have it, and haven’t played it. Play it! Takes a little to get into but it’ll eventually suck you in completely!

———————-

And that’s what I’ve been up to lately. That and melting into things.

CURSE YOU HEAT TSUNAMI!!

Keeping Busy – Deathspuds, Animation & Painting

So I’m hoping to make “things I’ve been up” to a more regular thing on my blog. It has been pretty hard finding time to write and revise some good useful articles which I’m hoping to post soon. But until then, rather then writing something useful. I figure I’ll just write what I’ve been up to. At least that way this thing gets used and maybe some of the stuff in it may be useful, and/or even interesting!

So what’s been happening recently.

I’ve recently completed Milestone 3 for DeathSpuds. 

This milestone saw the implementation of Enemies which can melee and/or shoot projectiles at the player while moving through a level. The behaviour was a little bit whacky at first, mainly because I tried to condense the melee and Projectile shooting into a single Attack State but it just made it as confusing as the AI was behaving.

I ended up splitting the Melee and Projectile shooting into 2 separate AI States. It made more sense considering the Enemy would either do one or the other or both. And it was easier to determine when to switch between or leave these states by checking per state, rather then all in one.

The enemies also avoid walls now to. The also find a way out when they get backed into a corner.

Enemies that also just specialize in shooting projectile will also maintain there distance, running away when you get to close. Ones that can do melee will move in if you get to close to them. At the moment it’s set to be 3/4 of the closest possible firing distance. I’ll probably end up tweaking this or even making it an available factor in the Unity inspector to get better control over this distance.

This milestone also saw the implementation of enemies spawners, such as enemies spawning from a point and out of the ground. This presented a small problem with Unity’s Mecanim, which is handling all of our animations. It just doesn’t give you much control over using a single Mecanim Animator Controllers which defines the animation behaviour of a character given certain values, at an initial starting state. Forcing you to duplicate the controller file, renaming it, and setting a different starting state.

For example, one of our enemies can spawn out of the ground and also just be standing idly in the scene. But in order to do that, your need to define 2 specific Animator Controllers for the 2 different types of starting states. The controllers are basically identical, accept one has it’s initial starting state as “Idle” and the other as “Spawning”. It would be nice if it were possible to force a particular state onto the animator for purposes such as this.

I know it doesn’t sound like much but imagine making adjustments to one and having to duplicate and set the starting state. Now imagine doing that a hundred times with just minor adjustments over a long period of time. It would get quite annoying.

In all the Enemies are pretty fleshed out and it’s going quite well. I can see some issues popping up which I’ll probably address if and when they arise, such as line of sight  of projectile shooters with enemies blocking the way. But it could just be a matter of making them simply move their position, I doubt it… but here’s to hoping it is.

There was a whole bunch of other things which went in. A lot of which was for to improve performance at run-time for the first level. Which Josh has made to look damn awesome. But I’ll leave it that for now.

Today, I also integrated some core animation components into my flash framework. It hasn’t been much of a priority before because most of what I was doing with flash was being driven by code or physics. Since I’ve been working on point and click / hidden object engine, having a means to control animations and animatable things has become pretty important.

My goal was to have an item you clicked from the scene move themselves into the foreground, and spin and fade into your inventory. I ended up implementing an Animation Manager that let you pass in Animates, basically animations that define a particular behaviour, such as spinning and fading. Basically setting values on this animates and passing it to the Animation Manager will cause the animation to occur.

I also had to make sure that it was pretty easy and straight forward to do for people who may end up using this engine the future. Mainly Elise. The way you use it was kind of inspired by how you use [UIView beginAnimation] in the iOS Core Animation Framework. Of course what I’ve implemented is nothing compared to how Core Animation actually works. But I based my design purely on it’s ease of use, minus the static call.

I’ll most likely be tweaking this over time and adding more features to it and even more animate types but overall I’m pretty happy with how it turned out.

I’ve also been doing some digital painting for the backgrounds in our game.

Point and Click Background 1

Elise did most of the line work for the painting. I’ve just been colouring it in. It’s a work in progress. We’re still working out the final look of some other areas, so some things are likely to change.

And that’s what I’ve been up to lately.