• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

108 Neutral

About Shadax

  • Rank
  1. Regarding an architectual mix between BTs and FSMs: Crytek uses exactly that approach. Basically the AI's decision making system is a classic BT with all the typical nodes (Sequence, Selector, Loop, Action, custom Decorators, etc.). Plus, it offers a StateMachine node that houses multiple State nodes. These are decorators that in turn house a single BT on their own. Transitions between States of the particular level a BT lives in can be triggered arbitrarily from within that BT by sending a signal. So, instead of having to propagate success or failure all the way up in the hierarchy, a signal can be sent, which gets handled by the StateMachinde by activating different State (i. e. BT).     Cheers!
  2. Disclaimer: Neither do I have much practical experience doing path following in more complex scenarios.         I think this approach can fall short when the agent has been pushed off his course far enough to end up behind a wall whereas his target position resides exactly on the opposite side of that wall -> steering forces would eventually cancel out each other. And worse: he could then start sliding himself into a dead-end while still trying to reach the target position and avoiding that wall.   Here's what I would try to experiement with: apply a slightly modified Funnel algorithm on a more local basis while moving. You could pass in the target point where your agent intends to steer towards to, then let the algorithm figure out a point that lies withing a valid funnel. If the figured-out point happens to be your target point, just steer straight towards it as your agent won't go off the navmesh. Otherwise, scale the direction from your agent to that point by some amont representing your intended steering force, and move towards that point. Repeat while moving.   Does that make sense?     -- Shadax
  3. I have no experience in wrapping a BT by a higher-level GUI (had to build my BTs in XML by hand, and the flowgraph thingy was based on a totally different technology that existed already), but it sounds like something that has been done by other gaming companies - Alex had often mentioned the possibility to expose certain nodes to the game-designer differently than what's going on under the hood.
  4. From my experience, one's users (game designers) are more comfortable with flowgraphs, rather than fully-fledged BTs that offer the full spectrum of what can be done with such a system. Most of the time, our designers were using sequence-like nodes in their flowgraphs, and also parallels, though they were not called "parallels", but were rather wrapped by a "synchronization". Also, nodes couldn't fail - just execute and then finish, which simplified their way of thinking. To be able to do branching, a named flag could be set by one node, and be queried by another condition-like node, which had 2 outputs (condition being true or false) that linked to the further nodes. So, things were simplified for the sake of usability by having every node implicitly act as a sequence as well as a parallel without a BT-like fallback mechanism.   So, the flowgraphs were like a Windows OS (get simple things done quickly on a higher level), whereas the BT was more like a Unix-like OS (combine small low-level tools to build really powerful things).   -- Shadax
  5. So, you got a better idea where to post this question?!? Regards
  6. What's up with this book? Prices are starting at beyond 500 bucks for that title!? Parts 1-3 are still reasonably priced, but something's odd about #4. Is it out of print and contains secret CIA knowledge or what?? Regards, Shadax
  7. Hello, I think my concern was that I saw problems where there shouldn't be any. Call it lack of experience. Alex and Ashaman73 were right, there's basically always one active node that gets processed frame per frame until it finishes (with success or failure). When something in the world happens, then that active node gets asked if it can handle the event. If it can't, there might be another node in the tree that can. In that case, the so-far-active node gets cancelled by some manager (usually by the containing tree structure itself), and then starts the new node. Passing control to another node follows a clean sequence ("sequence" here is not meant in terms of a "sequence node" of the BT): (1) ask a potential candidate to take over control. If it accepts, then (2) shut down the old node and (3) start the new node and then (4) keep updating the then-active node until it finishes or a new event occurs that it can't handle. NB: I wasn't accustomed to the term "priority selector" in Ashaman73's sample, but having read that Spore article on the net, I can now see the difference between a *simple selector* and a *priority selector* wheres the latter one is always re-evaulated until it hits the currently active path on each frame. Please correct me if I'm wrong (or tell me whether I'm right). Greetings, Shadax
  8. Sorry for the late reply. Just to get this right: so, in your BT you always have no more than 1 active [i]leaf-node[/i] and keep track of it ? And you continuously re-evaluate the whole tree on every simualtion tick? And when a [i]different[/i] node eventually becomes active, you disable the [i]old current[/i] node (and all its parents up to the root of the tree) and switch execution control to the new node? I'm not sure about my above assumption when it's about [i]Parallels[/i]. I'd assume that a [i]leaf-node[/i] would no longer be marked as the active one, but rather the Parallel then, right?
  9. That's an interesting idea, Ashaman. Do you also have any mechanism that kicks in once a particular node is no longer being visited? Elaborating on Alex' idea: On a per-tick basis, we could keep track of all nodes being visitied in an "active list" and assign them the current tick-counter. Everytime a node gets visited, its tick-counter gets updated (so that it reflects the global tick-counter). After a traversal of the tree is finished, we compare the tick-counters of all nodes in the active list with the global tick-counter. If we find that some nodes of the active list contain tick-counters of the past, we then know that these nodes haven't been visited in the last tick and could explicitly give them the chance to clean up. Just some quick thoughts. And I suppose this idea may introduce some undesired side-effects, e. g. when a new node is getting control before no-longer-active nodes start their cleanup process (like starting a new animation, then stopping the old one on the same animator). Greetings, Shadax
  10. Thanks for the hints, Alex. The thing about events would have been my next question: How could the BT pointfully stop a specific Action that reports to be be "still_running" and notifying it of getting stopped? I think a classic example would be a character being able patrol and to fight an enemy. I'm considering a simple BT like this: [html] (?) /\ / \ / \ / \ [->] [A:Patrol] /\ / \ / \ / \ [C:HasEnemy] [A:Fight] NB: (?) = selector [->] = sequence [C: ...] = condition [A: ...] = action [/html] Then, to have the Patrol Action no longer run when an enemies comes by, the tree might have to be changed a bit (notice that the order of the sub-trees is now swapped!) : [html] (?) / \ / \ / \ / \ / \ / \ [->] [->] /\ /\ / \ / \ / \ / \ / \ / \ <Inverter> [A:Patrol] [C:HasEnemy] [A:Fight] | | [C:HasEnemy] NB: <Inverter> = Inverter Decorator [/html] And this is where my understanding of BTs starts lacking: Is it correct that the Patrol Action would then simply no longer be updated (no matter of the status it reports on every tick) without ever giving it the chance to "shut down in a controlled manner"? I can sense that I could add even more nodes in the BT to somehow help the Patrol Action getting notified or even executing a completely new Action, which could deal with the "shutdown of the Patrol behavior" - kind of a "helper Action" for "the real Action". The more I think in that direction the more I get the feeling that the BT can easily become overbloated and thus getting more and more lost in details.
  11. Hello, assuming there's an Action in a BT that would take more than one simulation tick to execute (eventual success or failure shall be ignored for now). How exactly does the update of the whole BT work in such a situation? (A) Does the tree re-evaluate on every tick from its root down to all children until meeting that Action which is found being still in progress and having it execute a bit further? (B) Or does the tree somehow "remember" what its last Task was that hasn't finished yet and simply continues with that task on next tick? And then there are Parallels... if I understand their concept correctly, they too, would be updated every tick as long as their parent Task hasn't finished yet. Thus I assume there would be [i]several[/i] Tasks being marked as "still_running" [i]at a time[/i], and the BT would execute all of those "still_running" Tasks on every simulation tick. Greetings, Shadax
  12. I was hoping that if I get pointed in the right direction I could learn something new about game AI programming. My idea was: first read about the according theory in books and then try to match that theory with a game that used that specific technique successfully. I thought learning something new might be easier that way (I want to prevent reading the "wrong" stuff and getting lost). Does this make sense?
  13. Thank you for this information, Dave. It should point me in the right direction for learning something about HFSMs by a practical example. Greetings, Shadax
  14. Hello Thank you for your effort so far, Dave. I assume "the suits" haven't given their approval yet. Out of curiosity: why do you think that it's probably a BT and not a goal-oriented behavior as the major component? (Disclaimer: I'm just learning about BTs, nevertheless I think I'm used to GOB, at least when it comes to what Mat Buckland's famous book tells us about it). From my level of knowledge, GOB aims at continuously satisfying all "needs" of the character, thus building a small plan for the most insistent need at a given time, executing the actions set up by the plan until these actions are all successfully finished or until an even more urgent need from the character's state space arises. Thus, I can see many parallels between what I think GOB is about and how the enemies in Splinter Cell behave - at least too many to make my current lack of experience about BTs prove me wrong. Greetings, Shadax
  15. Hello everyone, I was wondering what kind of AI system(s) Splinter Cell Conviction might have used. Just a simple FSM that always has the enemies be in states like "relaxed", "alerted", "seeking player", "combat", "taking cover" at a time? Or did they implement a rather elaborated goal-oriented AI system, that constantly tries to satisfy the enemies's needs? Greetings, Shadax