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

Vilem Otte

GDNet+ Basic
  • Content count

    712
  • Joined

  • Last visited

Community Reputation

2936 Excellent

About Vilem Otte

  • Rank
    Crossbones+

Personal Information

  • Location
    Czech Republic
  • Interests
    |programmer|
  1. So, as I've created some games already in Unity, I will describe simple example of how I'd do it in Unity these days (and most likely will do it next time I'll use Unity for something): Here is a simple example I put together in few minutes: https://otte.cz/random/MainMenu.rar Short description: What you need is some GameObject in scene which will have script containing public functions that are handlers for buttons. The class holding these must derive from MonoBehaviour, like the one in the archive: using System.Collections; using System.Collections.Generic; using UnityEngine; using UnityEngine.SceneManagement; public class MainMenuController : MonoBehaviour { // Function called for button, must have 0 or 1 string argument at most, must be public public void NewGameHandler() { // Load another scene with "Game" name, scenes must be added in Build Settings! SceneManager.LoadScene("Game"); } // Function called for button, must have 0 or 1 string argument at most, must be public public void QuitHandler() { // Exit the application Application.Quit(); } } Now on the buttons, add a On Click record, where you attach (drag & drop, or just click + select) this game object with above-like MonoBehaviour attached. Next, select (from event drop down) the MonoBehaviour class name and under it there will be a function (NewGameHandler, QuitHandler)... note that the drop down has 2 levels, it is easy to miss it. It is setup in the project in the archive, so feel free to use anything from it.
  2. Wait... you don't do anything to your secondary rays. The algorithm for DoF in ray tracing works as following: Start by casting a ray from camera into the scene. But instead of intersecting it with anything, you just determine the focal point for given pixel in the scene (pixel focal point). Now, for N samples, do: Select a random starting point on aperture. For circular - random polar angle + random radius, for rectangular - just use some distribution over the rectangle. Just make sure your probability distribution functions for your random number generator integrate to 1. Cast a ray through this point on aperture and focal point like you do normally, reflecting/refracting it around. I can put you a smallpt-like example up in few hours from now (I still have something to finish at work).
  3. I can't state for a book, but what you're trying is to simulate some physics behavior. So the real question from me is, are you trying to: Simulate the actual effect (in which sense it will have also most likely impact on gameplay), so that the actual effect behaves realistically Fake the effect and just rendering something that looks good/realistic There is quite huge difference between the two, and in the first case the actual rendering is most likely minor problem (due to the nature of simulation, it tends to be easy to actually render it), you can use information that are part of the actual simulation. In the second case, it tends to be easy to make 'good looking particles' for literally anything, while extremely hard to make them move and animate like realistic effect (basically 'fake' the simulation part).
  4. The problem with interpolation is, I can't do that beforehand. I have a set of elements from which I'm building a tree (those are voxels, generated for the scene). Now as I know the position of each voxel, I have no idea about its sorroundings (they can be in random order inserted into the set), all I know is their position and data (color, normal, whatever I wish to store). Adding voxels with interpolations would mean that I need to find neighbors in this set (which is actually easily done when octree building is finished). This will be quite hard, as the tree can't be easily modified. EDIT: Thinking of this, yes technically it is possible to add nodes, removing them might be more tricky - but yes, also possible ... as actually each node represents sparse octree itself. I believe this might be a decent way to handle inserting dynamic objects too ... or maybe different levels of quality (whenever it is necessary). Making this easily usable even for case of 'ball in stadium'. Each of the elements is inserted into the tree (the tree I generate is sparse), and doing any form of refinement will be hard, if not impossible once tree is generated (it uses parallel algorithm for that): You start with root node (levels = 1) Loop (for i = 0 to levels): For each element - traverse into the 'levels', and flag which nodes are to be split For each node in current level - if node is flagged, generate 8 child nodes Allocate generated child nodes Repeat the loop Now, I can't really change a tree once it is finished. The point is, I realized that bricks are something different than what I thought they are. The value in the centre is the most important one, and 26 values sorrounding the center are duplicated (yes, it is "memory overkill" in this sense)! The correct version of previous images is (and should be): [sharedmedia=gallery:images:8649] The mipmapping part seemed tricky at first (but my algorithm is wrong), what I should actually do is, for child nodes, use their center values (and the values between the centres - which will be 3x3x3 total values! Not 4x4x4!) and average this into the parent node's center. Then put the boundaries to fill boundaries in the parent node. Now, this will need additional step to perform the interpolations like I did for leaves, to guarantee that the border values in bricks are correct. [sharedmedia=gallery:images:8650]   Sounds quite complicated though (I didn't have time to measure time figures, as the code is still work in progress, so hopefully it won't be that big problem to compute).   EDIT2: Yes, I can confirm that now it works quite properly (even AO is smooth). The last part I'd like to investigate is traversal.   The sampling one is of course extremely fast if sample count is low, but as stated - unreliable. Increasing sample count can solve problems (basically oversampling everything), but tends to be quite heavy. But what's the point of using SVO when I'm just brute-forcing through right? Which has O(n) complexity.   I've tried ray-AABB intersections and stepping down the tree (using stack-based approach ... basically something similar to what one would use for BVH ray tracing). While reliable, it is extremely heavy if the nodes aren't pushed into stack in correct order (which doesn't seem as straight forward as I thought will be). This should theoretically have O(log(n)) complexity, assuming I put the children to stack in order to process them "along the ray".   I'd also like to try DDA-like approach (as each time I can determine on which level the empty intersected node is, it should be straight forward to step accordingly to next node), as stated previously - if implemented correctly, it should have O(log(n)) complexity of finding next node along "ray", and 
  5. From the album Posts sketches

  6. From the album Posts sketches

  7. And no, I still don't have filtering right. I noticed that 2 items will cause problems, so the first one is filtering inside leaves: Here is a pseudo-example: [sharedmedia=gallery:images:8641] This is our starting point - semi transparent nodes are visualization of part of the tree that is empty (therefore those nodes are not really there, and or course we can detect that there are empty nodes). Top left 4 nodes are full. Bottom left 4 nodes are also full (some with data that have alpha = 0). I will demonstrate filtering along X-axis (as described in paper). So, the first step is: [sharedmedia=gallery:images:8642] Writing data to the right neighbor (of course as tree is sparse we can't really access the 'transparent' - non existing nodes). This will be the result: [sharedmedia=gallery:images:8643] Now, as the data in right-most voxels need to be the same as in the left-most voxels, we need to copy from right back to the left. Like: [sharedmedia=gallery:images:8644] And the problem is: [sharedmedia=gallery:images:8646] Obviously as we can't write into non-existent nodes (due to sparse nature of the tree), the values won't match (even when we assume that value was with alpha = 0 in the previous steps). All the data neighboring non-existent nodes will be invalid ending up in a border. Of course the same problem is hit when computing interior nodes (mip mapped ones) - they will not match properly. Resulting in non-smooth ambient occlusion like this: [sharedmedia=gallery:images:8648] The paper sadly doesn't address this problem at all (it describes scenario when the tree is dense, in which case it is working properly, but as soon as tree is sparse, the problems arise). Any idea how to properly solve this? Obviously the leaf nodes can be solved by detecting non-existent nodes around currently processed node and set values to match (in all 6 directions). But how to perform 'mip-mapping' after (e.g. how to compute interior node values in a way that would make sense)?   My apologize for double-post!
  8. From the album Posts sketches

  9. From the album Posts sketches

  10. From the album Posts sketches

  11. From the album Posts sketches

  12. From the album Posts sketches

  13. From the album Posts sketches

  14. From the album Posts sketches

  15. From the album Posts sketches