Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - roguedjack

Pages: [1] 2 3 ... 5
1
You probably already know that but the FEAR SDK has a GOAP implementation for the AI will full source (C++)
http://web.media.mit.edu/~jorkin/goap.html
There was a source-only version on the site I linked in the previous post, but you need to register.

I was thinking about what you said about GOAP being limited to primitive actions, because acting directly on the game world.
Wouldn't it be possible to use compound/hi-level actions if you use GOAP on a more abstract search space.
For instance a GOAP "action" would be a selecting a specific tactic/behavior on a NPC, rather than concrete game actions. The said tactic/behavior implemented by FSM/whatever with actual game actions.
The GOAP search space would then be tactical features such as "X is near Y", "X is behind Y" etc... rather than concrete game states.

2
Is your game strictly turn-based or "real time" (eg: like dwarf fortress)? Just to be sure, as it can make a huge difference.

I know about GOAP and HTN but not used them.
This site has some stuff about them: http://aigamedev.com/
IIRC GOAP is more suited to individuals NPCs rather than squad AI?

I did some sort of planning for a Blood Bowl like Java project, not GOAP or HTN though.
Handling a team of players is kinda similar to squad behavior. The difference is a team act together in the same turn, while a squad is over severals turns each NPC acting on their own.
I implemented 3 AIs : a search based one, a planning+GA one and a rule-based one.
http://roguesurvivor.blogspot.com/2010/07/other-abandonned-projects-ii.html
All solutions kinda worked but had limitations and flaws.

With a planning solution, you could ditch altogether checking for re-planning conditions and just replan each turn.
For roguelikes I see more drawbacks in maintaining a plan over many turns and checking for replan conditions than simply generating new plans every turn. But that's just my opinion, SK seems to have implemented long term planning for his GRA roguelike.

For squad behavior, rather than top-down planning you could try the other way around :
(a) Top down : I want to encircle the player, how do my guys do that?
vs
(b) Bottom up: does this individual NPC action  contributes to the goal of encircling the player? if no, how can I improve that?

(b) is similar to my "beam ai" thing : you don't know who to write a good squad plan from scratch (very hard), but you know how to create a squad plan (easy), you know how to modify plans (easy) and you can recognize good from bad plans (moderatly hard).
Some sort of Genetic Algorithm on plans if you will.

Krice is right too. Just do a solution, and see what happens. Just make sure you can easily plug differents solutions with an abstract AI architecture (an AINPC interface or stuff like that) and have fun experimentating. I had lots of fun with my Bad Bowl retarded pet AIs.

Mmhh. i guess you're even more confused now sorry  :D

3
Programming / Re: Tracking targets
« on: January 07, 2011, 10:57:15 AM »
Krice.

Patterns are like standard algorithms.
Patterns help solving DESIGN/PROGRAMMING problems the same way standard algorithms help sove TASKS problems.
Patterns are good because they have been proven to work in practice and you can communicate your ideas more easily with other programmers with just saying the name of the pattern.
Patterns are just common ways to solve problems. Since quite a lot of people ended up using very similar solutions they have been formalized and given names like "Command pattern", "Observer pattern"...
Just like people used some similar data structures that are formalized and given names like "Tree", "List", "Graph"...
Nowadays patterns are part of your average software designer culture. Like "types", "variables", "quick-sort"....

Directing you to a pattern is a way of offering you a solution without writing a little 10 pages essay to explain you the idea in detail and how it is a candidate solution to your problem.
You wouldn't explain the list structure to other programmers over and over again. You just say "you can use a list to store your character items" and point them to the "list" idiom. Same for patterns.

Same with smart pointers. If you keep lots of references with pointers between your objects, smart pointers can help you avoiding crashing the program with invalid pointers. You can do without of course.

If you knew the Observer pattern for instance you wouldn't have to ask your initial question. It is exactly offering a viable, simple and clear solution for your problem.
Just like someone who know the "A-star" algorithm don't have to ask questions like "how can my AI find a path?".

You are perfectly entitled to refuse using or looking at these common solutions. Just know you are probably overlooking a set of tools that can help you fixing your problems.
Most programmers are using them not because they look nice or are fancy but because they work.
Just be aware that a lot of other people have gone through the same problems as you and ended up finding good solutions and are sharing them : Patterns, Algorithms, Data structures, Other languages...

