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

DrummerB

Members
  • Content count

    2
  • Joined

  • Last visited

Community Reputation

104 Neutral

About DrummerB

  • Rank
    Newbie
  1. Well, that could work in theory, but I have trouble implementing it. I tried both of the methods you mentioned using the fixed grid approach. Redirecting velocity vectors at the screen boundaries is how people usually implement a simulation where the smoke isn't supposed to leave the screen. This could probably be applied to objects in the simulation that are placed exactly on cell boundaries, but what if that not the case? [img]http://i.imgur.com/XnkQp.png[/img] Imagine an upstream airflow in the above situation. At the rectangle's bottom edge, in which cells would I redirect the vectors? The ones that are completely outside (below) the rectangle, the ones on the edge or the ones inside? None of these seem to be a good idea, because either the smoke would be redirected early (making it look like the rectangle had some repellent force on it), or the smoke would go inside of the box. At least that's how I see it. This is what I meant, when I said that a way too high grid resolution would be needed to get rid of artifacts. And once you add arbitrary polygons and rotations it really looks like a lost cause. [img]http://i.imgur.com/wgOJy.png[/img] This is why I started investigating the vortex method. Even though you still have to calculate a velocity grid from all the vortons, you can place the vortons at any position, not just on the grid. This made me think I could get better results. But I'm still not any closer to a working prototype.
  2. Hi, I'm new to this forum, but I thought this might be the right place to ask for advice. I'm trying to create a realistic, physically correct (looking) smoke effect in 2D. For more than a week now, I've been experimenting with different approaches in the fluid dynamics field. I successfully implemented an Eulerian fixed-grid algorithm (based on [url="http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/GDC03.pdf"]this[/url] and [url="http://cowboyprogramming.com/2008/04/01/practical-fluid-mechanics/"]this[/url] article) and it works as expected. [img]http://i.imgur.com/s9IsV.png[/img] (The cells are not smoothed for debugging purposes). However I just can't figure out how to implement boundary conditions for rigid bodies in the simulation. Being able to simulate realistic airflow around a ball and turbulences behind a moving object is why I started working on this in the first place. I spent hours googling and reading through countless articles and papers, but all of them just say that you have to account for boundary conditions when setting up the velocity equations or apply a poststep fix, but they never go into details. I'm also starting to think that a grid based method is not the best for simulating airflow around arbitrary placed and shaped objects, because you would have to use a very high resolution grid to get rid of artifacts. Correct me if I'm wrong. I also investigated vortex based methods, where you use an array of vortex particles (vortons) to represent the airflow. The vortons aren't fixed, because they are affected by the velocity field they create. So they move around and change their angular velocities. It's a bit more complicated then a fixed velocity grid method, but the real problems only arise once I want to add rigid bodies to the simulation. Let's say I just calculated the velocity field for the current frame from all the vortons in my simulation and it turns out to be a very simple one: [img]http://i.imgur.com/I7gjn.png[/img] Now I want to account for the orange ball in this flow. Wether the ball is stationary and the air is moving past it, or the ball is moving to the left in a non-moving field doesn't really matter. In some articles they suggest adding auxiliary vortons somewhere along the surface of the body to redirect the airflow and satisfy the boundary conditions. But I couldn't yet figure out where and what kind of vortons have to be added. [img]http://i.imgur.com/l1sy1.png[/img] In the above case we could determine the ambient air velocity [i]V[sub]A[/sub][/i] at a point [i]P [/i]on the ball surface and place a vorton alongside a line normal to the airflow. Then we specify a vorticity (angular velocity) of the vorton, so that the velocity it creates equals [i]V[sub]V [/sub]= -V[sub]A[/sub][/i] at [i]P[/i]. This way all velocity at [i]P[/i] is canceled and the boundary conditions are satisfied at [i]P[/i]. The problem is, that there are two possible ways to place the vorton (to the right or to the left of the airflow vector). Placing the vorton on the other side also means we have to reverse it's vorticity. How to we find out where to place the vorton? We could use the angle between the normal vector at [i]P[/i] and the airflow to separate the vortons into clockwise and counter-clockwise vortons. This would result in something like this (blue: clockwise vorton, red: counter-clockwise vorton): [img]http://i.imgur.com/fAYtZ.png[/img] This looks like to could work, but I'm not sure. What do you think? The air infront of the ball is pushed away, and it sucks in some air behind it. However in the case of a rectangle it won't work: [img]http://i.imgur.com/TF0ZN.png[/img] Using the surface normals to categorize the vortons into CW and CCW ones will result in a row of vortons all turning in the same direction. Instinctively I would categorize them like this: [img]http://i.imgur.com/OZDTg.png[/img] This looks more like what one would expect (although I'm really not sure), but how could this be implemented? One could use the distance from the edges, but that sounds more like a hack then something stable. Or maybe I'm completely on the wrong track and there is a better way to do all of this? Any hint, advice or useful link would be very appreciated. Thanks for reading.