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

Alex Hopkins

Members
  • Content count

    1
  • Joined

  • Last visited

Community Reputation

156 Neutral

About Alex Hopkins

  • Rank
    Newbie
  1. EDIT: Stupidly, my Near plane was set too small (to combat an earlier issue). I do not know how to delete this post however.   I'm following Frank Luna's Introduction to 3D Game Programming with DirectX11 and I am seeing an issue with the edges of the polygons on screen. (I'm using Windows SDK, Effects11 and DirectXTK in my solution on Windows 7) The intersection between the waves and hills (from chapter 8) and the edge of the crate have horrible dancing polygons, almost like Z-Fighting but not. I can't paste all my code but here is a link to a quick video clip demonstrating the effect. Does any DirectX pro have any insight into why this might be happening or has anybody seen this before? There is a more obvious effect on this video (ZIPPED)  https://www.dropbox.com/s/y6arcbn5c8jpcmh/MEngine%202014-01-02%2015-28-13-59533.zip
  2. [quote name='Jason Z' timestamp='1346332323'] That looks pretty cool - nice work. [/quote] Thanks Jason, I'm currently reading through Practical Rendering & Computation with Direct3D 11 and I know a few friends who've bought it based on my recommendation, incredibly useful, thankyou!
  3. I find it hard to visualise the flow and complete process required for a game loop using DirectX11 so to help myself I made myself a kind of cheat sheet. It's based on the presumption that most things are obvious and that just the order and steps required are to be detailed. The render calls made to the Model class don't include a Draw call to the GPU, as that is handled later by the Shader custom class. HD Version: https://www.dropbox.com/s/7322x0i76sdnagm/DirectX11_Cheat_Sheet.png
  4. One of the things I like most about Unity3D, apart from the rich editor environment, is the way the GameObject class is so rich. It provides access to many useful methods and exposes the things common to all objects within the game, such as position and rotation. I wanted to emulate something similar for my C# DX11 engine, so I came up with this approach. public abstract class GameObject { public Vector3 Position; public Vector3 Rotation; public static int UUIDCount = 0; public static List GameObjects; public int UUID; } This is a very stripped-bare version of the class but it demonstrates that all GameObjects will have a Position and Rotation property (along with associated methods). The UUIDCount is a static int that is incremented whenever a new GameObject is instantiated. This is applied to the UUID field of that instance, giving each GameObject a unique identifier. (No account is currently made for destroyed objects freeing up UUIDs) The instantiated GameObject also adds itself to a static list of GameObjects. This allows them to stay in scope even if they fall out of scope in the code that generated them, just like Unity. This list will later be iterated and each GameObject can have certain methods called, such as Update (to call Update on any attached scripts!). Any visual editors I make will also be able to list the active GameObjects (handy for debugging). The Instantiate() method of the GameObject is static and templated, so it can be used by any derived class. public static T Instantiate(Vector3 Position, Vector3 Rotation) { var newGO = PInstantiate(); GameObject go = newGO as GameObject; go.TranslateTo(Position); go.RotateTo(Rotation); return newGO; } private static T PInstantiate() { var constructorInfo = typeof(T).GetConstructor(new Type[] { }); var newGameObject = (T)constructorInfo.Invoke(new object[] { }); return newGameObject; }
  5. I have finished "spec 1" of my custom model format, IOF. It is intended to remove a lot of the complexity of OBJ files that I won't be using but also introduce important features that I feel OBJ files are missing. I am splitting the work of this format up until smaller "specifications" so that I don't spend months on finishing the complete model format. The model file contains the spec version it was made for and so all files can be loaded for backwards compatibility. Unfortunately certain features will require a re-build of the IOF file from the original OBJ file. For example, in "spec 2" I plan to support mesh groups and hierarchies. The former is partially encoded in the original OBJ file as separate group entries but the latter isn't supported at all. So a "spec 1" IOF file will have lost the group information, meaning it can't be upgraded to spec 2. Currently, "spec 1" is very simple. Instead of the multiple separate index values for position,normal and texture coordinates in the OBJ file, the IOF file stores unique vertices and indexes to them as a whole. That means that more vertices generally will be output from the IOF than were stored in the OBJ but it also means that the Index into the vertices is compatible with OpenGL and DirectX indexed arrays. To achieve this, an 8-tuple is used as the key in a Dictionary. This 8-tuple is merely the entire vertex information, comprising the position, normal and texture all together. This uniquely identifies each vertex. The 'faces' list is iterated through and every time, the dictionary of unique vertices is checked for that vertex. If the entry exists, the index is returned (the index is stored inside the vertex structure as Dictionary classes generally don't care about ordering) and stored in the Index list. If the entry doesn't exist, it simply creates a new vertex, fills out the index and adds it to the Dictionary before adding to the index list. One of the features I wanted from the IOF model format was easy serialisation and deserialisation. Parsing through an OBJ file isn't hard, but its more cumbersome than it ought to be. Using a serialising system allows JSON objects to be used instead of plain-text line prefixes, making later deserialsing much easier. The single down-side to this (that I can see) right now, is that the exported IOF files are in the order of 4 times the size of the original. This is a combination of the extra vertex information and also the names of the JSON fields being output for each vertex. This issue takes an ~90kb file up to ~250kb. While this isn't going to fill a hard-drive yet, I expect that IOF Spec 2 will have to support compression of some kind. A quick test shows that the 250kb IOF file is zip compressed down to ~23kb, a 90% saving in disk space. This must be optional though, as it will obviously put extra computation time on the deserialising later on.
  6. [quote name='jbadams' timestamp='1345773348'] Welcome! [/quote] Thanks JB
  7. I am switching my focus from C++ to C# for my landscape / environment engine, and switching from native DX to SharpDX. There are many reasons for this, chief among them the speed at which you can achieve things in C#. I could continue my engine in C++ but the rate of progress wouldn't be great and given that this project will end up being a submission (hopefully) for a University project, I'd like to have time spare to write a dissertation! I appreciate there is a performance penalty for using managed code and calling DirectX but the engine I am writing will be portable to C++ as and when I have adequate time to do so. One of the main areas of exploration for me here is to see how many of DirectX 11's new features can be applied simultaneously to achieve fast-performing rendering techniques for an open world environment. It may seem counter-intuitive then to use managed code to do this but as well as offering a practical investigation into how plausible game engines are in C# it also offers a chance to see whether a DirectX10 C++ engine written to be as close to a DirectX11 C# as possible competes. Obviously a scientific evaluation of DirectX 11 and 10 would pit them against each other on common ground, but I can say I'm ascertaining whether DirectX11's new features are enough to overcome certain limitations elsewhere (like using C#).
  8. So whenever I read about how to import a model into your game, it tends to be followed by suggestions that the user go and read the appropriate file format specification. Then a few suggestions related to model asset libraries like ASSIMP. I have tried many of the libraries and always seemed to have one or two issues with them, none of which were fatal, all of which were annoying to debug. For my project going forward, I will require many models to be imported and I'd like to minimise the pain of doing so further on. I wrote an OpenGL-based 'sniper' game for University that allowed the importing of hundreds of models at run-time and you could fly around the city "painting" models in and rotating them individually. There were a lot of models so I wrote a custom level format which housed a list of possible models and all the meta-data. This was in XML format. Now, I'd like to go further and gain more control over the models themselves as well as the levels. I'm favouring JSON as a format for things as it seems to map slightly more to what I want to do, plus with serialisation tricks and some reflection, it might be possible to output replays/gamestates. So, I'm writing a custom model format. It's going to be very basic and include only things such as Vertex positions, Normals Texture coordinates Texture-file linkages Lighting information per-vertex Maybe smoothing information Possibly hierarchical meshes Extra meta-data for run-time use The first obstacle I found while running my OBJ importer is that the "Faces" index into separate position, normal and texture index arrays which isn't compatible with a DirectX index buffer. So, algorithmically parsing these index arrays must be done first. So, my output file format will be called, tentatively, "Indexed ObjectFile Format" or IOF. I'm half-way through writing a custom tool to convert between OBJ to IOF. It's both fun and educational to write your own model formats and certainly good practice writing game tools such as model converters. Knowing your model format intimately can only be a good thing later on down the line when you wish to incorporate more advanced features like skinning, animation etc.
  9. I once had to write a DirectX "scene" for a module at University. Back then, I wasn't aware of graphics debugging tools such as PIX or nSight. They are amazing! They allow you to capture a frame of your application and examine every tiny detail of the graphics pipeline. You can see all of the DirectX calls and the render targets as they existed at each point in time. You can click on a single pixel and they can tell you which draw calls affected that pixel and how. Stepping through the shaders (black magic) allowed you to visually see the effects of the shader code and verify them with the output in the render targets. Contents of Vertex and Index buffers are easily displayed and even viewed in 3D preview. So now, it's 2012 and Microsoft has caught up and released a suite of graphics debugging tools in their newest Visual Studio (11 / 2012). Having access to every little piece of the puzzle means people are able to diagnose bugs more quickly and in my experience, the graphical bugs are some of the hardest to understand. Currently, nSight doesn't work with Visual Studio 2012. I wonder if they are going to update it or if they feel it's a fruitless endeavour, given Microsoft's new found efforts in this area.
  10. Hello World! My name is Alex and this is my first post on my first blog on GameDev. I am currently studying for a Bsc. Hons in Computer Game Application Development at Abertay University, in Dundee, Scotland. I am about to enter my fourth year and decided that before I do, I'd start work on experimenting with the development of my own game engine. I've never done this before, so I expect that I'll make plenty of mistakes along the way and will constantly fight myself to not try to over-optimise early-on. That kind of thing, I regularly read, is a bad thing. Optimise when there is a need. I became interested in making a game engine when I first started to read about the advancements made possible in DirectX11. It seems quite amazing the things that are possible using DirectX and the care taken in it's development seem to suggest Microsoft cares about PC gaming, Although they have seemed to bin XNA and a lot of developers seem unhappy with the impending Windows 8 release. So, I came to write this blog because I wanted a place to journal my thoughts and findings. After watching a video on YouTube about DirectX 11 Tessellation, I noticed the uploader had a blog here. I regularly visit this site, it's an amazing resource, but have never thought about blogging here. It begins...