Tag Archives: turret behavior

Attack and Gather with Buttons, Oh My!

10 May

The updated game. – This version should work better on mobile. UPDATE: So, when I run this project in my editor, everything works fine. Exported, the game has some baffling bugs. As far as I can tell, this is because I’m on the Construct 2 beta update channel. And if there’s one thing that can be said about Scirra, it’s that they do frequent and often bug-causing updates.

On the surface, all that’s new is the interface and the inclusion of Attack Bots. Of course, in the background there was more, but it was mostly stupid bug fixing. This time around, Gather Bots care less about finding Dead Bots, and their behavior has changed so that they “swarm” less one object. Attack Bots search for Dead Bots to bring back, and, if they see another team trying to take a Dead Bot, they attack.

One of the things I had to change a while back was the Turret system used by my bots. The Construct 2 behavior plugin, “Turret Behavior”, had some real limitations as far as determining whether an object was a suitable target. So, I just use events to control which objects are targeted. I’m getting close to the point where I must just try and write my own Plugin. If nothing else, it’s good motivation to learn Javascript.

A Gather update?

29 Apr

In my last post about gather I mentioned that it might still be interesting to focus on the “ant farm” aspect of what I had built, and ignore the science subtext I was trying to force in. So, I decided to pluck away, and this is the result:

Gather – Click on the big Yellow and Pink boxes to spawn bots of those respective colors. I left all the log info commands in, so clicking on things will give object variable info.

Why pursue this?: While I think I’m using a lot of the same mechanics, my end goal is much simpler. I still like the “AI voyeurism” in watching two sets of the same instructions battle it out for supremacy. It’s also helpful for me to keep sharpening my RTS programming skills.

Where am I going with it?: The scary part is, not many of the actual systems are going to change, but the emphasis I placed on different parts has changed. Before I was worried more about the different base”nodes” talking to each other and sending “signals” with different transmitters, with bots being tools of the base. Now it’s more traditional, with the idea being that the production of bots is the purpose of the base and ore.  Resource bots still look for ore, Attack bots are going to attack enemies, and Road bots are going to connect the different nodes up. The only real change for the bots is that Resource and Attack bots are now concerned with picking up “un-energized” bots and bringing them back to base for recharging, thereby keeping up the team numbers at a lower cost.

The next thing I want to implement is the Attack bots. Their role will be to actively look for un-energized bots and to destroy enemy bots that are carrying un-energized bots.  These will take a different resource for production, so I’ll also put in the different colored Combiners.

An update.

9 Mar

I decided to do some follow up posts for my Neural/AI RTS thing.

Construct 2′s Pathfinding behavior is giving me some problems. I want to create automatically create paths on-screen between two objects to send units back and forth them. Right now, the units will usually take one path to get to an object and another path to go back. I’ve experimented with adjusting the “cost” of taking different paths so that units will prefer the first route, but that breaks the game when it works.

On a similar note, I would like to see expanded capability of pathfinding by having access to the pathfinding nodes directly as objects. They just added the ability to reference the node the object is heading towards by it’s array index, and you can access the (X,Y) coordinates of a node by index already.

Construct 2′s path finding behavior is still fairly new and they’re still evolving it and fixing it.

On more of the design side of things, I was planning to have units be ordered by instructions linked to a particular resource type. Orders could build up in complexity, and basically it becomes similar to programming. Different order configurations could be saved as physical “macros” in the game world. The goal would actually be to represent muscle movement patterns stored in our brain. I’m worried that while this may be a novel way of doing things, it may not be very fun. It’s certainly not practical.

I’ll post the prototype for posterity’s sake, but there’s a lot of shit going on that I don’t feel like explaining.

http://dl.dropbox.com/u/11289993/Gather2/index.html

Gathering AI

21 Feb

Construct has added a bunch of interesting features since I last used it, so I figured I might as well prototype some ideas that needed to be worked out. I should probably just write something down that summarizes my musings on games inspired by neuroscience, but for now I have this, Gather AI.

Right now, “bots” automatically gather red ore and return it to base. After 4 red ore are collected, a new red ore bot will spawn. The player can click and hold on the base to make the red bots move towards the base, when they arrive they will “sacrifice” themselves. Once 4 red bots are sacrificed, a “green” bot appears.

The idea is to create an RTS style game, where players control AI units indirectly through commands. Even the clicking in this prototype is more direct than I intend to get. Essentially, your base will run itself based on set parameters.

One of the main features I wanted to try out was PathFinding, but I it was giving me some problem. Ironically, all of the work in this prototype is done with the turret behavior, which is still new but I’ve pretty much created the same functionality out of code before. But still, Turret behavior is a nice package and I’m looking forward to working with PathFinding.

I also like that they’ve incorporated most of RexRainbow’s “Function” extension into Construct 2.

Follow

Get every new post delivered to your Inbox.

Join 81 other followers