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 - BirdofPrey

Pages: [1] 2 3
1
Programming / Re: Methods against Save Scumming
« on: March 25, 2011, 08:13:02 PM »
I still don't see how it makes permadeath more meaningful but I realize now it's not a worthless exercise.
It's the only thing that makes permadeath meaningful in the first place

Permadeath isn't a thing if it's not permanent

Yes but making cheating harder doesn't affect that at all. For the people who don't cheat permadeath is just as meaningful as it was before and for people who do cheat it will also be just as meaningful (i.e. not at all).

2
Programming / Re: Methods against Save Scumming
« on: March 25, 2011, 05:09:59 PM »
Can you explain the assertion that making savescumming harder makes permadeath more meaningful? You've said it a couple times but I'm not getting it. We've already established that people who want to savescum will do it anyway.

e - After considering a little more, I do see a bit of a point. Making it harder to do may discourage a subset of the savescummers from cheating and instead play the game in a way that is actually tense and fun. I still don't see how it makes permadeath more meaningful but I realize now it's not a worthless exercise. Still, as others have said don't put too much effort into this aspect :P

3
Programming / Re: Methods against Save Scumming
« on: March 25, 2011, 12:55:54 PM »
You're combatting a problem that doesn't exist.

edit - particularly if you're adding savescum functionality as a feature of the game. Why prevent people from doing something indirectly that you've already allowed them to do directly? It makes no sense.

4
Programming / Re: Making a Mac Roguelike
« on: March 17, 2011, 05:01:22 PM »
Making a small scale game for a specific OS is totally understandable but the kind of game you're talking about (which would be a gargantuan feat to program) would be quite a waste if you cut off more than half of your potential players. I'm making a roguelike on OS X myself but I'm restricting myself to cross-platform libraries and would advise you to do the same.

Of course, if your main objective is to learn cocoa by all means do a project in it but it doesn't sound like a good idea to blow your epic roguelike load on it.

5
Programming / Re: Non-random content
« on: February 22, 2011, 08:38:08 PM »
I'm one of those people who are really annoyed by static content in ADOM, and this thread compelled me to think about why exactly that is. I decided I'm totally cool with doing one dungeon after another or whatever, as puppy cave -> whatever dungeon isnt functionally any different from doing D1-5 before D6-10. What really pisses me off is GETTING the quests every time, every single game having to search through the entire town full of agonizingly stupid NPC's who just wander randomly, and finding the one who gives the quest who is often in the last place there is to look.

So in conclusion, I think static content is fine, as long as you're aware that any annoyances found in the static areas, even minor annoyances, will become enormous annoyances because you have to do them over and over and over again.

6
You've basically completely nailed what I'm planning. What you suggested will be a perfect stopgap for between my implementation of individual AI and group AI. In the end I'll want to have a general framework for hierarchy of command because certain other constructs will use it as well, most notably the AI personality that runs the lab branch.

7
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.

I like this... behavior implementation will be a good entry point to my scripting system. If a certain creature can control teleport at will, I can change its GOTO_DESTINATION behavior to change both how the behavior is turned into an action and I can also define it to have a much lower search cost to that behavior to simulate moving around being so easy.

8
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.

This could work... it could be quite costly to replan for every active agent in the game, particularly since agents wont just 'freeze' if you go to another level, but I could compromise by replanning every turn for every creature within sight / general proximity to the player.

As far as the top-down vs. bottom-up,  I was going to do bottom-up (GOAP) for the individual NPC's, and top-down (HTN) for the groups to determine what the bottom-up goals should be. So the higher-level pincer attack task could translate to goals to form groups on both sides of the player and then swooping in, but the individuals' task of getting to their respective groups and the attack itself could be done in a bottom-up way. I'll certainly let you all know how it works out. Seems promising in my head.

edit - Oh yeah, and the game will be fully turn-based. Although, far far far in the future when this game is complete, I am contemplating a real-time RTS mode where you play as the hive instead.

