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

SunDog

Members
  • Content count

    127
  • Joined

  • Last visited

Community Reputation

232 Neutral

About SunDog

  • Rank
    Member
  1. Would love to see someone try that on the Caltrain in the Bay Area. 
  2. Well there's a reason why people get 4 year degrees in this stuff :-)
  3.   The ACARS and the transponder are different systems.  The transponder continuously sends out data, or else it would be pretty much useless for avoiding air-to-air collisions, etc..   The ACARS system only sends out every 30 minutes. It seems as if the transponder was intentionally switched off before the last communication from the pilot to ATC. Which is why pilot involvement is suspected.   (If there was trouble, why wouldn't the pilot somehow communicate this with ATC - I've heard that this can even be as simple as changing the transponder code which I've heard takes like 5 seconds - even if the pilot had a gun to his head something like this should have been possible) 
  4. Well Quake 3 uses BSP trees which no one uses anymore - not sure about other aspects of the code like physics and collision detection.   If you're talking about rendering, it might be better to start from the ground up.  I am currently learning DirectX using Frank Lunas book and some of the tutorials.   The C++ FQA http://yosefk.com/c++fqa/ is also a good reference for another take on C++.   But after reading it, realize you have to use C++ despite its defects, because aside from plain old C which makes, its necessary to get the high systems-level performance you need for a competiive 3D game.
  5.   Because you are using a vector of players when you should be using a vector of pointers or references to players.   E.g.   vector<Player> player_vec; Player p("someplayer") p.setFoo(0);   player_vec.push_back(p); p.setFoo(1);   Player p2 = player_vec[0];    p2.getFoo();  /// returns 0   This shoudl be somethign like  vector<Player*> player_vec; Player p("someplayer") p.setFoo(0);   player_vec.push_back(&p); p.setFoo(1);   Player *p2 = player_vec[0];    p2->getFoo();  /// returns 1 Edit: Basically what Spiro suggested
  6. Well in my current simple game engine I split out the rendering from the rest of the game engine.  Its sort of like a MVC framework (Model-View-Controller)., with the Renderer being the "view" and the Engine being the "controller".  I also have a Scene object which fits into the Model.   The GameEngine class is probably the closest it comes to the God class, but at least with the rendering and scene stuff split out, this should be a fair balance between responsibilities.
  7. A good programmer is going to need several languages in his toolbox.  Depending on the what the specific field they are in, these languages will differ   Unmanaged "systems level" language  -: C and C++ are pretty much the only canidates here, though D is on the horizon Managed  "application level" language - C#, Python, Java  Scripting language - LUA Web (client side) - Javascript, HTML Web (server side) - Java, PHP, Ruby, Python Database - SQL ( I really wish Datalog were a valid option here) And last by not least, the "I'm cool and know more than you" functional languages - Scheme, Erlang, Haskell :-)
  8.   Good point. I was thinking about making a book, but things change so quickly in the software world that perhaps a wiki would be better, since it can be updated.    Yeah, if it is an old book, unless it teaches universal concepts, which still apply today, it would not be such a good buy.      No kidding, I bought Frank Lunas book on 3D game programming with DirectX, I thought being published in 2011 it was recent enough, but when I tried to use his examples, I found out that most would not compile, because MS had totally changed all the DirectX headers.  This was mostly fixed by downloading the old standalone DirectX SDK, but for some reason there is this one function having to do with compiling the shaders whcih doesn't work.   His info and approach are still good, but I switched to working from the MS Tutorials directly using the "new" DirectX SDK.  I hope to be able to incorporate some of his code into a small engine I am building.
  9. This translates to:  The people working on this project only know C, and are only just learning C++ now...   If you're part of an organization with a lot of C programmers, and you're transitioning to C++, then this might be a very valid decision... But if you're trying to hire new programmers to work on a C++ project, people who don't realize how constructors/destructors actually work will fail the technical interview and not be hired...   Your example code is a lot smaller and clearer when written using C++ constructs: class A : boost::noncopyable { int* intPtr; int intPtrSize; public: A(int size) : intPtr(new int[size]), intPtrSize(size) {} ~A() { delete[] intPtr; } }; class B : boost::noncopyable { A a; float *floatPtr; int floatPtrSize; public: B(int aSize, int bSize) : a(aSize), floatPtr(new float[bSize]), floatPtrSize(bSize) {} ~B() { delete [] floatPtr; } }; It's also safer in that it cannot be misused by the programmer. E.g. A requires a size value for it to be initialized. If inside B, we remove "a(aSize),", then you'll get a compile error saying that you've forgotten to initialize a. In your original code, if we remove "a.init(aSize);" from B's init function, we get no such compile-time error. Your original code also allows the user's of A/B to call init or despose more than once per object, or not at all. The C++ method ensures they're called exactly once each, and in the right order.   You've also broken the rule of three by having custom clean-up code in a class without custom cloning/assignment code. This lets the users of A/B create code buggy code, like this: A one; one.init(42); A two; two = one; one.despose(); two.despose();//double delete bug If you actually use C++, then such bugs aren't possible, with compile-time errors generated instead: { A one(42) A two; //compile error - default initialization disabled A two(one); // compile error - copying disabled A two(0); two = one;//compile error - assignment disabled }//destructors called, double delete bug impossible I'll stick with cleaner, simpler, safer, more predictable code      What happens with that approach if you make an array of A objects ?   What happens if an exception gets thrown in A's constructor?  (B is left in an undefined state)   Also, boost isn't an integrable part of C++.  Alot of people dislike it because it slows down compilation time considerably.  I also don't like the idea of relying an external library for something so basic like proper initialization of my objects.
  10. Trivial constructors (basically constructors that might initialize variables to a defined state, but don't do anything like dynamically allocate memory), along with trivial copy constructors and destructors make RAIII much easier, without having to resort to shared/smart/auto pointers.   The problem with C++ is that constructors and destructors are often called implciitly without the programmer realizing it, in addition the compiler generates default constructors in any case.   Using a complicated constructor leads one to use pointers to objects and call new(), when really standard simple scoped objects would be a much better solution.   Example: class A { private:        int* intPtr;        int intPtrSize; public:         A()  {  intPtr = nullptr; inttPtrSize = 0; }        A(const &A other) { intPtr = nullptr; }       // no copy constructor        virtual ~A  { }                                          // empty destructor        void init(int size)   { intPtr = new int[size]; inttPtrSize = size; }        void dispose()  { delete[] intPtr; intPtr = nullptr;}   };   class B { private:       A a;       float *floatPtr;       int floatPtrSize; public:       B() {  floatPtr = nullptr; floatPtrSize = 0; }          B(const &B other) { floatPtr = nullptr; }          virtual ~B() { } // empty destructor       void init(int aSize, int bSize)  { a.init(aSize);  floatPtr = new float[bSize]; floatPtrSize = bSize; }       void dispose()  { a.dispose(); delete[] floatPtr; floatPtr = nullptr; }   } In the above example, I am using RAII with respect to A's lifetime in B.   Theres no complicated constructor chaining, and no possibility of an exception being thrown during A's constructor, which would leave B's floatPtr in an undefined state.    On the destructor side,  I don't do anything and have to call an explicit dispose() method.  This makes the code much clearer as to whats actually going on, rather than implicit destrucotrs being called   At least, if I try to do something with "unitilaized B", the program will crash trying to dereference a null pointer. This is a much easier bug to track down, than a memory leak.    Bottom line for me, is that the only two sane choices are to use something lie the above pattern, or wrap everything around smart pointers to avoid shooting yourself in the foot.
  11. This is the reason I usually stick with trivial, or even empty, constructors, and then call an explicit init() function after instantiation.  Constructos, exceptions, and manual memory management are a really bad combination :-) .  The problem is even worse for destructors.
  12. Well if you're rich, you can hire a really good programmer to do all your work for you.
  13. I program in LabVIEW for my job   LabVIEW kicks butt at interfacing with National Instruments (NI) hardware (NI makes LabVIEW)   For anything else, it is usually not the best choice.   It doesn't really simply a whole lot - you still typically have to use loops/branching/case statements.  Block diagrams can quickly turn into a mess  Yes the obvious thing is to make sub routines, but sometimes this is a pain when you have to query or update something a control the GUI, it involves making a passing a control reference to the subVI (like a subroutine, function, method, etc.)   It has OO, but last I looked I didn't like what I saw    The only potential advantage for visual programming I can see, is that it can make parallelism much easier.   The flow chart does not impose order except for what you wire.   LabVIEW is relatively strongly typed and passes arguments to its subroutines by value  based on (there are references, but not as easy to use).  But in making parallelism easy, it also creates problems such as unintentional data copying.     For whipping up a quick GUI though, its pretty awesome compared to other solutions I have come across
  14. Programming isn't "against" game making, it is part of it.  Another part is art.   Another part is design.  Another part is writing (for Bioware/Telltale/etc. games, etc.).  Another part is sound/voice acting.  And if you are talking about something that is intended to be sold, marketing.  I guess you can also add management for the bigger projects    Depending on what type of game you are making, some of these tasks are going to utilize more time/resources than others.   Have a novel game concept?  Best work out the design and all the ramifications, before moving on the next stage.   Want to push the envelope with graphics?   You are probably going to need to writing your own engine, which involves alot more programming.   Want to do a fairly typical FPS, but maybe with some novel environments? Thats going to require alot more effort into art.   Doing a story-heavy game?  The writing/voice acting is probably your most critical aspect.   Doing a mobile game that is competing with all the other thousands of games that are already released?  You need a really good marketer    Rarely are games a one man effort, it seems like a tremendous mountain to climb to get to turn ideas into reality, because well, it is    If I want to paint a picture, but I have no experience in paiting, my brushes and paint are not "against" me, the problem is me    As for the age issue, Carmack and Romero were in their early 20s when they released Wolfenstein and Doom.  To some extent they were like, Gates, Jobs, Zuckerberg, etc. were in "the right time at the right place" and with the right tech.   A small team of young innovators are definitely able to come up with "earth shattering" tech, but typically, it is markets that are not yet mature.   I would put forth that idea the games industry, at leas for PCs back then, was not mature.   Just like the personal computing industry when Gates and Jobs started Microsoft/Apple.   Or social networking with Zuckerberg.   So its much harder for an indepedent studio group group to compete with the likes of EA, Activisiion, 2K, etc. .  It would have to be a pretty darn novel idea.   Not a simply a variant of an FPS or RTS, racing game, sports game, turn-based strategy, etc.  that consumers have seen dozens of times before in various incarnations.
  15. But if the frame rate slows down, usually the mouse will be rendered at that same slow frame rate. I see no advantages on keeping the mouse refreshing while the user can't see where it is at.     Isn't it possible to have the mouse be drawn over the scene, even if the scene isn't completed rendering yet?    This would involve moving the SwapBuffers or whatever the equivalent is outside of the rendering loop, but I think it should be possible.