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

BenS1

Members
  • Content count

    152
  • Joined

  • Last visited

Community Reputation

352 Neutral

About BenS1

  • Rank
    Member
  1. Great article!   I can relate to everything you've said there (Also being a 38 year old developer, who has been writing games (Although only as a hobby) for about 24 years).    I wish you all the luck in the world. I also wish I had the balls to do what you've done.   Ben
  2. Thanks again all, I think I'm starting to get it now.    I think the heart of my problem is that I'm not encapsulating the details of the renderer, so for example my Terrain class doesn't have a simple Material and Geometry but instead has much lower level information, such as: // The Vertex and Index Buffers describing a tile ID3D11Buffer* m_TerrainVB; ID3D11Buffer* m_TerrainIB; ID3D11Buffer* m_SeaVB; ID3D11Buffer* m_SeaIB; ID3D11Buffer* m_BoxVB; ID3D11Buffer* m_BoxIB; ID3D11VertexShader* m_TerrainVS; ID3D11PixelShader* m_TerrainPS; ID3D11VertexShader* m_SeaVS; ID3D11PixelShader* m_SeaPS; ID3D11VertexShader* m_BoxVS; ID3D11PixelShader* m_BoxPS; // The input layout for terrain vertices ID3D11InputLayout* m_TerrainInputLayout; ID3D11InputLayout* m_SeaInputLayout; // Constant Buffers ID3D11Buffer* m_PerFrameCB; // Per frame constant buffer ID3D11Buffer* m_TerrainObjectCB; // Per object constant buffer I guess I need to better encapsulate these, so that I just have higher level Material and Geometry classes, and then I can use the above advice to just send the Material and Geometry to the renderer.   It's all starting to make sense, and should help to simplify and tidy up the code too (I hate messy code, so I've not been happy with this for a while now).   Thanks Ben
  3. I've just read the 2 articles on Component Entity Systems, and they're pretty interesting and I can see how the memory layout is efficient from a cache point of view, but I'm not sure how well it would work in my case.   Lets imagine a an RTS game, with potentially thousands of units in play at any one time. You might use a Quad tree to partition the space and only update the units in view with every frame, and objects just outside of view are updated every other frame (Some on the odd frames and some on the even frames to balance the load) and units even further away are updated even less frequently. I'm not sure how this fits in with the CES idea.   Also, imagine if a have a world that can potentially support a theoretical 100,000 entities (Maybe 2000 units + loads of bullets, rockets, missiles and other objects). In reality most of the time you'd only have an average of 1,000 entities, but in the heat of a massive battle this could increase significantly. Having your systems walk all 100,000 entities every time when most of them will be empty seems inefficient.    One final comment, for worlds with a large number of potential entities it may be better for createEntity and destroyEntity to maintain a list of the index to free entities so that creating a new entity can be done in constant time, rather then potentially having to walk up to 100,000 items in the array.   Interesting concept though and definitely looks like a good idea for many applications, but potentially doesn't work for everything, but then nothing ever does.   Thanks again Ben
  4. Thanks both for your replies,   GK, I'm actually reading Game Engine Architecture 2nd Edition right now, but I haven't got to that part of the book yet.    Previously I'd read the otherwise excellent Game Coding Complete book but this was the one area that I found confusing in that book.   Thanks Ben
  5. I've been writing games as a hobby for about 25 years now, and in my day job I'm a LEad C++ developer writing realtime performance critical highly multithreaded code, however there is one thing I've always struggled with and that is how to separate the Rendering Code from the rest of the game code. It seems that lots of games books suggest that you should do it but they don't really explain how to do it.   For example, lets imagine you have a Command & Conquer style RTS game, internally you might have classes representing the terrain, objects on the terrain, units (Player, remote and/or AI) and bullets/rockets/lasers etc.   These classes contain all the information relating to the object, for example for a player unit you might have the units position, speed, health, waypoint list etc. You may also have rendering data too such as models\meshes, textures etc.   In this simple model (Which has worked fine for me for many years) you can have standard methods on the objects such as Update() and Draw(). It all works great.   The problem is, what if I want to port my DirectX game onto another platform that uses say OpenGL? My rendering code is so embedded into the game code that it'll be a major job to port it.   The books seem to suggest that you should have separate classes for your game objects and your rendering objects. So for example you might have a Unit class that supports an Update method, and a separate UnitRenderer class that supports the Draw class. Whilst this makes sense and would indeed make porting much easier, the problem is that the UnitRenderer would need to know so much about the internals of the Unit class that the Unit class would be forced to expose methods, attributes and data that we otherwise wouldn't want to expose from the Unit class. i.e. we might have a nice clean interface exposed from the Unit class that encapsulates the internal implementation and is sufficient for the rest of the game, but the need to expose internal information to the UnitRenderer means that your nice clean Unit class becomes a mess and exposes its internal implementation details to anything that can access the Unit class.   Plus of course there are performance implications of doing this.   How do people typically separate their games code from their Rendering code?   Thanks in advance Ben
  6. Just for future reference if anyone else has the same question.... I downloaded CMake and followed the instructions here: http://assimp.sourceforge.net/lib_html/cmake_build.html   And to my surprise it actually worked. By worked I mean that it generates Solution\Project files for the versions of Visual Studio you select (As well as different target platforms, such as x86 or x64) and they build just fine.   The solution\project files it generates are a good starting point, and it builds, but they're a bit of a mess as they use absolute full paths instead of solution relative directories etc, but it's only a minute of 2's work to tidy that up.   Thanks Ben
  7. Thanks LennyLen   Yes I initially downloaded the binary install but it only includes the release lib files and not the debug versions. I'm not sure if this is an issue though.   I eventually found the build instructions (Not in the most obvious place I have to say), and so I'll try using CMake later (HAving never used it before).   Thanks for your help Ben
  8. Hi,   Looking at the Assimp website it suggests that Assimp builds for several versions of Visual Studio upto and including VS2012 (VS11), however when I download the full install I don't see any solution files or instructions on how to build it.   Has anyone built it from the Visual Studio IDE, and if so please can you share your instructions on how you did it?   Thanks in advance Ben  
  9. Hey, how come theirs has been updated for DirectX 11, the spine on my version says "DirectX 1" :)   (Yeah, i got one of the first batch that had the printing error)   Great book though.   Any plans on keeping it up to date with DirectX 11.1/11.2 and updating it to use the version of the DirectX SDK now included in the Platform SDK and not the old Standalone June 2010 DirectX SDK?   Thanks Ben
  10. Another tool to try is Depends.exe and tell it to profile your game. It'll then list all the DLLs loaded (Which tree of which DLLs loaded them).   Here is the output on mine:   Interestingly you can see that D3D11.dll tries to dynamically load D3D11SDKLayers.dll twice. The first time it tries to load if from my games directory, and fails (See the yellow circle with a question mark in it). The second time it loads it successfully from the SysWOW64 directory.   Try this with your app and see whether D3D11.dll is even trying to load the layers DLL and if it is where is it looking and failing.   Thanks Ben
  11. Can you check if you have D3D11SDKLayers.dll on your system. On my system I found it in the System32 and SysWOW64 directories, as well as in \Microsoft DirectX SDK (June 2010)\Developer Runtime\x86 and \Microsoft DirectX SDK (June 2010)\Developer Runtime\x64 directories.   Also when you run your app use something like SysInternals Process Explorer to see if the D3D11SDKLayers.dll is being loaded.   For example, when I run my game in Debug mode I can see from Process Explorer that the DLL is being loaded, and specifically I can see its the one from the SysWOW64 directory:   Thanks Ben
  12. Thanks again Zaoshi   The XMFLOAT4X4 solution is working for me, but I'll keep this in mind for future.   Of course I could create my own RAII wrapper that acts as a smart pointer for aligned mallocs and frees.   Thanks Ben
  13. Thanks again Zaoshi   Can I then free the memory using delete, or does it have to be freed using free?   If it can be freed using delete then it'll allow me to use a smart pointer (I don't like using naked raw pointers if I can help it).   Thanks Ben
  14. Thanks again Zaoshi,   If I use _aligned_malloc then it'll allocate the memory, but it won't called the constructors and all the other stuff that new does. Similarly with free vs delete.   I've actually given up on the alignment and worked around the problem by changing from using XMMATRIX (Which requires alignment) to using XMFLOAT4X4 (Which doesn't require alignment) and using the Load/Store functions to convert between them if and where necessary. There doesn't seem to be any performance impact at all.   Thanks everyone for your help.   Ben
  15. Ok, it is clearly an alignment issue. I added this:   g_Logger.DebugOut("Address of Matrix = %p, alignment = %d", &m_TextDrawData[currentDraw].Transform, __alignof(SpriteDrawData)); m_TextDrawData[currentDraw].Transform = XMMatrixMultiply(transform, XMMatrixTranslation(x_offset, y_offset, 0.0f));   And it output "Address of Matrix = 008A06F8, alignment = 16"   As you can see, it says the alignment is 16 but the actual address of the matrix is not on a 16 byte boundary.   The question is why. XMMATRIX is defined as "__declspec(align(16)) struct XMMATRIX", which the documentation suggests will cause it to be allocated on 16 byte boundary's. The docs also say it will be inherited, so as struct SpriteDrawData includes an XMMATRIX member the SpriteDrawData itself will be aligned accordingly to honor its alignment requirements. But clearly that's not happening here.   From doing some reading around today it appears that pragma pack actually only manages the packing within a structure but doesn't actually ensure that the structure is aligned to a multiple of the pack value.   Thanks Ben