I would disagree with that statement above. Most programmers want to really simulate parts of their games like they are real world things. Mostly i find this to be a great starting point, but not usualy an end point. There are various reasons for that of course and i am sure i won't cover them all here, at least not in this post. Let me start by talking about one of the most obvious forms of simulation tried in a game, and then i will talk about it's effect on a player etc.
Jumping. Yup something as simple as jumping used to be the number one simulated physics type item. A programmer would start out with the usual gravity ad then input a vertical velocity for making them jump. The issues with this tended to be that in 60fps land that your initial jump would be quite a lot of pixels if you wanted to to jump anything useful. Now lets talk about useful. In games the layout of a level is a very important aspect, and making a real world jump severely restricts what kind of layouts you will see. Just imagine if you will how a platform game level would look if you had to get to the top of the screen, but could only jump about 3 feet at a time. There would have to be a very large number of platforms to jump upon to get to the top of the screen. It could could also be called boring as well as you have to make so many jumps. Oh dang, i forget what point i was working on making as my mind is filling up will all the other issues that this simulation represents. argh!
Also using gravity as a fall mechanic tends to make the falling speed rdiculous and then there are real bad collision isues. So we cap max velocity and know that will fix the issues of collision. It does not then lok like a simulation, as max faling velocity is usually way way less than real world terminal velocity. 60fps was a real handicap, snapshotting movement is always going to be an issue for fast moving objects. Now of course we can say that 30fps is much worse. In a way it is, but in another it is not. Fast moving objects do not realy need a cap of max velocity. The reason is that was can multi-sample the movement and therefore know that collision will still work. This is simply done by making the logical frame happen more often than the physical drawing frame. So by doing a double logical frame then you will get a movement distance of half what it was. The down side to this technique is that it
uses more processing power. One technique added to this in the past was to see how far you had travelled and then know how many movement control/detection logicals to chop it into to make it work accuratley. This again is great, epsecially when you have enough processor power to handle it.
But back to my original isue which is gameplay and desgn. If you restrict the designer to only have a mediocre jump at al times, then you are restricting what the designer can give you as far as challenges. For example if you can only jump a distance of say 5 feet across. Then to make that jump easy should be about a 4 foot gap. To make it hard it should be the maximum. But wth only 5 feet to work with it is hard to make a nice variety. Usually though the design issues become more apparent from the curve/arc of the jump than from the actual distances. The curve of a real jumper is very straight forward and really does not vary much (unless maybe you are an international class athlete). So it is again harder to get variety in gameplay.
Ok, i am done for now saying it is bad to simulate. In fact it is an excellent way to start, but know when you start what kind of layout you realy want. Don't let the simulation control your game. Control the simulation y your gameplay parameters. If you already have a level you want to make a character jump around, then go for it. Then once you have something you are happy with as fare as control and feel. Then go ahead and tweak the level to match what should be a great platform control.
Parting shot.. I do not think i have ever used real gravity for my platform games player control. I have sed it for lots of effects and enemy creatures however. The shaprness of the movement suits them much better.
I hope you fond this interesting, and as usual i invite comments to dicuss this.
Laters
Please check out my Kickstrarter project.Those rewards are coolio.
Wednesday, July 14, 2010
Subscribe to:
Post Comments (Atom)
Posts
Yup. Simulation can be a fine thing, but (other than a couple specialized sub genres) it doesn't make the game. In fact, simulating real world physics accurately usually detracts from gameplay like you said. I like how you touched on gravity. The thing a lot of people don't realize I think is that most games have gravity set quite low. That's because when people think they want real world physics, what they really want is movie physics. I have yet to see a car flip end over end from the explosion of it's gas tank in the real world...
ReplyDeleteAnd jump mechanics, great point on that. Jumping is a gameplay item. Which is why it's ok that even the most simulation based games tend to have exaggerated jumps and other games no jumping at all.
I don't know if I agree with you on the physics step though. Because display framerate doesn't really make a difference to simulation quality, just the physics framerate does. In other words, if you simulate once per display frame at 60Hz or twice per display frame at 30Hz you get the same results. And the processing cost of the two would be nearly identical (as far as the physics goes). Increasing the physics processing frequency does improve collision detection on thin objects though. Beyond 60Hz though, the cost usually takes a big jump, so then a continuous collision model for the fastest moving objects become increasingly attractive.
Yo ED,
ReplyDeleteYeah i never quite explained that right (as usual for me). The 30hz double physics is the same as single pysics pass for 60hz. Or should be close. Sometimes you can take some excellent shortcuts for multiple passes though. Beyond 6 hz you have to see what evironment you are in and see how much continuous collisons models will cost. I know in lua and the environment i am that continuous physics wold be a major burden, and multiple pass style is the way to go for our simple games.
Thanks for the informed comment
Da Voodoochief
Oh yeah, definitely when using Lua. It's always about balance. My favorite part :D. And yeah, there is come good stuff with the double physics step. And a lot of other tricks as well. The interesting bit, is often rendering takes enough time to push ya to 30Hz, and then the double physics step is a great option. And many times a double 60Hz step is around the same speed as a single 30Hz (depending on system and data) because there's less corner work and inter-penetration to solve through. So it's very much a worthwhile technique to review.
ReplyDeleteOne thing I think a lot of gamers misunderstand is that they think making 60Hz is just a better engine or some such. In reality it's a balance that studios choose to take or not. With current hardware, sure, anyone could run at 60Hz, but that always comes at a trade-off. Because you can always use the extra processing time of a move to 30Hz to make other improvements, most often increasing the display quality like more polys or better post effects, but it could just as easily be better physics or more particles. A more efficient code base just gives you more quality points to spend on the features you want.