• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

vreality

Members
  • Content count

    151
  • Joined

  • Last visited

Community Reputation

436 Neutral

About vreality

  • Rank
    Member
  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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Unity

    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.   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. 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.