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

Enalis

Members
  • Content count

    326
  • Joined

  • Last visited

Community Reputation

333 Neutral

About Enalis

  • Rank
    Member

Personal Information

  1. Just to elaborate some more, chaining shaders would require you to output to an FBO at each stage, this takes up quite a bit of VRAM if they are RGBA32. Also, keep in mind that you are writing out to a lot of extra pixels for every frame, this also slows things down quite a bit. As mentioned before, it is unavoidable sometimes, like in the case of a Bloom pass, but it should definitely be minimized.
  2. Are you planning on doing this in real-time in a shader? I ask because that could result in quite a performance hit. Also, if you are not doing it in a shader, there is software that can already re-build height maps for you, given an obvious height scale parameter. It's important to note that if you are mapping something like stone, where one "bump" in the normal map might have the same slope as another, you will end up with the same height at those two different places because the curvature is the same and there's no way to know without the original height map where the slope ends in height at those distinct spots.
  3. *Obligatory don't do it yourself unless you really have to reply!*   Before you delve into this, have you looked at Tiled (http://www.mapeditor.org/)? It's very powerful and would easily create these sorts of maps with the right tile-set.
  4. As mentioned previously, these things are indeed separate. I have also been working on the problem. What I do is keep the mesh data in very very small patches. I can tessellate these patches on the GPU for more visual detail, or turn them into a grid to pipe to the physics system. It works pretty well.
  5. I often describe my day simply as such:   40% research/reading 40% conversation 20% coding
  6. I've had no issues thusly with any of the modules. I would avoid their threading stuff now though, since c++11 threads are pretty good.
  7. I'm working on a design for a pipelining game engine, with data some parallelization at each pipeline stage as well.   If I have 4 stages (input/networking, physics/animation, logic/ai, rendering). If I understand the idea of pipelining correctly, then each stage would get it's own copy of the game state, including a copy of the physics simulator (in my case a bullet physics world object). That way each stage can operate concurrently without affecting the other.   Now let's say that at stage 3, an object gets added to the simulation, stages 1, 2 and 4 are now out of sync, and since their simulation state data is ahead/behind respectively, then how can I even add this object to those simulation states without having them be out of sync from the start?   I'm sure this is something commonly solved, I just haven't been able to find any literature on the subject.   Thanks in advance!
  8. DAE is XML, there's a schema and a specification... beyond that it's pretty much up to you. The last time I went to use DAE directly, I ended up reading it myself. I would personally recommend Assimp.
  9. A good start for anyone getting into js coding is to use a lint tool. It will help you keep your code tidy and professional, as well as use good practices. You need to be heading in a good direction though. As far as cameras go, you can either define a simple x, y position in the world, and just offset your tiles by this. You can also give it a width and height to know how many tiles fit in a camera's frustum. There are many approaches but starting there might be easiest.   Have you considered using a HTML5 canvas rendering engine? There are many out there and will help you get started with rendering sprites and normal game things.
  10. I encourage you to spend time and look at a few different operating systems, APIs and development environments in general. I found love with OpenGL and KDevelop on KDE in Linux (Kubuntu). I haven't looked back in quite a while. I keep my engine/games cross platform so they'll run on Windows, OSX and Linux though, just for good form.
  11. Have you tried setting the clear buffer color to say, 0, 0, 0, 0?   In opengl that is: http://www.opengl.org/sdk/docs/man/xhtml/glClearColor.xml
  12. 1: If it's truly turn based, this should be completely fine, and will make life a lot easier I'd say. I've even considering using compressed json strings for packets on real time games just because JSON rocks.
  13. I'm going to try to put my Linux fanboyism aside:   For development, I find Linux to be a little easier to get started. You simply install most of the things you need to get started via the package manager and go. And when you do need to compile your own dependency, I find it less of a headache.   I also prefer the idea of Linux. Most distributions like Ubuntu are mostly if not all open source. This allows for the community as a whole to work on things together. The beauty of it is that you can go hack on your favorite Linux application most of the time and get things fixed.   Typically, if you have well supported hardware, Linux is rock solid. Because hardware vendors sometimes don't release specifications for their hardware drives can be a bear. Normally there is some support somewhere but it's hard to reverse engineer other drivers or figure out how to write some from scratch.   I for one am a fan of Kubuntu's latest version 12.10. I find KDE (The desktop environment, like explorer in Windows) to be a good transition from other OSs that doesn't sacrifice customizability. Out of the box, the applications bundled are rock solid as well. If you are a coder, you'll likely love KDevelop or even just Kate.   I do keep a windows box around for gaming and some media in general hooked up to my TV but that is it. And with Steam beta being out for Linux, and Netflix at least working for now, that Windows Box may not survive much longer.   My suggestion to you is to go out and download Kubuntu 12.10 and put it on a USB Drive to test it. You don't have to install it to test it out. The experience won't be as good running from a USB Drive but you can at least test some of your system compatibility.   Here's a link: http://www.kubuntu.org/
  14. I would say it's a useful exercise. There's still plenty of validity to the technique. I see the future of graphics techniques for engines being a myriad of approaches mixed together. Deferred is obviously an awesome technique for many lights on opaque surfaces. But many deferred renderers have a sort of traditional forward renderer stuffed inside to do translucent objects as well. As far as where to learn this stuff, I spent most of my time piecing together tiny articles talking about techniques, but in the end, how you implement it might be entirely dependent on the scope of the engine/game being developed. For instance, the battlefield 3 engine has buffers specific to terrain info storage, where my engine wants to accommodate both ground/space based games so I can't count on this info being there. In the end, I sincerely recommend you piece through some code. Feel free to look at mine as I've already done a lot of what was mentioned, but it's really up to you to discover your own techniques. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] [url="https://github.com/palodequeso/Element-Games-Engine/blob/master/Engine/Graphics/Source/RendererDeferred.cpp"]https://github.com/p...rerDeferred.cpp[/url]
  15. I struggled with this at first but found the data driven architecture to be quite nice. I have the basic Object class which you can attach any number of different types of attributes too. These include mesh/materials, variables, lights, particle systems, rigid bodies, etc. Attributes are user create-able too so you can attach any number of your own attribute types to the object. These can be used and manipulated in the specific game code, outside of the engine. One other thing you can do is attach a lua script to an object which has the ability to manipulate the object directly. Obviously some things need coded specific to the game itself, but most things can be accomplished with a flexible attribute system. I know this still sounds like a tangle web, but I invite you to just try coding a simple prototype... I think you'll find it easy to get through once you start. My code is on github, feel free to take a look. Here's a starting point: https://github.com/palodequeso/Element-Games-Engine/blob/master/Engine/Game/ObjectAttribute.h