• 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

152 Neutral

About theydidntnameme

  • Rank
  1. I have successfully contacted the author. The ' was simply a harmless typo. 
  2. I'm trying to implement this paper:   https://www.cs.ubc.ca/~van/papers/2013-TOG-MuscleBasedBipeds/2013-TOG-MuscleBasedBipeds.pdf     I'm having a hard time understanding Equation (17), specifically what rk' is and where it came from.   I know that rk is the moment arm (a vector), Pb is a position (vector), jk I think is the position of joint k, and Fb and Tb are vectors calculated by equations (14) and (15). What is rk' though? I don't see any mention of it anywhere in the paper. Some google searches on vector prime notation lead me to believe that a vector with the prime symbol means the vector is tranposed. But I can see the transpose symbol already uses T, so is it really saying that vector rk is tranposed?
  3. I did something similar in Warcraft 3, but with a Bomberman game. That wasn't my first project that involved programming though.   My first project involved creating a heavily scripted map for Medal Of Honor: Allied Assault. In that game you have the map which is created in a level editor, and then you create a level script that goes along with it. I haven't played much of Quake 3, but I'm guessing this is the "Quake C" type stuff that that game had.   My vision was to create a level that was heavily scripted that had you fighting alongside squadmates that weren't cannon fodder. There was a medic in the original game, but I wrote a medic script from scratch that was more customizeable. You could tell the medic who to follow, how many health packs he had to give to others, etc. I eventually wanted to write AI for him to take cover during battles but I never figured that out.   The level that my YouTube video shows isn't the first project I did in MOHAA, but it was the culmination of everything I learned writing scripts for that game. Everything "scripted" that you see in the video is done via the level script. The squadmates following each other, the tank encounter, conversations, truck ride, etc were all done with my level script. A lot of things are broken as you can see, and I eventually gave up when I tried to implement wall climbing at the end.   The scripts involved mainly if statements and for loops. There were also several functions, which were either called with "thread function" which would execute the function in a separate thread, or "waitthread function" which would call the function and block until it returned. I asked LOADS of questions on the Medal Of Honor .Map forums, where the people there were extremely patient and helpful, and taught me a lot about programming (especially the user jv_map, or jvmap, I can't remember the spelling).   This was done in the Summer of 2003, when I was 14 too like Vexal. Then Call Of Duty was announced (by the original developers of MOHAA that went to form their own company) and they took the vision that I had for my map and made a complete game out of it   http://www.youtube.com/watch?v=ra3NLiLYdZg&feature=youtu.be
  4. I would go in a heartbeat too. Living on the frontier is something I always wondered about when I read history books as a child. Everything around us on the planet has been explored... I want to go to a new place and discover new things. I was never one that was dependent on a lot of things in order to live, so I imagine I could live quite well in the limited environment (slow internet, no water etc lol).
  5. It's also easier to write implementations when you can rely on assumptions. If you know an array will have space for exactly 12 elements, you can cater specifically to that, as opposed to an array that could possibly have space for only 1 element, or hundreds. You have less cases to worry about. This could also limit your ability to do certain things, but the reason the limit was chosen in the first place was because it allowed the designers to do what they needed to do. Another example: trying to create the ultimate engine. Most game engines are very specialized. By assuming that a given engine will be used for only FPS games, you can design the program based on these assumptions (e.g. you can't roll the camera upside down when by turning it). Or a multiplayer focused engine, where all logic consists of client/server communications with cheat detection etc since we are under the assumption that we will not be creating singleplayer experiences.
  6. Quote:Your new paddle angle is independent of anything you've done in previous frames, so don't try to shove "current facing angle" into your calculations. atan2(y/x) is the right approach, but it assumes that a rotation of 0 degrees will cause the paddle to face the positive x-axis, and that your rotation isn't backwards. You may need to add a multiple of 90 degrees and/or negate the angle to fix things if those assumptions don't hold. Oh, and make sure that you're using radians where you need radians and degrees where you need degrees. Finally, if you're only using mouse displacement over a single frame, you may run into aliasing effects; in that case, summing displacement over the previous 2-4 frames could give better results. Thanks for the reply. i was using atan all this time which requires y/x already computed (1 argument). i had no idea atan2 existed which is what I needed (giving the angle including negative values of x and y). i used atan2 and it returns angles in the 1st and 2nd quadrants from 0 to 180, and in the 3rd and 4th quadrant from 0 to -180. I fixed that by checking to see if y < 0, and if so, add 360 to the result. actually I should mention atan2 returns everything in radians, i converted this answer to degrees then added 360 to fix the 3rd and 4th quadrant results. another thing that was messing me up is that im using the SDL coordinate system (positive y is going downward, negative y goes up) which was screwing with my calculations. ive fixed this and now its working perfectly. i actually planned from the start to have it set up so that 0 degrees is facing the positive X axis increasing counterclockwise. i have one image of the paddle at 0 degrees (its actually facing 45 degrees but ill fix the image) and when I load the program i used SDL_gfx to rotate it 360 times and store each of the rotations in an array of SDL_Surface *'s :). so in short everything works now and I will look into smoothing the movement over multiple frames in the future. thanks for the help! o and the code below for anyone interested. angle is what the paddle uses to draw the correct paddle image rotation. the image in the array I use is "paddles[angle]" bool Paddle::DoMove(int x, int y) { double angleRad = 0; double angleDeg = 0; //the x and y passed are SDL coordinates. arctan2 // uses cartesian coordinates; y = y*-1; //no mouse movement, do nothing if (x == 0 && y == 0) return false; angleRad = atan2(y, x); angleDeg = angleRad*180/PI; //atan2 reports angles in 3rd and 4th quadrant as negative. fix by adding 360 if (y < 0) angleDeg += 360; angle = angleDeg; return true; }
  7. hi everyone. im trying to make a breakout game in c++/SDL where the paddle is a semi-circle shape (rotating around the center of the screen), and its angle o facing is controlled by moving the mouse in the direction you want it to point to. this allows for 360 degrees of freedom. everything is setup so that every frame all I have to do is calculate the new angle that the paddle should point for that frame. my function to calculate the angle is failing miserably however :) every frame I get the relative mouse position (x, y) that the mouse moved from the last frame, then I warp the mouse back to the center of the screen. I get the correct readings for relative mouse position every frame, and its not affected by warping the mouse back to the center. so basically everything is in place, I have all my data (current paddle's angle, mouse x and y displacement) for each frame, now what I need to do is figure out how to calculate a new angle to move the paddle. how can I do this? my idea is if you set your X axis to the line that is perpendicular to the paddle's current facing (and y axis parallel to the paddle's current facing angle), then the only mouse displacement that will be used for determing how far to rotate the paddle will be that movement which lies on the x axis. I hope that made sense. I spent all day yesterday trying to figure this out and am failing miserably :(. for starters I just tried to set the angle of the paddle each frame to arctan( relativeMouseY / relativeMouseX ) but that doesn't seem to work either, my paddle jumps all over the place. any help is appreciated :)