• 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

869 Good

About Vorpy

  • Rank
  1. It looks like you aren't looking up the pixels in the masks correctly. Instead of spriteOneVect[s1XAP*s1YAP], something like spriteOneVect[s1XAP+sprite1width*s1YAP]
  2. How is the velocity of the top ball affected by the constraint?
  3. fps is not a linear measure of performance. A drop from 1000 to 500 fps is approximately the same as a drop from 500 to 333 fps, or 111 to 100 fps, or 60 to 56 fps. In each of these examples, the difference in run time is about 1 millisecond. Using your numbers: 1400 fps = .7 ms 520 fps = 1.9 ms 140 fps = 7 ms That 900 fps you're losing is caused by approximately 1.2 ms of processing. If you made your algorithm 4 times faster, you would get approximately 1000 fps. Except that the 1400 fps number was from debug mode, so it doesn't really mean anything... So anyway...it's better to time your code than use your fps counter. And measuring performance in debug mode is meaningless. Complex but highly optimizable code, like STL containers, will tend to run very slowly in debug mode but very quickly in release mode.
  4. If you haven't already implemented a simpler algorithm, like Dijkstra's algorithm, I'd recommend doing that first. A* is a complex algorithm so it can really help to have a good understanding of the more basic algorithms. You might also want to look into the fringe search algorithm. It's simpler than A* and can perform almost as well (or better); in fact, it will probably perform better than your current A* implementation because A* requires a bunch of optimizations to perform well. One big A* optimization is to avoid scanning the open and closed lists to determine if a node is on them. You can keep track of which list the node is on within the node itself (only takes a few bits of memory per node, just be sure to clear this out between searches).
  5. It doesn't matter if the projection is expensive, since you only need to do it once. Store the results somewhere.
  6. Treat the sponge like an octtree, except that instead of dividing each cell 8 ways it is divided 27 ways. For a given ray intersecting a non-empty cell, do the collision against its 27 children and recursively process the non-emtpy children it hits in the order that it hits them until you find the first intersection with a non-empty leaf cell. Each recursive step returns a boolean indicating if a non-emtpy cell was hit, and if so, the location and normal of the hit. Now you just need to perform the intersections between the ray and the grid of 27 cells efficiently.
  7. You have one extra degree of freedom. If you had a third point, or a desired second derivative, or a desired slope at some point, there would be one solution instead of infinitely many. As it currently stands, a straight line could go through your two points (second derivative of 0).
  8. What is your question? Remember that once you have the camera transform, you use its inverse when rendering in order to draw things relative to the camera.
  9. I think your rotation will be something like 90/90/45 Edit: Actually, are you applying each of the transformations in world space, or in the local space? The transformation you want could also be something like 90/45/90...try different combinations like that to see what works.
  10. It looks like you are adding the position of the rigid body to the torque and linear impulse. When the object is at the origin this has no effect, but as soon as you move away from the origin this will create erroneous torques and impulses. Since the linear impulse make the object move down the negative z axis, this negative z value is being added to the torque, making the body rotate. You only want to apply the rotation of the rigid body to the torque and linear impulse, not the entire transformation.
  11. The closest games usually get to this is storing the movement from the animation alongside the animation itself. Then as the animation is played, the movement is also applied to the object. If the animation has the character moving forward .1 meters in a frame, when that frame is played the character is moved that distance.
  12. Zeroing out the velocity when hitting the wall is fine, but since the key is still being held down, they should get their velocity back in the next frame. Just adding velocity once when the key is pressed isn't enough if you're going to clear it later. You need to apply acceleration or set the velocity as long as the key is down.
  13. Each square has 3 possible values and there are nine squares. There are 3^9 or 19683 permutations. Many of these are not reachable in an actual game (for example, boards where both X and O have 3 in a row). Since the number isn't that high, you could probably just make a table of that size and you'll just have entries that are never visited. Or use a hash table/map/associative container of your choice. You can encode the entire state of a tic tac toe board into a 16 bit integer. A simple way to do this is to assign empty, X, and O the values 0, 1, and 2 (in any order you'd like), then set an accumulator to 0. For each space in the board, multiply the accumulated value by 3 and add the value of that space. Or even encode the entire board into a 32 bit integer by simply using 2 independent bits to store the state of each square. There are far fewer possible states if you account for symmetry. With symmetry, there are only 3 states after the first move (corner, side, and center). But if the goal here is to find weaknesses in an imperfect player, then you wouldn't want to exploit symmetry because the imperfect player may have asymmetric weaknesses.
  14. The state is the entire state of the board, not the state of an individual square. There is only one starting state, which is the empty board. There are 9 valid moves from this state.
  15. A normal does not have a "reference point". It is just a direction. It looks like you're adding the first vertex of the triangle to the normal when you compute the normal, and then subtracting it later. It shouldn't be added in the first place. The dot product should be between the triangle's normal and the direction the camera is facing. The direction from the camera to the first vertex of the triangle is not meaningful here.