I moved to a new URL! Check it out!

posts tagged with: gamedev

Behavior Tree Experiments

Behavior Tree Experiments
As I dig back into my main project one of the upcoming things on my to do list that has been bugging me has been getting the enemies working in a fun and compelling way. Something where they feel smart enough to be challenging to take on.

Usually the way I've always done enemies is through finite state machines which is a pretty fancy term that you shouldn't look up on Wikipedia unless you're going to become incredibly confused. Basically a finite state machine can be used to separate an enemy's behaviors into a bunch of different distinct states. A state can then link itself to other states. So an enemy might have attack, confused, hurt, or defeated states, and depending on what's happening in the game it will switch between them to act on things.

A behavior tree is way more fancy than that and apparently is more powerful in a lot of ways. Ways that I'm not sure that I understand yet, and ways that I've been trying to figure out over the past however long I've actually been working on this game.

Image


I've started putting together a quick behavior tree library that covers the basics that I learned from this article here. For now I'm calling it Kodo and you can check out the full source on BitBucket. I'm not sure how well it works at all, so be warned. Currently I'm using it for some tests using Otter, and so far it seems like things are working but I haven't stepped into the realm of incredibly complicated trees yet.

One of the toughest things for me right now is understand how exactly I'm supposed to be building behavior trees. Finite state machines have always been easier for me to implement, and understand, and going from that to behavior trees has left me completely clueless for the most part, but everywhere I go on the internet assures me that behavior trees are ultimately worth it in the end!
programming csharp gamedev
Posted August 11th 2014 11:54 AM (General)
1 Comment

Taking a Quick Break

Taking a Quick Break
Whoops! I think this is the longest I've ever let my blog go without an update in a long time. I've been traveling a lot this month and haven't really had a whole lot of time to sit down and do a lot of cool game dev work to talk about.

I was at EVO just two weekends ago, and this last weekend I spent visiting my old college roommates, and some high school friends that I haven't seen in a billion years. Yesterday I was in New York City, and now for the rest of the week I'm in Upstate NY where apparently it's totally okay to convert the shoulder into a driving lane whenever you want. On Saturday I'll finally be back in Phoenix!

I have been working on a little side thing experimenting with near-infinite level generation. It's a little game in Otter right now with just boxes and the game scene is filled in as the player travels through it. Areas of the level also unload when the player gets too far. I wanted to try to make something in which the player can go out in any direction and keep finding stuff, and not have it be bound by any walls or anything like that. I started it on the flight out to the east coast, and worked on it a little bit in a coffee shop in NYC more, but right now it's just a bunch of squares that aren't that exciting.

Image


I think for my developer/mental health I should start working on tiny experiments like this more. It's something that I used to do often, but now I feel like I don't want to take time away from my main project, but that usually ends up being a bad attitude... more thoughts on that later!

Should have more time this week to work on some stuff though before I go back to the west. Sorry about dropping off the face of the internet for awhile!
otter gamedev
Posted July 22nd 2014 1:25 PM (General)
2 Comments

Dev Log: Overworlds

Dev Log: Overworlds
Getting back into the swing of game development has been a little tougher than I thought. Especially since July isn't exactly going to be a calm month for me to really dig into stuff. This 4th of July weekend is pretty busy, and I'm still right in the middle of it. After I'm heading up to EVO with a bunch of folk, and then I'm spending some time on the east coast after that. Traveling and getting work done doesn't really go hand in hand for me, so hopefully I can still salvage some time to get some game development in.

Anyway, my recent developments have lead me into making some sort of overworld map for my game. As I started to work on it, I quickly realized that I have no clue what I'm doing. I haven't really worked on anything like this before, and I'm slowly figuring out how to properly structure and manage it all.

Image


Basically the map screen is going to be some kind of turn based system that will determine what kind of encounter you go into next. The player will be able to choose where to go with their character, and there will also be enemy forces moving about in the area attacking things. The main issue I have right now is that I think I know how I want everything to work, but I have no idea how to code it.

I've never done any sort of turn based anything before, so I've been spending some time researching the internet for any leads. I found a few quick examples, but not really any sort of examples that come with source code to look at. I find it very difficult to go from an abstract concept to actual code, and a lot of times these examples or tutorials I find just explain the broad concepts of a system and don't really dig into the details which is where I always get lost... but hopefully with enough just messing around in a code window I can stumble onto the right answer.
stratoforce gamedev dev log
Posted July 5th 2014 3:56 PM (General)
No Comments

Otter Updates 0.9.6

Otter Updates 0.9.6
Otter is slowly approaching the big 1.0.0 moment, and I've been tinkering with it little by little trying to fix bugs that pop up. I've also been using the dev branch so you can see my updates as I make them. Otherwise the default branch is supposed to be the "stable" one, and every once in awhile I merge the dev branch in with the default one.

