Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 May 2012
Offline Last Active Apr 06 2015 06:07 AM

Posts I've Made

In Topic: How should systems pick which entities to process? (Entity Component Systems)

06 April 2015 - 05:23 AM

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.

In Topic: Advanced unit steering (e.g minion movement in moba games)

06 April 2015 - 05:10 AM

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?

In Topic: Implementing a quest/achievement system

06 April 2015 - 05:08 AM

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.

In Topic: Question about saved games

18 March 2015 - 09:07 AM

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.

In Topic: Changing a Request-Response based interface to a synchronous one

18 March 2015 - 06:00 AM

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.