Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

212 Neutral

About kremvax

  • Rank
  1. I would add that in terms of code design, it's often a bad idea when you try to be as flexible as possible. The motivation can be good, be the result is often bad - leading to overly complex design; and while you tried to "design" for change" you end up with something harder to refactor. Which is well illustrated here:
  2. Hmm, looks like you're describing the decorator pattern?
  3. Very interesting article, but it raises some new questions. If I can sum up the GC part of your post, we can say having long-term life variables is better than short-term (and anonymous functions, immutable etc.). It can be a pain for good code design, so I guess it's recommended to optimize only hotspots when necessary.   By the way, GC engines can evolve, and they will of course. When looking at the java GC, we can see there are efforts to make short-term variables performing as well as long-term, in order to reduce the need of optimizing against code design. We can hope the same will happen for JS engines.
  4. kremvax


    It's just a solution, among many other. Up to you!
  5. kremvax


      I agree with that but if there's no need for complex dialog here, then simpler is better. The idea of a simple sequential data file is ok when there is no multiple choice questions for the player, no "behavioral" AIs who would have to choose between various responses, etc.     (my post wasn't clear about that ... just edited it)
  6. kremvax


    @diventurer , I guess the idea is to make it easier to translate the texts if ever the game went to be localized. Simple CSV files are fine for that. I mean they are fine for storing keys / values kind of data, but the dialogs structure should be defined elsewhere.     Czar05: Since you have linear dialogs, the structure is not so complicated. For instance you could have :   - 1 structured data file (like json data) which stores the dialog sequence { KEY_SEQUENCE: [{ character: X1, KEY_TEXT: Y1}, { character: X2, KEY_TEXT: Y2}] }   - localization CSV file KEYS, EN, FR, DE ... Y1, ..., ..., ... Y2, ..., ..., ...
  7. kremvax

    Implementing Component-Entity-Systems

    This is an interesting article, however I'm not really convinced by a full component-entity architecture, throwing away all OOP design. It's still possible to use composition inside a restricted inheritance tree, an entity being not just an ID but an object composed with delegate classes. The inheritance tree would only reflect the nature of the objects, in that it is very unlikely to change over time (I would say, if the nature itself of an object has to change, probably it means that a new Object should be created instead), and composition is used to implement some specific behaviours only. For instance I would see a "Character" class ; an AI would be Character composed with AI behavior, a player would be Character + input-related behavior, but they really share the same nature.   Describing entities as objects + delegates may also speed up debugging I think (I've never try it but having to look for an ID in X differents tables when doing step-by-step debugging doesn't sound to be as convenient as seeing the whole object's properties in one sight).
  8. Hello,   The "why it changed" is fine considering this commit is not responding to an opened, reported issue. But I would say ideally the issues should be reported first (github provides an issue system), and then a link to the issue in the commit message would simply answer to the "why" part.   Also, you could also write more in-code comments. Commit messages are only read when the commit is submitted, and then forgotten (except searching in the git history, which can be a pain after hundreds of commits), whereas code comments will still be read on further developments.
  9. kremvax

    about keyword and include

    in this example you only use language native elements, without referring to any external function, type or class. That's why you d'ont have to include anything there. Just add somewhere   std::string s = "foo";   and you'll get an error because of missing headers.
  10.   by this you mean something like a script driven system for conversations between npc's?     Script or even just data (difference between script and data can become thin). Like what I've started to do, things like this : [{ text: "Hey %name%, show me what you can sell! I'm looking for %goodstype%", condState: [buying], responses: [{ text: "First choice quality, take it!", condState: [have], responses: [{ text: "Thanks, goodbye." }] },{ text: "Sorry %name% but I don't have any, come on later.", condState: [dontHave] }] }]   an excellent question, i've always done hard coded myself.  anyone out there use scripts?   if so, why?      i have full source code access, low compile times (at least during the early stages when i do AI), and don't have non-coders to deal with, so i've never needed scripts.   I read this yesterday : http://intrinsicalgorithm.com/IAonAI/2012/11/ai-architectures-a-culinary-guide-gdmag-article/ and found that the Sims-like approach, with an utility function that computes a score for each pair of Action+Character, would really fit my game well. At least I hope. And it allows some data-driven tuning if I explode the utility function, for each action, in parameters that are quantifiable.   For instance let's say I have an "Eating" action. Its utility function will be parameterized with a weight on AI's hunger. This weight can be an external data.   The counterpart is that this approach will give me less opportunity to script very special behaviors for particular characters.       this thread should help....   http://www.gamedev.net/topic/638940-types-of-quests/   i've done some serious quest and mission generators in the past. my games tend to use procedurally generated content, so i've had a lot of practice writing quest and mission generators.   Thanks, I'll read it soon!       stuff like that's easy to handle with code.   and that's another thing you must watch out for in writing quest gens, perhaps the most important.     when writing quest gens, you must prevent by design, or check for and handle, everything that could possibly happen to make a quest un-doable. otherwise the player gets stuck.  this can get complicated.  the checks can easily double the size of the code that runs a given quest.   Thanks for the tip. I think if on every quest "object" I keep a reference to the places / characters / objects involved, and with an "availability for quests" boolean attribute on each game object it looks like we can handle that in that way... (i guess)
  11. Hello, I'm starting a new RPG project, which is my first RPG (I've already developped smaller games), but before going too far in the development I need to take some time of reflection. The problematics in RPG-programming sound much more complicated than everything I've done before. That's why I'm looking for good and modern literature about RPG programming, unfortunately it turns out to be quite hard to find reading on such specialized domains. I'm especially interested in: - How to design a data-driven dialog system between AI - How to design AI behaviors? Pros and cons between hard-coding and scripting ... - How to design a powerful, flexible quest system - Common pitfalls to avoid in these domains? So any thought, any links to litterature would be greatly appreciated. Maybe I don't look to the right place, but I didn't find anything of interest in gamedev's articles, directly related to these subjects. I'd be surprised not to find any reference on that in 2013.     --------------   Now let's give some more information of my own project, if you're ok to read more - I've already started to implement some stuff, it's more like a draft than final code that I will use: it's still time to refactor, and I'm going to do some. It's all C++, with json data. See https://github.com/jotak/RPGProject/tree/reorg_dialogs . I've started to implement some AI behaviors, dialog system, etc. But I'm not sure if it will still fit well when the project grows up. It must be scalable. See in particular this folder : https://github.com/jotak/RPGProject/tree/reorg_dialogs/Sources/AI . - AI class refers to an AI character. - Each AI have some traits. There's a method that compute the attraction between AIs according to traits. Space is partitionned in order to limit the possible interactions between AIs (no need to compute interaction with someone 5 miles away) - Each AI can have a "timetable", in json, which tells at some hour in the day what it's supposed to do. - Each AI is doing an AIAction, which is either taken from its timetable, or dynamically attributed in code (for instance when I'm starving, I'll try to buy food and then eat). I already can see some limitations induced by this system. Timetable are written in json. What happens if everyday at noon I go to lunch at the inn... then inn's keeper get killed, the inn closes... my timetable becomes invalid, I have to dynamically write a new one? Isn't LUA or such scripting language more adapted for this? Maybe the best way would be to create a json/LUA interface, if it doesn't already exist?   This is just a quick flavour among numerous questions I have on these subjects.   Many thanks. Joel
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!