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

IncidentRay

Members
  • Content count

    23
  • Joined

  • Last visited

Community Reputation

154 Neutral

About IncidentRay

  • Rank
    Member
  1. Just wondering, Hodgman, with this design at what point are the references to the Model and RigidBody components removed from the PhysicsWorld and VisualScene objects?  If the Player struct calls a remove method in its destructor, then the Player would need to store a reference/pointer to the PhysicsWorld and VisualScene, which seems a bit inelegant IMHO.  Or is storing these references actually the right way to do it?
  2.   This should probably be safe_delete(T*& x) as otherwise you're only assigning the local variable to NULL.
  3.   This is certainly true.  However, I don't think it's what L. Spiro meant to imply.
  4. I would like to see some justification for this claim, please. On the face of it, it makes no sense to me.   I think it is fairly obvious. Would you prefer that we are all exactly the same? Being different keep things interesting. But I know that keeping a mix in things is much more important to me than it is to most others. L. Spiro Read http://pervocracy.blogspot.co.nz/2011/03/gray-coveralls.html please.   Also, do you really need to repeat this tired old cliche?  Actually, back in this thread (http://www.gamedev.net/topic/639144-sony-and-the-ps4-im-impressed-your-thoughts/page-3) you were rightly criticizing the stereotyping of men as "sex-hungry dolts".  So why the change?
  5.   I had heard of this technique before; I was more wondering about the specific case of state-groups, where it seems that a lot of states would need to store pointers.  For example, pointers to shaders, textures, vertex buffers, index buffers, cbuffer data, etc.  Your example of model assets cleared up my questions about this, though.  I wasn't quite sure what the name for this technique was, however, so your suggestions for terms to research look helpful.  I'll have a look at the article you linked as well.   So in general, the idea is to also store the actual data as well as the state groups, then in place of an actual pointer use an offset or address to the data, and then perform pointer-patching when loading.     I think linear iteration would probably be fine for me as well.  Using the bitfield to skip the rest of a state-group if possible sounds like a good idea.
  6. [quote name='Hodgman' timestamp='1358051934' post='5020960'] If you're going for memory efficiency, be aware of your compiler's padding behaviour when designing your header structures [/quote]   Yeah, that StateGroup struct was just a quick example; I'd definitely worry about padding in real code.   [quote name='Hodgman' timestamp='1358051934' post='5020960'] e.g. I put state-groups directly in my engine's model, material and technique files [/quote]   Putting the state groups in resources files is an intriguing idea.  How do you deal with pointers in this case, as obviously they will have different values each time you run the engine? I suppose you could store some other data in the pointer field, and then fix the pointers at runtime -- e.g. maybe a hash of a filename.  Or do you do something else?     [quote name='Hodgman' timestamp='1358051934' post='5020960'] I do pretty much the same thing that you've thought of here, except I also put a bitfield in the header, with one bit for each type of state. [/quote]   Your recommendation of storing a state bitfield sounds good -- that looks like it would be quite useful.  As I understand it, the bitfield can be used to quickly check whether a state group can be totally ignored, but if not, the next step is to check each state individually?   Thanks for the detailed example of how you might generate state groups; that answers several questions I had.
  7.     Moving the errors to compile time is definitely a good thing.  So then the RenderItem struct can have a pointer to a DrawCall rather than just a pointer to a Command. I'm not quite sure how it would work for the state-group, however.  I was thinking of having a StateGroup struct which actually just stores the header -- i.e. the number of states, the size in bytes, etc.  Then the actual commands would be allocated contiguously after the header.  For example,   struct StateGroup { u8 numStates; u32 sizeInBytes; }; void Foo(StateGroup* group) { State* states = (State*)((u8*)group + sizeof(StateGroup)); }   I can't see a way to stop the user from putting DrawCalls in the state group.  Do you implement StateGroups differently, or is there something I'm missing?       Yeah, I forgot that linkers can do that; thanks for the reminder.  TiagoCosta's use of templates is probably completely fine then.   EDIT: This editor seems to keep messing up the angle brackets for templates, so I can't get the quote above right.
  8. [quote name='TiagoCosta' timestamp='1358025244' post='5020848'] I'm pretty sure you just need a single level of inheritance [/quote]   You're right, it does look like a single level of inheritance would be fine.  I was wondering about the purpose of the State struct, as I can't think of what data members it would have.   About templates (sorry, not Hodgman!): I'm pretty sure templates are a purely compile-time feature, so it shouldn't have too much of a runtime-performance penalty.  However, melbow has a good point: templates often do increase the size of the compiled code.  I think there probably wouldn't be much benefit if you implemented exactly the same thing but without using templates (e.g. just copying and pasting your classes/structs/functions and changing the variable types).  Templated functions could possibly cause cache-misses if the compiler hasn't placed the code for both implementations nearby.  In your example, if the instructions for next<int> and next<BindVertexShaderCommand> aren't nearby, this might cause an i-cache miss.  However, this only applies if they're not inlined, so if they are inlined, you should be fine.  I've only started learning about how caches work recently, though, so someone should correct me if I'm wrong.
  9. Thanks for the reply, Hodgman.  Memcpy does seem to work on non-POD types in this case.  I'm interested in the alternate design you suggested using composition rather than inheritance.  That looks like it work quite well for one level of inheritance, but I'm not sure about how you would extend this to multiple levels of inheritance.  For this renderer design, I think you might need two levels of inheritance -- you mentioned that State inherits from Command, and then, in my understanding, you have multiple render-state structs derived from State.  Would you just do something like this? struct Command { u8 id; }; struct State { Command baseClass; // other members... }; struct BindShader { State baseClass; Shader* shader; };
  10. [quote name='Hodgman' timestamp='1357784838' post='5019739'] I get around the undefined behaviour with inheritance... [/quote]   But if you use inheritance, don't the structs become non-POD types?  That might create more undefined behavior to deal with -- for example, I was thinking of using memcmp for detecting redundant state-changes in the RenderGroup class, but that would only work if the structs were POD.
  11.   Yeah, availability of useful libraries is definitely an important factor -- that's why I was mentioning text manipulation and Lua integration in the original post.   I actually am writing the game itself in C++, but in this case I think reusing code between the engine and tools isn't too important. These are mostly data-conversion tools, which will write files in a format known to the engine, so the tools and the engine don't need to interact directly.  The idea you mentioned of being able to move some asset conditioning steps from the pipeline to the game could be useful, but for the types of files I am converting, this would probably not be too practical.  For example, I would prefer if the game didn't have a dependency on the Cg framework, so this means the shaders will have to be compiled offline.  So what I'm saying is that in my case I think it's okay if the tools are written in a different language to the game.     Hmm, that looks like a reasonable idea; I don't know too much about web development though, and getting the interaction right between the UI and the back-end looks tricky.
  12. Yes, I am writing this only for me, but as this is also intended as a learning exercise, I would prefer if I could write something cross-platform.  As to the suggestion of using Objective-C, I find Objective-C overly verbose and hard to read.  I agree that it might be the best choice if I need something with a complicated GUI, but I don't, so I don't think it's worth it.
  13. Yes, what I meant is that I use a Mac.  I'm not sure what you mean by your first sentence; are you saying that I could use a Mac-specific programming language?   I had heard of Mono, but I wasn't sure how practical it was, so thanks for the input.  From what you've said, using C# with Mono sounds like a good choice then.   EDIT: My line of reasoning for wanting to make it cross-platform was that most people seem to make their tools Windows-only, so if I need to support another platform, it's probably better to support Windows as well.
  14. Thanks for the responses!   Yes, I'm just making offline tools, so as you say, load time isn't too important.  I don't like Java much, but I'm interested in the possibility of using C# as a cross-platform language.     Mostly because I don't have a PC.  Also I just think it's theoretically a bit nicer.     Wow, that stuff looks great; I'm quite intrigued by the idea of using C# now.     Okay, I'll look into Mono.
  15. I'd like to make a content pipeline for some of my games/engines/etc I'm working on, and I'm not quite sure what would be the best language to use.  I'm using C++ for the actual runtime, but this seems very unproductive for tools.  I've seen C# recommended several times for Windows-only content pipelines, but I'd like to know if there's anything more cross-platform.   Here are some features that an ideal language would provide: It also should provide some abstraction of OS-specific functionality such as directory iteration, etc.  It should also be easy to use high-level features such as regular expressions and other text-manipulation techniques. Integrating this language with Lua should be simple, as I want to use Lua as a data-description language for several resource types. Calling external processes shouldn't be too hard -- for example, I might want to use the Cg toolkit's cgc program to compile shaders. I suppose C++ could work if I used heaps of boost libraries -- this does seem a bit cumbersome though, and I imagine it would cause a large hit on compile times.   Anyone have any suggestions for a good language to use?