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

darookie

Members
  • Content count

    2544
  • Joined

  • Last visited

Community Reputation

1441 Excellent

About darookie

  • Rank
    Contributor

Personal Information

  • Location
    Mannheim, Germany
  1. Just to nitpick a little - trees are graphs. Acyclic directed graphs to be specific  Regarding your question, it is probably not a good idea to stuff every kind of information you need into a single data structure. Rendering requires a different graph (tree) structure and data to be efficient than path finding or collision detection. Your initial scene graph may contain all the required data, but for real time use it's best to split that data up into separate layers (render nodes, path finding nodes, collision information, objects, etc.) and data structures that are optmised with regards to their respective usage.   Yet another thing to consider is the way your data will be used in general. A streaming file format and data structure has different requirements from a static graph that is loaded once (like using zones for larger patches of terrain). A http://en.wikipedia.org/wiki/Quadtree might provide a relatively simple way of subdividing larger scenes into smaller parts. It can be pre-calculated in an offline step so your heightmap can initially be quite large. By storing the tree in a linear fashion to a file and using an index into each level of the tree you can then easily locate and deserialise the data you need at runtime if you need to.   HTH
  2. I would also recommend looking at Unity3D. It has a free edition that lets you try out and get comfortable with its development environment. Another plus of Unity 3D is that is has a wide variety of supported platforms. You should seriously consider 3D models for your characters, though. Depending on the number of characters/enemies needed, the effort of creating animations and different versions can be significantly lower than for 2D artwork (animations and models can be reused and easily modified).   On the hardware side of things nothing special is required. Pretty much any PC (not older than say 5 years) with a dedicated mid-range graphics card and a bit of RAM will do. The amount of money required depends on the number of and payment for the team members. The amount of time required depends on the experience of the team and the amount of time your and your team members are willing or able to put into into the project. A total playtime of roughly fifty hours sounds pretty ambitious, though. Experienced professional full time teams take on the order of two to five years for such a project - just to give you a sense of scale here.   You might want to consider starting with a demo first - like a quest plus an optional small side quest with less than 30 minutes of gameplay, but with some of the major elements and features of the game implemented. Tracking your efforts in doing so will give you an estimate on how your team performs and how much time and money would be required to actually finish it. Making a demo will also provide you with a sense of how to structure your workflow and how labour intensive the various aspects of the project might turn out to be. 
  3. The remaining errors are a result of interface changes in the ID3DX library between your installed version and the one the core_graphics implementation was built upon. UpdateSkinnedMesh() should take 3 parameters and be used like this: UpdateSkinnedMesh(matrix, NULL, mesh), where matrix points to your bone transform matrix and mesh is your mesh pointer.   I don't know the parameters for GenerateSkinnedMesh(). As a rule of thumb, however, you should never just throw in NULL parameters at random. Instead, take a look at the parameter types the function expects and match the variables that are used by the old code against them. Any parameter of the function that is not used by the existing code can be NULL (if it's a pointer).
  4. There is no such thing as "directx units". If you model a unit cube the exported cube should be a unit cube as well. Any perceived difference in scale is therefore a result of either scaling by the exporter or simply different camera settings in Blender and your application. The former can easily be checked by examining the vertices of the loaded model.
  5. Start by actually reading what the linker is trying to tell you: The last error for example tells you about a missing implementation of the Run()-Method in the class cApp. A quick look at your main code confirms this - you need to implement cApp::Run() there. The other linker errors have nothing to do with DX8 or DX9 either - you simply seem to have forgotten to include a bunch of cpp files in your project. All those missing methods the linker is telling you about are implemented in source files that are not part of your build. That's what you need to fix. You should also just include either dx8 or dx9 libs - not both (e.g. get rid of the #pragma comment(lib, "d3dx9.lib"), #pragma comment(lib, "d3dx9d.lib") and #pragma comment(lib, "d3d9.lib")).
  6. Since string literals in C are not marked as executable it's much more likely that DEP is simply not enabled for all programs.
  7. One must also keep in mind that generics are not at all equivalent to C++ templates or even Java generics (type erasure!). Some of the major annoyances with the platform have just recently (.NET 4) been fixed (like co- and contravariance issues with generic collections and enumerations).
  8. [quote name='Alpha_ProgDes' timestamp='1348241307' post='4982407'] [quote name='Hodgman' timestamp='1348239008' post='4982394'] Or if you think of positive mass as something that sucks space-time in towards it (like a vacuum cleaner's nozzle against a bed-sheet), then 'negative mass' would be something that pushes space-time outwards (like a leaf-blower). [/quote] So I guess Dark Matter has negative mass. Since in theory, it's pushing the universe outward. [/quote] That would be Dark Energy - Dark Matter - as the name implies - exerts the same gravitational effects on fabric of space time as ordinary matter. The only difference is that it seems to only interact with the rest of universe via gravitation.
  9. [quote name='Karsten_' timestamp='1347016516' post='4977569'] However, this mentality of developing software using platforms like .NET and Java because it is "easier" really needs to disappear if we as an industry are to progress. The C# language in particular really needs to die. It was marketed very well by Microsoft and was embraced by developers when it actually offers nothing beyond what Java had (un)provided for years. Unfortunately demonstrating how easy it is to sway the direction of technology. (if it wasn't for this, we could have had some awesome C++ libraries by now simplifying development for newcomers in a correct and innovative manner). [/quote] Just a side note on your ramblings. At the end of the day, all that counts is productivity and getting things done. Programming software is difficult enough as it is and there is no reason to burden the programmer with implementation details when an alternative programming language (tool!) allows him or her to focus on the actual problem at hand. You seem to have a very skewed idea of "progress". Progress is not adding library xyz to programming language foo just to be able to achieve the same that another language features natively (either as part of the core language or its baseline runtime environment). Progress is to explore and discover means of being more productive, less error-prone and able to cope with the increasing complexity that software requires today and perhaps even more so tomorrow. Ideology is nothing but a hindrance for true progress. A programming language is nothing but a tool. Knowing and promoting only one tool not only limits your choices on approaching a problem (both mentally and technically), and makes you inflexible when it comes to being to productive (i.e. regarding prototyping). Innovation needs room for new ideas and living in a one-programming-language-box doesn't provide much of that. Finally, just to counter your argument from ignorance that C# has nothing to offer that Java had for years - one word: LINQ, oh - and DllImport, hm, maybe the unchecked and unsafe blocks, lambda expressions, etc. etc. Bottom line: Learning more than one programming language is not a waste of time and statements like "language/platform xyz has to die because it hinders progress" are simply both untrue and quite offensive to the hard working, dedicated and bright people that created them. There is no silver bullet. Period. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
  10. Unfortunately most of the utility functions for loading models has been removed from later versions of the DirectX-SDK. The main reason is that developers tend to use their own model formats that best fit the requirements of their gfx engines, frameworks or digital content tool chains. Internal tools have therefore been dropped due to lack of developer interest and conflicting requirements. A scene format like [url="http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=7478532"]Adobe FBX[/url] for example might be rather feature complete and efficient for complete scenes, but is unsuitable for streaming data (like in large open world type games). Streaming data formats on the other hand depend on the target medium (SSD server disks vs. slow optical media on consoles, and so on) and the clustering of the data. In short, there are a bunch of libraries and SDKs (like FBX mentioned above) that provide fairly complete access to model and scene data, but loading these formats directly using the Direct3D API is often unavailable, because the process depends on the architecture and implementation details of your rendering system. Thus, most implementations provide an abstraction layer that lets you access all aspects of the serialised data, but leave the rest to you.
  11. Since you are not interested in pre-existing solutions, here's a path that might be worth exploring. First you'll want to export your model data in a format that is well defined and -supported by the digital content creation tool of your choice. In other words, try to stay away from the tool's proprietary format and save your assets as [url="https://collada.org/mediawiki/index.php/COLLADA_-_Digital_Asset_and_FX_Exchange_Schema"]COLLADA[/url] files for example. Next you need to identify the exact data that you need to render your scene and specify the exact memory layout that your renderer requires (e.g. index data width, vertex format, texture format, etc.) and convert the COLLADA files to a binary package that can be processed by your renderer without any further pre-processing. Ideally, you'll structure the binary data in such a way that the parameters to your CreateVertexBuffer or CreateTexture2D calls are actually stored directly in the data file. Using an intermediate format such as COLLADA has the advantage of allowing you to tweak your actual converter while leaving the actual asset unchanged and relieves you from the burden of writing custom exporters for your content creation tools, which in addition to the time required to get used to the SDK, is just another potential source of errors. However, being new to GameDev I would strongly suggest to use existing libraries and tools first. Trying to roll your own tool chain for asset processing shifts your focus from actually creating a game to creating tools which, depending on your goals, might just be in the way of actually finishing a game. There's nothing wrong with using .X files and all rendering packages that I'm aware of have exporters available. You'll have plenty of opportunities to to create your own tools after you gained some experience in actually creating games, but YMMV. HTH
  12. [quote name='David.M' timestamp='1345205474' post='4970517'] C++ is regarded as being the "best" language for game development because that's what AAA game studios use. They really have to use C++ though because speed is critical in those situations. [/quote] I'd argue that this is not even the most important reason. The existing code base that companies spend hundreds of person years developing is a reason that is not to be underestimated. No big studio wants to throw their most valuable assets away just to gain some productivity. Yet another big plus for C++ is the relative ease of creating portable code. The C++ toolchain is available for consoles, PCs and smart phones, while other programming environments might not (or at least not "out-of-the-box").
  13. [list=1] [*]Being faced with a random problem (say: writing a simple text adventure) [*]Looking at the options I have available (I started with BASIC on a Commodore 16) [*]Learned how to use the tools to achieve my goal [*]Tried to improve my skills by learning some theory (I started looking at algorithms like bubble sort, insert sort and data structures, etc.) [*]Bought a lot of shareware- and technical disk magazines (this was way before the internet) and looked at other people's code - now it's the internet. [*]Learned new languages (namely C and later Pascal), because they were used by many people in these disk mags [*]Added the new languages to my "toolbox" and tried to figure out what they were especially good at [*]Went back to Step 1 and repeated this cycle ever since. [/list] My current skills include a wide range of languages with varying degrees of current working knowledge (from domain specific ones such as SQL, XPath, XSLT, IDL and regular expressions to general purpose languages such as C++, ARM assembly, C#, Java, F#, Ruby, Pascal/Delphi, Javascript, ...). Lately (for the past 8 or so years, that is) I added a Step 7a to the cycle - acquiring more in-depth knowledge on some language features like implementation details, to better understand how the language works and why.
  14. I don't understand what you mean by "unique name". Each new entry in the list can already be identified by its list index, which is by definition unique with each list (e.g. no two separate instances can have the same list index at the same time). If you need a way to identify list items given only a reference, you can always add a property to your class like a time stamp or just use the list index: [source lang="csharp"]// 1) Unique name using time of instantiation class Market1 { public Market1() { Name = dateTime.UtcNow.Ticks; } long Name { get; private set; } } // 2) Unique name using list index (example only works for single list per class type) class Market2 { // here the constructor not only assign the name but also adds the instance to the list public Market2(IList<Market2> list) { Name = list.Count; list.Add(this); } int Name { get; private set; } }[/source]
  15. That is to be expected. Javac is just the compiler that generates bytecode from your program. You can execute the program using the java command.