9
words

You're right, I didn't really give any details on the nature of the game. I haven't said too much about it outside of IRC yet, but I might as well spill the beans.

The basic premise is that you are an exterminator, and you must destroy a newly-created race of giant, telepathic hivemind insects before their numbers proliferate beyond control, dooming the human race. While the actual combat will be mostly roguelike-style (with lots of ranged combat ala doomrl), the various factions of the game will manage their resource gathering/usage and unit deployment in a more RTS-like fashion. Meaning if you fight your way through to various egg chambers and torch the eggs you'll be saving yourself some future pain and wasting hive resources.

A key mechanic of the game is that the hive insects are all mentally linked, behaving like 'fingers' of a singular consciousness. Therefore I need the hive to be able to coordinate pincer attacks and flanks, as well as hanging back and attemping to flush the player out of small corridors instead of piling up to be dealt with one at a time as is typical of roguelike AI. The hive will also learn from your actions; the first time you throw a grenade, they won't know what it is. The second time they will know to either run away, try to kick it back at you, or sacrifice a unit by throwing it on top of it to protect the rest.

It might seem that the game is overly stacked against the player, especially considering that when one of them sees you, they all know where you are, but there will be various ways the player can disrupt the hivemind. In order for the bugs' psychic link to penetrate thick layers of rock (floor to floor), there will need to be special 'transmitter' bugs in the area, acting as vertebrae in the spine of the hive. If all transmitter bugs are killed on a floor, the remaining insects will be disconnected from the hivemind and easier to pick off. This obviously makes them a prime target for players and an important asset for the hive to protect. Disconnected hive insects won't learn either, so killing off the transmitters and then throwing the grenades won't let the hive learn about them. There will also be shorter-term solutions, like EMP pulses that disrupt the psychic link for a temporary period of time.

It's not just the bugs that will be using this group behavior either. There will be waves of police/military coming down, who will be giving information and taking commands from commanders on the surface. The AI entity that oversees the laboratory area will also be an important character, and will control a sizable host of robots for offense/support/repairs as well as numerous cameras for information gathering and monitoring.

I think what I'm looking for requires more than FSM's to pull off, but if you can think of a way that I could make it work I would love to hear it. In general I prefer simpler solutions but it seems to me that what I want to do is somewhat beyond the realm of FSM's.

I like that concept of dynamic terrain, although it would complicate things if you added player allies to the mix.

edit - I guess I should mention a bit more about what I want combat to be like. As I mentioned it will probably seem somewhat like DoomRL, with an emphasis on ranged combat. Fighting humans will probably involve a fair amount of running and finding cover, while fighting the bugs will often come down to mowing them down as they attempt to overwhelm you with their numbers, though some will have ranged attacks too like acid sprays / poison barbs or whatever. Even the bugs simply swarm-rushing you will require some modicum of coordination though, since I would want them to form a group(s) together near the player before attacking all at once.

10
Sounds like you plan too much. Just do it. Then check out what went wrong. If a generic AI theory doesn't fit in, don't use it.

I decided you're right, it's way too premature to try to plan out the squad aspects right now. Started a simple GOAP system that is currently correctly generating a basic 'move to player -> melee attack' plan, I'm just going to build up on it and see where it goes.

Still wondering about the replanning process though, if anyone has used these systems before.

11
Programming / Advanced AI techniques in roguelikes (GOAP and HTN planners)
« on: February 06, 2011, 08:57:44 PM »
I recently started to design the AI system for my big roguelike project. The standard roguelike AI uses finite state machines but those are not nearly expressive enough for my needs... I want the AI agents to make decently intelligent plans to carry out their goals and be able to re-plan in reaction to changing world states, and one of the main gimmicks of the game requires certain enemies to behave in a highly coordinated manner as if they share a singular consciousness.