Some solutions are just superior to others, others are superior under some conditions. Most of the time someone else has already solved a problem better than you could ever do ("you" means you, me, everyone).
You either:
a) accept that and trust other programmers experiences.
or
b) try for own thing and see the results.

Most people start doing b) thinking "uh. that new thing is complicated, useless, stupid, overdoing-it. the stuff I already use is fine."
...and after months or years of experience...
"hey, those guys were right! the best solution i found is just like those guys said in the first place! and sometimes they found an even better soltion than mine! duh! i lost a lot of time, but at least I learned! next time i'll listen and havea look at that new thing first!"

Ok. Hope my little easy didn't bore/enraged you. Good luck anyway with whatever solution you choose.

4
Programming / Re: Tracking targets
« on: December 23, 2010, 07:27:34 PM »
Allright then.

Your "targeted by" solution is basically the observer pattern :
An object notify another object something has happened to him (eg: the item is taken by someone else).
http://en.wikipedia.org/wiki/Observer_pattern

If you run into pointers problems (eg: item "targeted by list" might hold invalid pointers at some point) and still don't want to use IDs for storing game object references you could consider using smart pointers:
http://en.wikipedia.org/wiki/Smart_pointer
Assuming you program in C++ the Boost library is a good complement to the STL :
http://en.wikipedia.org/wiki/Boost_C%2B%2B_Libraries


5
Programming / Re: Tracking targets
« on: December 23, 2010, 09:24:48 AM »
There is still overhead for using a hashtable with IDs, whether or not some would consider it negligible. There is zero overhead for using a pointer.
If you never share your pointer of course a pointer is the best thing.

6
Programming / Re: Tracking targets
« on: December 23, 2010, 09:22:03 AM »
I don't really follow advices.
Why do you ask for other people opinions then?
If you have already make up your mind go ahead then.

Quote
Besides.. isn't pointer a kind of id anyway?
Game ID != Memory ID (pointer).

For instance, how will you save to disk shared references to game objects that rely exclusively on pointers?
You have to have an ID on top of that, whether you call it "shared pointer" (smart pointers in boost for instance) or hand-made ID.

7
Programming / Re: Tracking targets
« on: December 22, 2010, 04:09:16 PM »
I agree with some advices given here:

1 You should use entity IDs for storing logical relationships between game objects not pointers.

2 The entity initiating the relationship is the one responsible for managing it, not the other way around (eg: AI decides to target an item, so AI is holding the targeted Item ID and will check for the item validity and status).

3 An AI planning over many turns is not as interesting as it sounds. You have to explicitly code reactivity to game state changes or the AI will appear even dumber than a purely stateless reactive AI as the planned AI risks persisting in doing irrevelant actions (eg: AI keep trying to get a far away item while under fire; sounds easy to fix but you will have lots of situations like this to think about and code proper reactions).

There are a lot of benefits in doing 1 and 2 with only the negligible overhead of using a hashtable for ids.

8
Early Dev / Re: Rogue Survivor Alpha 6
« on: December 15, 2010, 10:14:25 AM »
Is it common knowledge that cars are a survivor's best friend?  I just figured it out last game I played and man, it makes such a difference.  I lasted for over 3 weeks that time.
Indeed cars barricades can be very effective. But remember that ZMs and high-tier zombified can push them. If you are patient enough you can make very strong barricades. That's ok with me, as you must invest time doing this rather than getting supplies for instance.
I reduced their numbers in 6.0 and might consider adding more restrictions to their usage, such as needing someone to help you pushing them.

Quote
Do the national guard guys stop showing up or become really rare after a certain amount of time or something?  It seems like there are no NPCs around who can stand up to the undead between the time when the national guard guys stop coming and when the survivors start showing up, and by then the undead have an unbreakable grip on the world.

I understand that it's supposed to be pretty desperate by that point (and it is!) but I think the game is a lot more fun when you're interacting with your fellow survivors.
Other stuff is supposed to happen that is not implemented yet, but it is supposed to be harder and harder as time pass anyway.

Quote
Do zombies start upgrading automatically after a while?  I see a lot of the zombie princes, but I don't see enough survivors for that many of them to be plausible.
Correct.  Invasion events (the midnight zombie thing) bring more and more high-level zombies : each zombie that invade has a % chance to be upgraded, this % increase over time.
The rationale is that they come from other places where they already killed enough people to upgrade.

9
Early Dev / Re: Rogue Survivor Alpha 6
« on: December 14, 2010, 03:52:15 PM »
I understand the ESC thing. You redefined the key for exit for the game keeps mentioning ESC as the exit key. I'll fix that.

