• 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

1263 Excellent

About GeneralQuery

  • Rank
  1. You say that as if it were a surprise :) Granted, this was a zeitgeist topic about, what, 15 years ago but when have these threads ever ended well? Still, if anyone needs any more gasoline to throw onto the fire I'm here all day (or at least until the inevitable lock).
  2. Hard to tell without any code. What is the point of reference being used to determine LOD distance and visibility?   You could look into something like clipmaps, it's fairly simple to implement.
  3. We have no idea what any of these methods do so the first port of call would be to list them.
  4. I'm doing a 2 for 1 on gasoline right now if anyone's interested.
  5. Nearly. This puts your point into [0,1] range:   // Assumes all values are floats so cast appropriately if not... float relativeX = mouseX / screenWidth; float relativeY = mouseY / screenHeight; And now to expand from [0,1] range back into absolute positioning:   float absoluteX = relativeX * screenWidth; float absoluteY = relativeY * screenHeight;
  6. It's early days so there's not much to say. The terrain is very bland and featureless at the moment, partly because of the very low frequency geometry (experiment with higher frequency heightmaps and/or exaggerating the height to step away from the bland "rolling hills" look) and partly because it's hard to say what the surface material looks like (it's very dark, too dark to see anything meaningful). It's a good start, though. Certainly enough to build upon.
  7. Disclaimer: IANAL! "Does giving credit to the musician in the credits actually lessen or remove any of these consequences?" No. You need permission from the copyright holders of the composition and the recording itself. Crediting the musician isn't enough and even if the musician gave permission, that's no guarantee that other parties do not hold copyright on, say, the recording.
  8. Do you want the retain the absolute coordinates (i.e. x:60,y:10 on machine1 is x:60,y:10 on machine2) or relative coordinates (i.w. x:25%,y50% on machine1 is x:25%,y50% on machine 2)? I'm assuming the latter so I'm not sure what the issue is with the thrust of 3TATUK2's suggestion. Working with coordinates in normalized form (i.e. [0,1] or [-1,+1]) would be the obvious solution as you can map these values to whatever size/resolution you want with more than enough accuracy but I guess I must be missing something?
  9. They do not add detail. You start with your "hi res" mesh (generated offline, through some modelling process or whatever) and then reduce the complexity of the mesh with respect to the distance from the viewer to reduce the workload of the rendering process. This is not the same as "adding detail at runtime" which would imply some form of tessellation/surface displacement technique (or whatever).
  10. Your lighting looks off. I don't know if that's a normal or lighting equation issue but something isn't right. This could be why the transitions between LODs is so odd and inconsistent. I personally would address this issue first and foremost. ETA: It looks like the lower LODs are the problem but I may be wrong as the issue could be more fundamental.
  11. Read the full GPU Gems chapter. It's a LOD technique for performance, not about displacement mapping or tessellation.
  12. It's not about NOT writing an engine; ultimately the end product WILL be an engine, albeit very specific to the game. You can then reuse aspects that are generic in the next game and so on until you end up with software that could be made generic enough for a family of game styles (or whatever). And this is the key issue: the description you gave of the components you feel you need are very game-centric because there is a very clear and specific goal to the project (Torchlight clone). Already the direction is focused and the design anticipations are reasonable for an actual end product, rather than trying to guess what you think you'll need for the Super Uber MegaEngine (tm) that will do every game style on the planet, kill CryTek dead in the water and even make you coffee whilst you're at it (and on your first coding attempt to boot!). It's a philosophical position rather than a literal, immutable rule.
  13. Oh right, yes, your experience sounds more than adequate to your needs. Calculus is a must for a lot of GI work in my experience but it seems as if you have this base covered. Your best bet would be to check out the Rendering Equation and see if you can make heads nor tails out of it. If not, then I would say you will have your work cut out for you as it will come up in various shapes and forms throughout your research. There's lots of reources online to explain this aspect to you but if you are lacking in the mathematical department then I would advise you brush up on this first. That's not to say you can't research GI without such skills but it will be a handicap for you. Some topics to get you started: * Global Illumination (obviously!), very broad topic encompassing many techniques * Radiosity * Virtual Point Lights * Spherical Harmonics * Environment Mapping (this resource is great, check out the whole blog, lots of good info here) GI is not my field but I did tentatively survey some of the literature a few years back so hopefully this will give you some ideas and maybe some more knowledgeable users can fill in the gaps for you.
  14. What you could do is generate your 2D colour key from your heightfield image and then check for intersections of particles and what not by getting the particle's position within the heightfield to obtain the colour key value and then check the particle's y position against the heightmap's height value at that point to see if an intersection occurred. I have never done this so I am freewheeling here but IMO this would be simple to implement and would avoid the more costly and involved method of 3D collisions between more arbitrary geometry.
  15. Do you have institutional access to online journal resources like ACM, IEEE, Wiley etc? The reason I ask is that the general web isn't really too hot for learning this stuff so the best approach (IMO) is to go straight to the horse's mouth and read the academic papers. But! They are often behind a paywall (hence the institutional access). There are ways around this (try and find a copy of the paper on the author's website, emailing the author, etc.) but this is much more long winded than having access to the journal repositories. My approach to research is to find a paper that is either seminal or an offshoot off of a seminal piece and track down the references, both forwards (papers that cite that work) and backwards (papers cited by that work). Before long you will have a web of papers covering most of the pertinent works. That's not to say there aren't any fantastic resources online (there are!) but I would not use them as my primary research vessel as they are far and in between in my experience. Places like this website are great for asking questions to clarify key points but (again, IMO) this is an inefficient means of learning about a topic if your research is intended to be broad and comprehensive.