The obvious choice is to spring for some kind of planning system, but after reading a bunch of dissertations on various planning systems it seems that each one on its own has some rather hampering weaknesses. My first choice, GOAP (Goal-oriented Action Planning), is pretty decent at planning and re-planning for individual units but has some issues, some of them being the inability to express compound actions (since all actions are considered 'primitive' actions that act directly on the game world) or to force certain actions to be performed in a certain order (which could lead to unwanted behavior like, for example, a creature advancing to melee range of their target BEFORE drawing their melee weapon, when the opposite order should always be enforced). It also seems to be less than ideal when it comes to coordinated group behavior.

The other method I've been looking into, Hierarchical Task Networks, solves all the aforementioned issues and is well-suited for group tactics, but seems to be fairly weak when it comes to reacting to a changing world state, and since it uses a top-down search instead of a regressive one it seems very difficult to make good cost estimates for a working A* search. I'm worried that using a simple depth-first search instead may make the resulting plans too deterministic.

I'm playing around with the idea of combining these two approaches: The HTN planner would be reserved for higher-level abstractions and group strategising, while the GOAP planner would handle the individual units. I think if I pulled it off correctly both systems could complement each other and could result in smart, coordinated monsters without being too difficult to extend its behaviors and goals. I'm having a hell of a time figuring out how to plan the actual implementation, however.

If there's anyone here with any kind of experience with these types of planners, do you have any advice for how I should go about things? In particular I'm wondering at what level of abstraction I should make the bridge between the HTN and GOAP system, and how exactly I can map HTN tasks to GOAP goals. I'm also kind of unclear on the replanning process. What is the best and least computationally expensive way to keep track of whether a given plan is still viable or not? Re-checking the preconditions of every action in the plan every time an agent's working memory changes slightly seems way too costly.

Any help/thoughts would be appreciated. Sorry if this post is kind of rambly/unclear, I still only have a rudimentary understanding of the way these planners work in actual implementation, and I imagine it shows.

12
Programming / Re: Skill suggestions
« on: November 26, 2009, 09:59:50 PM »
Why is it more convenient to have 26 skills represented by a-z than say, 10 skills represented by a-j ?

Just my opinion, but 52 trainable skills seems a little bit over the top.

13
Programming / Re: View of a Scrolling Dungeon
« on: November 25, 2009, 03:59:48 AM »
I was thinking of keeping it consistent in just centering it at the average of enemy positions on the screen, making sure all currently visible enemies are visible on the screen. I would include an option to just have it centered on you though, crawl-style.

14
Programming / Re: View of a Scrolling Dungeon
« on: November 22, 2009, 06:26:46 AM »
I've been thinking of my own scrolling scheme I wish to implement soonish... Eventually I'd like a scrolling smoothly animated screen that keeps up with you depending on how far you venture from the center, that automatically shifts the camera to a spot between you and all visible enemies, though you could move it yourself at any time by holding spacebar and moving it around with the direction keys. Tapping spacebar would center the camera.

What do you think of this setup? Any problems that I didn't think of?

15
Programming / Re: Burnout
« on: October 05, 2009, 02:55:03 PM »
I'll add my vote to playing games too.

Another point that nobody mentioned yet: keep the code clean and easy to work with.  If you implement something quick & dirty because you want to test some ideas go back to it afterwards and refactor it into something that's easy to work with in the future.

The code doesen't have to be 100% brilliant at all times, but make sure it isn't too bad and doesn't have ugly hacks, especially not if you are thinking of letting in go for a while.

You are *that* much less likely to continue working on a project after a while of being away if it is a horrible mess.  So tidy up before you stop, and then take a break.

-Ido.

Yes. If you know you might be taking a long break, you should really try and force yourself to 1) leave code that is as clean and manageable as you can and 2) dont leave in the middle of a section. I took a hiatus once in the middle of a complicated mapgen algorithm and when I came back just the thought of figuring out how it all worked again compelled me to scrap the whole freaking thing and start from scratch. Which wasn't a bad thing necessarily but avoid the situation if you can.

Pages: [1] 2 3