• 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

1068 Excellent

About plainoldcj

  • Rank
  1. Hey, maybe reading this helps with your scewed texture problem: [url=http://www.xyzw.us/~cass/qcoord/]the q-coordiante[/url]
  2. Okay, here's my code: view on github. I'm using the graph data structure and Voronoi algorithm of the LEDA library. The LEDA API is actually pretty good, so you should have no trouble reading the code, even if you are unfamiliar with the library. The output of LEDA's Voronoi algorithm is a planar graph. Every edge is labeled with the site on its left side, and every proper node is labeled with CIRCLE(a, b, c), where a, b, c are sites closest to that node. The target nodes of unbounded edges have nodes at ,,infinity'' that store degenerated circles. More information here. The idea to bound the Voronoi Diagram, i.e., to intersect it with a quad, is as follows. First of all, assume that we only want to get rid of unbounded regions. Then we can choose the quad so large that is only intersects unbounded edges of the Voronoi Diagram. The basic idea is to traverse all unbounded edges and move their target nodes from ,,infinity'' to the border of the quad. So, for each unbounded edge you compute the intersection point with the quad. That's pretty cheap, because the quad consists of only four segments. Also, you don't need to create new nodes or something like that. You can efficiently find the next unbounded edge (in counter-clockwise order) by following the face cycle of the unbounded ,,backface'' region. While traversing, you could simply connect the target nodes of two adjacent unbounded edges with a new edge. In addition, you have to add the four ,,corner nodes'' of the bounding quad. In essence, I check for every pair of adjacent edges if there is a quad node between them. If that is the case, I add it. Because I traverse the backface in stricly counter-clockwise order, the quad nodes are added in that order, too. So at any time, there is only one possible candidate node that I have to test. For my particular application, I needed to bound the Voronoi Diagram with a fix-sized quad, which might intersect edges of proper regions (I wanted to render a fix-sized section of the diagram). Therefore, the code I show you first loops over all nodes and edges. Every edge that intersects the quad is subdivided into two new edges: one new edge is outside the quad and can be discarded. The other new edge is treated like an additional unbounded edge. I implemented this algorithm because a naive approach using general segment intersection algorithms turned out to be too slow.
  3. I'm not entirely sure I understood your question correctly, but to me it sounds like you want a ,,bounded voronoi diagram''. Or, put differently, you want the intersection of the vornoi diagram and a rectangle. If that's what you want, I'll gladly tell how I've done it in one of my projects.
  4. Okay, I'm tired and maybe I'm missing something. However, it appears that you simply adopt the orientation of firePoint for the newly instantiated game object. I assume firePoint is the tip of the gun and its a child of the player game object. So, I'd say you turn the player in direction of the mouse, the firePoint turns accordingly and then you instantiate the bullet with the same orientation. What you want to do is shoot the bullet in direction (mousePos - firePoint.pos). If I recall the Unity API correctly, you could simply assign that direction to transform.forward. Alternatively, there is a method Quaternion.LookRotation.
  5. Hey guys, great links, thanks! I find pygame.org especially useful, because it shows screenshot of the games.
  6. Hey, at the moment I'm heavily procrastinating, so I thought it's a good time to refresh my language knowledge Therefore, I'm asking if one of guys has a small game (around 10k loc maybe) written in Java or Python that I can tinker around with. Ideally, the game has only a few library dependencies. Also, the code should be "java-ish" or "python-ish" (as opposed to translated from, say, C), so I get to learn common idioms and standard libraries. Open source games are fine, too. So, any suggestions?
  7. That's interesting, I haven't thought about it this way before. I don't know much about SC2, but I've played WC3 a lot (lot). In WC3, there are research queues. Both games focus on micro-management of single units or small groups of units. That's a design decision that forces you to have little automation (including AI) of movement and casting, because that's how players compete. I like the idea, that most of what happens is caused by direct player input. I agree that the player has to carry out a lot of tasks, but I don't think they want to keep the player busy clicking. The assignment of drones to minerals, for example, has been automated in SC2, simply because it's a boring task with no consequence for the outcome of a match.
  8. I prefer method 2 for composition, although I sometimes use method 3 for the following reasons. 1. using pointers, you can forward declare class Graphics in the header to reduce dependencies, which in turn reduces compile times when you modify class Graphics 2. using pointers, you can put all the initialize() work in the constructor and you don't have to worry about your object being in invalid state. (in cases where you can't use initializer lists)
  9. It sounds like the weapon is rotated around it's center and then translated, so maybe the order of transformations is a problem and you can try to change translate * rotate to rotate * translate.   In general, you want the weapon to have a fixed position in camera space. Therefore the easiest way is to not transform the weapon at all.   If you transform all your objects by the same "world" matrix, however, you want to give the weapon a local transformation that cancels this effect. that is the weapon matrix is the inverse of the world matrix. Try using a standard Invert() method first and see if it gives the desired results.   After that you can try to replace the Invert() call with a product of translation and rotation matrices.
  10. Maybe it's already sufficient for your application to sort the individual triangles back-to-front. You can store the vertices statically on the gpu and issue a sorted list of indices in every frame, for example. It's not too bad.   If you really need perfect transparency you may consider depth peeling. It's a multipass technique and runs on older hardware.   The cheapest trick is to draw in any order and tell everyone it's correct. Most people don't notice alpha-blending errors anyways :)
  11. Think in terms of frustrum planes, not view rays. You could try something like this, again using the right frustrum plane for example: 1. get the plane equation 2. cast ray R along x-axis to find object-plane distance 3. move camera along x-axis so that distance is 0 depending on the object or which bounding geometry you use you should sample the distance at every vertex and use the minimum or something like that. im not really sure what you are trying to do. after the camera translation the object should still be outside the camera view, right?
  12. In the example above the right plane of the viewing frustrum should be a supporting plane of the object. that is the object and the plane must intersect and the object must lie on one side of the plane.
  13. Does your problem look similar to this: https://dl.dropboxusercontent.com/u/56764397/screendump0.png ? When you talk about the camera losing pixels and objects moving into the screen this could be a clipping problem.
  14. Hmm. To my surprise the problem disappears when I choose a sufficiently large negative value for the near clipping plane. So before I set (znear, zfar) = (0.1, 100.0) for both the perspective and the orthographic projection matrix and the error occurs. When I choose (znear, zfar) = (-100.0, 100.0) for the orthographic matrix everything looks fine. I have no idea why. Since setting znear = -100.0 essentially doubles the viewing volume I would guess the error becomes even worse!
  15. Hey guys,   I observe strange artifacts in my application when I switch from perspective projection to orthographic projection. Here's an image of the problem: https://dl.dropboxusercontent.com/u/56764397/projection_bug.png It looks to me like some sort of z-fighting.   Now, I'm using depth peeling for transparency and the artifacts disappear when rendering with another transparency technique, so maybe the issue is how I read and write the depth textures.   It's pretty strange, though, because the projection matrix is not referenced in any fragment shaders.   Any ideas what I can do to isolate the problem?