• 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

401 Neutral

About K_J_M

  • Rank
  1. Hi Acharis. I downloaded your game and gave it a whirl. And i really like this. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Everything ran smoothly and was really easy to pick up and play without instructions. The only thing i felt was lacking was the sound effects and possibly some music to help generate some more atmosphere. I contemplated writing something similar a while ago, more along the lines of the 'Ishar' games but instead decided against the step movement idea. But it works really well in your game. I can see this working really well on mobile devices. Might be worth considering porting it to mobiles when you've finished the PC version. The graphics have a real old school charm about them. Keep up the good work. KJM
  2. Hi. For my Autocross Racing game i used lateral Pacejka coeficients similar to this curve. [img]http://www.trinosis.com/files/lateral_pacejka_curve.jpg[/img] This gives a very forgiving tire with a lot of grip at all slip angles. I noticed in your second video that your car reaches a maximum slip angle before it loses grip and spins around. This is classic of a Pacejka curve that peaks at a small slip angle. once past this peak, the tire has no grip and the car spins around. Altering your Pacejka curve so it looks similar to mine above should help prevent this and allow for drifting. You should be able to get variable car handling from using different curves. The Racer sim for instance uses different coefficients for front and rear tires. But specifically for my game, i just rotate the cars velocity vector by the lateral Pacejka force to give that arcade drifting feel. It's not physically accurate in any way and i did have to tune various attributes to get the correct feel i was after. In theory, a physically accurate sim should be able to produce a wide range of handling for a car from an arcade drift feel to a simulation mode, by altering such things as the Pacejka curves, engine power, gear ratio's ect. But in practice creating an accurate sim is going take a long time to do (particularly because theres very little information available on the subject), so it comes down to priorities. If your priorities are to get an arcade game written as quickly as possible then i see no reason in hacking together an arcade sim, which is exactly what i did for my game. If on the other hand you want to write a physically accurate sim and then use that as a basis for games, then it will take a long time to get right. You could use a third party car physics engine and i know some general purpose physics engines support wheel physics and suspension constraints (Newton physics engine for example) , so that may be an easier route for you.
  3. " I would argue with that. In your post #6, the blue arrow IS the real velocity of the tyre, which is perpendicular to the vector from CG to wheel pos, but not to the wheel's heading. So it WILL generate both long/lat forces. If you do the same calculations for the remaining 3 wheels the sum of all Fx's will be zero if the CG is at the center of the car, so that's why there is no movement of the car body. " Thanks for the explanation Bmarci. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] I see there were flaws in my understanding. I was assuming that a stationary car spinning on the spot has zero linear velocities and as a result no slip angles could be generated. But in fact, you show that although the car chassis has no linear velocites, the wheels actually do and therefore the slip angles can be calculated whilst ignoring the angular velocity of the chassis. Sorry for any confusion pochypoch.
  4. Thanks for the comments. Both Long and Lat Pacejka formulas need FZ (load) as one of the inputs. And a resulting force as output. The traction circle caps the forces to a maximum limit. I think the Racer sim reduces Longitude forces in favour of Lateral as a way to cap the forces. But there are several different methods that i've seen. Since the traction circle limits forces, and these are calculated from Pacejka which requires FZ (load) as an input, the traction circle caclulations are applied after the forces have been calculated.
  5. Hi. The Pacejka formula's work in wheel local coordinates. Longtitude pointing in the direction the wheel rolls in and Lateral at 90 degrees to Longtitude direction. So,as i understand it, Case 1 Example is correct. Although i'm no expert, i always understood that a stationary car spinning on the spot with the steering centred produces no longtitude forces from the tires to move the car forwards or backwards. But only lateral forces to slow down the rate of spin. But, maybe someone with more detailed knowledge than me can give a more accurate explanation.
  6. It seems to me you are looking at the issue with regards to world coordinates. If you look at the issue with regards to local car coordinates then each wheel has 0 longtitude velocity and (N) Lateral velocity if the car is spinning on the spot. Marco Monsters car physics tutorial performs the world to local coordinates transform by rotating the linear world velocities by the yaw angle of the car / wheel. s = Sin(yaw_angle) c = Cos(yaw_angle) local_lateral_velocity = (world_x_velocity * c) + (world_z_velocity * s) local_longitude_velocity = (world_x_velocity * -s) + (world_z_velocity * c) And to transform back from local to world coordinates. ( Note the sign for the sine command is reversed, which reverses the direction of rotation ) world_x_linear_velocity = (local_lateral_velocity * c) + (local_longitude_velocity * -s) world_z_linear_velocity = (local_lateral_velocity *s) + (local_longitude_velocity * c) But in regards to a stationary car spinning on it's axis the lateral wheel velocity is derived from the car angular velocity.
  7. Hello PochyPoch. I havn't read all of your post but a quick glance brought me to question 4. To clarify Part 4. If the car is stationary and spining on it's axis, and the front wheels arn't turned to any steering angle (yaw) but pointing in the direction the chassis points, then each wheel generates +- 90 degrees slip angle. The wheels only have lateral movement. ie they are only sliding sideways as the car spins. The sign of the slip angle depends on whether the car is spinning clockwise or anti clockwise. My statement about not generating slip angles was because the car is stationary and no slip angles are generated from the code that uses linear velocities of the car chassis to determine the slip angles. My basic method was using 1 wheel (chassis) to determine the slip angles and Bmarci was using 4 wheels. Slip angles are generated by the difference between the longitude and lateral velocities of the tire. The confusion comes from the fact that i was using the car chassis to determine the slip angle and not for each tire. So when writing your sim, you need to take into consideration the angular velocity of the car and the slip angle that generates for each wheel and the linear velocities of the wheel (chassis , since the wheel is attached to the chassis). The car can be moving with no angular velocity (moving forwards or sliding sideways), stationary but spinning on it's axis or any combination of the two. And both situations need to be considered to determine your actual slip angle for each wheel. The steering angle of the front wheels also needs to be taken into consideration for the front wheels slip angle. Hope thats clearer. And best of luck with your game. I too have made a top down racer. [url="http://www.trinosis.com/"]http://www.trinosis.com/[/url]
  8. Hey, thats great. Congrats on getting it working. Glad i could help. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
  9. Ok, from what you've written then, it seems the problem might lie with the forces acting against the wheels from the angular velocity of the car. If we assume your car is stationary and points at 12 o clock with the front wheels centred, but is spinning on it's axis (yaw) then the wheels generate 0 slip angle because there is no long or lat linear velocities of the car. But there will be friction against the wheels as the car spins, acting in the opposite direction to the movement of the wheel. I ended up just using a constant friction value applied to the angular velocity of the car at each update. I don't think the force acting against the wheels changes much if at all but i wasn't able to find a definitve answer to this question and so just ended up using a constant friction force. You could use Pacejka to return a force with a slip angle of 90 degrees ( 1/2 * Pi Radians ) for all wheels to slow down the angular velocity of the car or apply a constant as i do. Using Pacejka seperately for the front and rear wheels makes sense because if the front wheels are turned you can call Pacejka with a different slip angle. For the front wheels pointing straight ahead the slip angle would be 90 degrees as the car spins, and if turned 90 degrees the slip angle would be 0.
  10. I get slightly different slip angles in my demo. 12..3 -> slip 0 to -90 degrees 3..6 -> slip +90 to 0 6..9 -> slip 0 to -90 9..12 -> slip 90 to 0 The important thing is that your 12 - 3 and 9 - 12 slip angles have different signs for going forwards and 3 - 6 and 6 - 9 have different signs for going backwards. So, Lateral Pacejka will return the correct signed force for skidding left and right. I have different signs when the car spins past 90 degrees and starts going backwards. But i wouldnt worry about that until you get it working correctly going forwards. Just to state the obvious, you are working in Degrees and not Radians, and not getting them confused ? I would still reduce your code further to simulate what i do in my demo, with one wheel. Since your still having problems. Once thats working as it should, then implement 2 wheels and when that works go to 4. Also make the load and camber on the wheels constant, at this stage to simplyfy things as much as possible. Could you upload a demo, so i could get a look at what's actually happening. Or a short video perhaps. I don't understand these two lines Fx=slip_ratio*0.25*Fz Fy=slip_angle*0.1*Fz To cap the forces to a traction circle / elipse you just normalise each and then multiply by a maximum length, if they exceed a maximum force. You treat both as a 2d direction vector. Also remember that Fz is used in the Pacejka equations. So i don't know why you're using it in those two lines. Just remove those two lines from your code and see what happens. Pacejka expects slip angles from -90 to +90, load (Fz) and camber as inputs and outputs FY as force.
  11. Hi Catmull Dog. Yes, i totally agree with you. Theres nothing worse than having to re invent the wheel. I'm really suprised i havn't been able to find an already established algorithm for solving this problem. But if i find one, i'll definately share it with the community.
  12. Hi. "I plotted my pacejka curves and they seem to be good. I implemented Brian Bechman's version and compared to the Racer's source they produce very similar results." Yes, i've had a look at Brian Beckmans Physics Of Racing Series too. His alternate Pacejka curve formula produces similar curves to Pacejka, but they don't take into account load and camber if i remember correctly. Which are essential for a realistic sim, for load transfer when cornering for instance. As the loads on the tires change. That /400 seems to be an "ugly" hack Yes, i ddn't use real world values in the demo. Theres no calculations using Newtons for force ect. It's just a basic implementation to get the basic sim working. Your Torque theory sounds right to me. Here's a paragraph from my "Physics For Game Developers" book on Torque. "Force is what causes linear acceleration, while torque is that which causes rotational acceleration. Torque is force times distance. Specifically, to calculate the torque applied by a force acting on an object, you need to calculate the perpendicular distance from the axis of rotation to the line of action of the force and then multiply this distance by the magnitude of the force. This calculation gives the magnitude of the torque. "
  13. Hi. I'm affraid i don't have a solution for you, but since no one yet has replied to you, i thought i'd share my experiences. I recognise some of Marco Monsters formula's in your code. I remember implementing his tutorial some years ago and found that his algorithms produced a very unstable and jittery car, especially at low speeds. I would reccomend stripping back your code to treat the car body as one wheel and get that moving and turning correctly. Then add in your longitude and engine calculations. There is also the issue of the traction circle / elipse. Which constrains the longitude and lateral forces so they don't exceed their specified limits. I'm not sure if this is an issue for you or not. I have a simplified Lateral Pacejka demo i could upload for you to have a look at, including the source. This treats the car as 1 wheel and might help you to see where your problem lies. Windows Demo here. 1.5mb [url="http://www.trinosis.com/files/lateral_pacejka_car_physics_demo.zip"]http://www.trinosis.com/files/lateral_pacejka_car_physics_demo.zip[/url]
  14. For anyone thats interested i've created a small demo with source code demonstrating the intersection method described in my third post here. 655k. Windows only. [url="http://www.trinosis.com/files/line_to_catmul_rom_spline_intersection_demo.zip"]http://www.trinosis.com/files/line_to_catmul_rom_spline_intersection_demo.zip[/url]
  15. Heres what i have so far. The code might serve to help others. But it's not working correctly and the root returned isn't correct. The terms a0,a1,a2,a3, b0,b1,b2,b3 are what i've found from google searches, i think they are correct for a Catmull Rom spline, but i'm not sure. \\ Spline Control Points \\ p0x# \\ p0y# \\ p1x# \\ p1y# \\ p2x# \\ p2y# \\ p3x# \\ p3y# t# = 0.5 spline_x_pos# = 0.5 * ((2 * p1x#) + (p2x# - p0x#) * t# + (2 * p0x# - 5 * p1x# + 4 * p2x# - p3x#) * t# * t# + (3 * p1x# + p3x# - p0x# - 3 * p2x#) * t# * t# * t#) spline_y_pos# = 0.5 * ((2 * p1y#) + (p2y# - p0y#) * t# + (2 * p0y# - 5 * p1y# + 4 * p2y# - p3y#) * t# * t# + (3 * p1y# + p3y# - p0y# - 3 * p2y#) * t# * t# * t#) A# = (line_point_1_y# - line_point_2_y#) * spline_x_pos# B# = (line_point_2_x# - line_point_1_x#) * spline_y_pos# a0# = -0.5 * p0x# + 1.5 * p1x# - 1.5 * p2x# + 0.5 * p3x# a1# = p0x# - 2.5 * p1x# + 2 * p2x# - 0.5 * p3x# a2# = -0.5 * p0x# + 0.5 * p2x# a3# = p1x# b0# = -0.5 * p0y# + 1.5 * p1y# - 1.5 * p2y# + 0.5 * p3y# b1# = p0y# - 2.5 * p1y# + 2 * p2y# - 0.5 * p3y# b2# = -0.5 * p0y# + 0.5 * p2y# b3# = p1y# c0# = (A# * a0#) + (B# * b0#) c1# = (A# * a1#) + (B# * b1#) c2# = (A# * a2#) + (B# * b2#) c3# = (A# * a3#) + (B# * b3#) root# = ((c3# * t#) ^ 3) + ((c2# * t#) ^ 2) + (c1# * t#) + c0# And heres my previous code which does return a correct root. t# = 0.5 spline_x_pos# = 0.5 * ((2 * p1x#) + (p2x# - p0x#) * t# + (2 * p0x# - 5 * p1x# + 4 * p2x# - p3x#) * t# * t# + (3 * p1x# + p3x# - p0x# - 3 * p2x#) * t# * t# * t#) spline_y_pos# = 0.5 * ((2 * p1y#) + (p2y# - p0y#) * t# + (2 * p0y# - 5 * p1y# + 4 * p2y# - p3y#) * t# * t# + (3 * p1y# + p3y# - p0y# - 3 * p2y#) * t# * t# * t#) temp_1# = (line_point_1_y# - line_point_2_y#) * spline_x_pos# temp_2# = (line_point_2_x# - line_point_1_x#) * spline_y_pos# temp_3# = ((line_point_1_x# * line_point_2_y#) - (line_point_2_x# * line_point_1_y#)) root# = temp_1# + temp_2# + temp_3#