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


GDNet+ Basic
  • Content count

  • Joined

  • Last visited

Community Reputation

704 Good

About extralongpants

  • Rank
  1. [quote name='HuskyMaster' timestamp='1296079074' post='4765296'] Alright, i know theres a reason "file" is in the name. you've gotta use c++'s 'write to files' commands, but my question is: what exactly do you write to a save file? Say youre making an RPG. To the file you would just write the Stats, Last Position, Name, Items in Inventory, Skills, Etc., all in a specific order? Then when the file is loaded next, just set the game up using what it read from the file? tutorial link please? [/quote] There's no one right way to do it. Just save any data you need, however you want to, and read it back in however you want to. It doesn't even necessarily have to be in a specific order, and it doesn't need to be written to a file either - you can save it as a database entry, send data to a remote server, or whatever. Typically, though, you do save it to a file, and what you described sounds fine to me. For a game with lots of data to save, the save file format may need to be optimized for space, so that the saves don't fill up the users hard drive. To do that, you have to make sure that you're saving only what you need, and that the data you [i]are[/i] saving, is saved in an efficient way. The simplest step in that direction is just to save your data in a binary format, rather than a plain text one. For the most part, though, especially for a small game, I think it's best to just stick with a plain text format. That way, if you find a problem with reading/writing a save, you can just open up the save file in a text editor and figure out what's wrong with it (or even fix it). To make reading & writing easier, you can use libraries that handle common plain text formats like XML or JSON.
  2. [quote name='NEXUSKill' timestamp='1296049641' post='4765030'] I think what was meant by Sweep Testing is testing everything just in case... [/quote] I think the swept test was originally mentioned here: [quote name='Burnt_Fyr'] IIRC Swept volume testing will accurately detect collisions even with fast moving/really small objects. Don't quote me on that however. [/quote] and then here: [quote name='Nanoha'] Sweep tests are more accurate but also more costly. a cheaper approach is to just move the objects and check if they intersect, then move them apart if they do. That works fine unless your objects are particulally small/fast (in which case you can switch to a sweep test or a ray test). [/quote] Both of these look like they're talking about swept collision volumes, but the terminology can be confusing.
  3. [quote name='bambinoh' timestamp='1296002624' post='4764805'] Hi. Sorry I can't offer any help or advice of some sort. I'm very much a beginner myself and I try to learn wherever I can. However, you guys mentioned 'sweep testing' a couple of times. What exactly do you mean by 'sweep testing'? I've been googling on it for a while but I can't come up with an explanation... [/quote] Basically, instead of just detecting whether two shapes or volumes overlap at one single moment in time, you test for collision between the volumes that the objects create as they move through time (usually from this frame to the next). A sphere moving some distance over time might look like a pill/capsule, for instance. Using this, you can predict exactly what point in time two shapes will collide, and move them to that position. You're basically preventing collision instead of fixing it. It also means that no matter how fast or small your objects are, you will detect any intersections (assuming your floating point numbers don't fail you). If you just look up 'swept circle collision' on google images, you'll see some images that make the concept clearer. Here's an article I found on swept ellipses and spheres: [url="http://www.three14.demon.nl%2Fsweptellipsoid%2FSweptEllipsoid.pdf"]PDF[/url]
  4. [quote name='jdim' timestamp='1295974902' post='4764528'] [code] cir1->y_center += sign(cir1->y_center - cir2->y_center); cir1->x_center += sign(cir1->x_center - cir2->x_center); [/code] These lines move the ball away from the circle it is hitting to make sure it doesn't calculate more than one collision. [/quote] They move the ball away, but as far as I can tell, they only move it away by 1.0f. The circle should be moved such that the distance between the two centers is (c1->m_radius + c2->m_radius). The function sign can only return -1, 0, or 1. Unless the ball happens to overlap by only 1 unit, this is not going to move the ball far enough away to avoid another collision check.
  5. 360 vertexes for a circle [i]is[/i] a lot, but if you only have 10 or so circles on the screen, I don't think it would drag your app to a crawl. This code in the circle-circle collision response function looks suspicious, unless I don't understand it: [code] cir1->y_center += sign(cir1->y_center - cir2->y_center); cir1->x_center += sign(cir1->x_center - cir2->x_center); [/code] It looks like the implementation for sign just returns 0, -1, or 1. If that's true, then you're adjusting the position of your circles by 1 unit during a collision, and basically doing so again and again until there is no collision. That's going to be really slow. Especially since you are reflecting the circle's velocity every time. You should be able to use vector2x & vector2y to adjust the circles so that they are not colliding, in a single step. The same goes for the segment collisions.
  6. [quote name='Burnt_Fyr' timestamp='1295897729' post='4764079'] IIRC Swept volume testing will accurately detect collisions even with fast moving/really small objects. Don't quote me on that however. [/quote] It will, depending on the implementation (is rotation properly swept, for instance). I had thought about that, when I originally posted, but I figured he probably wasn't using swept testing. I was also considering that there may be a problem sweeping over multiple frames, although now that I think about it, I guess that would be doable - just not necessarily as straight forward as single frame sweeping.
  7. I would not recommend skipping collision checks. If you don't check for collisions every frame, you run a greater risk of missing a collision between fast moving objects. How are you detecting collisions? Are your objects 3D or 2D? Typically, the collision test for bounding shapes or volumes is much faster than a polygon or pixel-perfect collision test. It's an easy optimization, and will probably improve your collision detection efficiency a great deal. Additionally, if one of your shapes is a ball, there's probably no reason to use anything except a bounding circle/sphere for that object. i.e. there's probably no reason to additionally test pixel or polygon collisions. You typically want your collision shapes to be as simple as possible (without the simplicity affecting gameplay). It could also be that your collision test is implemented in an inefficient way, but we'd have to see your code to accurately judge that.
  8. I'm not too familiar with python, but a few things stand out: - The line "if else event.key == pygame.K_LEFT" needs to be indented, so that it is under the block for "elif event.type == pygame.KEYDOWN" - Where does colWidth come from? - moving is initialized as a Boolean, but later you assign it a string value. That seems a little strange to me, but maybe that's a python-ism.
  9. When you run the app from Finder, I believe it sets the working directory to "/". You have at least two options: 1) - use c++ code (possibly Mac API calls) to set the current working directory to the directory of the executable, before you load any assets. 2) - wrap the executable inside a .app. This is easy - just create a MyExe.app folder, and move the executable into MyExe.app/Contents/MacOS/. When doubleclicking the .app in finder, the working directory will either be in the same directory of the .app folder, or inside the app, at MyExe.app/Contents/MacOS (I think this depends on whether you've copied resources into MyExe.app/Contents/Resources). You can also just recreate your xcode project as a cocoa application, and it will be built as a .app (it will be bigger, however, because you'll be pulling in the Cocoa framework, among others).
  10. In the project tree, expand the node labled "Executables". There should be an entry for your exectuable there. Double click on it and go to the 'General' tab. At the bottom, you should see an option for setting the working directory when running the executable. Look at that to see where xcode is running the executable from, and make sure it really is running it from where you thought it was. Are you launching your executable from Terminal? Make sure you cd into the Debug directory, then do ./MyExe, as opposed to doing something like ~/MyFolder/Debug/MyExe
  11. You can put the ray in the partitioned space, by assuming that you don't need to test against any part of the ray that falls completely outside of the partitioned space. Basically, one corner of the bounding volume is at the ray start, and the other corner is at the edge of your partitioned space, in the direction of the ray. However, unless your rays are near the edge of your space, and pointing outward, they're going to occupy a LOT of partitioned space, which could defeat the purpose of putting them in there. You can try splitting up your ray into multiple parts, that all point to the same base object. That way, you get decent partitioning, but still get the advantage of having objects know what they're really colliding against. If your ray moves or rotates a lot, however, you'll be updating a lot of components. I don't think rays are typically inserted into partitioned spaces like that. Rather, the test for collisions against a rays are immediate, one-time operations that utilize the space partitioner. You can still treat them as persistent objects, though. I assume the broad phase of the collision test basically gathers what objects could be colliding with what other objects, and only tests those for actual, fine-grained collisions. Rays might just have to be treated specially, in the way their collision candidates are collected. An octree might traverse neighboring nodes, for instance, as it tests for collision along a ray, which is different than the way it would gather collision candidates for bounding spheres, in which it might just add all objects inside the occupied node or its parent nodes.
  12. It's hard to say without knowing what errors you are getting. Also, try putting your code inside [source][/source] tags, as mentioned [url="http://www.gamedev.net/topic/534974-hey-guys-source-tags-are-your-friends-read-this-before-posting-here/"]here[/url], or by using the 'insert code snippet' button on the posting form. As it is, the codie is difficult to read, and there may be syntactical issues that we can not find without proper formatting. In the mean time, without the code formatting, it looks like your "if event.type == KEYDOWN:" statement might be inside of the if block for "if event.type ==QUIT:", which would definitely cause you some problems, but that might just be the forums screwing up the formatting of your text.
  13. You should not have semicolons after your if conditions. if ( plusButtonClicked == true ); should just be if ( plusButtonClicked == true ) For future reference, you should include the error messages that the compiler gives you, the next time you need help. Usually we would need the error messages in order to determine what is actually wrong. I would also suggest looking up the error code on msdn or google (usually the compiler will have some sort of code associated with the error, e.g. C2039), so that you can fully understand why it was considered an error to do what you did. Good luck with your calculator!
  14. What you want is to understand transformations. You basically need to apply a set of transformations on your triangle, in a specific order, to achieve the desired effect. Try reading up on transformation matrices, and how they relate to OpenGL. Here's an article I came across (I don't know how good it is): http://www.songho.ca/opengl/gl_transform.html Determining which order to translate and rotate something is a common problem, and something you should easily be able to google the answer for, if the issue arises.
  15. [quote name='GMA965_X3100' timestamp='1294951303' post='4758478'] Still no luck. Followed your advice. No luck. Do you happen to have a working example of cg setup in a Dev-Cpp file for eg.? [/quote] I do not, sorry. To test the suspicion of incorrect include paths, try changing your #includes to refer to the complete path of the files, e.g.: #include <C:\Program Files\NVIDIA Corporation\Cg\include\Cg\cg.h> Do this for every Cg-related file that you include. If the compiler [i]still [/i]complains about undeclared identifiers, something else must be wrong.