Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

436 Neutral

About vreality

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. In general, don't make anything you're not using.  There are too many ideas and decisions which you'll only arrive at through practical use, which means that making without using will accumulate wasted work and required rework.   So don't make an engine without also making the game/content which will use it.  And by extension, don't make your engine cross platform unless you're making a cross platform game.   That being said, as has been suggested above, you should make your design as portable as you can even if you don't port it.  I suspect this will be good for design anyway, since isolating platform dependent code is a form of separating concerns.
  2.   (Not having looked at the target game, but just speaking of game development in general...)   Most people also have no experience in game, UI, or sound design, music, game production, tech or art direction, IT, QA, HR management, etc.  Good personnel to fill these needs (and several more, for higher-end titles) should be added to the budget just to facilitate development.     If we hope to do anything more than simply get something made, we'll also need to cover market research, PR, advertizing, distribution, business law, etc.    A handful of acquaintances making something on the side for fun is one thing.  But when we turn it into a commercial project in which we hope to pay expenses, and maybe even profit, we have to somehow account for at least all of the above.  These are some of the reasons it's tough to arrive at an actual budget.    It's probably much, much cheaper for an established group whose just succeeded on all fronts with a similar title, to make a given game than it would be for a business speculator to put together the same project from scratch to get the same result.  Figures based on the former are likely to woefully underestimate the latter, in both time and expense.    This is one of the reasons it's tough to get savvy investors interested. 
  3. vreality

    Good game with pale programmers

    I saw this talk a while back which suggests that lack of sunlight is bad for your health for more reasons than just lack of vitamin D (blood pressure, heart health, etc.).  I would suggest, that if possible, you open the blinds and let some UV into the office.
  4. vreality

    Placement new

    I once used placement new in a serialization scheme.   I used it with special "do nothing" constructors to fix up the virtual function table pointers on object images loaded from disk.
  5. vreality

    Need advice on TDD approach

    I imagine a good answer might involve breaking the buffering out into its own class (one responsibility for one class, etc.).    Also, I've occasionally made a unit test a "friend" of the class it tests so it can screw with internals without exposing them in general.
  6. +1   A tech demo is fine.  You don't have to create a lot of content or gameplay to showcase engineering skills.   But you should realize that most of the value you'll potentially provide to your creative co-workers is in making it easy for them to create content.  So beyond your ability to create run-time features, you'll want to showcase your ability to facilitate content creation.
  7. vreality

    Why Behavior Architectures?

    Perhaps state machine mechanics, decision trees, etc., should be provided as optional tools, rather than as a framework - er - into which - you must plug.   My team once implemented co-routines (that is, the ability to "Yield" and have processing resume from the same spot next frame- so as to wait, in the middle of a logical flow - for a condition to be met) because we were sure it would make behaviors easier to write.  It didn't really.  A stone-age switch-statement state-machine was just as clear, and effectively as simple to use.   Although I have to admit, I have occasionally daydreamed about a graphical state machine tool.
  8. vreality

    virtual and class inherience

    No, they are still treated as virtual... Haha - your code is making calls to some object pointed to by a pointer, which just happens to be the same object.  This demonstrates that - yeah - the object is "not yet a derived type object".   But as far as calls made directly to members within a constructor, the same function gets called whether its treated as non-virtual or as virtual (on an object which is "currently" of base type).  I don't know for sure, but I'm not sure the compiler is required to pay the virtual function call overhead in this case.
  9. vreality

    virtual and class inherience

    Unless, of course, static dispatch is what you want it to do.  It's simple enough to understand that constructors and destructors treat all calls to their own member functions as non-virtual.   For the curious, here's why:  To help ensure that member functions are only being called on initialized objects in valid states, C++ has a guiding principle that no class member function should be called before the constructor of the class is called or after the destructor of the class has run.    During execution of a base class constructor, the derived class constructor has not yet been called, and during execution of a base class destructor, the derived class destructor has already been run.  So it would be a violation of the above principle if the base class constructor or destructor could call any derived class members.   Virtual function calls would allow exactly that, so within constructors and destructors, calls to the object's member functions are all treated as non-virtual.   The way I like to think of it is that during execution of a base class constructor, the object being constructed is not yet a derived type object.  The derived class's constructor has not yet been called and so the derived class's functions are not yet accessible.  Similarly, during execution of a base class destructor, the object being destructed is no longer a derived type object.  The derived class's destructor has already run and so the derived class's functions are no longer accessible.
  10. vreality

    questions about singletons

    If there were ever two instances of this class then all of my resources would potentially be invalidated because their handles could suddenly be used to load a new resource. My whole motivation in creating the singleton was to enforce one-and-only-one instance. As pointed out earlier in this thread (and easy enough to forget that I've done so in the past), it's not a singleton unless it provides global access. If you're forced to use a bit of static data to enforce the "singularity" of an object, that's unfortunate, and may require you to address initialization order and threading issues. However, that doesn't require you to also make that object globally accessible. You can still create and use it as a normal object.
  11. Expect Unpredictable Change   You will get the most done if you focus on making something work.  You will get bogged down if you try to plan out all future code.   Don't try to write code as you imagine it existing in the final product.  Instead make it work, with the understanding (and plan) that you will completely transform it several times, as the need arises, to make it work well in future contexts.   Sometimes people worry that this will lead to bad (unplanned) architecture.  And, in fact it will, if your codebase is resistant to change.  But if you get good at transforming and growing designs, you can, in fact, continuously improve your design as you go.   For professionals in this industry, this skill is hugely important, because we rarely (if ever) find ourselves developing a codebase from scratch.
  12. vreality

    Proper way to sync data to disk?

    For persistent data (account info. character info., etc.) you might use a sql interface to store data in a database.   Generally, you don't store transient data (game state, etc.) on disk.
  13. vreality

    Different methods of ack:ing packets?

    Last time I wrote a reliability layer, it was essentially your option C - but without an explicit missing-nack notification.   Let's say a packet gets lost on the way from Alice to Bob.  If Bob ever receives another packet, he'll send around 16 nacks for the missing packet before it's ready to fall off his ack/nack mask.    That means at least sixteen consecutive packets would have to be dropped/delayed on the way back from Bob to Alice in order for Alice to then get a packet with an ack/nack history that didn't cover the packets waiting for acks in her sent-cache.   In the context of high performance, quick response networking, it seems reasonable to consider that a broken connection.
  14. vreality

    DLL question

    No. Your dll will generally be compiled against the same memory manager as the rest of the engine (unless you do something to prevent it), and your engine is linked against the interface you expose from the dll, so generally, the engine can delete objects it gets from the dll. How does one link against an interface? These preventative methods of which you speak, by that would you mean use an interface? In visual studio, you would list the dll's corresponding .lib file as a dependancy of the .exe (more on import libraries here). Doing "something to prevent" the dll from using the same memory manager is not referring to a "preventative measure". It's referring to situations like implementing your own memory management (e.g., overriding ::new) in your executable and forgetting to make your dll use your override as well. If you're not doing anything like that, the dynamic linker will link the dll's "new" calls to the same "new" that's called by the .exe. I suspect that most memory management worries with regard to libraries stem from the practice of publishing them to be used by others in unpredictable situations. In that case, one must be very careful to ferret out all assumptions about how memory (and other system resources) might be handled on the other side of the .exe-.dll boundary. Breaking systems of your project out into libraries, as we're discussing here, is not quite the same situation. You're just as likely to have a dangling pointer issue with the renderer as with any other class from that DLL, so what makes one class magically safe, and the others unsafe? Quantity and ownership. If the .exe owns a single .dll exposed object, which owns all other .dll specific resources, it becomes trivial for the .exe to do its part to ensure that they go with the dll when it's unloaded. If, on the other hand, the dll hands out pointers to dll specific resources, it becomes significantly less trivial to - er - "recall" them all when something decides it's time to swap out the dll.
  15. vreality

    Why XML is all the rage now?

    Points about JSON > XML aside...   As a game developer, the big deal to me is that it's a flexible standardized text format which means: I don't have to create my own libraries to read, write, or navigate it. At least for the purposes of developing and debugging tools that use, generate, or convert it, it's human readable. It's diff-able and potentially merge-able, which to me makes it first-class revisionable.
  • 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!