Here's some of the recent changes and fixes!

* Text now has CenterTextOrigin() in an attempt to find the center of the actual text, and not the full bounding box.

* RichText also now has CenterTextOrigin()

* Fixed Text bug that would cause text to jitter when the height of the tallest character was changed.

* Fixed the same issue in RichText.

* Tilemaps have had some improvements in their performance for looking up tiles.

* Tilemaps can now use Enums for their layers.

* Fixed bugs with accessing tiles out of range in a Tilemap. Tiles are now automatically clamped inside of the limits of the Tilemap.

* Tilemap GetTiles() will return a list of TileInfo objects for every tile on a specific layer.

* GridCollider now has a Clear() function

* GridColliders can now load collision data from a Tilemap, using a specific layer on the Tilemap.

* Fixed a bug with not updating Graphics when their alpha was changed.

* Game's "SmoothAll" value should now actually affect Textures. Considering changing this to a static value on Texture.

* Fixed crash bug with Surface's SaveToFile() function.

* Updated the Glide Tween Library to the latest revision.

* Updated the documentation.

That's all for now. If you have any issues you can post on the forums and that'll be the easiest way to get help. Hope everyone out there is having fun with the engine!
otter csharp gamedev
Posted June 12th 2014 2:06 PM (Otter)
No Comments

Dev Log: Quick Lighting Test

Dev Log: Quick Lighting Test
As a quick experiment I wanted to see how Otter would be equipped to handle a simple lighting set up. The basic set up is just a big render texture that is filled with a dark color with a blend mode set to multiply. Then light is rendered to the render texture with a blend mode of additive. The result is a layer of shadow that can have light rendered to it.

Image


The code for this set up right now is pretty straight forward as well. I'm using a black and white image for the light. Just a black rectangle with a white radial gradient in the center.

Here's some sample code to show how this effect is achieved with Otter!
//set up the surface

public Surface SurfaceLighting = new Surface(Game.Instance.Width, Game.Instance.Height, new Color("379")) {

    Blend = BlendMode.Multiply

};



//set up the light

public Image ImageLight = new Image(Assets.ImageLight1) {

    Blend = BlendMode.Add

};



//add the surface to an entity to render it

//this happens in an object's initialization

AddGraphicGUI(SurfaceLighting);



//render light to the surface

//this happens in a Render() function

Draw.SetTarget(SurfaceLighting);

ImageLight.Color = Color.White;

Draw.Graphic(ImageLight, Input.MouseX, Input.MouseY);

ImageLight.Color = Color.Red;

Draw.Graphic(ImageLight, Input.MouseX + 500, Input.MouseY);

ImageLight.Color = Color.Blue;

Draw.Graphic(ImageLight, Input.MouseX - 500, Input.MouseY);

Draw.ResetTarget();
otter dev log gamedev programming csharp
Posted April 16th 2014 4:58 PM (General)
4 Comments

Dev Log: Pathfinding Fun

Image


Like a cat chasing a laser pointer, I have some basic enemies chasing paths through the skies.

Right now I'm using A* and although I don't really know what is going on that much, I have a system that enemies can use to find paths to their destinations. Normally I wouldn't bother with any sort of path finding, but for this game I want enemies to have to intelligently navigate through obstacles that the player is deploying, so my usual "make up a path finding function that doesn't actually path find but sometimes works out" function wont cut it.

What I have currently is a pretty straight forward set up:
- One PathFinder instance in my Scene. It extends Entity so that it can be updated by the scene automatically.
- Enemies request a path from PathFinder and also register a callback Action with the request.
- The PathFinder instance adds the request to the queue.
- Every update the PathFinder will take the top item of the queue and start the path finding process.
- The actual A* algorithm and calculations are run on a BackgroundThread so that the game can continue while this is going on.
- When the path is done calculating the callback is fired, and the enemy now knows about its path.
- It chases down the nodes that were added to its path.

I made a quick change to the A* algorithm as well under the sage advice of Chevy Ray: I'm using a maximum movement value that will stop the algorithm if the move costs become too high. The result is that the algorithm will return a partial path to the final target instead of the entire path (which could take a long time to calculate in a set of nodes with a lot of open spaces.) So with this in mind the rest of my logic looks like this:

- When the enemy reaches the last node, it checks to see if its close to its intended target.
- If not it requests a new path to its target.
- If it is then it will enter its attack behavior, whatever that is.

So far this seems to be working out pretty well. I have a lot of work to do with how enemies will end up treating their path nodes in regards to their actual movement. Right now they just try to move toward each node, but with a lot of nodes together they end up having some trouble, like that wiggling in the animation above. Something like an averaged out path between a lot of nodes might work better... hmm!
gamedev dev log programming stratoforce
Posted April 9th 2014 4:11 AM (General)
4 Comments
« newer posts
older posts »