Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

679 Good

About metsfan

  • Rank
  1. metsfan

    You Don't Need to Hide Your Source Code

    I should send this to my boss, he'd get a good laugh.  Good luck getting anyone to invest money into your game if your source code is open source.  The premise of this article is flawed, and that is demonstrated by this statement:   "Understand: keeping source code secret does not by itself do anything to stop unauthorized copying.".    Businesses do not keep their source code a secret to prevent unauthorized copying.  There are other measures built into software and sometimes even hardware to prevent this sort of thing.    The purpose of keeping source code a secret is all about equity.  Source code is an asset.  Businesses spend anywhere from tens of thousnads to hundreds of millions of dollars building source code.  The applications themselves are valuable, yes, but the real value is in the source code itself.  By exposing the source code of their applications, a business would essentially be inviting competitors take what they spent their hard earned cash on, and put you out of business.  Additionally, sometimes in business the only thing you have on other competitors is a head start, and by giving out your source code, you forfeit that advantage as well.   I understand where you are coming from, and it is noble, but naive.  Businesses take OSS every single day, brand it as their own, and give absoutely nothing back to the community, and snicker "those open source idiots, they saved us millions, and we dont have to give them a dime".  I'm not saying OSS is bad.  I love OSS and contribute to it myself.  But the way us idealistic software developers think of OSS is not how the majority of the world, especially the MBAs, think of it.    TLDR - OSS is great, but sometimes its best to keep things to yourself, especially if you are trying to make money and/or have competition. 
  2. metsfan

    Engaging Independent Creative Professionals

    Well written article.  I would change the title though, and generalize this article, as these tips are good advice when dealing with ANY kind of contracted work.  
  3.   If performance is not an issue, this system should work fine.   The problem here, is that using a string map, or even an integer map if you decided to use an enum instead of strings, is that if you are looking up components in a map, and you are doing this many times per frame (in the hundreds or thousands), the performance will suffer big time.     The way I have implemented the entity-component model if performance is important is to use multiple inheritance  and use the compentent classes like "mixins".  For instance, if you want a Rock to have Sprite and Velocity, per the example in the article, you would do:   class Rock : public SpriteComponent, public VelocityComponent   Now Rock has those getters/setters, and you don't have to do any icky dynamic casting or string map lookups, of course at the cost of the dynamic ability to create new entity types, since now you will have to create a new class definition for each new entity type.  Tradeoffs.
  4.   It is not explicitly stated in this article, but I have implemented such systems before.  I always did this sort of thing, as you suggested, on a "per object type" basis.  This avoids the needs to dynamic_cast every object coming out of the system, and also just seems to make a bit more sense to me (for instance, in a relational database, you have a separate ID sequence for each table).   I will say though, that if he had used pointers in that vector, it would alleviate any allocation errors for derived classes.
  5. metsfan

    C++: Custom memory allocation

    Smart pointers are a useful feature, but they aren't a solution to every problem.  If every single one of your pointers is a smart pointer, you are definitly doing it wrong.  You should only use shared (i.e. reference counted) pointers when you want two different objects to both be the "owner" of a pointer (i.e. shared ownership).  This gives either object the ability to free the pointer, but only when both objects no longer reference it.  In general though, you should try to create pointers that are owned by only one object, and deleted by only one object.  This is a much better way to make sure memory is not leaked.     Also, just because you use smart pointers, it doesn't mean that you will never have a memory "leak".  For instance, if you have two smart pointers, that both retain a reference to each other  unless one of them frees the reference to the other, neither pointer will ever be released.  So even with smart pointers, you still need to aware of what's going on.  
  • 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!