Jump to content
  • Advertisement

Max Yankov

  • Content count

  • Joined

  • Last visited

Everything posted by Max Yankov

  1. I'm surprised that so many people in this thread treat the choice of array vs vector as a major early-time design decision. Array vs vector is implementation detail; expose methods that will allow you to iterate through components, add and delete them, so that the user of this system won't even know if it's array, vector or experimental probabilistic data structure on the inside.
  2. You already have working A* algorithm, and it takes the red wall into account. Can't you just provide information about other units to this algorithm in the same way you provide information about the wall?
  3. It's generally a good idea that you're trying to keep different mechanics modular, and expose public interface with information that these systems need.   However, quest and achievement mechanics (at least, how they're usually understood) are conceptually different: you don't get new dialog options because you unlocked some achievement, but you certainly will see new dialog options if you're on a certain quest (you didn't mention this scenario, but it usually exists). So, since the quest mechanic can affect the behaviour of dialogs and vice versa in a variety of ways, they need to be coupled closely. How exactly — depends on your exact goals and game architecture.   But if you're talking about achievements, statistics, user analytics and other mechanics that can't affect the gameplay in any way, you only need to pass information one way, and while achievements/stats/analytics need to have knowledge about NPC/Dialogs/Quests, the latter don't need to know about the former. So, as you suggested, I would expose a public interface with read-only access to all necessary data. Also, if your language has events, I would use them instead of public getters: that way, your achievement system can just subscribe to an event and then act on it, instead of constantly checking if the variables changed.
  4. Max Yankov

    Question about saved games

    Also, it's a good idea to write a lot of unit and regression tests for this, as changes in save-files can be one of the most painful for the players, especially in single-player, story-driven games. Save new binary saves every time you touch the load/save functionality, and ensure that before you commit, all previous versions of save-files can be successfully read. You may want until release to implement such a testing system, but then in the haste of final crunch and then immediately releasing a patch you may forget about it — and upset a lot of users. Especially if you plan to release an early version of the game for preview.   Maintaining backwards compatibility can be painful; personally, I prefer using migration pattern for that. Every time I change the format, I write a special migration method that converts the previous version to the current one, so that n to n+x save-file goes through x consecutive migration methods. This makes the main save/load logic simple and clear of all the special flags and exceptions for the older versions, and so easier to maintain.
  5. What language are you using? Threading and asynchronous logic is a very language and sometimes even framework-specific thing. In modern C#, for example, there are async/await, in Unity's version of C# there are coroutines, and in your language and framework of choice there are likely to be some specific mechanisms for this.
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!