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


  • Content count

  • Joined

  • Last visited

Community Reputation

96 Neutral

About Burnhard

  • Rank
  1. Quote:Original post by ApochPiQ Whether you're deliberately trying to salvage your image by pretending you were never wrong, or whether you're just having a really hard time expressing what you're actually trying to say, the fact of the matter is that phresnel is hardly the only one who has had trouble comprehending your trains of thought around here lately. I would ask for an explanation, because if you're referring to the Object Constructor thread, I think I adequately dealt with the issue there and managed to defend my use of the IOC/DI pattern and everything else I did, despite repeated attacks by people who didn't understand it. That is the only "argumentum" I've been involved in here and that was really a religious discussion, rather than a technical one. The original point I made on this thread was poorly articulated. I don't believe "because it needs to be compiled" is the reason it doesn't work properly, I meant because "C++ is hard to compile", for various reasons, one of which happens to be conditional compilation - and that is what MS have said. This is notwithstanding the fact that "MS fucked it up in any case" with earlier versions of VS. Quote:I honestly hope I don't need to explore that thought any further. I think you should explore it further because I can't find the "delete" button on my account and this place is full of fucking nerds.
  2. Really, that's unnecessary. My point is that C++ is harder to compile due to *things like* conditional compilation. My original statement, which shouldn't have been so ambiguous, was that because it has to be compiled/parsed piece-meal, it's hard to do. I've pointed out that C# intellisense is better than C++ intellisense, even in 2010 and that I conclude that doing so for C++ is therefore more difficult (that's an empirical result). But you don't dispute that, because you agree with the next poster who said it's easier to parse C# than C++, which is what I've said too. If someone else says it, you agree, if I say it, you start swearing. And if you think it's harder because it contains more ambiguities, then why are you even arguing with me when I point out one of those ambiguities (conditional compilation)? It seems you're stalking me around the forums disagreeing with whatever I say just for the hell of it. Untwist knickers.
  3. I agree with the idea that entities interacting with each other as much as with the player is one of the things you'd associate with a sense of immersion. I think to give the agents intentionality is important too. That is they're not just robotically interacting with some designated other, they're doing so in order to satisfy some goal they have and obviously the player can to an extent interfere or become involved with that goal. I think people like Braben are working on these possibilities (The Outsider for instance). But for me intentionality is the key.
  4. Quote:Original post by phresnel The amount of macros used in good C++ code is negligible. And thus, they don't participate relevantly in compilation time. It's not the code you write, it's all of the headers you pull in from libraries, windows (if you're using windows), etc. there's a lot of conditional compilation in *those* at least. Take a look in windows.h, just for a laugh. Quote:Original post by phresnel The point is that you pretended, after some contextual inlining, that C# does not have to be compiled to reap meta information from it, which is wrong. Period. I don't think I said that. My point was that it's just much cleaner especially in terms of conditional compilation. The point I made was the same point that the guys actually writing the intellisense feature have said. If I'm contradicting you, I'm not contradicting them, and they're the experts. Quote:Original post by phresnel Tbh, I am unsure why you constantly change your intentions and consensus from post to post, and counter derive untrue things afterhand about non existent posts, like me implying things about what you've said but which you did not say in reality. Get some sleep and stop becoming personal. I didn't. I'm not being personal. I'm simply pointing out that if you want to know what's up with intellisense and why it was hard to implement for them up to 2008, then read what they guys who were responsible for implementing it have said. 2010 is almost up to standard, but it's still not as good as the .NET equivalent. I don't think I've said anything particularly controversial here. All I've done is disagreed with you as you seem to be implying that it's no more difficult to parse C++ over C# and therefore the reason intellisense is inferior for that language over C# is a mystery. Well, it's not really a mystery, as the guys who write the feature have explained why they had problems with it.
  5. I have iQuarium on my iPhone. I had a fish for about a week but then started to resent that fact I had to feed it and take care of it otherwise it would die (!). So now I have a dead fish in a tank :p. These things for me are little trinkets it's fun to play around with from time to time. Personally I don't like the compulsory element of losing your stuff (the pet), if you don't play with them regularly.
  6. Quote:Original post by harminal Thanks for all the replies i think ill go with a 3x3 grid Also does anyone have any tutorials about the quadtree crap just to get me started?? Cheers Quad-Tree Crap
  7. It's still in the container though, so holding a reference, which means the custom deleter won't be called. I thought the idea was to remove it from the container when it was destroyed, not destroy it when it was removed from the container, if you see what I mean. On the whole I tend to prefer explicit operations to those applied implicitly through a kind-of trick in cases like this. It makes for less obfuscated code. But I think the purpose of holding the lists in D3DDevice should be explained. Do the objects using a particular buffer ask D3DDevice for a reference to it when they need it, i.e. shared_ptr<BufferClass> GetBufferX(), or do they share the reference itself as a member variable? In the former case you can completely destroy and re-create your list of buffers without having any side-effects outside of the D3DDevice instance. In the latter case you're asking for trouble.
  8. Can you clarify the problem please? Are you just wanting the item to be removed from the list when the pointer goes out of scope or is destroyed?
  9. Something doesn't seem right with the OP's conclusions, so I will pitch in with my observations from when I did my dissertation. The problem here is you should write your dissertation as you would any other paper, with one eye on the expectations of the examiner. I could, for example, pitch up with a 3d renderer full of bells and whistles, but if I don't correctly present my write-up, demonstrating certain concepts, I'm going to fail. These include but are not exclusively: (1) Evidence and discussion of relevant research in the area (2) A chosen methodology (preferably one that's well known) (3) A design (again, preferably one that's well known) (4) Code that implements the design (5) Some conclusions. Your dissertation is 10% actually writing code and 90% writing a paper. That is why you can still pass your dissertation with an A grade even if you don't write any code whatsoever. So I think in this case that something has gone wrong with the paper, rather than the subject choice or implementation. The interesting thing though is that your friend has done 2 and failed both. I get the impression he didn't go and ask his tutor why he failed the first before he started on the second! Edit: Ah, I see phantom has anticipated my reply :p.
  10. Quote:Original post by phresnel About the default constructible thingy: C++0x will mop this argument away using perfect forwarding, move semantics and variadic templates: *** Source Snippet Removed *** g++ will kindly accept this code if you want to play with it. That's all good. I don't think we'll get 2010 until the next IT budget comes around.
  11. Quote:Original post by theOcelotAardvajk has shown why the container argument doesn't hold I will reply to the container point because one of the arguments against what I'm doing is that it's somehow "restrictive". The container point was meant to demonstrate that it's often hard to avoid zombie objects because you often need a default constructor on objects used in containers. That is to say you can't use ".resize" on your container without the default constructor. If you refuse to implement another way to initialise your object, then you're not complying with the requirements of the container. That is itself a restriction. The point was not to say, "there's no other way of adding an item to a container" as there are clearly other approaches one could take (including push_back - provided you enjoy public copy constructors), or having a container of pointers. If you're going to do the latter, surely you should prefer a container of shared_ptr? What I'm trying to say here is that because I'm always using shared_ptr, this is not really something I need to think about. So I'm not defending the specific case of using a container, but the principle of always preferring shared_ptr.
  12. Quote:Original post by Sneftel Quote:Original post by Burnhard This() can't be used in a constructor, because This() does not exist until after the constructor has done its work.Newer versions of shared_ptr get around this by lazily constructing the refcount block and filling it in later. Which creates its own problems, but at least solves that particular annoying problem. The version I'm using at the moment gives a bad_weak_ptr exception.
  13. Quote:Original post by Nitage Quote:Wait, what? Why would it be inappropriate to want to use shared_from_this in the constructor? Calling it from a constructor strongly couples the class to shared_ptr, to the extent that it can only be owned by a shared_ptr - can't even be allocated on the stack. It also creates some lifetime issues that can be a bit tricky to manage (and yes Burnhard, shared_from_this can safely be used from a constructor). No, it can't. This() can't be used in a constructor, because This() does not exist until after the constructor has done its work.
  14. Quote:Original post by Nitage I think the problem here is that you take criticism personally. You've been advocating an overly prescriptive use of RAII which focuses too narrowly on shared_ptr. You've repeatedly refused to engage with the criticism, instead preferring to pretend that the use of smart pointers and RAII in general is being criticised. I think your goal here is to "win" a nerdy argument, rather than to engage with the concepts I'm addressing, and as I don't wish to just reiterate the same concepts with words in a slightly different order, I don't think I'll continue to defend them. At the end of the day, I'm happy enough to let bug-tracker do the talking.
  15. Quote:Original post by theOcelot Or you could just throw to begin with, in your constructor. That doesn't violate any of the principles you laid out in this post, except the one quoted above. The points are interesting: (1) throwing in constructors is ok if you're using RAII - you can enforce this kind of behaviour by using smart pointers. That's why I use them everywhere (making use of them everywhere is a point of contention for some strange reason). (2) there are common cases where an object must be default constructable (containers for example). Most non-trivial objects aren't default constructable, so you're going to have to initialise them in any case. But the important point is that two-stage construction is always safer, because you can guarantee your constructor doesn't throw. Quote:Original post by theOcelot Does anyone remember what RAII stands for? It's "Resource Acquisition Is Initialization." Yes. It's about the *destructors* of objects on the stack being executed when it unwinds. Quote: Why not use them, even if you don't strictly "need" them? Who really needs RAII at all, when you can use free functions and gotos? Absurd. Don't start misrepresenting what I'm saying. I can type until I'm blue in the face, but it will never sink in: use them if you need to use them. If you don't need to use them, then don't. The issue is whether or not you know you need to use them. If you don't know whether or not you need to use them, then you don't understand your own code. Quote: Your bringing them up now is... telling. Speaking of straw men... Yes, such as your comments on the use of raw functions and goto.