Self-defence counting as murder seems to really annoy the players. I'll add code and data to handle self-defence cases.

10
Early Dev / Re: Rogue Survivor Alpha 6
« on: December 13, 2010, 12:57:10 PM »
Thanks for the comments.

Getting the game running was kind of a pain.  The default sound/graphics options didn't work for me, and I had to download the configuration executable to change them separately from the game itself.
This is an oversight in this release, the configuration program was supposed to be included in the download.

Quote
I'm not a fan of keeping saves in the "my documents" folder instead of in the same folder as the game, but I guess that's personal preference.
Same for me tbh, but some people who use the installer can't find their program files folder. At least everyone knows where their documents folder is.

Quote
I also didn't care for the hints the game throws at you as you play.  The concept is fine, but the little reminder is intrusive, and I didn't see a way to turn it off after starting a round.  I recommend a key to turn off future hints at the hint screen instead of only making it available in the options menu.
You can access the options in game to disable the hints. Shift-O. Remember you can access the keys with Shift-K (its in the welcome banner).

Quote
It's possible to rebind the exit/cancel key from escape to something else, and this can make it impossible to get out of certain menus.  When the aforementioned situation came up, the game resisted my attempts to shut it down. 
I don't understand this. Why it is impossible? The ESC key doesn't work? Are you running the game on a laptop or notebook?

Quote
Is there a way to reset keybindings to their defaults?  I didn't see if if there was.
No.

Quote
Basically, I think the gameplay itself is fun, but there are a lot of other things that need work.
Don't hesitate to tell me about these "lot of other things" I'm here for that.

11
Early Dev / Re: Rogue Survivor Alpha 6
« on: December 11, 2010, 03:21:25 PM »
Updated for Alpha 6 release.

12
Early Dev / Re: Rogue Survivor Alpha 4.3
« on: November 27, 2010, 05:42:27 PM »
Alpha 5 out. Please use the other thread.

13
Early Dev / Rogue Survivor Alpha 6
« on: November 27, 2010, 05:41:20 PM »
New new release.
Still Alpha but not really.  :D

Download & More
Check the blog:
http://roguesurvivor.blogspot.com/

About

Rogue Survivor is a free zombie survival roguelike sandbox game with unique features and modding support.
The game takes place in a town famous for being the headquarters of the powerful CHAR Corporation.You wake up amidst the chaos and you must find ways to survive.

Survive in the city

    * Play as living or undead.
    * Survive the zombies!... and the humans.
    * The undeads get stronger every day.
    * Find food and shelter... but you're not alone.
    * Reincarnate when you die and continue playing as another character.
    * Graphic tiles, mouse support and musics.

Interact with NPCs

    * Fight raiding gangs.
    * AI controlled survivors are trying to survive just like you.
    * Trade with other survivors.
    * Lead a band of survivors.   
    * Get help from the National Guard.
    * Commit murders...
    * ...but watch out for the police.
    * ...and of course beware the undeads.

A dynamic game world

    * A dynamic procedural world.
    * A city with different districts, buildings, sewers and subway.
    * Push or destroy objects, build barricades.
    * Day/Night cycle.
    * Weather.
    * Things happen all the time, the world is not waiting for you.

Get tools, skills and friends

    * Learn skills by surviving to see a new sunrise.
    * Scavange items and barricading material.
    * Various weapons and items. 
    * Get followers and turn them into useful buddies.

Learn, Customize and MOD

    * In-game manual and hint system.
    * Redefine the keys.
    * Wide range of options to configure the gameplay and the difficulty.
    * Resizable game window, playable on any resolution.
    * More than 10 original musics.
    * Mod the graphics, musics, actors, items and skills.
    * Selection of different rendering and audio engines.


New features are added with each update!
Grab the latest version on the download page!
For Windows systems only.

14
Early Dev / Re: Rogue Survivor Alpha 4.3
« on: November 24, 2010, 01:10:43 PM »
Mmh. Can't seem to reproduce the bug on my computer.
RS is using standard WinForms input methods.
The bug might have to do with some weird key data being set on notebooks the second time you press the Ctrl/Shift/Alt key.
Annoying.  :-\

15
Early Dev / Re: Rogue Survivor Alpha 4.3
« on: November 23, 2010, 10:24:56 AM »
I'll check that, might have to do with the UI input code or threading.

Pages: [1] 2 3 ... 5