Posts Tagged ‘AI’
Straight to the point, these are some scripts I wrote in C# for Unity 2D stuff that I’ll be using – feel free to use them any way you want.
This script is ment to make creating platformer scenes a bit easier. Assign it to the tile you are using and then give it six sprites for said tile – it will detect nearby tiles and automatically select the appropriate sprite to use, then rotate as needed so that you can place tiles and leave it to the rest.
Pretty self-explanatory, this is a simple script to act as a sort of 2D CharacterController for the player. Comes with a debugging option. Requires a trigger collider to detect whether or not the player is on the ground.
Also rather self-explanatory. Simple script that doubles as very basic A.I. and physics handler for enemies. Physics is nigh-identical to player physics. Also includes debugging option and also needs a trigger collider.
Decent health script I wrote for whatever needs it. EnemyLogic will need this to deal damage properly to the player properly. Includes logic for invulnerability periods after getting hit. Debugging on this will only display health in the console.
This is my 3rd ludum dare and I am going to use the same tools as always:
- Libraries: CreateJS, Creatine, and easystarjs (maybe)
- Graphics: Inkscape and GIMP
- Sound: No idea
Independent from the theme, I’m hoping to use behavior trees to control some NPC’s (I wrote a 3-part tutorial on behavior trees on my blog) and I am praying to all gods to elect “You Are Already Dead” as the final theme!
So in the process of preventing the enemy from tripping backwards and suffering a gran maul seizure, we’ve apparently given him the ability to glitch through walls. Like I said, I suck at A.I.
In other news, the base construction and terrain are coming along nicely. The basics of building is done, and what’s left is to allow for multiple block types and defenses. On the front of enemies, we’ve got to create spawning, give them health and actually make them dangerous.
In short, we’ve got a long way to go and a lot to do. Even so the knowledge gleamed learning to not suck at Unity will really help in the long run, and will prove valuable come August’s Ludum Dare. Besides that, watching the A.I. I wrote fail miserably was incredibly funny. Hopefully we’ll pull this off, but even if we don’t, fun was had.
Oh, and I am so including an option to ‘un-fix’ all the glitches on the A.I. – there’s no way I’m restricting that fun!
A Fuzzy Associative Memory (FAM for short) is a Fuzzy Logic tool for decision making. Fuzzy logic FAMs are highly applicable in Game AI.
A Fuzzy Associative Memory uses Fuzzy Sets to establish a set of linguistic rules , e.g.:
- “If the orc’s hit points are a little low, retreat from the enemy”
- “If the enemy is distant and my rocket ammo is low, the rocket launcher is a poor choice”
- “If the enemy is near and my shotgun ammo is okay, the shotgun is a very desirable choice”
- “If the ship is off course by a little bit, correct just a little to the right”
- “If the bird is much slower than the flock, speed it up a lot”
The linguistic rules, and the fuzzy sets they contain, are defined by a human “expert” (presumably, you). That is to say, the rules codify intelligence and map this knowledge from the human domain to the digital.
After the rules are defined, a FAM is consulted to help your AI make a descision:
- The orc retreats, attacks, strafes.
- The ship launches long range missiles or fires short range guns.
- The control rods are lowered into the reactor or raised out of it.
As you can see, the fuzzy rules are deliberately vague and use qualifiers like “a little” and “a lot”. Furthermore, the lines between fuzzy sets are intentionally blurry. This is the nature of fuzzy sets; they capture such human fuzziness in a way that extracts highly natural behavior from the fuzzy rules. When defining these rules, it helps to imagine interviewing a bona fide expert in the domain and writing down the skills necessary to be successful in the domain.
Learn more, and get the Ruby Gem for your own game:
So I let my AI roam my procedurally generated maze. Check the video!
Drew a bit of a blank on the theme, so decided to write a fairly traditional stealth-’em-up. This time I have mostly resisted the urge to make it pretty, and have got the core mechanics working instead!
You can turn the torches on and off, collect loot, and I have a sinister capsule patrolling a series of waypoints, coming after you if he spots you, and returning to patrol if he loses you again. Title and pause screen are working.
Day 2 is all about making gameplay from those core mechanics, and tarting it up – although one important thing I haven’t yet done is factor shadows into the visiblity code. But I know how that will work, just haven’t done it yet. Just done a last-minute stress test to see how many dynamic lights I can get away with, and the answer is “not many”. I may burn a lot of tomorrow optimising…
Gettin’ that polish going!~ I’ve added a title screen, as well as a way to control if a Human or CPU controls each of the two sides. Also my AI is getting smarter! It’s still quite beatable; my search depth is… next to nothing really, so it only gets as far as predicting your next move and making some vaguely intelligent guesses as to what kinda of things improve its position. I’ve still got about 6 hours though, and pretty much the only thing I’ve got left to do aside from AI improvements is adding some movement animations to help see what’s going on. I’m actually at a point where I’m about to ask some IRC peoples to help me test. If you’d like to help with that just let me know; I’m Luthwyhn in IRC.
Here’s a shot of my title screen!
I hope everyone else is getting done too! I’ve been too busy to keep with with chat more than occasionally. Keep up the good work, though!
Yes, you heard right, folks! My game is a completely playable implementation of Tablut as of about 9 hours ago! There’s a few minor things it doesn’t do (warn you for Check/Mate), and plenty of places that can be polished (Movement animations?)… but the game can indeed be played! Currently, though, it only works as a 2-Player game. My goal with the remaining ~15 hours is to implement a mildly competent AI system who can play as the Attack and/or the Defender, at your own choice. Currently the AI moves at random until and unless it has a move that will allow it to win immediately, in which case it takes that move. It’s not much, but it is indeed a start! The visuals have changed just a little since my last update, so I’ll post a new screenshot as well:
BLDR is done! It probably could have used more levels and obstacles, but I think it’s great! Postcompo version will definetly include more levels.
Download it here: http://www.filesavr.com/bldr
EDIT: I forgot to include it in the instructions, but arrow keys to move and R to restart the level.
Postcompo edit: New download link at http://kittylambda.com/files/BLDR.zip (thanks to PsySal)
Phew. I just got the “AI” system I’ve been working on the last hours to work at least a decently. The enemy ships don’t move totally random anymore, they try to line up so they can hit your ships at least. It’s still really stupid though, especially when close to the screen edges but it’s as good as I’ll bother to make it I think.
I’ve also implemented levels and game-over conditions, a shop where you buy new ships between the levels and done tons of bugfixes/speedups since yesterday. There is still one really annoying bug where the sprites sometimes doesn’t get cleared completely and leave one or two lingering pixels, but I’m sure I’ll figure that out soon.
After that there is mostly fine polishing left to do, the shop screen is very, very minimalistic right now, to the point of not making any sense, the interface graphics could also need some love and after that it’s on to game balancing.
Copied from my Dev Blog
So eventually you’re going to have to put in moving/walking/talking elements of various varieties in most any game. Maybe they are lemmings. Maybe they are AI controlled bot opponents in an FPS. Or maybe they are soldiers in an RTS, or enemies in a hack and slash. In any case it’s daunting to add these gameplay elements because the behaviour will ultimately require so much tweaking and experimentation. Where do you start?
Carefully creating a system for managing/handling such creatures is… somewhat uninspiring work. And worse, what kind of result do you get? Did you end up forgetting some crucial detail, or do you get a very complex, neural-net-enhanced AI that just acts stoopid? Good luck!
When you see your little guys moving around, only then do you start to see what practical changes you can make to their behaviour. It doesn’t mean you can’t have larger scale frameworks in place, it’s just that even with these frameworks (e.g., pathfinding) it’s not too obvious how to code the heuristics until you are into.
This brings me to my Golden Rule of Adding Moving Gameplay Elements:
First, just add something that stands still and you can zap.
Of course, “zap” might stand for anything. Maybe zap means clicking an RTS unit. Or talking to an NPC. But your first implementation should not worry about movement or anything. It should just create the actual unit, place it. You can start to work out your enemy placement/spawning system at this point, or start to think about how they will behave. But either way, what you really need before you can get started on any practical level is to get it placed. And in order to do that most easily, just forget everything else that will have to go into it for the time being.
I would do well to remember this in the future. This way of thinking avoids me spending all kinds of time mulling over millions of options without anything to start experimenting with. With a purely dumb element placed, purely dumbly, I am able to start the kind of wheedling experimentation neccesary to make it work.